2.7 Migration Types: Cold Migration, Storage vMotion & Cross vCenter Export

2.7 Migration Types: Cold Migration, Storage vMotion & Cross vCenter Export

Section 2.3 explained how vMotion works. This section answers objective 7.6.1: which migration type fits each situation, and what each one requires.

The Migrate Wizard's Choices

Right-click a VM and choose Migrate. The wizard offers:

Requirements by Migration Type

Cold Migration

• The VM is powered off (or suspended), so there is no CPU compatibility check between hosts. You can even move between CPU vendors, as long as the guest OS supports the new hardware.
• Can move compute, storage, or both, including to another data center or vCenter.
• Copies use Network File Copy (NFC). If a VMkernel adapter uses the provisioning TCP/IP stack (Section 5.4), that traffic stays off the management network.

vMotion (Powered-On Compute Migration)

• VMkernel adapters enabled for vMotion on source and destination, able to reach each other (Layer 2, or routed with the vMotion TCP/IP stack).
• CPU compatibility: the same CPU vendor, with EVC or Per-VM EVC when generations differ.
• Storage: the destination must see the VM's datastore, unless you change storage at the same time.
• No blocking devices: detach host-local devices such as a CD-ROM connected to a host device or an ISO on local storage, and passthrough devices without vMotion support.
• Enough destination resources, and no violated must VM-host affinity rules.
• Concurrency: up to 4 vMotions per host on 1 GbE and 8 on 10 GbE or faster.

Storage vMotion (Powered-On Storage Migration)

• The host running the VM must have access to both the source and destination datastores.
• The VM keeps running; its disks and configuration files move with no downtime.
• You can change the disk format during the move (thin to thick or back), and you can place individual disks on different datastores.
• Virtual-compatibility RDMs can be converted to VMDKs during the move. A physical RDM's mapping file moves, but the LUN stays where it is.
• Not allowed for Fault Tolerance VMs.
• Storage DRS (Section 3.4) uses Storage vMotion for its recommendations and datastore maintenance mode.

Change Compute and Storage Together

Moves a running VM to a host that does not share its storage by copying memory and disks over the vMotion network. It combines the vMotion requirements with enough destination datastore space.

Cross vCenter Server Export (Advanced Cross vCenter vMotion)

• Added in vSphere 7.0 Update 1c as Export (from the source) and Import (from the target) workflows in the vSphere Client.
• Works between vCenter instances in different SSO domains, with no Enhanced Linked Mode required. You enter the other vCenter's FQDN and credentials.
• Supports powered-on (vMotion) and powered-off migration, several VMs at once, and network mapping at the destination.
• Can copy instead of move (keeping the source VM).
• Long-distance vMotion tolerates up to 150 ms round-trip time between hosts.
• Encrypted VMs need both vCenters to have access to the same key provider, configured with the same name.

Why Migrations Fail Validation

Worked Scenarios

Scenario 1: Host decommissioning without shared storage. A standalone host with only local storage must be retired, and its running VMs must move to a cluster with a different datastore, without downtime. Use Change both compute resource and storage. vMotion copies memory and disks over the vMotion network, so both hosts need vMotion-enabled VMkernel adapters and compatible CPUs.

Scenario 2: Datastore evacuation. A storage array is being replaced. Put its datastore into datastore maintenance mode when it is in a Storage DRS datastore cluster, or use Change storage only for each VM. Storage vMotion moves the disks while the VMs keep running. FT VMs must have FT turned off first.

Scenario 3: Cross-generation cluster move. VMs must live-migrate from an older Intel cluster to a new Intel cluster without EVC. Either enable EVC on the destination cluster at a mode that the older hosts' CPUs also support, or set Per-VM EVC on the VMs (while they are powered off) before moving them. If downtime is acceptable, a cold migration avoids the CPU checks entirely.

Scenario 4: Tenant migration between separate vCenters. A business unit's VMs move to a new vCenter in a different SSO domain. Use Cross vCenter Server export with network mapping, and verify the target has the needed port groups, datastores, and, for encrypted VMs, the same key provider.

Limits to Remember