Technical Shmechnical: VMotion
If you ever listen to system administrators or just about anyone involved in IT these days, you'll probably hear the term, VMotion, during the conversation. If you need to know more about this virtualization feature, the following is an explanation that is simple enough for anyone involved in the industry as an observer, manager, project manager or public relations role to understand and use confidently in those discussions. Please ask any further questions on this topic in the Talkback section.
VMotion is the moving of a virtual machine (VM) from one VMware ESX host to another. This "motion" can take one of several different forms. The motion can be an automated process in an effort to balance the workload among ESX hosts within a host cluster. It can be performed manually as a migration by an operator. It can occur between hosts in reaction to a host reboot or during a "maintenance mode" function. Additionally, these migrations may take place at times scheduled by an operator in unattended mode. But, what does VMotion mean to you and what does it buy you?
VMotion is a very positive feature in VMware's ESX and ESXi products and an extremely valuable one. To better understand VMotion, look at what it does for you when you use it.
Change Host
Changing the host on which your VM workload runs is usually a very easy task and doesn't require a reboot, shutdown or any outage. This is the typical VMotion between hosts in the same cluster. However, this type of motion can also occur between clusters if the two clusters share storage. This is also the motion type that occurs between hosts in Distributed Resource Allocation (DRS) moves. DRS is an automated way of balancing workloads among VMware host systems. It is NOT based on the number of VMs running per host but the non-disk resource (CPU and memory) consumption per host. Note: This type of motion is a live motion. It occurs while the VM is up and running with only a momentary loss of connectivity. You can choose to manually balance your systems, if you're skilled in those matters. But, for the rest of us, a clever method is to use VMware's "aggressive" DRS setting until VMware's algorithms balance appropriately among hosts and then slide the DRS setting down to a more conservative setting. By using a more conservative setting, you prevent the "DRS dance." DRS dance, as I call it, is the constant shuffling of VMs among hosts. It's not a good idea to allow VMs to constantly move about, so if you find that yours are, slide the setting a notch toward conservative.
Change Datastore
Changing your datastore means moving the VMs physical disk files from one LUN to another. This move, like a host VMotion, can be done as a live migration. This action does not occur in DRS. Changing a datastore is a common, though less frequent, practice than changing hosts. Moving a VM's disk files can occur for one of a few reasons but it almost always involves the need to maximize free space for additional VMs, especially for those who employ thin provisioning for disk files.
Thin provisioning means that a disk files grow (but don't shrink) dynamically, when the VM requires more space. The disk can't grow past its designated capacity. If you create a VM's disk as "thin" and allocate 80GB to it, it may only use a few gigabytes initially but over time the size of the disk increases to to 80GB. At 80GB, it stops growing and reacts like any disk that's too full.
Actually, before the disk fills to its maximum, unless it does so very quickly, you should receive a notice that the disk is close to filling up. Thick provisioning is the practice of allocating 100 percent of the space for a disk at creation time.
Change Host and Datastore
This is the least common move, although it does occur with some regularity in larger environments and is also a non-automated motion type. Typically, when you're required to perform such a motion, it occurs between data centers or clusters that do not share storage. This means that the VM must be in a powered off state to perform the motion. Such a significant change might also require changing your VM's network settings, after the VM has made the trip.
The "Technical Shmechnical" series focuses on common industry topics in a simplified manner to allow us all to communicate more effectively on those topics. If you have a topic that you'd like discussed or explained in Technical Shmechnical, let me know.