Top 5 vMotion Configuration Mistakes
One of the best technologies for vSphere is the virtual machine migration technology, vMotion. vMotion received plenty of fanfare and has been a boon to virtualized environments for nearly five years. While this technology is rather refined, we can still encounter configuration issues when implementing it. Here are five vMotion configuration errors you'll want to avoid:
1. Lack of separation.
This is clearly the biggest issue with vMotion. vSphere can permit roles to be stacked on a network interface and spread across multiple IP addresses on a network. To ensure vMotion events bring the best performance, security and reduction of impact to other roles, implementing as much separation as possible will increase the quality of the vSphere environment. Keep in mind also that the vMotion event that transfers the memory of a virtual machine is sent unencrypted, so separation, at the least by VLAN, is a good idea. The best separation would be to have all vMotion traffic occurring on an isolated network on dedicated media that doesn't share physical connections with other vmkernel interfaces, management traffic or guest virtual machine networking.
2. Careless configuration that breaks requirements.
How many times have we tried to move a virtual machine with something silly getting in the way? Sloppy practices such as creating a VMDK on a local disk resource or mapping a CD-ROM device to a datasatore can prohibit the vMotion event. Further, extreme examples such as not zoning all datastores to all hosts or putting a single virtual machine's disk resources on a number of datastores that are not fully zoned across the cluster can cause migration issues. Take the time to make sure these issues are not going to cause migration issues, which, in most situations, can be addressed by a Storage vMotion task first.
3. DRS configured too aggressively.
Just because you can vMotion, doesn't mean that we need to do it -- so much. Pay attention to the cluster statistics and spot-check behavior of individual VMs that migrate a lot. If DRS is set too aggressively or one VM has behavior that may fool DRS, it may be worth a manual configuration value for the VM or make the cluster's configuration be less aggressive for DRS.
4. DRS not aggressive enough or set to manual.
The DRS setting can also be scaled back too conservatively in clusters that have a limited amount of resources, yet a dynamic workload that DRS can't do too much for. Further, if DRS is set to the automatic option but only the most conservative setting, the cluster's performance could be better if it was engaged a tad more. If DRS is set to manual, then vMotion events will not happen automatically as the cluster or individual VMs become busy.
5. Virtual machine configuration becomes obsolete.
It's always a good idea to keep the VM hardware version and VMware tools up to date. This can help vMotion as well as Storage vMotion events, as features are continually added to the platforms. Of course, the individual unit (the VM) needs to be able to support these new features, and the virtual hardware version and VMware Tools installation are critical to make this happen. If there are any VMs that are still at hardware version 4, take the time to get them updated to the current version (vSphere 4.1 is hardware version 7).
These tips will knock out the majority of issues, both with traditional vMotion and Storage vMotion tasks. While definitely not a catch-all list, thse issues outside of the host are usually tied to this list above.
What configuration mistakes get in the way of successful vMotion events in your vSphere environments? Share your comments here.
Posted by Rick Vanover on 06/28/2011 at 12:48 PM