Neu in der HA-Implementation ist u. a. auch ein Feature namens Orchestrated VM Restart. Es erlaubt in Version 6.5 nicht nur, VMs nach einem Ausfall oder bevor ein Server zur Wartung in den Maintenance-Mode genommen wird, auf einem anderen Host neu starten, sondern auch deren Start-Reihenfolge durch relativ komplexe Regeln zu steuern.

Mit Orchestrated VM Restart kann der Administrator, Aneinanderreihungen voneinander abhängiger virtueller Maschinen oder ganze Gruppen solcher VMs festlegen und dann die Reihenfolge bestimmen, in der die einzelnen VMs neu gestartet werden. Der Admin kann sogar einstellen, dass ausgewählte VMs mit dem Booten warten, bis der VM sämtliche von ihr durch andere VMs bereitgestellte Dienste tatsächlich zur Verfügung stehen.

VM Restart Priority

In der bisherigen HA-Implementation (bis vSphere 6) gibt es hingegen nur die „VM Restart Priority“, welche der Admin mehr oder weniger prophylaktisch auf high, medium oder low setzen kann.

Um dies zu tun, wechselt man nicht etwa in den Detail-Bereich der HA-Settings, sondern navigiert in den Cluster-Einstellungen zum Bereich Configuration. Hier wählt man den Eintrag  VM Overrides und klickt auf Add. Mit dem grünen Plus-Symbol lassen sich dann einzelne VMs hinzufügen und mit individuellen Cluster-Einstellungen versehen, etwa im erwähnten Menü VM restart priority durch Auswahl eines der Einträge „low“, „medium“ oder „high“. Soweit so gut. Bei vSphere 6.5 kommen noch die Optionen „Lowest“ und „Highest“ hinzu.

Regel-abhängige VM-Restart-Priorität

Neu ist, dass VMware unterhalb des Menüs VM restart priority zwei weitere Menüs Start next priority VMs when, Additional delay und or after timeout occours at  hinzugefügt hat.
So kann der Admin etwa bei Start next priority VMs when Policies einstellen wie z. B. „Ressource Allocated“, „Powered On“ „Guest Heartbeat dedected“ oder „App Heartbeats detected“, ”wodurch” oder “durch was” der Start der nächsten Priority-Gruppe getriggert wird.

Dies erlaubt ein weitaus granulares Steuern, wann die jeweils nächst höher priorisierte VM/VM-Group startet. Die beiden letztgenannten Optionen setzen allerdings die VMware Tools voraus.

Hat der Admin die Start-Priorität an sich festgelegt, kann er bei Additional Boot-Delay bei Bedarf einstellen, wie lange auf den Start des nächste Batches gewartet werden soll. Unter „resources allocated” versteht VMware das pure Scheduling des Batches selbst, während “Powerd On” das Vervollständigen des PowerOn-Events als Trigger verwendet oder die Guest-, bzw. App-Heartbeat-Erkennung nach dem vollständigen Start der VM samt VMware-Tools und/oder der Anwendung.

Letzteres setzt voraus, dass App-HA aktiviert ist, was wiederum eine „App-HA-aware“ Applikation voraussetzt, während „VM-Monitoring“ (Guest-HA) nur das Aktivieren der Funktion in den HA-Settings benötigt. Allerdings benötigen beide Funktionen die VMware-Tools für das Austauschen von Guest-, bzw. App-Heartbeats zwischen VM und Host.