As soon as vSphere 5.0 Update 1 become available I updated my lab. I wanted to get the benefits of all the bug fixes. Some of these bug fixes I had played a part in getting them fixed. After the upgrade I noticed that Auto Start was no longer working. I could no longer choose to enable Auto Start or disable it. It was all just greyed out. First I thought this was something I had done (sort of was), even though I had used Update Manager for the upgrade process, it was still showing as enabled on some hosts and not on others. Then I thought maybe this was by design, as I do have a HA/DRS Enabled Cluster and Auto Start has never been supported in this case.

I saw a tweet come through from Kyle Gleed (@VMwareESXi) who is one of a group of very talented and knowledgeable VMware Technical Marketing guys. His tweet was regarding an Auto Start issue impacting the Free VMware Hypervisor after upgrading to Update 1. Many people running the Free vSphere Hypervisor use Auto Start to start VM’s in a particular order when a host boots. Few use Auto Start in licensed HA/DRS Clusters.  He had posted a blog article titled Free ESXi Hypervisor – Auto Start Breaks with 5.0 Update 1. Initially I thought this might have been related to my problem. However it wasn’t. Here is a screenshot of what I was seeing.

Why use Auto Start in the first place?

So before I tell you why this has happened I’m going to tell you why I used Auto Start in the first place in an HA/DRS Cluster. Simple answer, as you can see from the screenshot above, I have HP P4000 VSA’s configured on local storage on each host. I was knowingly using Auto Start even though it wasn’t supported. This was to get my storage back up and running in the case of a host reboot. In an attempt to avoid the problem I described in my article The Achilles Heel of the VMware Distributed Switch.

Perhaps this is a bit of a legacy that is now probably not needed with the changes to VMware HA in vSphere 5? The reason I say it’s a bit of a legacy is that in previous versions of vSphere HA would not record the power state of each VM and power everything back on when the hosts boot up in the case of a complete power outage. In vSphere 5 this is exactly what happens. You can find out more by reading my article vSphere 5 HA Complete Failure Experience.

However this doesn’t cover you if someone accidentally reboots the wrong host, or you have someone accidentally push the wrong power button (people make mistakes). What about the case of full site maintenance and full shutdown of the systems? Although this is rare, it does happen. I’ve had a number of customers do complete site shutdowns for scheduled power maintenance, sure they had a DR site for services during the maintenance, but what about making start-up automatic? You’d want some of these systems to automatically start back up such as domain controllers, vCenter Server, and it’s database server. Eric Gray describes this exact scenario in his blog article “Cold Starting a Datacenter” at vCritical regarding maintenance being conducted on his companies labs.

So why is Auto Start Broken in fully licensed HA/DRS Clusters?

This is by design. This is probably why people were confused and also thought the issue with Auto Start in the Free VMware vSphere Hypervisor was also intentional, which it was not. The use of Auto Start in HA/DRS Clusters has never been supported. Even though my use case around having Local storage shared via VSA is completely valid, and even encouraged for customers now that VMware has their own VSA, VMware has finally decided to disable this functionality from working when hosts are in HA Enabled Clusters. Here is the description of this “resolved issue” from the vSphere 5.0 Update 1 Release Notes:

• Automatic virtual machine startup and shutdown option is disabled when host is part of a HA (High Availability) cluster
  In vCenter Server the ESX host setting Allow virtual machines to start and stop automatically with the system should be disabled when the host is added to a HA cluster, as this feature is not supported with HA. The option to re-enable the setting should be greyed out when the host is in the HA cluster. This issue is resolved in this release.

Note: If you cluster does not have HA enabled Auto Start will continue to work, however it will still be unsupported. I would not recommend disabling HA just as a way of getting Auto Start to work. HA is much more important compared to the use cases for Auto Start.

The Final Word

So even if you  have a good reason to want to use Auto Start in a HA/DRS Cluster it is no longer just an unsupported configuration. It is a completely unavailable option. You can no longer use the Auto Start functionality for any hosts that are part of an HA/DRS Cluster. If you want to do some maintenance that could generate a need to use Auto Start, then you might have to temporarily remove a host from a cluster and put the VM’s you wish to Auto Start on that host. Unfortunately this leaves you without any redundancy and doesn’t help in the situation of VSA’s that are using local storage on your hosts.

Maybe if enough people think having the ability to use Auto Start, even if it’s not supported, then VMware will bring back that functionality as an option even in an HA/DRS Cluster. Either that or have an option to configure any particular VM as an Agent VM (via the GUI) that always starts with a particular host, not just due to HA events. VMware’s Agent VM functionality in vSphere 5 could be expanded so any particular VM could be tagged as an Agent VM, and this VM would always automatically start with the host, shutdown or power off when the host enters maintenance mode etc. Currently this functionality is not being widely used, except with VMware products, such as vShield and others. Perhaps the changes in vSphere 5 Update 1 will be the catalyst to see more vendors using the Agent VM functionality. You can check out this article title Agent VMs written by Duncan Epping.

In a recent tweet Mike Foley (@mikefoley) suggested a better solution would be a cluster-wide auto start flag per VM regardless of host. Thanks Mike for the great suggestion.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.