VM restart priority vs. startup order

Ein reales Szenario:

Eine defekte USV soll getauscht werden. Alle Komponenten sind redundant mit Strom versorgt (ein Netzteil an USV, das andere direkt am Stromnetz). Vor der Abschaltung der USV kommt es zu einem kurzen Ausfall im Stromnetz. Die USV ist zu schwach um auch nur diese kleine Schwankung abzufangen. Die Folge: Ein Blackout der vSphere Infrastruktur (ESXi, Storage, Fabric, LAN). Prinzipiell ärgerlich, aber kein Problem. Denn auf allen ESXi Knoten waren zuvor Startreihenfolgen definiert, die genau regeln sollten wann welche VM startet. Leider starteten die ESXi Knoten alle vorher laufenden VMs praktisch zeitgleich, was zu einer erheblichen Belastung der Storage führte (Boot-Storm).

Was war passiert?

Man muss hier zwei unterschiedliche Szenarien unterscheiden:

  • Ordentlicher Kaltstart einer vSphere Infrastruktur nach vorherigen Shutdown aller laufenden VMs
  • Clusterneustart nach Blackout

Letzteres trifft auf den oben beschriebenen Fall zu. D.h. HA bemerkt hier, daß es zu einem Crash kam und versucht alle zuvor aktiven VMs neu zu starten. Die Startreihenfolge auf ESX Ebene ist hier ohne Belang. Alleine HA ist jetzt für den Neustart verantwortlich. Den Ablauf der Ereignisse unter vSphere 5 hat Duncan Epping kurz in einem Artikel skizziert.

Wie kann man steuern, daß nach einem solchen Ausfall nur die Kerndienste neu starten? Eine vor dem Crash zufällig laufende Test-VM sollte z.B. auf keinen Fall unnötig Last auf die Storage bringen und ausgeschaltet bleiben bis sie jemand manuell startet. Die Lösung liegt in den HA Clustereinstellungen.

Unter VM restart priority gibt es vier Optionen:

  • Disabled
  • Low
  • Medium
  • High

Ein möglicher Ansatz

  • Man setzt die VM Neustartpriorität clusterweit auf „Low“.
  • Test-VM und unwichtige VM auf „Disabled“. D.h. selbst wenn sie zum Zeitpunkt des Blackouts liefen, würden sie von HA nicht neu gestartet werden. Das schafft Luft für die elementaren Kerndienste.
  • Unter „High“ könnte man z.B. Domaincontroller, DNS/DHCP Server und VirtualCenter (falls virtuell) ansiedeln.
  • Mit Priorität „Medium“ kämen weitere wichtige Server, die von Servern der „High“-Klasse direkt abhängig sind. Z.B. Exchange-, Sharepoint- oder SQL-Server.
  • Der ganze Rest, der keine explizite Regel bekam, erhält die Clustereinstellung mit „Low“, also in der dritten Startwelle.

 

 

VM Autostart Einstellungen verloren

Wenn ESXi Hosts ihre Autostartreihenfolge „vergessen“, dann liegt es oft daran, daß nach der Änderung die Management-Agent nicht neu gestartet wurden. Die Folge sind nicht startende VMs nach einem Kaltstart.

Protokoll zur Änderung der VM Bootreihenfoge

  1. VM Startreihenfolge im vSphere-Client anpassen. Host > Configuration > Virtual Machine startup/shutdown
  2. Management-Agents neu starten
    1. ESXi Konsole (DCUI) öffnen
    2. F2 (customize system)
    3. Login als root
    4. „Troubleshooting Options“ auswählen (ESXi 4.1, ESXi 5.x)
    5. Restart Management Agents
    6. F11
    7. nach erfolgreichem Neustart [Enter] drücken und vom DCUI abmelden.

 

 

SDRS – VM Platzierung und Cluster Fragmentierung

Was passiert wenn eine neue VM auf einem SDRS Cluster erstellt werden soll, der zwar genügend Speicherplatz dafür aufweist, dessen einzelne Datenspeicher aber nicht über genügend Platz für die VM verfügen? Dieses Interessante Thema diskutiert Frank Denneman in seinem Artikel Storage DRS initial placement and datastore cluster defragmentation.

SDRS wird in diesem Fall versuchen, bestehende VMs innerhalb des Storage Clusters zu verschieben, bis die Platzierung der neuen VM gegen keinerlei Beschränkungen oder Obergrenzen verstößt. Obiger Artikel erklärt sehr anschaulich den Prozess der Verschiebung und der Entscheidungsfindung.

Windows Treiberleichen entfernen

In Windows Systemen befinden sich nach einiger Laufzeit eine Menge Gerätetreiber, die mittlerweile nicht mehr gebraucht werden. Besonders interessant ist dies bei der P2V Virtualisierung eines realen Systems. Die ursprünglichen Treiber für z.B. RAID Controller, LAN Adapter usw. können entfernt werden.

Bestandsaufnahme

Ich beschreibe den Vorgang für Windows 7 / Server 2008 (R2), aber er ist ähnlich für 2003 Server. Nur wir in letzterem Fall keine Administrative Kommandokonsole benötigt.

Über START > Suchen > cmd. Mit rechtsklick die Option „als Administrator ausführen“wählen (wichtig bei W7 und Server 2008!). Bei XP/2003 reicht eine normale Kommandozeile.

set devmgr_show_nonpresent_devices=1
start devmgmt.msc

Der Gerätemanager öffnet sich, zeigt aber i.d.R. noch keine inaktiven Geräte. Dazu muß unter „Ansicht“ die Option „ausgeblendete Geräte anzeigen“ aktiviert sein (vgl. Bild unten).

Nun werden auch inaktive, oder aktuell nicht verbundene Geräte aufgelistet. In diesem Fall Bluetooth-Adapter. Der entsprechende Treiber kann entweder durch ein Kontextmenü, oder durch das „Deinstallieren“ Icon in der Funktionsleiste entfernt werden.