Objective 7.4 – Migrate virtual machines
Identify compatibility requirements
no concerns over CPU compatibility, shared storage is not a requirement but downtime is required.
At least advanced licence is required, shared storage, identical network configuration per host, gigabit ethernet for the vMotion vNIC, CPUs must be of the same family, NX/XD (No Execute and Execute Disable) and instruction sets must be consistent i.e. masked or exposed (EVC can help with this), ESX/ESXi version must be 3.5 or newer, CPU virtualisation extensions enabled, locally mapped CD and or floppy will not pass validation, mapped internal vSwitches will failed validation, CPU affinity cannot be set.
At least advanced licence is required, no snapshots in place, virtual disks mist be persistent, only RDM in virtual compatibility mode can be migrated (this is only the pointer not the underlying data), source and destination datastores must be accessible from the source host, two simulateous svMotions can occur by default, four is the maximum.
Cite the three methods of virtual machine migration
The three defined above!
Determine migration use cases
|Moving what?||Downtime toleranted?||migration method|
|virtual machine||yes||cold migration|
|virtual machine files||no||svMotion|
|virtual machine files||yes||cold migration|
|virtual machine files and registration||no||svMotion then vMotion as series operations|
Compare and contrast migration technologies
svMotion can be used to convert a virtual disk to or from a thin or thick provisioned format, changes the datastore used.
vMotion is used to move a running virtual machines state from one host to another.
Powered off and suspended virtual machines can be migrated across datacenters, vMotion and svMotion cannot. Cold migrations can also be used to simulateously change datastore and host; though running svMotion then vMotion will result in the same without downtime.