6
HyperV 2019 - Events 3020 und 12054
Moin,
wir haben zwei, von der Hardware her, identische Primergy RX2540 M5-Server mit identischem Treiberstand und Windows Server 2019 Datacenter als Betriebssystem. Beide sind HyperV-Hosts, die VMs wurden von Server 2012R2 migriert, die Konfigurationsversion angepasst (5.0 auf 9.0).
So weit keine Probleme, allerdings hängt einer der Server beim Reboot / Herunterfahren ewig, weil versucht wird, den HyperV-Dienst zu beenden. Nach zwei Stunden reicht mir das Spiel und ich führe ein Reset aus, der Server startet dann auch wieder normal.
Im Eventlog (Hyper-V-Worker) sehe ich dann für verschiedene VMs die Events 3020 und 12054 (nicht für alle)
Manchmal (auch nicht immer) folgt dann noch Event 12054:
Die Google-Suche zeigt mir da nix an (oder ich google falsch)...
Gruß
wir haben zwei, von der Hardware her, identische Primergy RX2540 M5-Server mit identischem Treiberstand und Windows Server 2019 Datacenter als Betriebssystem. Beide sind HyperV-Hosts, die VMs wurden von Server 2012R2 migriert, die Konfigurationsversion angepasst (5.0 auf 9.0).
So weit keine Probleme, allerdings hängt einer der Server beim Reboot / Herunterfahren ewig, weil versucht wird, den HyperV-Dienst zu beenden. Nach zwei Stunden reicht mir das Spiel und ich führe ein Reset aus, der Server startet dann auch wieder normal.
Im Eventlog (Hyper-V-Worker) sehe ich dann für verschiedene VMs die Events 3020 und 12054 (nicht für alle)
Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
Quelle: Microsoft-Windows-Hyper-V-Worker
Datum: 11.02.2020 21:33:29
Ereignis-ID: 3020
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: NT VIRTUAL MACHINE\82863288-1340-425A-90A6-2D570F5F7EAB
Computer: HyperV-Server.domaene.local
Beschreibung:
Die Beschreibung für die Ereignis-ID "3020" aus der Quelle "Microsoft-Windows-Hyper-V-Worker" 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:
VM-NAME
82863288-1340-425A-90A6-2D570F5F7EAB
%%2147942402
0x80070002
Die gebietsschemaspezifische Ressource für die gewünschte Meldung ist nicht vorhanden
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-Worker" Guid="{51ddfa29-d5c8-4803-be4b-2ecb715570fe}" />
<EventID>3020</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2020-02-11T20:33:29.422246000Z" />
<EventRecordID>1316</EventRecordID>
<Correlation />
<Execution ProcessID="8532" ThreadID="7352" />
<Channel>Microsoft-Windows-Hyper-V-Worker-Admin</Channel>
<Computer>HyperV-Server.domaene.local</Computer>
<Security UserID="S-1-5-83-1-2189832840-1113199424-1462609552-2877185807" />
</System>
<UserData>
<VmlEventLog xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
<VmName>VM-NAME</VmName>
<VmId>82863288-1340-425A-90A6-2D570F5F7EAB</VmId>
<ErrorCode>%%2147942402</ErrorCode>
<HResult>0x80070002</HResult>
</VmlEventLog>
</UserData>
</Event>Manchmal (auch nicht immer) folgt dann noch Event 12054:
Die Beschreibung für die Ereignis-ID "12054" aus der Quelle "Microsoft-Windows-Hyper-V-Worker" 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:
VM-NAME
82863288-1340-425A-90A6-2D570F5F7EAB
%%2147942402
0x80070002
Die gebietsschemaspezifische Ressource für die gewünschte Meldung ist nicht vorhandenDie Google-Suche zeigt mir da nix an (oder ich google falsch)...
Gruß
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 546320
Url: https://administrator.de/forum/hyperv-2019-events-3020-und-12054-546320.html
Ausgedruckt am: 08.04.2025 um 14:04 Uhr
6 Kommentare
Neuester Kommentar
Moin,
ich würde mir erstmal die entsprechend VM anschauen, welche dort nicht richtig herunter fährt.
Tritt das Problem auch auf wenn du diese händisch neustartest?
Fährt der Server sauber durch wenn diese VM nicht läuft?
Worum handelt es sich bei der VM?
Gruß
Spirit
ich würde mir erstmal die entsprechend VM anschauen, welche dort nicht richtig herunter fährt.
Tritt das Problem auch auf wenn du diese händisch neustartest?
Fährt der Server sauber durch wenn diese VM nicht läuft?
Worum handelt es sich bei der VM?
Gruß
Spirit
Hi Spirit,
ja, war auch meine erste Idee... Alle VMs lassen sich händisch problemlos (neu)starten.
Ich habe mal ein wenig weitergewühlt, auf dem anderen Host tauchen diese Fehler nicht auf. Was mir aufgefallen ist: Bei den fraglichen VMs waren, wie im Default vorgesehen, Produktiv-Prüfpunkte eingestellt. Bis auf eine Ausnahme allerdings keine Datenbank o.ä. in der VM. Ich kann auf allen einen Produktiv-Prüfpunkt erstellen, aber scheinbar nicht korrekt wieder löschen (Fehler bei der Zusammenführung). Im HyperV-Manager taucht der Prüfpunkt danach allerdings nicht mehr auf, sehe ich mir das Verzeichnis im Explorer an, liegt der da noch rum. Also ein Bug in der Ansicht.
Passend dazu im Eventlog (Hyper-V-VMMS) Event ID 19100:
Google sagt das:
https://support.microsoft.com/de-de/help/4230569/error-messages-when-you ...
(Fehler 4).
Es wartet die nächste Wand:
Ungültiger Parameter: "NT VIRTUAL MACHINE\901f65e3-3945-44f9-af06-109a2d8e9439"
Ich finde den Link leider nicht wieder, aber da stand, dass das mit einem virtuellen User zu tun hat, der nicht mehr existiert.
Nun denn, Lösung ist scheinbar in dem Fall, die VM wieder "neu aufzusetzen", also neue VM anlegen und die vorhandene VHDX verwenden.
Was ich jetzt gemacht habe (Prüfpunktdateien im Explorer sind verschwunden):
- Umstellung von Produktiv- auf Standardprüfpunkte
- Neuen Standardprüfpunkt angelegt
- Prüfpunkt wieder gelöscht (funktioniert nun, Zusammenführung erfolgreich).
Ich starte den Server heute Abend noch einmal neu und beobachte, ob er wieder hängenbleibt. Rückmeldung folgt!
ja, war auch meine erste Idee... Alle VMs lassen sich händisch problemlos (neu)starten.
Ich habe mal ein wenig weitergewühlt, auf dem anderen Host tauchen diese Fehler nicht auf. Was mir aufgefallen ist: Bei den fraglichen VMs waren, wie im Default vorgesehen, Produktiv-Prüfpunkte eingestellt. Bis auf eine Ausnahme allerdings keine Datenbank o.ä. in der VM. Ich kann auf allen einen Produktiv-Prüfpunkt erstellen, aber scheinbar nicht korrekt wieder löschen (Fehler bei der Zusammenführung). Im HyperV-Manager taucht der Prüfpunkt danach allerdings nicht mehr auf, sehe ich mir das Verzeichnis im Explorer an, liegt der da noch rum. Also ein Bug in der Ansicht.
Passend dazu im Eventlog (Hyper-V-VMMS) Event ID 19100:
Protokollname: Microsoft-Windows-Hyper-V-VMMS-Admin
Quelle: Microsoft-Windows-Hyper-V-VMMS
Datum: 12.02.2020 12:29:41
Ereignis-ID: 19100
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: HyperV-Server.domaene.local
Beschreibung:
"VM-NAME": Die Datenträgerzusammenführung im Hintergrund konnte nicht abgeschlossen werden: Allgemeiner "Zugriff verweigert"-Fehler (0x80070005) (ID des virtuellen Computers 901F65E3-3945-44F9-AF06-109A2D8E9439).
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-VMMS" Guid="{6066f867-7ca1-4418-85fd-36e3f9c0600c}" />
<EventID>19100</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2020-02-12T11:29:41.191920700Z" />
<EventRecordID>2171</EventRecordID>
<Correlation />
<Execution ProcessID="4356" ThreadID="2632" />
<Channel>Microsoft-Windows-Hyper-V-VMMS-Admin</Channel>
<Computer>HyperV-Server.domaene.local</Computer>
<Security UserID="S-1-5-18" />
</System>
<UserData>
<VmlEventLog xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
<VmName>VM-NAME</VmName>
<VmId>901F65E3-3945-44F9-AF06-109A2D8E9439</VmId>
<ErrorMessage>%%2147942405</ErrorMessage>
<ErrorCode>0x80070005</ErrorCode>
</VmlEventLog>
</UserData>
</Event>Google sagt das:
https://support.microsoft.com/de-de/help/4230569/error-messages-when-you ...
(Fehler 4).
Es wartet die nächste Wand:
Ungültiger Parameter: "NT VIRTUAL MACHINE\901f65e3-3945-44f9-af06-109a2d8e9439"
Ich finde den Link leider nicht wieder, aber da stand, dass das mit einem virtuellen User zu tun hat, der nicht mehr existiert.
Nun denn, Lösung ist scheinbar in dem Fall, die VM wieder "neu aufzusetzen", also neue VM anlegen und die vorhandene VHDX verwenden.
Was ich jetzt gemacht habe (Prüfpunktdateien im Explorer sind verschwunden):
- Umstellung von Produktiv- auf Standardprüfpunkte
- Neuen Standardprüfpunkt angelegt
- Prüfpunkt wieder gelöscht (funktioniert nun, Zusammenführung erfolgreich).
Ich starte den Server heute Abend noch einmal neu und beobachte, ob er wieder hängenbleibt. Rückmeldung folgt!
Du erstmal die produktiven Prüfpunkte reaktivieren. Dieser führt der Hypervisor bei jedem shutdown der VMs zusammen.
Warum es zu Problemen kommt schaust du dir danach an. Ggf. zu wenig Speicherplatz?
Warum es zu Problemen kommt schaust du dir danach an. Ggf. zu wenig Speicherplatz?
Bingo, habe den Server neu gestartet, der läuft jetzt problemlos durch. Wie oben schon vermutet, hat das mit dem virtuellen User zu tun, bei der Migration der VMs muss irgendwas schiefgegangen sein, da der andere Server dieses Verhalten nicht zeigt. Im Eventlog wird nach dem Neustart jede VM angemeckert:
Also ein Berechtigungsproblem...
Protokollname: Microsoft-Windows-Hyper-V-VMMS-Admin
Quelle: Microsoft-Windows-Hyper-V-VMMS
Datum: 12.02.2020 20:49:26
Ereignis-ID: 16300
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: HyperV-Server.domaene.local
Beschreibung:
Die Konfiguration eines virtuellen Computers kann nicht geladen werden: Unbekannter Fehler (0x80004005). (ID des virtuellen Computers: 901F65E3-3945-44F9-AF06-109A2D8E9439)
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-VMMS" Guid="{6066f867-7ca1-4418-85fd-36e3f9c0600c}" />
<EventID>16300</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2020-02-12T19:49:26.585345500Z" />
<EventRecordID>2224</EventRecordID>
<Correlation />
<Execution ProcessID="4368" ThreadID="6896" />
<Channel>Microsoft-Windows-Hyper-V-VMMS-Admin</Channel>
<Computer>HyperV-Server.domaene.local</Computer>
<Security UserID="S-1-5-18" />
</System>
<UserData>
<VmlEventLog xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
<VmName>
</VmName>
<VmId>901F65E3-3945-44F9-AF06-109A2D8E9439</VmId>
<ErrorMessage>%%2147500037</ErrorMessage>
<ErrorCode>0x80004005</ErrorCode>
</VmlEventLog>
</UserData>
</Event>Also ein Berechtigungsproblem...
Wenn du ein Backup von den Maschinen hast würde ich die im HyperV Manager löschen und neu erstellen bzw. einmal neu importieren.
Anscheind passen dem Irgend welche Rechte auf den Ordner nicht. Das sollte das Problem beheben.
Nichts desto trotz solltest du die productiv Prüfpunkte deaktivieren wenn du diese nicht zwingend brauchst.
Anscheind passen dem Irgend welche Rechte auf den Ordner nicht. Das sollte das Problem beheben.
Nichts desto trotz solltest du die productiv Prüfpunkte deaktivieren wenn du diese nicht zwingend brauchst.
So, Problem gelöst...
Ich habe eine VM gelöscht und im selben Verzeichnis die VM neu angelegt, unter Verwendung der vorhandenen .vhdx. Testweise den HyperV-Host neu gestartet. Mist, die ID der "neuen" VM wird immer noch angemeckert.
Nun gut, sehe ich mir die betroffenen VMs einmal genauer an. Siehe da, die liegen alle auf einem iSCSI-Target. Die VMs, die auf den lokalen Server-Platten liegen, sind nicht betroffen. Dann ist mir wieder eingefallen, dass ich einen merkwürdigen Effekt bei der Installation der neuen Server hatte: Alle VMs waren migriert, im HyperV-Manager waren direkt nach dem Start aber nur die "lokalen" VMs zu sehen, die VMs auf dem iSCSI-Target wurden nicht angezeigt.
- Gruppenrichtlinie "Warten auf Netzwerk" war aktiviert, daran lag es nicht.
- Simple Methode: Den Dienst "Hyper-V-Verwaltung für virtuelle Computer" auf Start - Automatisch (Verzögert) stellen. Klappt.
Dieser letzte Punkt fehlte auf dem betroffenen HyperV-Host. Ich war der festen Überzeugung, dass ich das eingestellt hatte, dem war aber nicht so...
Der HyperV-Manager kommt also beim Start nicht an die VM-Dateien heran.
Getestet und läuft problemlos. Mein eines Problem hatte mit dem anderen überhaupt nichts zu tun, klassischer Fehler.
Spirit, Dir vielen Dank für die Unterstützung und die Ideen!
Ich habe eine VM gelöscht und im selben Verzeichnis die VM neu angelegt, unter Verwendung der vorhandenen .vhdx. Testweise den HyperV-Host neu gestartet. Mist, die ID der "neuen" VM wird immer noch angemeckert.
Nun gut, sehe ich mir die betroffenen VMs einmal genauer an. Siehe da, die liegen alle auf einem iSCSI-Target. Die VMs, die auf den lokalen Server-Platten liegen, sind nicht betroffen. Dann ist mir wieder eingefallen, dass ich einen merkwürdigen Effekt bei der Installation der neuen Server hatte: Alle VMs waren migriert, im HyperV-Manager waren direkt nach dem Start aber nur die "lokalen" VMs zu sehen, die VMs auf dem iSCSI-Target wurden nicht angezeigt.
- Gruppenrichtlinie "Warten auf Netzwerk" war aktiviert, daran lag es nicht.
- Simple Methode: Den Dienst "Hyper-V-Verwaltung für virtuelle Computer" auf Start - Automatisch (Verzögert) stellen. Klappt.
Dieser letzte Punkt fehlte auf dem betroffenen HyperV-Host. Ich war der festen Überzeugung, dass ich das eingestellt hatte, dem war aber nicht so...
Der HyperV-Manager kommt also beim Start nicht an die VM-Dateien heran.
Getestet und läuft problemlos. Mein eines Problem hatte mit dem anderen überhaupt nichts zu tun, klassischer Fehler.
Spirit, Dir vielen Dank für die Unterstützung und die Ideen!
