posted

3 Comments

Posted by Kyle Gleed, Sr. Technical Marketing Architect, VMware on 18 July 2012

VMware recently released a patch on July 12th that, among other things, fixes a virtual machine auto start bug that was introduced with 5.0 Update1 (5.0U1).  This bug affects customers running the free version of ESXi and has received a lot of attention in the communities in recent months.  Unfortunately, it took a while to get this fixed which has led some to speculate that there might be more to this issue than what VMware is letting on.  I’d like to provide some clarification around this and help clear up some of the confusion.

Before I talk about the auto start bug affecting the free version of ESXi I need to point out that in the same update (5.0 Update 1) there was an unrelated change to the auto start behavior for licensed ESXi hosts running inside an HA cluster.  While this is a separate issue, it’s understandable that there is a bit of confusion around the two issues as they both came with 5.0U1 and both affect virtual machine auto start behavior. 

Let’s take a closer look at both issues.


Issue #1 – Auto Start Broke in vSphere Hypervisor

This issue is a bug tied to how restrictions are enforced with the free version of ESXi.  In 5.0 U1 there was a change to the way we enforce restrictions that unfortunately broke the VM auto start feature.  Getting this fixed took some time but I’m glad to say we finally got it.  Unfortunately, there was an oversight when drafting the release notes for the patch and we failed to document this particular fix, which has led some to speculate that VMware may be trying to keep a low profile on it.  This is not the case.  After all I blogged about the fix on the vSphere blog the same day the patch became available.

Issue #2 – Auto Start Disabled for ESXi Hosts in a vSphere Cluster

The second issue, again unrelated to the first, came because 5.0U1 also includes an update that disables the auto start option for licensed ESXi hosts running in an HA cluster.   Using auto start with hosts running in an HA cluster is not supported and the ability to set the auto start should have never been there.  This is because when a host is added to an cluster, HA makes decisions about starting and restarting VMs.  So this change was actually closing a gap.

However, as Michael points out in his blog, although using auto start while in an HA cluster was never supported some people chose to use it anyway is it provided a degree of extra protection in certain scenarios.  As such for these folks this change “broke” how they were using VM auto start.  On a side note I have seen some discussions about possibly requesting a feature enhancement to add this back, which is a topic for another blog.

So in summary, there were two changes in 5.0u1 that affected the VM auto start:

There is a change in the way restrictions are enforced with the free version of ESXi, which broke VM auto start.  This change only applies to the free hypervisor and is fixed in latest patch made available on 12 July 2012.

There is also an unrelated change that disables the ability to configure auto start for hosts that are in an HA cluster.  This issue applies to licensed ESXi hosts that are running in HA clusters.  This change is not a bug, but was made to close a known gap.

I hope this helps clear up confusion related to the VM auto start behavior in vSphere 5.0 Update 1.

Follow me on twitter @VMwareESXi

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