Fehler beim Versuch die ausgewählten virtuellen Computer zu starten

[dataKEKS 17]

Hallo Freunde des Hyper-V,

 

ich verzweifle gerade im Zuge des Patchday an einem Hyper-V Problem für das ich einfach keine Lösung finde: Auf unserem Hyper-V (Windows Server 2022 Standard, HPE Proliant ML350 Gen10) laufen rund 20 VMs, darunter auch vier Terminalserver. Alle VMs wurden auf genau diesem Server überhaupt erst in Hyper-V erzeugt und installiert. Wir reden von rein lokalem Speicher, keiner wiederhergestellten Maschine, aber sie legt ein wirklich seltsames Verhalten an den Tag.

 

Wenn wir - so wie heute - die Updates vom Patchday installieren fahren wir nicht extra alle VMs herunter sondern überlassen das dem Hyper-V im Zuge des Neustarts. Bis auf einen TS (auch Windows Server 2022 Standard) klappt das auch mit wirklich allen VMs wunderbar, nur ein TS tanzt aus der Reihe: Er hat den Status gespeichert und kann nicht mehr gestartet werden.

 

Wenn wir versuchen die VM zu starten erhalten wir die Fehlermeldung Fehler beim Versuch die ausgewählten virtuellen Computer zu starten, nur ein gespeicherten Status verwerfen ermöglicht uns die Maschine wieder zu starten :-(

 

Alle Systeme laufen gegen den gleichen, internen WSUS und sollten somit den gleichen Patchstand haben, aber aus irgendeinem mir nicht erfindlichen Grund tanzt eben ein Server aus der Reihe....

 

Kennt jemand dieses Verhalten und hat eine Lösung für mich? Tante Google hat mir bislang nichts hilfreiches geliefert :-(

 

 

Grüße aus BaWü

Norbert

[Nobbyaushb 1.650]

Moin

in Zukunft bitte vor dem reboot vom Host ALLE VM herunterfahren

Der Manager killt die einfach wenn der shutdown zulange dauert

(hier gibt es einen internen Timer, genaue Zeit müsste ich nachlesen. .)

Für die VM gibt es auch einen Workaround, kann ich morgen früh nachschauen

[Nobbyaushb 1.650]

Moin nochmal,

 

guck dir bitte die Anleitung an (ist in englisch)

 

Fixing a Virtual Machine that's Stuck in a Saved State -- Redmondmag.com

 

Grüße aus dem echt kalten Bremen

[dataKEKS 17]

Guten Morgen Norbert (herrlich so ein Gespräch auf Augenhöhe :-)),

 

also empfiehlt der Kollege was ich mir auch schon überlegt hatte: VM neu anlegen und die VHDs der Original VM übernehmen. Werde ich heute Abend mal so ausprobieren, wenn ich unseren Hyper-V jetzt im Tagesbetrieb herunterfahre ist das selbst in den Faschingsferien äußerst ungern gesehen

 

Update folgt

 

 

Norbert (der aus BaWü)

[NorbertFe 2.374]

Hi,

 

ich muss jetzt einfach mal total OT einfach antworten, damit man mal einen Thread nur von Norberts hier sieht. ;)

 

Viel Erfolg

Norbert

[Nobbyaushb 1.650]

Moin,

den Host brauchst du nicht runterfahren, nur die VM

Und Fasching oder Karneval gibts hier (fast) nicht...

[dataKEKS 17]

Jain, ich will ja sehen ob sie nach Neuanlage aus dem Status gespeichert wieder sauber hoch läuft.

 

Norbert (der Dritte??)

[testperson 1.956]

Moin,

 

vor 11 Minuten schrieb Nobbyaushb:

Und Fasching oder Karneval gibts hier (fast) nicht...

das heißt Fastelovend (alles andere ist Fasching)!

 

Gruß

Jan

 

P.S.: Viele wissen es gar nicht, dass ich eigentlich Janorbert mit stummen "orbert" hinter dem "n" heiße. 

 

 

[dataKEKS 17]

Sodele, jetzt konnte ich mich endlich dem Thema wieder widmen und kann folgendes berichten:

 

Da ein Neustart unseres Haupt-Hyper-V im Tagesbetrieb bei den Usern nicht so toll ankommt habe ich die VMs auf einen kleineren, eigentlich nicht mehr benutzten Testserver ausgelagert, einen HPE MicroServer

 

Egal ob ich ihn mit Server 2022 oder 2025 betreibe, die problematischen VMs haben das Problem nach Export auf dem eigentlichen und Import auf dem Testserver beibehalten, das spricht sehr für die Vermutung das wirklich in der Konfiguration ein Fehler steckt und nicht der ausführende Hyper-V das Problem ist.

 

Somit war klar: Jetzt bekommen die beiden problematischen VMs mal eine neue Konfiguration, also VM im Hyper-V gelöscht, neu angelegt und dann die VHDs wieder eingebunden, LAN Konfiguration passend definiert (bei uns VLANs) und die VMs gestartet - funktioniert. Was nur quasi zu erwarten war: Für Windows sind es neue NICs, und damit musste ich noch die statische IP Adresse wieder eintragen. Werde das gleiche noch einmal probieren und vor dem Start der VMs noch die alte MAC Adresse händisch hinterlegen, aber das nur am Rande.

 

Jetzt zum spannenden Teil: Neustart des Hyper-V ohne die VMs vorher herunter zu fahren: Es tut wieder, die VMs können problemlos wiederhergestellt werden ohne irgendeine Änderung am ausführenden Hyper-V

 

Somit wissen wir jetzt schon einmal wie wir das Problem lösen können, wenn jetzt noch die NIC im Zuge der Neuanlage im Hyper-V nicht neu erkannt wird wäre das natürlich noch eine enorme Erleichterung

 

Update folgt.

 

 

Norbert

[dataKEKS 17]

Update: Egal was ich mache, und sei es manuell die alte MAC Adresse im Hyper-V für die VMs hinterlegen: die VMs erkennen bei mir immer eine neue Netzwerkkarte. Sicher kein Weltuntergang, aber für diejenigen, die eine feste MAC / IP brauchen ist es hoffentlich eine hilfreiche Info.

 

Noch eine Auffälligkeit: Windows bindet nur das C: Laufwerk automatisch wieder ein, wenn die VMs wie in meinem Fall aber mehrere Laufwerke haben müssen diese noch händisch in der Datenträgerverwaltung wieder online geschaltet werden. Empfehlung meinerseits: VMs auf jeden Fall nach Neueinrichtung noch mal neu starten damit sie mit allen Partitionen / Laufwerken und korrekter LAN Verbindung einen clean boot erreichen kann

 

 

Norbert

bearbeitet 20. Februar von dataKEKS

[NorbertFe 2.374]

Das ist normal und keine wirklich neue Erkenntnis 😉

[dataKEKS 17]

vor 1 Minute schrieb NorbertFe:

Das ist normal und keine wirklich neue Erkenntnis 😉

Na Du schaffst es aber immer wieder meine Hoffnung an das gute in der IT zu torpedieren *jammer*