If you’re looking for a product that integrates with HA/FT and vMotion, detects and automatically repairs Windows system and application failures, you might want to check out vAppHA: –

http://www.neverfailgroup.com/virtualization/vapphatrial.html

The book is correct; my earlier comments are not. VMware HA cannot be used to protect MSCS clusters. vSphere Update 1 allows the VMs to reside within an HA/DRS cluster by disabling HA/DRS for those VMs alone.

Rob,

I’m not aware of any other Windows service-level fault tolerance options that will co-exist nicely with HA, DRS, FT, and VMotion. They probably exist, but I’m not familiar with them or how they would interact with vSphere’s functionality.

In your book, Mastering VMware vSphere 4 (pg 458-459), you seem to indicate that virtual machines in a clusered configuration are not valid candidates for VMotion, and they cannot be part of a DRS or HA cluster. True? One of your posts seems to indicate that you can use VMware HA with MSCS.

Thanks
David

In reading VMware’s ‘Setup for Failover Clustering and Microsoft Cluster Service’, the vSphere MSCS Setup Limitations section states that none of the VMware high availability features (HA, FT, DRS or vMotion) are supported when using MSCS clustered virtual machines. Similar limitations exist with EMC AutoStart as well.

As a provider of turnkey systems that rely on having highly available applications, this seems to nullify most of the benefit of virtualization. Are there any options for providing application (Windows service) level fault tolerance that will allow for continued use of the VMware high availability features?

Thanks,
Rob.

For this one could use ms clustering … in clustering you can create dependent cluster resource(s). If the main goal is to have a high availability of an application then FT and HA aren’t sufficient to archieve this goal. Or am i missing a point?

I think VMware should add an API/option through VMware tools, where a guest can declare itself to have failed at a certain point in time, VMware will kill the VMX process, and ensure that VMware HA/FT will react accordingly.

There really should be an admin control too
Right click a VM choose “Fail this VM”

To ungracefully kill it (as if the host died), and allow HA to bring it back up somewhere else.

But for guest OS patched/maintenance, that’s what vMotion is for.
Failing intentionally as a routine procedure seems like a dangerous strategy, granted in a guest OS-level cluster it’s your only option.

Good question! When you turn off FT, the secondary VM is destroyed. Even if the secondary VM weren’t destroyed, vCenter Server doesn’t expose the secondary VM in a way that users can manipulate it, so you wouldn’t have any way to power it on in the event that the updated primary didn’t work properly. Further, IIRC, you can’t have FT enabled on VMs that have VMware snapshots present.

All that being said, you could use array-based snapshotting or cloning to get the same sort of effect. There are numerous potential issues there as well, many of which I’ve addressed in previous articles on how to use NetApp cloning technology. Have a look at http://blog.scottlowe.org/tag/NetApp for more NetApp-related articles, many of which discuss the interaction between array-based snapshots and VMware virtual machines.

Thanks!

Great article… and very timely as I have a customer who asked what the pluses and minuses are for Clusters and vmware’s implementation of HA & FT.
But I have some general questions.
Given the way FT works; could a user turn off the FT on a VM…snap or clone the VM then do an update to the apps or OS ….then turn FT back on? This would provide some failback / availability value and still have the original VM running… While I have not done this as a lab exercise …shouldn’t this work in theory?

Or you could run VMware on a Stratus ftServer and eliminate all the additional hardware and software costs and get better then 5-nines uptime right out of the box on an Intel platform. Better yet, run VMware HA on the Stratus and you’ve got any unplanned hardware and OS downtime covered as well as individual VM/application. And VMotioning from a Stratus to any other x86/x64 is not different then anything else – Intel to Intel. Simpler, better SLA and better TCO. A winner all around.