4
Hyper-V Verwaltungsdienst stürzt ständig ab
Hallo zusammen,
ich habe ein kleines Problem bei einem Kunden, dessen Netz ich betreue. Dort laufen zwei Server mit Windows Server 2012 R2 und Hyper-V Virtualisierung (autark voneinander, ohne Cluster). Soweit läuft auch alles wunderbar, ich habe nur das Problem, dass ich vor Konfigurationsänderungen in Hyper-V, Erstellen/Anpassen von VMs und dem Start des Backups (mithilfe von MS SCDPM 2016) der VMs jedesmal den Dienst "Hyper-V Verwaltung für virtuelle Computer" in der Dienstesteuerung neu starten muss. Ich bekomme sonst die Fehlermeldung, dass die Änderung aufgrund eines unbekannten Fehlers nicht möglich ist. Der Dienst scheint intern nach einiger Zeit abzustürzen, obwohl er noch läuft. Im Eventlog sehe ich keinerlei Auffälligkeiten, solange der Dienst läuft und nichts an Hyper-V verändert wird oder ein Backup der VMs gezogen wird. Bei Backups bekomme ich dann z.B. wieder die Meldung, dass die VSS-Kopie der VMs wegen eines unbekannten Fehlers nicht erstellt werden kann. Starte ich den oben genannten Dienst neu, funktioniert alles soweit einwandfrei.
Kann mir da jemand weiterhelfen?
Vielen Dank schonmal im Vorraus.
VG
ich habe ein kleines Problem bei einem Kunden, dessen Netz ich betreue. Dort laufen zwei Server mit Windows Server 2012 R2 und Hyper-V Virtualisierung (autark voneinander, ohne Cluster). Soweit läuft auch alles wunderbar, ich habe nur das Problem, dass ich vor Konfigurationsänderungen in Hyper-V, Erstellen/Anpassen von VMs und dem Start des Backups (mithilfe von MS SCDPM 2016) der VMs jedesmal den Dienst "Hyper-V Verwaltung für virtuelle Computer" in der Dienstesteuerung neu starten muss. Ich bekomme sonst die Fehlermeldung, dass die Änderung aufgrund eines unbekannten Fehlers nicht möglich ist. Der Dienst scheint intern nach einiger Zeit abzustürzen, obwohl er noch läuft. Im Eventlog sehe ich keinerlei Auffälligkeiten, solange der Dienst läuft und nichts an Hyper-V verändert wird oder ein Backup der VMs gezogen wird. Bei Backups bekomme ich dann z.B. wieder die Meldung, dass die VSS-Kopie der VMs wegen eines unbekannten Fehlers nicht erstellt werden kann. Starte ich den oben genannten Dienst neu, funktioniert alles soweit einwandfrei.
Kann mir da jemand weiterhelfen?
Vielen Dank schonmal im Vorraus.
VG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 328115
Url: https://administrator.de/forum/hyper-v-verwaltungsdienst-stuerzt-staendig-ab-328115.html
Ausgedruckt am: 26.12.2024 um 20:12 Uhr
4 Kommentare
Neuester Kommentar
Moinsen,
bissl wenig Infos!
meine Fragen:
- Welches OS haben die VMs?
- ist auf dem Hyper-V noch eine andere Rolle installiert?
Grüße
der jenni
bissl wenig Infos!
meine Fragen:
- Welches OS haben die VMs?
- ist auf dem Hyper-V noch eine andere Rolle installiert?
Grüße
der jenni
Alle VMs haben Server 2012 R2 mit den neusten Integrationsdiensten installiert. Auf dem Host läuft sonst gar nichts mehr.
Grüße
Grüße
Hi
ich habe ein kleines Problem bei einem Kunden, dessen Netz ich betreue. Dort laufen zwei Server mit Windows Server 2012 R2 und Hyper-V Virtualisierung (autark voneinander, ohne Cluster). Soweit läuft auch alles wunderbar, ich habe nur das Problem, dass ich vor Konfigurationsänderungen in Hyper-V, Erstellen/Anpassen von VMs und dem Start des Backups (mithilfe von MS SCDPM 2016) der VMs jedesmal den Dienst "Hyper-V Verwaltung für virtuelle Computer" in der Dienstesteuerung neu starten muss. Ich bekomme sonst die Fehlermeldung, dass die Änderung aufgrund eines unbekannten Fehlers nicht möglich ist.
Wie lange / Seit wann besteht das Problem mit dem Dienst ?
Wurden zuvor Updates eingespielt, Treiber aktuallisiert oder ähnliches ?
Tritt der Fehler bei beiden Hyper-V-Servern auf ?
Der Dienst scheint intern nach einiger Zeit abzustürzen, obwohl er noch läuft. Im Eventlog sehe ich keinerlei Auffälligkeiten, solange der Dienst läuft und nichts an Hyper-V verändert wird oder ein Backup der VMs gezogen wird. Bei Backups bekomme ich dann z.B. wieder die Meldung, dass die VSS-Kopie der VMs wegen eines unbekannten Fehlers nicht erstellt werden kann. Starte ich den oben genannten Dienst neu, funktioniert alles soweit einwandfrei.
Gibt es Einträge zu den VSS Writern bzw. wie ist der Status der VSS-Writer?Gruß,
Chris
Effektiv besteht das Problem seit dem Aufsetzen der beiden Server. Ich habe mir darüber anfangs nie groß Gedanken darüber gemacht, aber da jetzt die Backups den Dienst erfordern, muss ich dem nachgehen. Ich habe schon die neusten Updates und Treiber eingespielt, aber es hat keinen Effekt.
Im Ereignislog tauchen seit dem letzten Vollbackup (welches jeden Freitag Abend um 0:00 Uhr läuft) folgende Einträge auf:
Ereignis-ID 19510:
Ereignis-ID 2:
Laut vssadmin sind alle VSS-Write OK. Die Tagessicherungen (montags bis freitags um 20:30 Uhr) laufen mit dem Neustart des Dienstes auch einwandfrei durch.
Beim Vollbackup sollen alle Maschinen auf VM-Ebene als Bare-Metal-Recovery gesichert werden. Die Tagessicherungen ziehen nur die Produktivdaten auf Applikations-/Fileebene ab.
Im Ereignislog tauchen seit dem letzten Vollbackup (welches jeden Freitag Abend um 0:00 Uhr läuft) folgende Einträge auf:
Ereignis-ID 19510:
Die Beschreibung für die Ereignis-ID "19510" aus der Quelle "Microsoft-Windows-Hyper-V-VMMS" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.
Falls das Ereignis auf einem anderen Computer aufgetreten ist, mussten die Anzeigeinformationen mit dem Ereignis gespeichert werden.
Die folgenden Informationen wurden mit dem Ereignis gespeichert:
%%2147942480
0x80070050
Die gebietsschemaspezifische Ressource für die gewünschte Meldung ist nicht vorhanden.Ereignis-ID 2:
Beim Starten der Sitzung "" ist der folgende Fehler aufgetreten: 0xC0000022. Laut vssadmin sind alle VSS-Write OK. Die Tagessicherungen (montags bis freitags um 20:30 Uhr) laufen mit dem Neustart des Dienstes auch einwandfrei durch.
Beim Vollbackup sollen alle Maschinen auf VM-Ebene als Bare-Metal-Recovery gesichert werden. Die Tagessicherungen ziehen nur die Produktivdaten auf Applikations-/Fileebene ab.
