How many times we found ourselves stuck in a situation where application performances were not to a satisfactory level or in the impossibility to move servers without causing business interruptions? Or maybe we also experienced situations where hardware upgrades were prevented otherwise impacting on services provided. Some of them might be related to physical servers environments and from a certain perspective Servers running as virtual Machines are not exempt from the same service requirements. This is where VMware vMotion can help addressing such demanding requirements.
The benefits of Virtual Machines when compared to Physical Machines during disaster recovery, high availability scenarios and distribution of resources are evident. Migrating VMs makes no exceptions and is by far one of the best success factors when it comes down to resiliency operations running in Virtual Data Centers.
Reasons for migrating VMs can be various and different including but not limited to:
- Move to a different Host for better performances
- Move to a different Storage for increased or scalable capacity
- Aid Host with upgrades, patching or fixing issues during maintenance windows
Of course the VM migration process should be seamless and in real time which implies performing these operations whilst the VMs are powered on. Indeed a fascinating topic that VMware addresses with the so called “Hot Provisioning” also known as vMotion.
VMware vMotion has the capability of migrating a VM whilst running without interrupting the business continuity pertinent to that VM. Moreover vMotion offers the capabilities to migrate just the Computing resources as opposed to Storage or even them together.
The purpose of this article is to provide an overview of the options available as “out of the box” from VMware vCenter along with some considerations helping to avoid common configuration mistakes. Also this article is focusing on manual VM migrations as opposed to different scenarios where these operations are executed programmatically by mean of automated procedures. I would like to cover these topics separately in another post in more details. Let’s see this a bit in more detail.
vMotion requirements
So before starting I would like to make sure our home lab has the necessary requirements for vMotion testing:
- Each Host must be correctly licensed for vMotion
- Each Host must meet shared storage requirements
- Each Host must meet the networking requirements
How vMotion works
The purpose of vMotion is to migrate a VM into a different Host. This operation is performed with different steps. In order for the vMotion migration to be successful, once the the process is started the VM memory contents with relative transactions are copied to the destination Host. Subsequently also the Hardware information like BIOS, MAC Address and other devices are copied to destination. If this operation is successful the VM will resume from the new Host. Conversely the Virtual Machine reverts to the original state and location. Hence a dedicated network aided with a Shared Storage configuration will guarantee the recipe for success.
vMotion setup
For a manual VM migration let’s start selecting the intended machine and from the contextual menu we choose the Migrate option to start wizard.
Change Compute resources only
The wizard will offer 3 options: Changing the Computing or Storage resources or both together. Generally speaking one of the prerequisites for vMotion is for the Hosts to be configured using shared Storage. This particular requirement is not needed when running a Storage vMotion instead. Â In this case we just migrate the compute resources as per screenshot below.
At this point we can select the Host where we want to migrate. As soon as the selection is done VMware vCenter will evaluate and run a quick compatibility check to make sure the selected Host is suitable. VMs that use RDM or mapped to physical devices like CD Drives will show a warning in this phase.
Next step is to review the Network settings for the VM. By default the vMotion wizard reads and suggests the available Network Port Groups for source and destination Hosts. As a best practice when using two separate Hosts with Standard virtual Switches they should have identical configurations including the Port group labels. Even the “smallest” changes can cause warnings.
An example can be when the configuration properties of the virtual Switches are not identical having the “Promiscuous mode” enabled in the source or in the destination. In order to proceed error free we should carefully review all the configuration settings of the virtual Standard Switches.
As a final step before reviewing the settings we can choose the CPU priority by the Hosts to complete the operations. Although by default all traffic types use the “Default” VMware TCP/IP Stack called “Management” it is a best practice to create a dedicated VMkernel leveraging the built-in “vMotion” TCP Stack. This way we can not only physically separate the network traffic for hot Provisioning on a separate wire but we can also use e dedicated subnet for the purpose. Ideally we can also create this as a non routed network to increase security.
Or ideally since the vMotion traffic is not encrypted we can provide a level of encryption. Let’s bear in mind this is a built-in encryption option is available from vSphere 6.5!
And as per usual a summary to review the final step.
At this point the following will happen:
- vCenter verifies the virtual machine status on the current Host
- The virtual Machine settings are copied across the network to the destination Host (memory, registers and network connection details)
- The virtual Machine resumes operations from the new Host
All the steps will be visible through the recent task panel.
Change Storage only
In this case instead the wizard will offer the options to execute the Storage vMotion which means the virtual disk files will be moved to a new Datastore location as per screenshots below.
Since the virtual disk files will be moved into a new location it is also possible to choose the final format in the destination. The best one would be to keep the format consistent both location or change to “Thick”Provisioning for better performances in the long term. Of course this will add extra time to the provisioning of their drives upon their creation. At least we have the flexibility to choose the best option at the migration time also based on storage capacity. Last but not least also the ability to specify a Storage Policy.
And now a final review of the settings below.
Change both Compute and Storage resources
In this case the wizard offers the combination of the previous options. This can be useful during Host maintenance windows where both compute and storage resources might be unavailable.
At this point we need to choose the new location for the Virtual Machines to  migrate. As soon as the new container is selected the wizard will run a background compatibility check.
So in this case the wizard will show all the available storage including the “local” one to the selected Host. For resiliency shared storage should be used.
Again we can specify the Network Port Group that the Virtual machine will use at the destination Host.
Previous considerations apply here as well. A dedicated VMkernel network adapter for better performances will not only increase security but will also avoid any impact on the Management and VM networks.
And a final summary to review the setting before committing the changes.
Final considerations
So before closing this article I would like to share some vMotion best practices as final considerations that apply at both home lab and enterprise scenarios:
- Create a dedicated VMkenel adapter to “physically” transport the vMotion traffic
- Use at least one dedicated 1Gib NIC
- When available use additional NICs for fail-over or load balancing
- When using the same subnet as Management Network divide subnets using vLANs
- When possible enable the Jumbo frames for the vMotion Network from end to end
- Leverage the built-in VMware TCP Stack using a separate subnet with a dedicated Gateway for the vMotion network
- Make sure FQDN name reolutions is working across networks (Management and vMotion) and Hosts
- Encrypt vMotion traffic (from vSphere 6.5 and later)
In a separate article we’ll cover Cold Provisioning with regards to Snapshots, Cloning and Powered off Virtual Machines.
Add Comment