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:

• Active Connection to both Source and Destination vCenters
• Source vCenter
  • VM
  • VM’s Network Adapter/s
• Destination vCenter
  • Destination ESXi Host
  • Destination Datastore
  • Destination PortGroup/s

Here’s some example code on how that can be accomplished:

I also want to filling in a couple informative gaps in the above code:

• Due to the cross vCenter vMotion functionality being added in as part of vSphere 6.0, it can only be performed against vCenter servers of 6.0 and newer.
• The destination parameter only accepts an individual ESXi host. A workaround could look like the following code:
  
  $destination = Get-Cluster –Name Cluster01 –Server $destVCConn | Get-VMHost | Select-Object –First 1

  1	$destination = Get-Cluster –Name Cluster01 –Server $destVCConn | Get-VMHost | Select-Object –First 1

• The datastore parameter only accepts an individual datastore. A workaround could look like the following code:
  
  $destinationDatastore = Get-DatastoreCluster –Name DSCluster01 –Server $destVCConn | Get-Datastore | Sort-Object -Property FreeSpaceGB -Descending | Select-Object -First 1

  1	$destinationDatastore = Get-DatastoreCluster –Name DSCluster01 –Server $destVCConn | Get-Datastore | Sort-Object -Property FreeSpaceGB -Descending | Select-Object -First 1

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!

For more information on its use in your environment, see the PowerCLI cmdlet reference on Move-VM.