Microsoft can afford to give things away for free as it has deep pockets and offers a great deal of other products and services. If Microsoft was the clear leader in the virtualization space, than it would more than likely be charging customers for Hyper-V and other advanced features. Right now, though, Microsoft is playing catch-up, and giving things away for free is the best way to do that. Because Hyper-V is relatively new it just can’t compete with VMware in areas such as features, performance and product maturity so Microsoft continues to hammer away at the one area that is easy for them to compete at: cost.

So how will VMware respond to this? Most likely, VMware will match Microsoft’s initiative and add VMotion and HA functionality to the free version of ESXi, and possibly one-up Microsoft by also including another management product for free.

VMotion by itself is a useful feature but by no way a critical component to a virtual environment; it simply allows a VM to migrate from one host to another without any downtime, handy? Yes. Necessary? Not so much. VMotion is mostly useful when patching hosts and doing hardware maintenance that requires a host to be shut down or restarted. VMotion, however, is the foundation for many other advanced features like Distributed Resource Scheduler (DRS) and Distributed Power Management (DPM), which require VMotion in order to work. Those features have direct benefits as they help ensure a well-balanced environment and also result in cost savings from lower power consumption.

In my opinion, if VMware chooses to follow suite and give HA and VMotion away, it wouldn’t hurt VMware too much. Many customers will still want the additional features like DRS and DPM that rely on VMotion. Further, it’s possible to get HA functionality for free on ESX hosts via a few different methods, so giving HA away for free would be a good move. As we get closer to the release date for Hyper-V R2, expect VMware to fire back at Microsoft in some way to even out the playing field.

I recently experienced this problem first hand when VMs were mysteriously resetting at times even though they were not experiencing problems. The culprit? VMM. As mentioned, when this happens it can be difficult to determine as the vCenter event log will not have an entry that VMM caused the VM to reset, virtual machine state alarms will not be triggered, and the vmware.log will have no mention that the event occurred. The only evidence that a VMM event took place will be in the /var/log/vmware/hostd.log file on the ESX host and will look similar to what follows.

[2009-03-20 04:44:35.252 'TaskManager' 3076453280 info] Task Created : haTask-512-vim.VirtualMachine.reset-47992
[2009-03-20 04:44:35.323 'ha-eventmgr' 3076453280 info] Event 8420 : Win2003-1 on esx1.xyz.com in ha-datacenter is reset
[2009-03-20 04:44:35.323 'vm:/vmfs/volumes/48331160-05c64c5c-edf0-001e0bd8c708/Win2003-1/Win2003-1.vmx' 3076453280 info] State Transition (VM_STATE_ON -> VM_STATE_RESETTING)

Since this feature relies on monitoring heartbeats through VMware tools there is the possibility of certain events happening that cause the heartbeat to stop longer than the configured failure interval, thereby triggering a false positive and resetting the VM. One example of these types of events is an upgrade to VMware Tools on a VM which causes heartbeats to temporarily stop while the VM is being upgraded. For this reason VMware changed the VMM feature in vCenter Server 2.5 Update 4 to also monitor the VM’s disk and network activity. Therefore even if no heartbeats are received within the failure interval, the VM does not reset unless no disk or network activity is detected for a predetermined I/O stats interval. A VM guest OS that is truly locked up will typically not have any disk or network activity in addition to the loss of heartbeat. This added level of monitoring will help eliminate false positives and make this feature even better. Additionally you can change the failure detection interval to higher than the default of 30 seconds. This setting is located in the HA advanced options section as shown below.

So if you ever have a VM mysteriously reset itself and you have VMM enabled, be sure and check the /var/log/vmware/hostd.log file on the ESX host to see if it was caused by VMM. It would be very helpful if VMware could make it so that these types of events are also logged in the vCenter Server events view.