vMotions – What Types of Tradeoffs are You Making Within Your Environment
Nearly every IT Operations group leverages the ability to move VMs among their compute nodes multiple times in a day. Despite the differences in the naming convention (e.g. vMotion, live migration, XenMotion, etc.) we leverage this simple technique to fix performance problems or inefficiencies within our virtual infrastructure. Or at least we attempt to…
We often oversimplify migration decisions because they are quick and are low impact on the virtual environment or at least that’s what we believe. Despite such ease, sysadmins unknowingly makesnumerous tradeoffs in the process. If you move a VM, which server do you move it to, how will that VM play with its new neighbors, what happens to the levels of resource usage on the host, am I still being efficient with my resources?
I was recently working with a customer who expressed the complexity of moving VMs around the environment. His trouble was that no matter how he moved his VMs around his production cluster he couldn’t fix his performance problems. His main constraint was ready queue on the hosts, and when he went to manually move a VM he would eliminate ready queue on one host but simply create it on the new destination server. Or he would move the highest consumer of CPU off one host and to another, and create dangerous levels of ballooning on the destination node. Essentially, the customer could not solve his problem, he would just move it around. His production cluster had 19 physical servers with roughly 200 VMs.
Read the entire article here, vMotions – What Types of Tradeoffs are You Making Within Your Environment
Other FREE VMTurbo Resources