introduction
sometimes you need to move VM from host to another or from DataStore to another , because of many reasons linke :
- lake of host resources : CPU ,RAM
- insufficient space
- maintenance purpose
- troubleshooting purpose
VM could be
- online running
- or suspend
- or even offline , shutdown
Migrating a virtual machine [vMotion ] means moving a virtual machine from one host or datastore to another host or datastore.
vSphere supports a couple of VM migration types that can help you to get better resource utilization across multiple physical hosts and shift workloads between hosts in order to balance the resource utilization
vMotion Types
Cold vMotion
- Migrates a powered-off VM.
- Move VM from host to another host or from DataSstore to another DataSstore
- No need for shared storage
- Support hosts with different CPU
Suspended vMotion
- Migrates a suspended VM.
- Move VM from host to another host or from DataSstore to another DataSstore
- No need for shared storage
- Support hosts with ONLY similar CPUs
vSphere vMotion
- migrates a powered-on VM.
- Move VM from host to another host but NOT from DataSstore to another DataSstore
- shared storage is required
- Support hosts with ONLY similar CPUs
vSphere Storage vMotion
- migrates a powered-on VM’s files [.vmdk ] to another datastore.
- Move VM from host to another host or from DataSstore to another DataSstore
- No need for shared storage
- Support hosts with ONLY similar CPUs
vMotion requirements
Before performing a vSphere vMotion migration, ensure that the following conditions are met:
VM requirements
- the VM must not have a connection to an internal standard switch.
- the VM must have all disk, configuration, log, and NVRAM files stored on a datastore accessible from both ESXi hosts.
- the VM must not be connected to any device physically available to only one ESXi host, such as disk storage, CD/DVD drives, floppy drives, and serial ports.
- the VM must not have a CPU affinity configured.: [affinity rule will be discussed later with DRS article ]
- if the VM uses RDM, the destination ESXi host must be able to access it.
Host requirements
- shared storage is required. VM files on a VMFS or NFS datastore need to be accessible by both the source and destination ESXi host.
- at least a Gigabit Ethernet network interface card [1GBps or 10GBps ] with a VMkernel port enabled for vMotion on each ESXi host is required.
- identically named virtual machine port groups connected to the same network. All port groups to which the VM is attached must exist on both ESXi hosts. Note that the port group naming is case sensitive.
- CPUs in both ESXi hosts must be compatible. CPUs need to be from the same vendor (AMD or Intel, for example), CPU family, and must support the same features. Note that some features CPU features can be hidden by using compatibility masks.
CPU compatibility for vMotion
In order to to perform a vSphere vMotion operation,
- CPUs in both hosts must be compatible.
- CPUs must be from the same vendor (AMD or Intel, for example),
- must be in the same family
- and must support the same features.
However, there are some hardware extensions from Intel and AMD (such as CPU masking) that can help you mitigate the CPU differences.
When a VM is migrated between ESXi hosts,> then the VM has already detected the type of processor it is running on when it booted.
vMotion with different CPUs family
As we mentioned above : The CPUs on ESXi hosts need to be similar for vSphere vMotion to work.
But what if we have many ESXI host with different CPUs family or even different generation [HP and Dell for example]
VMware take care of this common issue and provide utility called VMware CPU identification [ CPUid ]
To download this tool, go to vmware official site here (you will need to register with VMware).
Conclusion
in this articles [ vMotion Part I ] : we have got an overview about vMotion concept and it’s types ,
also we get some considerations for different CPUs
next article [vmnotion Part II ] : we will see how to practice vMotion and Storage vMotion
