Professional Documents
Culture Documents
Vmware Vmotion In-Depth
Vmware Vmotion In-Depth
Vmware Vmotion In-Depth
The Virtual Machine Memory state is copied over the Vmotion Network from the
source Host to the Target Host. users continue to access the virtual machine and
potentially update pages in memory. A list of modified pages in memory is kept in a
memory Bitmap on the source Host.
After most of the virtual machine memory is copied from the source host to target
host the virtual machine quiesced no additional activity occurs on the virtual machine. In
quiesce period VMOTION transfers the virtual machine device state and memory
Bitmap to the destination Host.
Immediately after the virtual machine is quiesced on the source host, the virtual
machine initialized and starts running on the target host.
Users access the virtual machine on the target host instead of the source host.
The memory pages that the virtual machine was using on the source host are
marked as free.
1. The virtual machine working directory is copied by VPXA to the destination datastore.
2. A “shadow” virtual machine is started on the destination datastore using the copied files. The
“shadow” virtual machine idles, waiting for the copying of the virtual machine disk file(s) to
complete.
3. Storage vMotion enables the Storage vMotion Mirror driver to mirror writes of already copied
blocks to the destination.
4. In a single pass, a copy of the virtual machine disk file(s) is completed to the target datastore
while mirroring I/O.
5. Storage vMotion invokes a Fast Suspend and Resume of the virtual machine (similar to
vMotion) to transfer the running virtual machine over to the idling shadow virtual machine.
6. After the Fast Suspend and Resume completes, the old home directory and virtual machine
disk files are deleted from the source datastore.
vMotion In-Depth
vMotion, the one feature that excited me a lot when i first heard about it. vMotion is still my favourite
feature of vSphere, it has come a long way. Many new learners still keep asking about the process of
vMotion, so i thought of writing a bit about it.
What is vMotion?
Migration of a powered on VM from one ESXi host to another without any downtime is called as vMotion.
Well that is a technical definition, but what exactly are migrated from one host to another? To answer that
you should basically understand what actually is needed for a VM to run – Memory, CPU, Network, Storage.
Let’s look at the step by step process on how all these components gets migrated from one host to another
without downtime.
To help you understand better, let’s consider an example of a VM named ABC being migrated from host
ESXi-A to ESXi-B.
vCenter Server
Shared Storage
VMkernel port enabled with vMotion; vDS or Standard switch can be used.
Identical Virtual Switches and Port Groups on source and destination. If it is vDS, hosts should share the
same vDS.
Source and Destination host CPU’s must be compatible – same make, family
No CD/DVD’s to be connected VM during migration.
VM must not be connected to internal only switch.
No affinity configured on VM with host.
Relaxation on requirements
From vSphere 5.1 vMotion works even without having a shared storage. In this case disk contents are
copied first as changes occurring to disks are less compared to changes to memory.
vSphere 6 removes the requirement for shared vDS but it is best practice to have them on use same vDS to
avoid consistency issues during DRS calculations.
vSphere 6 also removes the requirement to have same port group name on the destination host, vMotion
wizard now allows us to select a different port group on the destination host.
Other things to know
vMotion will only transfer the VM to the destination if it is certain that it can complete the memory copy.
If vMotion cannot complete the memory copy it will fail with no impact to the running VM.
vMotion can now operate on routed networks. Supports upto 150ms round trip time and cross vCenter
migrations.
Cross vCenter migrations are supported when both vCenters are atleast on version 6 and must share same
PSC
vMotion can now use multiple NICs to transfer memory between hosts.
The VM’s memory contents are transferred between hosts in clear text and hence it is recommended to
use dedicated network for vMotion.
High priority migrations do not proceed if sufficent resources are available on destination host. Standard
priority migrations proceed but can fail in case of resource unavailability.
For RDM connected VM’s, select Same Format as Source during storage vMotion, failing to select this will
convert the virtual RDM’s to vmdk and physical RDM’s are unaffected. vmdk’s cannot be converted back to
RDM.
Storage vMotion renames teh under lying files in the datastore to allign with the name of the VM. If only
one disk is being migrated, only the migrated disk is renamed.
If source and destination hosts see same storage, then storage vMotion is intelligent enough to use storage
network for data transfer instead of VMkernel network.
During cross vCenter migration, since the Universal Unique Identifier (UUID) is retained, all the settings
like HA, DRS rules, Alarms, Tasks, Events, Shares, Limits and Reservations are also transferred.
Since VM performance is written to vCenter DB, during the cross VC migrations, this data is not migrated.
The MAC address of a VM is blacklisted on the source vCenter during cross vCenter migrations to prevent
conflicts with any new builds.