Bents Blog

 

Ein IT Blog mit Themen aus dem Windows Server Umfeld.

Reboot von Hyper-V VMs führt zur Systemwiederherstellung

Noch im vergangenen Jahr stellten wir auf unseren Kundensystemen ein extrem merkwürdiges Verhalten fest. Nach den letzten Aktualisierungen durch Windows Updates booten einige der Windows Server 2008 R2 VMs in die Systemwiederherstellung (Recovery Modus). Bisher betrifft das nach unseren Erfahrungen lediglich Maschinen mit Windows Server 2008 R2, die auf einem Microsoft Hyper-V Cluster betrieben werden – sowohl die Host-Systeme (ebenfalls 2008 R2 Datacenter) als auch die virtuellen Maschinen sind vollständig mit Windows Updates versorgt.

Problem

Da wir – bedingt durch verschiedene Notwendigkeiten der Systempflege – auf vielen Systemen automatische Reboots konfigurieren, starten die meisten der Server in unterschiedlichen Rhythmen während der Nacht neu. Typischerweise nutzen wir dafür die Aufgabenplanung und das seit Windows Server 2003 integrierte Systemprogramm shutdown.exe.

Aufgabenplanung: Neustart des Servers

Als Parameter für den Aufruf von shutdown verwenden wir typischerweise

%SystemRoot%\System32\shutdown.exe -r -f -t 0

welche für einen sofortigen, forcierten Reboot erwirken. Bisher funktionierte diese Lösung reibungsfrei – erst seit einigen Tagen beobachteten wir bei einigen der virtualisierten Maschinen, dass diese beim Neustart die Systemwiederherstellung starteten.

Neustart in die Systemwiederherstellung

Dies ist extrem ärgerlich, da so sämtliche Funktionen des Servers natürlich nicht zur Verfügung stehen. Bricht man den Dialog über die verbundene Konsole ab, so startet das System das Betriebssystem im Anschluss anstandslos neu.

Lösung

Da wir die Ursache für dieses Verhalten konnten wir bisher noch nicht finden, allerdings lässt sich selbiges mit einer Konfigurationsänderung (Workaround) des Windows-Start-Managers umgehen. Über den Kommandozeilenbefehl

bcdedit /set {default} bootstatuspolicy ignoreallfailures

wird die Neustart-Policy für den Standard-Boot-Eintrag auf IgnoreAllFailures gesetzt. Mit dem Befehl bcdedit kann man im Anschluss die geänderte Einstellung kontrollieren:

Windows-Startladeprogramm
-------------------------
Bezeichner {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows Server 2008 R2
locale de-DE
inherit {bootloadersettings}
recoverysequence {fabb4230-3ae7-11e2-a422-c35845ecfe8e}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {fabb422e-3ae7-11e2-a422-c35845ecfe8e}
nx OptOut
bootstatuspolicy IgnoreAllFailures

Nach dieser Einstellung trat das beschriebene Verhalten bei keiner der betroffenen virtuellen Maschinen mehr auf.

Fazit

Das hier dokumentierte Verhalten lässt sich bisher nicht erklären – Fehler an den virtuellen Maschinen konnten wir bisher ausschließen. Ob die Ursache bei neuen Windows Updates zu suchen ist, lässt sich leider nur vermuten. Wer hier Näheres weis, den bitte ich um einen kurzen Kommentar. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.

6 Kommentare für “Reboot von Hyper-V VMs führt zur Systemwiederherstellung”

  • Nils Kaczenski

    Moin Bent,

    einen Hinweis auf eine Ursache des Fehlers habe ich nicht. Allerdings rate ich entschieden von pauschal eingerichteten automatischen Reboots ab. Nötig sind sie nur selten bis nie, und wenn es mal Probleme beim Reboot gibt, sind die Auswirkungen eben so, wie du sie beschreibst …

    Schöne Grüße, Nils

  • Markus Rödel

    Ich würde bei der Ursachenforschung eher in Richtung ‚zu schnelles Runterfahren‘ suchen. Durch den /f Parameter werden u.U. Prozesse abgewürgt, bevor sie sauber runterfahren können. Den würd ich mal weglassen, außerdem bei VM-Hosts den WaitToKillServiceTimeout Reg-Eintrag länger machen.

    Viele Grüße,
    Markus

  • Bent Schrader

    Hallo Nils und Markus,

    vielen Dank für die Hinweise. Allerdings spricht allein die Häufigkeit und Anzahl an Windows Updates gegen manuelle Neustarts – die sind bei fast allen Kundensystemen nie am Tage und somit kaum von Hand durchführbar.

    Den Schalter -f können wir nach unseren bisherigen Erfahrungen ebenfalls ausschließen, da das oben beschriebene Verhalten nur unter HyperV virtualisierten Maschinen auftritt – bei VMware (gleiches Betriebssystem und gleicher Patch-Stand) war dies nicht der Fall.

    Gruß,
    Bent

  • Karl Widmer

    Hallo Bent

    Ich bin heute in genau das gleiche Problem geraten wie Du es hier schilderst. Der Unterschied ist jedoch das mein Problem auf vSphere 5 mit ESX-Hosts passiert ist. Bei vier Terminalservern (Server 2008 R2) habe ich Windows Updates eingespielt und danach die Maschinen neugestartet. Drei von vier Maschinen haben in die Systemwiederherstellung gebootet, einer läuft einwandfrei.

    Was mich jedoch stutzig macht ist die Tatsache, dass ein Restore der kompletten virtuellen Maschine insofern fehlschlägt, dass auch die VM nach dem Restore in die Systemwiederherstellung rein bootet.

    Die bekannten Mittel (fixmbr, fixboot, selbst ein rebuildbcd) haben nicht geholfen. Auch dein Tipp mit dem bcdedit half leider nicht. So musste ich den bestehenden Terminalserver erst in ein Template klonen, welches nun mit dem Anpassungsassistenten von VMware in drei neue Terminalserver geklont wird.

    Wie es scheint besteht dieses Problem in meinem VM’s schon länger, wurde jetzt aber erst durch einen Reboot und die Windows Updates ausgelöst.

    Ich werde wohl oder übel nicht um einen Microsoft-Call herum kommen.

    Viele Grüsse
    Karl

  • Bent Schrader

    Hallo Karl,

    vielen Dank für Deinen Hinweis. Interessanterweise habe ich am vergangenen Freitag bei einem weiteren Kunden – hier aber wieder mit Hyper-V Virtualisierung – das gleiche Phänomen erneut beobachtet:

    Beim Installieren der letzten Windows Updates und dem anschließenden, erforderlichen Neustart booteten alle virtuellen Maschinen in den Recovery Modus. Nach einem Abbruch ließen sich die Maschinen danach aber zumindest neu starten.

    Ich bin gespannt, ob es weitere Fälle gibt und Microsoft bereits Kenntnis von diesem äußerst merkwürdigem Verhalten hat.

    Gruß,
    Bent

  • Unkown

    Hallo.

    Wie ging es hier weiter ? Haben auch nach Jahren das gleiche Problem noch.
    Gruß und danke.

Einen Kommentar hinterlassen:

Antispam Bee hat Bent's Blog vor 410.433 Spam-Kommentaren bewahrt.