[SOLVED] Windows 2012 R2 Gäste starten nicht mehr

[clicks]

Guten Morgen,

über's WE wurden Wartungen an einem Proxmox-Cluster vorgenommen. In dem Zuge wurden auch alle Pakete aktualisiert, die Version 6.2 lief schon seit einigen Wochen stabil auf dem Cluster. Aus unerklärlichen Gründen starten nun 2 Windows Server 2012 R2 Maschinen nicht mehr. Sie booten, es erscheint für ein paar Sekunden das blaue Windows-Logo mit der Ladeanimation darunter (rotierende Kreise). Danach bleibt der Bildschirm schwarz. Die CPU-Last auf dem Gast liegt bei 100%, bleibt dort aber auch für mehrere Stunden, ohne das sich etwas tut. Andere Gäste laufen vollkommen ohne Probleme.

Dinge die ich schon probiert habe:
- Festplatten per Sata statt virtio anbinden
- Diverse unterschiedliche CPUs
- Starten auf einem anderen Node
- OS-Typ geändert
- Plattenplatz ist genug vorhanden auf dem Node, dem Storage als auch dem Gast-Image
- Abgesicherter Modus
- Im Log oder der CLI keine Fehlermeldungen
- qemu downgrade auf 5.0 (oder ist ein Neustart des ganzen Nodes notwendig? Habe "nur" den Gast neu gestartet)

Was kann ich noch probieren?

pveversion -v
proxmox-ve: 6.2-2 (running kernel: 5.3.18-3-pve)
pve-manager: 6.2-12 (running version: 6.2-12/b287dd27)
pve-kernel-5.4: 6.2-7
pve-kernel-helper: 6.2-7
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.65-1-pve: 5.4.65-1
pve-kernel-5.4.55-1-pve: 5.4.55-1
pve-kernel-4.15: 5.4-19
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-4.15.18-30-pve: 4.15.18-58
ceph-fuse: 12.2.13-pve1
corosync: 3.0.4-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.16-pve1
libproxmox-acme-perl: 1.0.5
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.2-2
libpve-guest-common-perl: 3.1-3
libpve-http-server-perl: 3.0-6
libpve-storage-perl: 6.2-8
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.3-1
lxcfs: 4.0.3-pve3
novnc-pve: 1.1.0-1
proxmox-backup-client: 0.9.0-2
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.3-1
pve-cluster: 6.2-1
pve-container: 3.2-2
pve-docs: 6.2-6
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.1-3
pve-ha-manager: 3.1-1
pve-i18n: 2.2-1
pve-qemu-kvm: 5.1.0-2
pve-xtermjs: 4.7.0-2
qemu-server: 6.2-14
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 0.8.4-pve2

uname -a
Linux bre-de-vn002 5.3.18-3-pve #1 SMP PVE 5.3.18-3 (Tue, 17 Mar 2020 16:33:19 +0100) x86_64 GNU/Linux
(Fehlerbild ist mit dem 5.4.65-1 Kernel das gleiche)

qm config 104
boot: cdn
bootdisk: virtio1
cores: 2
cpu: kvm64
hotplug: network
ide0: iso002:iso/virtio-win-0.1.189.iso,media=cdrom,size=488766K
memory: 8192
name: FOO-DE-SERVER
net0: virtio=22:3C:FD:56:624,bridge=vmbr0
numa: 0
ostype: win8
scsihw: virtio-scsi-pci
smbios1: uuid=bd0b6065-8fa9-44ca-a6d4-1e58e5bb025e
sockets: 1
virtio1: vm001:104/vm-104-disk-0.qcow2,size=110G
virtio2: vm001:104/vm-104-disk-1.qcow2,size=300G
vmgenid: b2b17344-c0bf-4181-8580-89054fad4ad2

 

[gmed]

Hi,

boote eine der VMs mal z.B. von einer gparted.iso um zu schauen, ob die Partitionstabelle etc. i.O. ist.
Den Festplattentyp dabei nicht ändern, da evtl. Treiber fehlen.
Wenn die Partitiostabelle etc. passt, von einer Server2012.iso booten und dann mbr und Bootkonfig wiederherstellen.

Wir hatten ähnliches mal mit Win10 Gästen.

 

[clicks]

Hi, danke dir. Ja das geht schon "irgendwie" in die richtige Richtung. Wir haben heute mehrere Maschinen versucht über die genannten Wege zu "retten". Leider ohne realen Erfolg. Merkwürdigerweise brechen uns grade auch ganz neue Maschinen weg, sobald eine zweite Festplatte hinzugefügt wird, booten die Maschinen nicht mehr - weil Windows Probleme mit dem Boot-Laufwerk bekommt (Stichwort: INACCESSIBLE BOOT DEVICE)

 

[markusd]

Hi,
Hast Du statt abgesichertem Modus mal "letzte bekannt funktionierende Konfiguration starten" (öder so ähnlich ) ausgewählt?

Markus

 

[gmed]

Hi, danke dir. Ja das geht schon "irgendwie" in die richtige Richtung. Wir haben heute mehrere Maschinen versucht über die genannten Wege zu "retten". Leider ohne realen Erfolg. Merkwürdigerweise brechen uns grade auch ganz neue Maschinen weg, sobald eine zweite Festplatte hinzugefügt wird, booten die Maschinen nicht mehr - weil Windows Probleme mit dem Boot-Laufwerk bekommt (Stichwort: INACCESSIBLE BOOT DEVICE)

Wichtig ist, das beim Ändern des Festplatten types (sata -> virtio) nicht einfach die vorhandenen Platten direkt umgestellt werden:

Zuerst an der funktionierenden VM eine neue Platte (wenige MB reichen) als virtio anstöpseln.
Booten und die fehlenden Treiber nachinstallieren. -> Herunterfahren.
Die im ersten Step erstellte Platte nun abklemmen und löschen.
Nun die vorhandenen Platten abklemmen und als virtio neu anklemmen.

Ist der Hinweis "INACCESSIBLE BOOT DEVICE" eine Meldung vom BIOS oder von Windows?

Wenn Windows sowas aufwirft, dann wie beschrieben von der Windows.ISO booten und die Startdateien wider restaurieren.

 

[clicks]

Danke euch, leider bringt der abgesicherte Modus auch nichts, auch dort bleibt der Bildschirm einfach schwarz.

Der Hinweis "INACCESSIBLE BOOT DEVICE" ist eine Fehlermeldung von Windows, sie erscheint ganz kurz mit einem Blue-Screen und die VM bootet dann durch.

Jegliche im Internet auffindbare Variante zur Wiederherstellung des Bootsektor/Bootmanagers, und davon gibt es etliche Varianten, habe ich probiert. Auch die letzten Updates habe ich per DISM rückgängig gemacht. Es bleibt das gleiche Bild.

Verrückterweise trat das Problem auch mit neuen VMs auf, bei denen wir nach der Erstinstallation (also auch schon aktive virtio-Treiber), ein weitere Platte angehangen haben. Das Image lässt sich danach in keiner Weise mehr booten, auch nicht auf einem separat installiertem Proxmox-System.

Ich bin mittlerweile recht ratlos woher das Problem kommen könnte. Leider ist das Vertrauen in die Stabilität des Clusters damit nicht grade gestiegen, so dass jeder Reboot zu einer (unnötigen) Zitterpartie wird. Aber ich bin mit Proxmox in Kontakt um das Problem einzukreisen.
Falls jemand aber noch Ideen und Hinweise hat, würde ich mich sehr darüber freuen (kann aber erst Ende nächster Woche wieder antworten

 

[markusd]

Hi
Bist Du hier weiter gekommen?
Ich hatte das mehrfach mit 2012R2:
Der Bildschirm blieb schwarz, in der Übersicht sah man etwas CPU-Verbrauch, es wurde keine IP gezogen..
Die von Dir geschilderte BOOTDEVICE-Fehlermeldung habe ich nie zu Gesicht bekommen, von daher kann es etwas anderes gwesen sein.
Der abgesicherte Modus half mir auch nie, wohl aber wie gesagt "letzte bekannt funktionierende Konfiguration starten" (öder so ähnlich )..
Hast Du zufällig als Feature "Desktopdarstellung" (win8.1-Zubehör ) aktiviert?

 

[HBO]

Genau dieses Problem hatte ich auch, aber nicht nur bei Windows 2012er Servern.
Wenn ihr mal auf dem Hostsystem per "fdisk" schaut werdet ihr wohl leider feststellen, dass eure Partitionstabellen einfach mal weg sind.
Hier hilft dann nur Datenrettung per Testdisk etc sowie Backup Restore.

 

[clicks]

Mittlerweile konnte ich den Fehler tatsächlich beheben. Auch wenn es mir doch etwas peinlich ist will ich erklären, woran es lag, um andere vor einer langen Fehlersuche zu bewahren.
Zeitgleich mit unseren Wartungsarbeiten am Proxmox-Cluster wurde eine Windows-Gruppenrichtlinie aktiv, welche fehlerhafte Registry-Einträge erzeugte, was dazu führte, dass Windows nicht mehr komplett bootete. Diese GPO hatte aber niemand richtig auf dem Schirm, bzw. vermutete sie, da sie auf anderen Clients (Win 10) ohne Probleme funktionierte. Also suchten wir immer in Richtung Proxmox/Virtualisierung und haben uns durch verschiedene Controller-Tests selbst weiter auf den falschen Weg geführt.
Erst als auch komplett neue Maschinen "umfielen" schwante uns, dass das Problem evtl. aus einer anderen Richtung, nämlich unserer Domäne, kommt.
Somit konnten wir die kaputten VMs in einer Windows PE Umgebung auch wieder reparieren, indem wir die entsprechenden Registry-Einträge korrigiert haben. Leider eine sehr belastende Suche durch die wir aber mehrere Dinge gelernt haben, auch wenn sie z.T. offensichtlich sein sollten:
- umfangreiches Wissen über den Windows-Bootprozess und Offline-Reparaturmaßnahmen (Stichwort DISM)
- Problemlösung sollte immer strukturiert, ruhig und unvoreingenommen angegangen werden
- Änderungen am System nicht kombinieren

Nochmal vielen Dank allen die Hinweise gegeben haben.

 

[fireon]

Vielen Dank für deinen Bericht Bitte sei so nett und markiere deinen Beitrag als gelöst.