Thursday, 5 May 2016

Back to Basics - Part 6 Migration

In our couple of blog post related to Back to Basics Series we discussed about Virtual Machine Files (Part1) Standard Switches (Part2) vCenter Server (Part 3) Templates (Part4) vApp Part 5 and we also discussed about the various tasks related to building Home Lab Part1Part 2Part 3,Part 4 and Part 5.
In this article we will be discussing about the various types of Migration methods and will understand their functionalities.

Types of Migration -

Cold: Migrating a Powered Off Virtual Machine to a New Host / Datastore.

When doing Cold Migration we can change both host and datastore across vCenter servers without the need of shared storage and similar CPU families.

Suspended: Migrating a Suspended Virtual Machine to New Host/ Datastore. 

When doing the Suspended migration both host and datastore can be changed across vCenter Servers again without the need of shared storage however CPU should be of same families.

Long Distance vMotion Migration - VMware vSphere 6.0 adds functionality to migrate virtual machines over long distances. 

We can now perform reliable migrations between hosts and sites that are separated by high network round-trip latency times. 




Few things to which our environment must comply before proceeding further with Long distance vMotion Migration.

1) A RTT (round-trip time) latency of 150 milliseconds or less, between hosts.

2) Our license must cover vMotion across long distances. The cross vCenter and long distance vMotion features require an Enterprise Plus license. For more information, see Compare vSphere Editions.

3) We must place the traffic related to virtual machine files transfer to the destination host on the provisioning TCP/IP stack. For more information, see the Place Traffic for Cold Migration, Cloning, and Snapshots on the Provisioning TCP/IP Stack section in the vCenter Server Host Management guide.


vMotion : Migrating a VM when it is Powered On to a New Host.

When performing the vMotion we are trying to change the host of the VM wherein both the source and destination host have the access to shared storage. 

While performing the vMotion migration we also need to ensure other prerequisites like both Source and Destination Host Cpu should be same family otherwise Enhanced vMotion Compatibility can be used and baseline can be created to ensure the vMotion is done without any errors.

Few other prerequisites should be taken care of like creation of VMkernel port on both the ESXi and dedicating it for carrying the vMotion Traffic.

How vMotion Works ! Behind the Cover

1) While doing the vMotion Virtual Machine Memory state is copied over the vMotion Network.(Created Using VMkernel Port and dedicating for vMotion Traffic)

2) As the user is currently accessing the VM on the Source host a list of modified pages is maintained separately in Memory Bitmap.

3) Once Most of the memory pages has been copied from the Source to Destination the VM is Stunned/Paused, during this stunned period the remaining amount of Memory as well as the Memory Bitmap is also copied from the Source to Destination ESXi host.

4) As soon as the stunned process is initiated the VM is initialized and start running on the Destination ESXi hosts.

5) GARP (Gratuitous Address Resolution Protocol) requests notifies the Physical Switch about the New location of the VM.

Storage vMotion : Migrating the Files of Powered On VM from one Datastore to another datastore. 

When Performing the Storage vMotion all the blocks are copied from source datastore to destination datastore.

If any changes post copying of these blocks occurs Mirror Driver synchronised the changed blocks.

Storage vMotion operation can be performed internally by VMkernel (Data mover) or can be offloaded directly to the underlying array if the underlying array supports Hardware Acceleration (VMware vSphere API for Array Integration) aka VAAI



No comments:

Post a comment