posted

1 Comment

I recently discovered that when using VUM to patch my vSphere 4.0 FT clusters that things don’t exactly work as I thought.  I knew that when patching a host with an FT protected VM that VUM will temporarily disable FT during the remediation.  However, what I didn’t realize is that FT not only gets disabled for the VMs on the host being remediated, but it actually gets disabled for all the FT protected VMs in the cluster.  It doesn’t matter which host in the cluster is being patched, FT gets disabled for all VMs in the cluster.  This caught me by surprise as it’s not very intuitive that when patching Host-A that VUM will disable FT for a VM running on Host-C and Host-D.

Looking into this I noticed that VUM does provide a warning, but even with the warning it’s not clear that VUM disables FT at the cluster level and not just for the VMs on the host being remediated. 

FT-Failure-Options-3.5

In VI3.5 and vSphere 4.0 the only way to avoid disabling FT for all the VMs in the cluster is to temporarily move the host out of the cluster while you remediate and then move it back after your done.  Not a difficult workaround but it does require extra steps, which are easy to forget.

In vSphere 4.1 things get a little better as you can now choose whether or not to disable FT when you remediate a host, but do be aware as the text description next to the checkbox is misleading.  The message implies that FT will only be disabled for specific VMs running on the host(s), but the reality is if you choose to disable FT it is still done for all VMs in the cluster.

FT-4.x-disable-ft

Bottom line, when using VUM to patch clusters containing FT protected VMs be aware that during the remediation FT gets disabled for the entire cluster and not just the host you are patching.   This caught me by surprise, and I don’t really like surprises.

Regards,

-Kyle

About the Author

Kyle Gleed

Kyle Gleed is a Group Manager within VMware’s Integrated Systems Business Unit (ISBU) where he leads a team focused on the adoption and deployment of the solutions and capabilities of the Software-Defined Data Center. Follow Kyle on twitter @Kyle_Gleed