PowerCLI is the best tool for automating management and configuration of VMware vSphere

Post navigation

Spotlight on the Move-VM Cmdlet including PowerCLI 6.5 Enhancements

VMware PowerCLI 6.5’s release introduced a lot of new cmdlets and improvements to existing cmdlets. One of my favorite improved cmdlets has to be Move-VM. Move-VM was already a very versatile cmdlet before this new release. It could be used to move a VM between hosts, datastores, resource pools, clusters, to new folders, to a vApp, and so forth. Now, with PowerCLI 6.5 R1, Move-VM can move VMs between vCenters! We can even take that a step further, Move-VM can move VMs to vCenters which are not linked together by SSO domain. That’s something that cannot be done by the web client!

Let’s start by taking a look at the newest addition to the cmdlet, migrating VMs between vCenters.

Cross vCenter vMotion

Cross vCenter vMotion was introduced with vSphere 6.0. It’s proved to be a great feature that opens up new options in flexibly managing a vSphere environment. One of the limitations in using cross vCenter vMotion by way of the Web Client is that it can’t migrate VMs between SSO domains. This is where the usage of PowerCLI is hugely beneficial because PowerCLI allows users to fill that gap. The key to PowerCLI being able to overcome that limitation is due to its ability to connect to multiple vCenter servers at the same time.

In order to perform a cross vCenter vMotion, there are a couple parameters that are needed:

Multiple NIC VM vMotion

If you look at the example code above, specifically at the network pieces, you’ll notice that it only focuses on moving a VM with a single NIC. However, both the NetworkAdapter and PortGroup parameters accept arrays. This means that you can pass multiple objects to those parameters.

One key thing to note is that the first item in each array will be referenced together, then the second items will be referenced together, and so on and so forth. If there are multiple network adapters and only one portgroup specified, the network adapters will all be assigned to the same portgroup. If there is only a single network adapter and multiple portgroups specified, the command will error out.

Here’s an example of doing a Cross vCenter vMotion on a VM that has multiple NICs:

Conclusion

The above examples are just the tip of showing just how versatile the Move-VM cmdlet really is. Let us know how you’re using Move-VM in your environment in the comments below!

About Kyle Ruddy

Kyle Ruddy is a Senior Technical Marketing Architect working for VMware R&D in the Cloud Platform Business Unit. Kyle currently focuses on vSphere and VMware Cloud on AWS automation and the associated automation frameworks including all things API, CLI, and SDK. Kyle is also a Microsoft MVP and long-term vExpert whom can be found blogging on VMware blogs, http://blogs.vmware.com/vSphere and http://blogs.vmware.com/PowerCLI, and his personal blog, https://www.kmruddy.com. His Twitter: @kmruddy

From everything I’m reading this should allow me to move VMs between any vCenter running 6.0 or above, however it errors out for me when I try to move a VM from vCenter 6.5 yo vCenter 6 (Update 2). Is this a bug or intended behavior?

How do you keep the same datastore that the VM is on when doing cross vCenter migrations? I have VMs that won’t move in the Web UI due to having multiple VMDKs on multiple datastores due to performance policies like SQL. How do you get around this to keep them on the same shared datastore? I already have moved some hosts to the new VC so each host has the same datastore connections that the ones in the old VC have. I need to get my last 2 hosts moved over to the new VC.

Hi!
I have made a Powershell gui to migrate VMs. When I migrate VMs between vCenters on the same layer 2 network it works perfect. But I get this error message when migrating VMs between vCenters (and ESXi hosts) on different routed LANs (and locations). It is probably due to a firewall.

What ports are required to be opened for it to work?

The VMware support told me TCP port 8000 is required, but is that really correct?

Beware that apparently Move-VM requres TLS 1.0 enabled on the destination VCSA at least. External PSC, should you have one, can still have TLS 1.0 disabled. That is a major, major disappointment since there is no any TLS related prerequisites for Move-VM cmdlet.

I spent tons of time troubleshooting why the cross-vMotion process was failing with “Move-VM The operation for the entity “” failed with the following message: “Authenticity of the host’s SSL certificate is not verified.”” error. And it turned out it happened because of the hardened VCSA which had TLS 1.2 enabled only.

Another issue which might need to be addressed in next releases. If the VM got moved in online state across non-federated instances, but kept on the same datastore when the source and destination hosts have the same LUN presented (that is just the VM system state gets moved over) it causes the situation when Storage Usage value (or $_.UsedSpaceGB in PowerCLI) will show up as 0.00B whereas the VM has all its virtual disks information displayed correctly. vMotion or storage vMotion do not address the issue. To fix it the VM needs to be either powered off or suspended then the actual VM Storage Usage value displayed properly on in a new vCenter inventory.

Live migration between vCenters by code has been available since 6.0. The code above works and does allow you to specify the portgroup on the new distributed switch. (Line 8 is how you obtain the portgroup from the destination vCenter)

Hi – anyone used this approach to move a VCSA (6.0 Update 3) from it’s own VSphere environment into a separate one?

We have an Atlantis USX Hyperscale deployment with 8 ESXi hosts, used for Horizon View. As part of the deployment, it puts the VCSA on the infrastructure the VCSA is managing, on one of the hosts local storage. I’d like to move the VCSA VM onto a separate VSphere instance (6.5) and trying to work out the best approach.

Are you aware if performing a cross center vMotion can just migrate the compute if the datastore is NFS and its the same path on both vCenters? Currently when we’re trying to do the cross vCenter vMotions its migrating the storage as well which is slowing down the migrations.

There’s two main options to achieve multiple migrations at the same time:
Option 1 – Use the ‘RunAsync’ parameter
Using the ‘RunAsync’ parameter will fire off each of the commands without waiting for the vMotion to complete. This, essentially, allows vCenter to handle the management of the vMotions and is quite comparable to selecting multiple VMs in the vSphere Client and performing a vMotion. One caveat, there’s not a lot of “tuning” that can be performed. (eg. you can’t control how many vMotions are being performed at once)

Option 2 – Use PowerShell’s built in parallel processing
There are a couple method to start new PowerShell processes to run multiple commands at a time. This option would allow the person performing the vMotions to control how many vMotions are being done at a single time. However, this too has its own caveats. One example of which, each new process is created as a brand new process. Therefore you would need to pass through authentication information as well as all the parameters to perform the task.