For a list of all objectives see the VCP5 page.
Objective 5.4 – Migrate Virtual Machines
See also: Objective 5.4 – Migrate Virtual Machines and Objective 5.4 – Migrate Virtual Machines.
Identify ESXi host and virtual machine requirements for vMotion and Storage vMotion (same as vSphere 4.x)
See the vSphere Virtual Machine Administration guide (page 219) and vCenter Server and Host Management guide (page 119 and 122).
Some basic requiments: for vMotion a specific vmkernel interface (enabled for vMotion) is required, as the CPU compatibility (or EVC). For Storage vMotion the host must see both source and destination datastore.
Identify Enhanced vMotion Compatibility CPU requirements (similar as vSphere 4.x)
See the vCenter Server and Host Management guide (page 123) and VMware KB: Enhanced VMotion Compatibility (EVC) processor support. More baselines are available.
Identify snapshot requirements for vMotion/Storage vMotion migration (similar as vSphere 4.x)
See the vCenter Server and Host Management guide (page 121). Some restrictions apply when migrating virtual machines with snapshots:
- Migrating a virtual machine with snapshots is now permitted, regardless of the virtual machine power state, as long as the virtual machine is being migrated toa new host without moving its configuration file or disks. (The virtual machine must reside on shared storageaccessible to both hosts.)
- Reverting to a snapshot after migration with vMotion might cause the virtual machine to fail, because themigration wizard cannot verify the compatibility of the virtual machine state in the snapshot with the destination host. Failure occurs only if the configuration in the snapshot uses devices or virtual disks that are not accessible on the current host, or if the snapshot contains an active virtual machine state that was running on hardware that is incompatible with the current host CPU.
- If the migration involves moving the configuration file or virtual disks, the following additional restrictions apply:
- The starting and destination hosts must be running ESX 3.5 or ESXi 3.5 or later.
- All of the virtual machine files and disks must reside in a single directory, and the migrate operation must move all the virtual machine files and disks to a single destination directory.
Migrate virtual machines using vMotion/Storage vMotion (similar as vSphere 4.x)
See the vSphere Virtual Machine Administration guide (page 223) and vCenter Server and Host Management guide (page 132). Can also be done from the vSphere Web Client.
About vMotion with high priority: On hosts running ESX/ESXi version 4.1 or later, vCenter Server attempts to reserve resources on both the source and destination hosts to be shared
among all concurrent migrations with vMotion. vCenter Server grants a larger share of host CPU resources to high priority migrations than to standard priority migrations. Migrations always proceed regardless of the resources that have been reserved. On hosts running ESX/ESXi version 4.0 or earlier, vCenter Server attempts to reserve a fixed amount of resources on both the source and destination hosts for each individual migration. High priority migrations do not proceed if resources are unavailable.
Remember that the Storage vMotion of virtual machines during VMware Tools installation is not supported.
Configure virtual machine swap file location (same as vSphere 4.x)
See the vCenter Server and Host Management guide (page 121).
You can configure ESX 3.5 or ESXi 3.5 or later hosts to store virtual machine swapfiles in one of two locations: with the virtual machine configuration file, or on a local swapfile datastore specified for that host. You can also set individual virtual machines to have a different swapfile location from the default set for their current host. If hosts are all 3.5 or later, during a migration with vMotion, if the swapfile location specified on the destination host differs from the swapfile location specified on the source host, the swapfile is copied to the new location. This can result in slower migrations with vMotion. If the destination host cannot access the specified swapfile location, it stores the swapfile with the virtual machine configuration file-
Migrate a powered-off or suspended virtual machine (similar as vSphere 4.x)
See the vSphere Virtual Machine Administration guide (page 220). Can also be done from the vSphere Web Client.
When you migrate a suspended virtual machine, the new host for the virtual machine must meet CPU compatibility requirements, because the virtual machine must be able to resume executing instructions on the new host.
Utilize Storage vMotion techniques (changing virtual disk type, renaming virtual machines, etc.) (same as vSphere 4.x)
See the vSphere Virtual Machine Administration guide (page 226).
During a Storage vMotion or also a cold storage migration all files are renamed with the current VM name. The vmdk can be change from thin to flat or viceversa.
For virtual compatibility mode RDMs, you can migrate the mapping file or convert to thick-provisioned or thinprovisioned disks during migration as long as the destination is not an NFS datastore. If you convert the mapping file, a new virtual disk is created and the contents of the mapped LUN are copied to this disk. For physical compatibility mode RDMs, you can migrate the mapping file only.
