WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

When to use Move-VM cmdlet vs xMove.ps1 script for performing Cross vCenter vMotions?

10.26.2017 by William Lam // 11 Comments

Since publishing my Automating Cross vCenter vMotion between the same and different SSO Domain article back in early 2016, I have had a large number of customers reach out to me and share their success stories of allowing them to perform datacenter migrations to consolidating vCenter Servers all due to this awesome capability that was introduced in vSphere 6.0. In fact, many of the VM migration numbers were in the 4,000 to 8,000+ range which completely blew me away. It was great to hear from customers on how the xMoveVM.ps1 script had enabled them to do things that was simply not possible before, especially without impacting their workloads.

I still get pinged on a regular basis from customers about using my script and one thing that surprises many customers when I mention to them that this functionality has already been ported over to the native Move-VM cmdlet that was introduced with the PowerCLI 6.5 release. This had always been my original intention to provide an example using our vSphere API and enabling our customers in the short term and working with Alan Renouf and the PowerCLI team to get this folded back into the official PowerCLI cmdlets. This means, you no longer have to use my script for basic Cross vCenter vMotions whether that is between the same or different SSO Domain, which is quite nice as the number of user inputs is significantly reduced by using Move-VM cmdlet.

UPDATE (01/01/2018) - One additional option is the recently released Cross vCenter vMotion Utility Fling. For more details, please have a look at the blog post here.

Lets take a look at an example below where I have a VM called TestVM-1 which is residing in vcenter65-1 and I want to vMotion it to vcenter65-3:


With just 5 simple and easy to read lines of PowerCLI, you can perform this operation:

[Read more...]

Categories // Automation, PowerCLI, vSphere Tags // Cross vMotion, ExVC-vMotion, Move-VM, PowerCLI, vSphere 6.0, vSphere 6.5, vSphere API, xVC-vMotion

Uniquely identifying VMs in vSphere Part 3: Enhanced Linked Mode & Cross VC-vMotion

07.11.2017 by William Lam // 7 Comments

Back in 2012, I had published two articles which provides details and guidance on how to uniquely identify a Virtual Machine for both a vSphere and/or vCloud Director environment. The primary use case for this information was for customers or partners who have developed their own provisioning solution which requires them to track their VM assets throughout their lifecycle, usually in some sort of configuration management database (CMDB).

  • Uniquely Identifying Virtual Machines in vSphere and vCloud Part 1: Overview
  • Uniquely Identifying Virtual Machines in vSphere and vCloud Part 2: Technical

Although these articles are almost 5 years old, the content is still very relevant today and I still continue to reference them both with customers, partners and even some of our internal R&D folks. Most recently, I had a question about whether the guidance in these article were still applicable or whether they would be impacted by some of the new VMware technologies and capabilities that had been introduced since writing those articles such as Enhanced Linked Mode (ELM) and Cross vCenter vMotion (xVC-vMotion).

[Read more...]

Categories // Automation, PowerCLI, vSphere Tags // Cross vMotion, Enhanced Linked Mode, ExVC-vMotion, instanceUUID, managed object reference, moref, PowerCLI, vSphere API, xVC-vMotion

Cross vCenter Server operations (clone / migrate) between versions of vSphere 6.x

02.27.2017 by William Lam // 7 Comments

When cross vCenter Server operations such as clone and migrate was first introduced in vSphere 6.0, it required that both the source and destination vCenter Server (includes ESXi hosts) to be running the same vSphere version. With the release of vSphere 6.5, this base requirement still holds true (e.g. vSphere 6.5 for both source and destination), especially when performing these operations using the vSphere Web Client where mixed-vSphere versions is not supported outside of a rolling upgrade.

Having said that, it is possible and supported to clone or migrate a VM across different versions of vSphere 6.x, for example a vSphere 6.5 and a vSphere 6.0 Update 3 environment. This can be accomplished by performing a xVC-vMotion or xVC-Clone operation using the vSphere API. For the the xVC-vMotion use case, I have extensively written about it here and here and with PowerCLI 6.5r1, the Move-VM cmdlet has even been updated based on my feedback to support this capability natively. Furthermore, you can even perform these operations across completely different vCenter Single Sign-On Domains, which enables a new level of mobility for your VMs and access to resources of independently deployed vCenter Server instances.

UPDATE (11/01/17) - The following VMware KB 2106952 has just been updated to reflect what is officially supported in terms of Cross vCenter Operations ( Clone / Migrate) across different versions of vSphere. The matrix in the KB reflects what has been tested by Engineering and one thing you may notice is that Cross vCenter vMotion/Clone from vSphere 6.x to vSphere 6.5 is only supported when running at least vSphere 6.0 Update 3. After speaking with the PM, the reason for this change is that pre-vSphere 6.0 Update 3, there were no pre-checks in the code to prevent Cross vCenter Operations for un-supported target hosts such as ESXi 5.5, which could lead to poor user experience as well as undefined failure scenarios. In addition, vSphere 6.0 Update 3 also includes additional enhancements to properly clean up failed provisioning operations which will make Cross vCenter Operations much more robust. Due to these reasons, though it is possible to perform Cross vCenter vMotion from earlier versions, it will not be officially supported. I have also updated my summarized table below to reflect what is in the VMware KB, but please use the KB as your official source of truth for what VMware supports.

To help make sense of the different combinations of vMotions and cloning operations, below are a few tables to help outline what is possible and supported today.

vMotion

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported N/A
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Cold Migrate

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported API
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5 Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Clone

Source vCenter Server Destination vCenter Server Supported  UI or API
vSphere 6.0 vSphere 6.0 Yes UI and  API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 No N/A
vSphere 6.0 Update 3 vSphere 6.5 No N/A
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No N/A
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Virtual Networking Migration

Source Type Destination Type Supported
VDS VDS Yes
VDS VSS No
VSS VSS Yes
VSS VDS Yes

Note1: vMotioning and/or cloning of VMs which uses the new vSphere Encryption feature introduced in vSphere 6.5 is not supported.

Note2: "Compute" only xVC-vMotion insufficient space issue has now been resolved with vSphere 6.0 Update 3, see this post here for more details.

Note3: xVC-vMotion is not supported on 3rd party switches as we can not checkpoint the switching state.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

  • Are Affinity/Anti-Affinity rules preserved during Cross vCenter vMotion (xVC-vMotion)?
  • Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0
  • Network Compatibility Checks During vMotion Between vCenter Server Instances
  • Auditing vMotion Migrations

Categories // Automation, vSphere 6.0, vSphere 6.5 Tags // Cross vMotion, ExVC-vMotion, vSphere 6.0, vSphere 6.5, vSphere API, xVC-vMotion

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...