ltstudiooo - Fotolia
Virtual machine portability makes it possible to move workloads in ways that were never possible in physical data centers. By using features such as VMware's vMotion or Microsoft's Live Migration for Hyper-V, a running VM can be moved from one virtualization host to another without incurring any downtime. An administrator might manually initiate such a move so that a host server can be taken offline for maintenance, or a VM might be moved automatically by a load balancer. In either case, the end result is that a VM could conceivably be moved to any available host server.
On the surface, moving VMs from one host to another may seem completely harmless. However, there are situations in which a host server might not be a good fit for a particular VM. That being the case, it is important to set some ground rules for VM migrations.
The process of implementing the rules that you have established will vary widely from one hypervisor to the next. For example, VMware and Hyper-V each support the use of affinity rules, but the rules are created in completely different ways. This tip discusses some situations in which placement rules might be helpful rather than trying to walk you through the rule creation process.
One of the most common situations you may need to create some VM placement rules is when there is a legal requirement for VMs to be kept separate from one another. Such a requirement is very common in public cloud hosting environments, but sometimes also comes into play in corporate environments.
Imagine for a moment that a public cloud provider has both Coke and Pepsi as tenants. In that sort of situation, there is probably going to be a contractual requirement to keep Coke's resources on separate virtualization host than the ones where Pepsi's resources reside. Similarly, in a corporate environment there may be a requirement to keep a compliance auditor's resources separate from the finance department's resources.
When this level of isolation is required, it is sometimes easier to place tenants or departments into separate host clusters rather than trying to build a set of rules, but either approach can work.
Sometimes VM placement rules are created in an effort to protect multi-tier applications. Suppose for a moment that your organization has a custom Web application consisting of a Web front end and a backend database. Let's also pretend that the Web front end and the database are stored on separate VMs. Because these two VMs are part of the same application you may wish to ensure that they always reside on the same virtualization host. Conversely, you may wish to keep the VMs on separate hosts either for performance or for security reasons.
If your goal is to keep the VMs together on a common host then the best mechanism for doing so is affinity rules. Affinity rules are rules mandating that certain VMs must exist on the same host as one another, even if the VMs are migrated to a different host.
Guest clusters also commonly make use of VM placement rules. Guest clusters are application level clusters that are at least partially made up of VMs. Guest cluster nodes should not typically reside on a common host server. Otherwise, if the host server were to fail then the guest cluster could also fail.
Admittedly, most hypervisor deployments are clustered at the host level, so a host level failure should result in VMs failing over to another host and that should keep the guest cluster nodes running even if they all exist on a common host. The problem with this idea however, is that the remaining hosts in the host cluster might not have enough resources available to absorb all of the VMs that were running on the failed host. As such, it is better to keep guest cluster nodes on separate hosts than to worry about whether the guest cluster will be impacted by a host level failure.
The best mechanism for keeping guest cluster nodes separate from one another is anti-affinity rules. Anti-affinity rules allow you to prevent certain VMs from residing on a common host unless there are not enough hosts available to keep all of the VMs within the anti-affinity set separate from one another.
System Resource Availability
One more issue to consider is system resource availability. You don't want a VM to be migrated to a host server that is low on available resources. Most hypervisors won't try to place a VM onto a heavily used host if a better option is available, but there are sometimes situations in which a VM needs to be moved and all of the hosts are running heavy workloads.
One way to prevent the VMs from completely depleting the available hardware resources is to set up host reserves. Host reserves are designed to reserve a certain amount of hardware resources for the hypervisor to use, thereby ensuring that a host server is never completely depleted of resources.
As you can see, there are a number of different circumstances that may require the use of host placement rules. Fortunately, most major hypervisors will allow the creation of rules that control VM placement.
Recognize and resolve VM migration problems more quickly
Fight against the top five virtual machine migration errors
What you should know about VM live migration