Sporadische Probleme beim Verbinden zu virtuellen Maschinen

[Pinky__ 0]

Tag zusammen,

 

ich habe seit kurzem ein Problem mit meiner Virtualisierung - vielleicht hat ja einer von euch eine Idee.

Seit einiger Zeit wird keine Verbindung mehr zu meinen virtuellen Maschinen im Hyper-V aufgebaut. Das bedeutet, das Fenster zu den Maschinen öffnet sich nicht mehr. Dieses Problem tritt nur sporadisch auf und lässt sich durch einen Neustart beheben.

 

Der Hyper-V Manager funktioniert ganz normal, der Status aller Maschinen wird angezeigt und diese laufen normal. Sie tun nachweislich ihre Arbeit. Bei einem doppelklick auf die Maschinen, (oder rechtsklick "verbinden") tut sich aber nichts -> das Fenster öffnet sich nicht.

 

Kleine Korrektur: Ich habe den Hyper-V Manager mal geschlossen und wieder geöffnet: Anschließend öffnet sich der Hyper-V Manager aber keine Maschinen werden angezeigt. Ob diese in dem jetzigen Zustand noch laufen kann ich im moment nicht sagen.

 

Begleiterscheinung: Wenn ich nun versuche die Kiste neu zu starten hängt sich der Server beim Neustart auf. (hängt im blauen "wird neu gestartet" screen).

Ein Kaltstart setzt alles zurück auf Anfang, die Maschinen sind dann zugreifbar. Bis irgendwann dieses Problem wieder auftritt. Dauert einige Tage, manchmal Wochen. In dieser Zeit verbinde ich mich täglich mehrfach zu den Maschinen.

 

Jemand eine Idee, oder ähnliche Erfahrungen gemacht?

 

Gruß Pinky

bearbeitet 5. November 2019 von Pinky__

[testperson 1.677]

Hi,

 

was findet sich denn im Fehlerzustand alles in den Eventlogs?

Auf was für einer Hardware läuft der Hyper-V und wo / auf welchem Storage liegen die VMs? Hier sind Firmware und Treiber sowie das OS (welches?) aktuell?

 

Ob die VMs noch laufen, sollte sich feststellen lassen, indem du auf die Dienste der VM zugreifst, die werden ja irgendwas machen. :)

 

Gruß

Jan

 

[Pinky__ 0]

Hi Jan,

 

ich habe zwischenzeitlich alle Dienste "von Hand" beendet und mich dann nochmal an einem Neustart versucht. Leider ist der Server trotzdem hängengeblieben und hängt jetzt im "starte neu"-modus herum. Die Remotedesktopverbindung funktioniert zwar noch bis dahin, aber leider habe ich jetzt keinen Einfluss mehr auf den Server. Sobald ich zur Maschine komme starte ich die Karre neu, dann gibts infos zu den Eventlogs.

 

Die Festplatten laufen im eingebauten Array als Raid 0. Darauf liegen sowohl OS als auch Maschinen und Storage der Maschinen.

Das OS ist aktuell, ebenso die Treiber. Firmware müsste ich prüfen, aber da mir gerade der Einfluss auf die Maschine fehlt muss ich auch hier nachliefern.

 

Ob die Dienste der VM noch laufen prüfe ich beim nächsten mal wenn die Karre abschmiert.

Es wirkt auf mich so, als würde der Virtualisierungsdienst abstürzen. -> Wenn ich den Hyper-V Manager öffne erscheint ja üblicherweise links die Baumstruktur:

 

Server

->v-Host 1

->v-Host 2

-> etc

 

Diese Baumstruktur wird nicht angezeigt - weder der Server noch die Hosts darunter. Daraus schließe ich, dass der gesamte Dienst abgestürzt ist. Einige virtualisierungsprozesse liefen allerdings noch als ich diese überprüft habe. Ich habe sie von Hand beendet - das hatte allerdings keinen Einfluss auf das System oder die Darstellung. Beim erneuten öffen des Hyper-V Managers blieb die Anzeige unverändert.

 

Mich irritiert, dass der Server sich beim Neustart aufhängt. Irgendwas blockiert da das herunterfahren.

 

Gruß Pinky

 

[Sunny61 806]

Ereignisprotokoll hat @testperson gemeint. Windows Taste + R > Ausführen > Eventvwr.msc [ENTER].

[djmaker 95]

Welche Version von Hyper-V setzt Du ein? RAID0 for OS und VMs ist außerdem recht gewagt . . . .

[Pinky__ 0]

@djmaker das stimmt. Ursprünglich war die Lokale festplatte ausschließlich für das OS gedacht. Die VMs lagen eigentlich auf dem angeschlossenen NAS. Es hat sich aber herausgestellt, dass die Geschwindigkeit der Datenübertragung nicht ausreicht, sodass die Dienste ihre Daten nicht schnell genug abspeichern können wenn die Daten übertragen werden müssen. Also mussten die Daten der VMs rüber wandern. Im selben Atemzug sind dann 2 weitere Festplatten eingezogen, um den Speicherplatz zu erweitern. Aus kostengründen ist die Lösung für den Moment noch so. Das eventuelle Drama hält sich in grenzen, da die virtuellen Maschinen sämtliche Daten ihrerseits ebenfalls auf dem NAS ablegen und nur das OS der VMs lokal betrieben wird.

 

Zur Sache:

Ich habe gestern die Kiste neu gestartet und dabei ist mir folgendes aufgefallen:

Es scheint sich um zwei unterschiedliche Probleme zu handeln, bezüglich der abstützenden virtualisierung und dem aufhängen beim Neustart.

Nach dem Kaltstart des Servers ist dieser wieder korrekt hochgefahren und die virtualisierung lief ohne Probleme wieder an. Ich habe auf Updates geprüft und den Server sicherheitshalber noch einmal durchgestartet. (durchstarten wollen) Er ist beim Neustart wieder hängen geblieben. Es scheint also so zu sein, dass sich der Server grundsätzlich beim Neustart aufhängt.

 

Gleichzeitig ist es so, dass die Virtualisierung alle Nase lang wie oben beschrieben in die Fritten wandert.

 

Ich vermute fast, dass ich um ein neuaufsetzen nicht herumkomme.

Aber zuerst mal die versprochenen Fakten:

 

Windows Server 2016 updates stets auf Stand. (v 10.0.14393 Build 14393)

Hyper-V Manager 10.0.14393.0

Management Console 3.0 Version 1607

 

Hardware: ProLiant DL360 G7

BIOS Version: HP P68, 16.08.2015

 

 

 

Ereignisprotokoll:

Kritisch	05.11.2019 16:12:36	Microsoft-Windows-Kernel-Power	41	(63)	Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.
Kritisch	05.11.2019 15:02:47	Microsoft-Windows-Kernel-Power	41	(63)	Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.
Kritisch	27.10.2019 07:13:24	Microsoft-Windows-Kernel-Power	41	(63)	Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.
Kritisch	21.10.2019 16:36:21	Microsoft-Windows-Kernel-Power	41	(63)	Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.
Kritisch	08.09.2019 15:10:07	Microsoft-Windows-Kernel-Power	41	(63)	Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.

 

 

 

[testperson 1.677]

vor 18 Minuten schrieb Pinky__:

Hardware: ProLiant DL360 G7

Laut Support Matrix ist Server 2012 R2 das letzte Supportete OS für den DL360 G7: https://techlibrary.hpe.com/us/en/enterprise/servers/supportmatrix/windows.aspx#.WLz3-zs19jE

 

vor 21 Minuten schrieb Pinky__:

Die VMs lagen eigentlich auf dem angeschlossenen NAS.

Was ist das für ein NAS und wie ist es angebunden? Das kann Hyper-V ebenfalls ganz schön aus dem Tritt bringen.

[Pinky__ 0]

@testperson

vor einer Stunde schrieb testperson:

Laut Support Matrix ist Server 2012 R2 das letzte Supportete OS für den DL360 G7: https://techlibrary.hpe.com/us/en/enterprise/servers/supportmatrix/windows.aspx#.WLz3-zs19jE

Bislang lief es einwandfrei - etwa über einen Zeitraum von ca 2 Jahren. Daher gehe ich davon aus, dass sich jetzt irgendetwas geändert hat, was zu den beschriebenen Problemen führt.

 

Ich habe gerade mal einiges an Software runtergehauen was ggf. zu Konflikten führen kann. Mal sehen ob das abhilfe schafft. Alternativ setze ich am Wochenende neu auf, falls wir nicht noch überraschend die Lösung finden.

 

vor einer Stunde schrieb testperson:

vor einer Stunde schrieb Pinky__:

Die VMs lagen eigentlich auf dem angeschlossenen NAS.

Was ist das für ein NAS und wie ist es angebunden? Das kann Hyper-V ebenfalls ganz schön aus dem Tritt bringen.

Die VMs _lagen_ auf dem NAS. Wie beschrieben habe ich sie da runtergeholt, weil die Performance nicht ausreicht um die Betriebsysteme aus dem Netzwerk heraus zu betreiben. VMs und HDDs der VMs liegen jetzt im lokalen Raid 0 des Servers. Die VMs selbst haben das Nas wiederum als Netzlaufwerk angebunden und kopieren Dateien nach der fertigen Bearbeitung auf das NAS.

Beispielsweise:

* Eine wawi erstellt rechnungs-pdfs etc, welche lokal auf C:\ gespeichert werden. Eine Batch kopiert diese PDFs regelmäßig auf das angebundene NAS.

* Ebenfalls wird ein backup der Wawi-DB regelmäßig erstellt, lokal gespeichert und dann rüberkopiert. Reine netzwerk-Datentransfer-Aufgaben, keine Prozesse die über das Netzwerk gestartet werden oder ähnliches.

* Dateien werden zum Konvertieren aus dem Netzwerk rüberkopiert, transcodiert und zurück-kopiert.

 

Das OS der Maschinen ist also absolut unabhängig vom NAS.

Es handelt sich dabei um ein QNAP TS 669 Pro.

 

 

Gruß

[Dukel 454]

Ist das ganze Produktiv oder eine Testumgebung?

[Pinky__ 0]

Produktiv im privaten Umfeld.

[Pinky__ 0]

Guten Morgen zusammen,

 

in der Zwischenzeit konnte ich etwas konkretere Informationen sammeln.

Heute morgen ist das System wieder abgestürzt. Derzeit befindet sich das System in dieserm abgestürzten Modus.

-> Ich kann keine Verbindung zu einer VM aufbauen

-> Die VMs haben Ihren Dienst eingestellt

--> Offenbar ist dies passiert nachdem ich mich zu den VMs verbinden wollte. Bis dahin liefen sie.

--> Der noch geöffnete Server Manager zeigt mir an, dass einige von den Maschinen Prozessorlast haben. (3% schwankend) Die Dienste die darauf laufen sind aber nicht verfügbar.

 

Beim Versuch auf die VMs zu verbinden werden folgende Logs geschrieben:

 

.Net Runtime

Anwendung: VmConnect.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: Microsoft.Management.Infrastructure.CimException
   bei Microsoft.Management.Infrastructure.Internal.Operations.CimSyncEnumeratorBase`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext()
   bei System.Linq.Enumerable+WhereSelectEnumerableIterator`2[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext()
   bei Microsoft.Virtualization.Client.Management.Server.LoadOSInfo()
   bei Microsoft.Virtualization.Client.ConnectionHelper.ConnectServer(Microsoft.Virtualization.Client.InformationDisplayer, System.String, Boolean, Microsoft.Virtualization.Client.Common.IUserPassCredential)
   bei Microsoft.Virtualization.Client.ConnectionHelper.TryGetVirtualMachinesInternal(System.String, Microsoft.Virtualization.Client.Common.WindowsCredential, Mode, System.String, System.Guid, Microsoft.Virtualization.Client.Management.IVMComputerSystem ByRef, System.Collections.Generic.List`1<System.String> ByRef, System.Exception ByRef)
   bei Microsoft.Virtualization.Client.InteractiveSession.CommandLineParser.TryParse(System.String[], Microsoft.Virtualization.Client.InteractiveSession.RdpConnectionInfo ByRef)
   bei Microsoft.Virtualization.Client.InteractiveSession.VmisApplicationContext.TryParseCommandLine(System.String[])
   bei Microsoft.Virtualization.Client.InteractiveSession.Program.Main(System.String[])

sowie

 

Application Error


Name der fehlerhaften Anwendung: VmConnect.exe, Version: 10.0.14393.0, Zeitstempel: 0x5789927d
Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.14393.3269, Zeitstempel: 0x5d9133fb
Ausnahmecode: 0xe0434352
Fehleroffset: 0x0000000000034c48
ID des fehlerhaften Prozesses: 0x4c58
Startzeit der fehlerhaften Anwendung: 0x01d598512a86b819
Pfad der fehlerhaften Anwendung: C:\Windows\system32\VmConnect.exe
Pfad des fehlerhaften Moduls: C:\Windows\System32\KERNELBASE.dll
Berichtskennung: 627727eb-213c-44ed-a882-43e6c2f9c049
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 

 

 

Diese beiden Fehlermeldungen wiederholen sich bei jedem Versuch zu einer der Maschinen zu verbinden. Die Maschine bei der der Fehler vorhin auftrat ist vorgestern aufgesetzt worden und wurde gestern eingerichtet. Sie ist also "brandneu".

 

Ein paar Minuten vor dem ersten Verbindungsversuch findet sich im Log noch folgende Fehlermeldung:

 

DeviceSetupManager

Fehler beim Staging von Metadaten. Ergebnis=0x8007000D für Container "{00000000-0000-0000-FFFF-FFFFFFFFFFFF}".

 

 

Jemand eine Idee was das Problem sein könnte?

 

Gruß

 

 

 

Edit: (Nachtrag)

 

Ein vielleicht nicht ganz unerhebliches Detail:

 

In der Ergebnisanzeige der Logs bekomme ich ebenfalls Fehler ausgeworfen. Beim Versuch die Fehlermeldungen unter

- Server

--> Hyper-V

oder

--> Remotedesktopdienste

 

anzuzeigen bleibt das Fenster leer (grau) und ich bekomme ein Popup:

"Abfragefehler"

Mindestens ein Protokoll in der Abfrage enthält Fehler. Die angezeigten Ergebnisse sind Teilergebnisse.

 

Einträge die wiederhergestellt wurden lauten:

Microsoft Windows Hyper-V High Avaiability Admin: Der Angegebene Kanal wurde nicht gefunden

Microsoft Windows Hyper-V Integration Admin: Der Angegebene Kanal wurde nicht gefunden

bearbeitet 11. November 2019 von Pinky__

[Nobbyaushb 1.471]

Meine Frage lautet - ist das Marken-Hardware, gibt es einen Service-Vertrag, ist die Hardware noch so neu, das man beim Hersteller einen Call aufmachen kann?

[Pinky__ 0]

Der Server selbst ist ein HP ProLiant, im Originalzustand. Keine anderen Bauteile verbaut. Einen Servicevertrag gibt es nicht und der allerneuste ist es auch nicht mehr - insofern: Nein, leider nicht.

 

Vermutest du ein Hardwareproblem?

Basierend auf den Fehlermeldungen google ich gerade etwas durch die Gegend und bin hierauf gestoßen:

https://community.spiceworks.com/topic/2104499-jan-2018-windows-updates-kb4056898-causing-hyper-v-guests-crash

 

Das hier beschriebene Problem ähnelt meinem. Das betroffene Update ist bei mir allerdings nicht zu finden. Dennoch finde ich den Ansatz sinnvoll, die Updates zurückzurollen. Das Problem besteht noch nicht allzu lange und Irgendwie muss es seinen Weg hinein ins system gefunden haben. Hier verdächtige ich ebenfalls die Updates. Also rolle ich mal 3-4 Monate zurück. Mal sehen ob das hilft. Anschließend starte ich die Karre neu. Mal sehen ob sie dann wieder komplett abglitscht.

bearbeitet 11. November 2019 von Pinky__