Cross vCenter VM Mobility Fling – macOS?

The VMware Cross vCenter VM Mobility – CLI was recently updated so I decided to try it out. In short, this little Java based application allows you to easily move or clone VMs between disparate vCenter environments.

The Fling is listed with the following requirements:

  • JDK 1.7 or above
  • Two vCenter instances with ESX 6.0
  • Windows : Windows Server 2003 or above
  • Linux : RHEL 7.x or above, Ubuntu 11.04 or above

There is no mention of macOS there, but I decided to give it a go any way, and it turns out that it works just fine on macOS as well!
Just make sure you have the Java JDK installed locally. When I ran it the first time, I got the following error, since the JAVA_HOME environment variable was not set.

~/Downloads/xvc-mobility-cli_1.2$ sh
set JAVA_HOME to continue the operation

This is very easy to fix, just run the following command in your terminal of choice, and should work just fine on your Mac.

export JAVA_HOME=$(/usr/libexec/java_home)

Next up is running the fling with the correct parameters (this is a clone operation, not a relocate):

~/Downloads/xvc-mobility-cli_1.2$ sh -svc [source-vcenter] -su [source-vcenter-username]
-dvc [destination-vcenter] -du [destination-vcenter-username]
-vms [vm-name] -dh [destination-host]
-dds [destination-datastore] -op clone -cln [destination-vm-name]
13:41:40.591 [main] INFO com.vmware.sdkclient.vim.Task - CloneVM_Task | State = SUCCESS | Error = null | Result =
13:41:40.597 [main] INFO com.vmware.sdkclient.vim.Task - Monitor task end
13:41:40.597 [main] INFO com.vmware.sdkclient.vim.Task - CloneVM_Task took : 0:51:33.728
13:41:40.603 [main] INFO c.v.s.helpers.CrossVcProvHelper - Successfully cloned the vm:[destination-vm-name]

I was able to clone a VM from my lab in Bergen to my lab in Oslo, without any problems what-so-ever. Not only is that a Cross vCenter vMotion, but also a Cross Country one, awesome!

Now this is just an example, please check the official documentation for all the parameters, and what the tool expects.

VMware vSphere 6.5 PSOD: GP Exception 13

While at a customer site, migrating an old vSphere 5.5 environment to 6.5, several hosts suddenly crashed with a PSOD during the migration. Long story short, we got hit by this: VMware KB 2147958: ESXi 6.5 host fails with PSOD: GP Exception 13 in multiple VMM world at VmAnon_AllocVmmPages (2147958)

It turned out that a bunch of the VMs we were vMotioning from the old environment had the cpuid.corePerSocket advanced setting set in the .vmx file, and this can cause ESXi 6.5 to enter a state of panic, and in our case it certainly did.

Upgrading the hosts to 6.5a, like the knowledgebase article states, alleviated the issue and we did not experience PSOD’s again while migrating the 100+ VMs from the old environment to the new one.

ESXi Snapshot Problems: msg.snapshot.error-QUIESCINGERROR

Photo by Sonja Langford

Just a quick post about something I experienced at a client, with ESXi 6.0 hosts, today:

If you have trouble performing VMware snapshots, and see a  msg.snapshot.error-QUIESCINGERROR error, check the host time settings and NTP.

In this case, snapshots of VMs located on other hosts in the cluster were fine, but once a VM was moved to the new host, snapshot operations failed after an hour or so.

It turns out a new host in the cluster was not properly set up to use NTP, and time drift between the host and the vCenter caused the snapshot failures. Correcting the time on the host and configuring NTP resolved the issue.

Always remember: If the problem isn’t DNS, it almost certainly is NTP.