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:
|
1 2 3 4 5 6 7 8 9 10 11 |
$sourceVCConn = Connect-VIServer -Server $sourceVC -user $sourceVCUsername -password $sourceVCPassword $destVCConn = Connect-VIServer -Server $destVC -user $destVCUsername -password $destVCpassword $vm = Get-VM $vmname -Server $sourceVCConn $networkAdapter = Get-NetworkAdapter -VM $vm -Server $sourceVCConn $destination = Get-VMHost -Server $destVCConn $destinationPortGroup = Get-VDPortgroup -VDSwitch $switchname -Name VM-Network1 -Server $destVCConn $destinationDatastore = Get-Datastore $datastorename -Server $destVCConn Move-VM -VM $vm -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore |
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:
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:
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.
Great stuff. 2 questions.
1.) Moving VMs across vcenters, does the source and destination ESX hosts have to be able to communicate? Or does only vCenters need to be able to communicate over network to move a VM.
2.) Is it possible to copy/clone a VM to a different vcenter with PowerCLI?
Thanks.
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?
That is not as intended. However there are several reasons that may occur due to some items not being backwards compatible (such as hardware versions, distributed port group versions, etc.).
I’ll follow up via email to see what the error is.
I got this error message:
The operation for the entity “VM-Name failed with the following message: “vMotion is not licensed for the Source host
Both Source and Dest. vCenter are latest 6.0
Both Source and Dest ESXi Host are 5.5 with E+ license
MFG
Christian
Great article, i understood each and everything about what you said in this article but Is it possible to copy/clone a VM to a different vcenter with PowerCLI?
Do you drop any pings while vmotioning between sso domains?
Does the move-vm command work in the reverse scenario of moving a VM from a vCenter 6.5 to 6.0?
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.
I have a question.
So I am using a variation of this script.
I am getting this error
Move-VM : 7/24/2017 3:09:54 PM Move-VM The operation for the entity “testvm” failed with the following message: “Network interface ‘Network adapter 1’ uses
network ‘DVSwitch: 50 3a a8 89 2a a5 0f 01-2b aa 10 48 7c 56 09 b4’, which is not accessible.”
At \Untitled3.ps1:27 char:1
+ Move-VM -VM $vm -Destination $destination -NetworkAdapter $networkAdapter -PortG …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Move-VM], CannotAccessNetwork
+ FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpdates_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.MoveVM
The Key for dvswitch is for the destination vcenter.
Jeremy: Would you mind posting this as a question in the PowerCLI VMTN communities? https://communities.vmware.com/community/vmtn/automationtools/powercli/
When you do, could you post the full command line and variable values you’re using?
Thanks!
Sounds like you may be hitting the below issue: “In vSphere 6.0 Update 2, there is a known limitation which prevents a VM that has multiple VMDKs stored across different datastores to be xVC-vMotion (compute only) using the vSphere Web Client. This limitation no longer exists in vSphere 6.0 Update 3”.
Found on: http://www.virtuallyghetto.com/2016/05/automating-cross-vcenter-vmotion-xvc-vmotion-between-the-same-different-sso-domain.html
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?
I get this error message:
ERROR: 2017-09-28 15:27:59 Move-VM The operation for the entity “vm-rull-tes
ERROR: t-xyz” failed with the following message: “A general system error occurred:
ERROR: Host not found (authoritative)” ERROR: At line:1743 char:1
ERROR: + Main ($CommandLine)
ERROR: + ~~~~~~~~~~~~~~~~~~~
ERROR: + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
ERROR: + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException
ERROR:
Thanks!
instead of using first host in target environment $destination = Get-Cluster –Name Cluster01 –Server $destVCConn | Get-VMHost | Select-Object –First 1
it is better to use the following workaround:
$destination = Get-Cluster –Name Cluster01 –Server $destVCConn get-vmhost | ?{$_.ConnectionState -eq “Connected”}| get-random
This will allow to choose the hosts not in maintenance mode and distribute the traffic evenly across different hosts if you run few vMotions in parallel.
When i run the script, the migration fails at 39% with the error below
‘failed to migrate’ Cannot connect to host’
Quite strange since I have authenticated to both vCenter servers with full permissions
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.
Hello Guys,
I am receiving the following error when I am trying to migrate a VM from one vCenter to Another.
PowerCLI C:\> Move-VM -VM $vm -Destination $destination -NetworkAdapter $network
Adapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore
Move-VM : 2/9/2018 3:19:23 PM Move-VM The operation for the entity
“ETLABVLLSOFTNAS” failed with the following message: “A general system error
occurred: Not initialized”
At line:1 char:1
+ Move-VM -VM $vm -Destination $destination -NetworkAdapter $networkAdapter
-PortG …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : NotSpecified: (:) [Move-VM], SystemError
+ FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpda
tes_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.MoveVM
Move-VM : 2/9/2018 3:19:23 PM Move-VM 2/9/2018 3:19:23 PM Move-VM
The operation for the entity “ETLABVLLSOFTNAS” failed with the
following message: “A general system error occurred: Not initialized”
At line:1 char:1
+ Move-VM -VM $vm -Destination $destination -NetworkAdapter $networkAdapter
-PortG …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : NotSpecified: (:) [Move-VM], SystemError
+ FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpda
tes_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.MoveVM
Can you tell me a hints where to look?
The error is to vague
Thanks
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.
That’s all is great but live migration between datacenters is not possible.
And another way – relocate vm is also not useful: there are no way to specify portgroup on new dvswitch…
So while operation is possible via web gui – there is no way to automate it…
🙁
What are you basing that information off of?
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.
Hi Team ,
I have tested this script & it works as expected. However , is there a way to trigger migration of multiple VM’s and we can trigger this script for a batch of VM’s
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.
Hi, Struggling with same issue as Martin Teruel on feb9, any solution found for it?
Similar issues can be found from https://communities.vmware.com/message/2787163#2787163
The destination parameter only accepts an individual ESXi host – i khowed it