Home Blog vSphere 6.5: vSphere HA What’s New – Part 3 – Orchestrated Restart

vSphere 6.5: vSphere HA What’s New – Part 3 – Orchestrated Restart

by Brian

For all vSphere HA 6.5 updates see the other parts of this series:

One of the best and 3rd highest used feature in vCenter is vSphere High-Availability (HA). vSphere HA allows virtual machines to restart onto running hosts should the host they reside on fail or become isolated. While this is very beneficial to customers, there are times where this still doesn’t quite cut it.

This is generally when customers have a multi-tiered application that requires an HA restart. The issue being that vSphere HA is no respecter of order dependencies, it is not aware of which VMs depend on other VMs. Multi-tiered applications then get restarted in no apparent order, since HA is just trying its darndest to get everything back up and running as quickly as possible. See the problem?

Once the HA restart event has occurred, it’s possible for the Multi-tiered application VMs to be ‘running’ but not ‘operational’. This can either cause confusion on the App Owners and VI Admins part, or it can just cause a lengthened outage of that application while the App Owner is tracked down, required to VPN in, and restart the services or VMs in the correct order.

We’ve seen this and understand the pain points and issues associated with the lack of restart dependencies. Today I’m happy to announce vSphere HA: Orchestrated Restart.


As of vSphere 6.5 you can create VM – VM dependencies which will force specified VMs to perform HA restarts before others. You can also choose in your vSphere HA settings, when the next VM should begin restarting (at the power-on initiated command, resources allocated, VMware Tools heartbeats, etc) as well as additional timeouts and delays if needed.

So for the 3-tiered application below, you can see that when the host (RED) fails, the DB vm restarts first on Host 2, with the Application VM restarting next on Host 3, followed by the Web VM on Host 2.


Configuring Orchestrated Restart

Firstly, you will need to go to your cluster settings and create your VM Groups. These will be specific Virtual Machines that you will want in each ‘tier’

database-serversOnce you have created your 3 tiers (they may look similar to what I have below), you will move on to the VM Rules page to create the dependency chain.vm-groups

The VM rules ‘TYPE’ is new, and it’s called ‘Virtual Machines to Virtual Machines’. It then allows you to choose two of the VM groups we previously created and tells them to first restart ___<Group 1>__, then restart ___<Group 2>___vm-rules

I now create my 2nd dependency showing that my Web Servers must wait on my Application Servers. Click ‘OK’


Once you’ve created your rules, you are good to go. Additional items may be tweaked in either the VM Overrides page or the vSphere HA cluster defaults.

And there you have it! Orchestrated Restart, folks!


You may also like


Behnood Moradi October 24, 2016 - 3:19 am

Thank You

Ash December 9, 2016 - 2:25 am

What if Database vm is not failover due to some reasons , would it start other dependent vm?

Brian Graf February 18, 2017 - 9:34 am

Hi Ash,

There is a timeout functionality that can be set in the vSphere Availability settings which will allow it to continue if it cannot successfully restart the VM within a given amount of time.

Comments are closed.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More