Den Hypervisor zu patchen ist der Moment, in dem alle virtuellen Maschinen gemeinsam einen Neustart oder einen Umzug erleben. Das ist planbar, wenn das Fenster, die Reihenfolge und der Rückweg feststehen. Es wird zur Überraschung, wenn am selben Abend die Firmware des Controllers, das Host-Update und das Feature-Update der Datenbank-VM laufen. Fällt danach etwas aus, weiß niemand, welche der drei Änderungen die Anwendung getroffen hat. Ein Schritt pro Fenster hält die Ursache zuordenbar.

Warum Host, Firmware und SQL nicht in eine Nacht gehören

Auf einem Cluster oder bei Replica lassen sich Maschinen vorher wegfahren, der Knoten geht in Wartung, und der Patch läuft ohne Stillstand der Gäste, sofern der zweite Knoten sie trägt. Auf einem Einzelhost stehen die Maschinen, solange der Host neu startet. Das muss die Fachabteilung wissen, inklusive der voraussichtlichen Dauer und der Person, die danach einen echten Vorgang prüft. Ein Patch „nachts, es merkt schon niemand“ scheitert an der Lohnverrechnung, die um sechs Uhr startet und auf einen nicht hochgekommenen Dienst trifft.

Firmware von BIOS, RAID-Controller und Netzwerkkarte folgt der Vorgabe des Serverherstellers und der Kompatibilitätsliste der Hypervisor-Version. Manche Plattformen wollen ein abgestimmtes Bündel, andere ein separates Fenster. Ein Controller-Update, das die Datastores beim ersten Start anders präsentiert, ist kein normales Gast-Update und braucht eine aktuelle Sicherung, die außerhalb des Hosts liegt. Gast-Tools und VM-Hardwareversion werden danach angefasst, nicht im selben Atemzug wie ein unbekanntes Firmware-Risiko.

Fenster, Reihenfolge und ein Start danach

  1. Trennen. Host-Patch, Firmware und große Gast-Updates bekommen eigene Fenster. In einem Termin läuft ein Thema, damit eine Störung zuordenbar bleibt.
  2. Sichern. Vor dem Host-Patch liegt eine brauchbare Sicherung außerhalb des Geräts. Snapshots, die dafür angelegt werden, haben ein Löschdatum am nächsten Werktag.
  3. Verlagern. Können Maschinen auf einen anderen Knoten, gehen sie vor dem Patch dorthin. Auf einem Einzelhost wird die Stillstandzeit angesagt, nicht versteckt.
  4. Reihenfolge. Nach dem Start kommt eine unkritische VM, dann Infrastruktur, dann die Anwendung. Die Fachabteilung prüft einen Vorgang, bevor das Fenster zu ist.
  5. Nachzug. Gast-Tools und Hardwareversion der VMs folgen in einem späteren, kleinen Schritt. Firmware nur nach Herstellervorgabe und Kompatibilitätsliste.

Der Rückweg ist die Sicherung vor dem Fenster und, wo die Plattform das hergibt, ein dokumentierter Stand des Hosts, nicht ein Snapshot jeder Datenbank „für alle Fälle“, der danach liegen bleibt. Wir kündigen das Fenster so an, wie andere Wartungen auch: Werktag, erreichbare Fachperson, Sperrzeiten für Abschluss und Inventur. Notfallpatches behandeln wir enger und trotzdem nicht als Freifahrtschein, am Freitag alles mitzunehmen.

Woran Projekte in der Praxis scheitern

  • Firmware, Hypervisor und SQL-Update in derselben Nacht kombinieren.
  • Den Einzelhost am Freitag nach Betriebsschluss patchen, ohne dass am Samstag jemand einen Fehlstart bemerkt.
  • Wartungssnapshots auf den Datenbanken liegen lassen.
  • Die Warenwirtschaft als Erstes starten und erst danach feststellen, dass das Netz des Hosts nicht steht.

Beispiel aus dem Betriebsalltag

Ein Fertigungsbetrieb hatte Host-Firmware, ESXi-Update und ein Windows-Feature-Update der Maschinen-VM auf denselben Donnerstagabend gelegt. Nach dem Start fand die Anwendung ihren Lizenzdienst nicht; drei Änderungen waren gleichzeitig geschehen. Beim nächsten Mal haben wir nur den Hypervisor gepatcht, die Firmware auf ein eigenes Fenster mit Herstellervorgabe gelegt und die Gäste unverändert gelassen. Zuerst kam eine kleine Dienst-VM, dann Dateidienst, dann die Anwendung, und die Produktion prüfte einen Auftrag, bevor das Fenster geschlossen wurde. Das Feature-Update der Gäste lief eine Woche später, mit einem eigenen Rückweg. Die Ursache wäre diesmal zuordenbar gewesen, und der Abend blieb innerhalb des vereinbarten Fensters.

Kurze Entscheidungshilfe

  • Ist das Fenster ein Werktag mit einer benannten fachlichen Prüferin oder einem Prüfer?
  • Liegt die Sicherung vor dem Patch außerhalb des Hosts?
  • Steht die Startreihenfolge auf demselben Blatt wie der Termin?
  • Bleiben Firmware und Gast-Feature-Updates außerhalb dieses Termins?

Wenn Hypervisor-Updates ohne Überraschung bei Ihnen ansteht, klären wir den Umfang unverbindlich: Virtualisierung. Hyper-V Einzelhost oder Cluster Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.