Inaccessible Boot Device nach Migration von ESXi bei ca.50% der VMs

S

salatbar

New Member
Oct 22, 2024
8
0
1
Hallo zusammen,

ich habe auf einem ESXi Host (7.0u3s) mehrere nahezu identische VMs die ich auf einen Proxmox 8.3.5 migrieren will. Diese Unterscheiden sich nur durch die Disk und RAM Größe.
Auf den VMs läuft überall ein Windows 10 aktueller Patch Stand.

Bei einigen funktioniert die migration nach Anleitung ohne Probleme, d.h. VM startet mit SATA Disk, im Nachgang lassen sich auch die VirtIO Treiber nachinstallieren und die VM startet fehlerfrei mit SCSI Disk.

Bei ca. der hälfte der Maschinen bekomme ich aber nach dem Start der VM ein inaccessible boot device angezeigt.

Hier die config von einer funktionierenden Migration:

Code: 
root@inv-clg-pve1:~# qm config 103
bios: ovmf
boot: order=sata1
cores: 2
cpu: x86-64-v2-AES
efidisk0: local-zfs:vm-103-disk-0,size=1M
machine: pc-i440fx-9.2
memory: 8192
meta: creation-qemu=9.2.0,ctime=1743064722
name: Test-SLV9
net0: e1000e=00:50:56:b6:5e:61,bridge=vmbr0,tag=5
ostype: win10
sata0: local:iso/virtio-win-0.1.215.iso,media=cdrom,size=528308K
sata1: local-zfs:vm-103-disk-1,size=55G
scsihw: virtio-scsi-single
smbios1: uuid=4236b687-c4eb-8b6a-0c68-3cc84a02a4df
sockets: 2
vmgenid: fe828607-3c92-484a-ad2a-0d80775d0a4b

hier die von einer mit Inaccessible boot device:

Code: 
root@inv-clg-pve1:~# qm config 106
bios: ovmf
boot: order=sata1
cores: 8
cpu: x86-64-v2-AES
efidisk0: local-zfs:vm-106-disk-0,size=1M
machine: pc-i440fx-9.2
memory: 24576
meta: creation-qemu=9.2.0,ctime=1743080009
name: Test-SLV11
net0: e1000e=00:50:56:b6:ca:fb,bridge=vmbr0,tag=5
ostype: win10
sata0: local:iso/virtio-win-0.1.215.iso,media=cdrom,size=528308K
sata1: local-zfs:vm-106-disk-1,size=100G
scsihw: virtio-scsi-single
smbios1: uuid=4236721c-1a17-073b-9c82-a575782d9d12
sockets: 2
vmgenid: 8eb38437-b848-425b-b3ac-e558b07b2f08



Code: 
root@inv-clg-pve1:~# pveversion -v
proxmox-ve: 8.3.0 (running kernel: 6.8.12-9-pve)
pve-manager: 8.3.5 (running version: 8.3.5/dac3aa88bac3f300)
proxmox-kernel-helper: 8.1.1
proxmox-kernel-6.8: 6.8.12-9
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
proxmox-kernel-6.8.12-8-pve-signed: 6.8.12-8
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2+deb12u1
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.6.0
libproxmox-backup-qemu0: 1.5.1
libproxmox-rs-perl: 0.3.5
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.2.0
libpve-network-perl: 0.10.1
libpve-rs-perl: 0.9.2
libpve-storage-perl: 8.3.3
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.3.4-1
proxmox-backup-file-restore: 3.3.4-1
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.1
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.3.7
pve-cluster: 8.0.10
pve-container: 5.2.4
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-3
pve-ha-manager: 4.0.6
pve-i18n: 3.4.1
pve-qemu-kvm: 9.2.0-2
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.8
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.7-pve2

Mir gehen ein wenig die Ideen aus wie ich die VMs noch zum booten bringen könnte.

Ein Versuch die VM manuell mit dem ovftool zu importieren und einzubinden bracht mir das selbe Resultat, also ein Inaccessible Boot Device.

Der Versuch den VirtIO Treiber per Reparaturconsole reinzuschmieren, wie erwartet ohne Erfolg da die VM auch ohne Treiber als SATA DIsk starten sollte.
Ich habe im BIOS eine neue Boot Option angelegt was in meinen Augen eher Sinnfrei ist da die VM selbst schon Bootet nur dann irgendwie die Windows Partition nicht zu finden scheint.

Hat jemand ggf. noch eine Idee was ich tun kann um die nicht laufenden VMs an rennen zu bringen? Ich würde ungerne die Kisten neu anlegen müssen.
Sollten noch weitere Informationen benötigt werden bringe ich die gerne.

Euch schon mal eine schöne Restwoche.
 
Last edited:
GMBauer said:
Hast du geprüft, ob in den betroffenen VMs auf dem ESXi noch Snapshots offen sind? Konsolidieren oder löschen, mit offenen Snapshots geht's nicht.
Click to expand...

Snapshots hab ich schon geprüft. Alle Maschinen sind sauber.

Wie und Warum kann ich dir einfach beantworten.
Ich war an einem Punkt angelangt an denen ich die VMs auch erst mal wieder aktiv brauche. Also habe ich mir per ovftool wie in Migrate to Proxmox VE
angegeben erst einmal die VM gezogen um dann in ruhe weiter zu testen.

EDIT: Sehe grade das ich das im Ausgangspost falsch ausgedrückt hatte.
 
Last edited:
salatbar said:
Hat jemand ggf. noch eine Idee was ich tun kann um die nicht laufenden VMs an rennen zu bringen? Ich würde ungerne die Kisten neu anlegen müssen.
Sollten noch weitere Informationen benötigt werden bringe ich die gerne.
Click to expand...
Das ist ganz normal bei Windows und habe ich schon mehrfach im Forum beschrieben.
Wenn du im Windows mit den VirtIO Tools die Treiber installierst, kopiert Windows die Treiber nur in den Driverstore.
Es muss erst eine SCSI Disk im laufenden System sein, bevor der Treiber bootfähig installiert wird.
Also eine SCSI Disk (gern 1GB Dummy Disk) in das System einbinden. Wenn die VirtiO Treiber bereits installiert sind, bitte im Gerätemanager kontrollieren ob der SCSI Treiber installiert ist und die Disk auftaucht.
Danach kannst du herunterfahren und die OS Disk auf SCSI ändern. (Dymmydisk löschen)
 
  • Like
Reactions: news and ThoSo
Falk R. said:
Das ist ganz normal bei Windows und habe ich schon mehrfach im Forum beschrieben.
Wenn du im Windows mit den VirtIO Tools die Treiber installierst, kopiert Windows die Treiber nur in den Driverstore.
Es muss erst eine SCSI Disk im laufenden System sein, bevor der Treiber bootfähig installiert wird.
Also eine SCSI Disk (gern 1GB Dummy Disk) in das System einbinden. Wenn die VirtiO Treiber bereits installiert sind, bitte im Gerätemanager kontrollieren ob der SCSI Treiber installiert ist und die Disk auftaucht.
Danach kannst du herunterfahren und die OS Disk auf SCSI ändern. (Dymmydisk löschen)
Click to expand...
Kurz nochmal damit wir nicht aneinander vorbei sprechen. Ich bekomme Inaccassible boot device direkt nach der migration. Da kommt SCSI noch nicht ins Spiel. Würde sich auch mit meinen Beobachtungen in der Reparaturkonsole decken. Dort sehe ich alles und kann auch auf die Partition mit zugreifen.

Deine Postings hier hatte ich schon gesehen und hatte sogar versucht mit Dummydisk zu zu starten und die Treiber zu implementieren. Am Ergebnis änderte das aber leider nix.
Ehrlich gesagt hätte mich das aber auch ein wenig gewundert da für mein Verständnis der Migrationsanleitung nach, direkt nach der Migration die VM mit SATA Disk angelegt wird und die dann auch ohne irgendwelche Treiber laufen sollte. Erst beim switch auf SCSI kommt dann die Dummy Disk ins Spiel. Das verstehe ich ja auch.
Korrigiere mich gerne wenn ich da was falsch verstanden habe.

ThoSo said:
Deine virtio treiber mit 215 sind auch etwas angestaubt, nimm mal die 248.
dann die treiber vor der migration installieren. Die müssen auch zur bootzeit aktiv sein.
Click to expand...

Da hast du recht das die was angestaubt sein könnten. Versuche das ganze auf jeden Fall noch mit den 248er.
Die Treiber vor der Migration zu Installieren hatte ich auch schon versucht. Auch hier das gleiche Ergebnis: Die VM grüßt mit inaccessible boot device.
Passt für mich aber auch nicht wenn ich auf jeden Fall eine Dummydisk benötige damit Windows die Treiber richtig schluckt. Wo soll ich die auf nem ESX her bekommen?

Ich bin euch aber dankbar für jede Idee, und wenn Sie in meiner kleinen Welt noch so abwegig erscheint. Dafür bin ich zu frisch mit Proxmox unterwegs, komme halt aus der Hyper-V und VMWare Welt.
 
salatbar said:
Kurz nochmal damit wir nicht aneinander vorbei sprechen. Ich bekomme Inaccassible boot device direkt nach der migration. Da kommt SCSI noch nicht ins Spiel. Würde sich auch mit meinen Beobachtungen in der Reparaturkonsole decken. Dort sehe ich alles und kann auch auf die Partition mit zugreifen.
Click to expand...
Also wenn du noch IDE oder SATA nutzt.
Hatte die VM noch Snapshots während der Migration?
Ist Bitlocker auf der VM aktiv? Nicht Bitlocker Status prüfen, sondern die Disk c:, ob diese Verschlüsselt ist.
 
Falk R. said:
Also wenn du noch IDE oder SATA nutzt.
Hatte die VM noch Snapshots während der Migration?
Ist Bitlocker auf der VM aktiv? Nicht Bitlocker Status prüfen, sondern die Disk c:, ob diese Verschlüsselt ist.
Click to expand...
Keine Snapshots
Keine Verschlüsselung. Bitlocker ist bei den VMs nie im Einsatz gewesen
Der ESX hat die Disk der VM als SCSI eingebunden.
Alle VMs auf dem ESX sind von der Konfiguration bis auf die Disk Größe und RAM Größe wie auch CPU Sockel und Kerne identisch und booten auch munter wenn ich sie anschalte.

Als Anleitung habe ich diese Anleitung genutzt:
https://www.proxmox.com/en/services...vironment/proxmox-ve-import-wizard-for-vmware

Bei ca 3:20 kann man sehen das die VM auf dem pve mit einer SATA Disk angelegt wurde. Kurz vorher wurde diese sogar einmal kurz gestartet.

Genau das Funktioniert in ca 50% der Fälle auch bei mir.
In den anderen Fällen leider nicht.
 
Nur weil du nie Bitlocker genutzt hast, bedeutet das gar nichts. Ich höre das ganz oft, dass Leute erstaunt sind, dass ihre Disk von Windows verschlüsselt wurde obwohl nie Bitlocker eingerichtet wurde. Dadurch haben die Leute in der Regel auch keinen Recovery Key.

Was siehst du wenn du die Disk in eine andere VM einhängst?
 
Falk R. said:
Nur weil du nie Bitlocker genutzt hast, bedeutet das gar nichts. Ich höre das ganz oft, dass Leute erstaunt sind, dass ihre Disk von Windows verschlüsselt wurde obwohl nie Bitlocker eingerichtet wurde. Dadurch haben die Leute in der Regel auch keinen Recovery Key.

Was siehst du wenn du die Disk in eine andere VM einhängst
Click to expand...

Brauch ich nicht einzuhängen. Wie schon oben mal erwähnt, komme ich per Reparaturkonsole auf die Disk.

Das gibt der manage-bde status aus:

Neue Bitmap (4).jpg

Da ist echt nix verschlüsselt.
 
Hast du mal gecheckt ob die VM vorher als UEFI oder BIOS lief und wie die neue VM eingestellt ist?

Inaccessible Boot Device bedeutet, dass entweder die Disk nicht lesbar ist (Bios+GPT/UEFI+MBR) oder ein Treiber fehlt.
Reihenfolge der Disks beim Booten hast du auch gecheckt?
 
  • Like
Reactions: waltar
Falk R. said:
Hast du mal gecheckt ob die VM vorher als UEFI oder BIOS lief und wie die neue VM eingestellt ist?

Inaccessible Boot Device bedeutet, dass entweder die Disk nicht lesbar ist (Bios+GPT/UEFI+MBR) oder ein Treiber fehlt.
Reihenfolge der Disks beim Booten hast du auch gecheckt?
Click to expand...
Die VM vorher lief als UEFI+GPT
Reihenfolge der Disks im Bios stimmt auch ist nur eine. Da steht der Windows Boot Manager oben.

Was mich an der ganzen Sache ja so irritiert ist das die VMs auf dem ESX immer nach dem gleichen Schema erstellt wurden. Da gibt es eine klare Handlungsanweisung zu und die wird auch jedes mal befolgt wenn eine neue VM hinzu kommt.
Manche laufen halt direkt und lassen sich auch direkt im Nachgang noch auf SCSI Umstellen, andere die wirklich bis auf die schon oben genannten Einstellungen identisch sind wollen nicht.

Ich werde den Kollegen wohl jetzt erst einmal vorschlagen die VM die nicht laufen neu anzulegen. Dann müssen die sich dann im Nachgang Ihre Kisten neu einrichten. Knoten im Kopf kurz vor dem Wochenende ist nicht gut auch wenn ich jetzt schon weis das mich das Thema auch am WE beschäftigen wird.
 
Last edited:
Mal als Ideen:
Prüfe doch mal eine Maschine vor dem Migration mit "sfc/scannow" ob hier evtl. Fehler vorliegen.
Die Treiber der VMware Tools sind aktuell, auf den Maschinen identisch und noch installiert?
 
ThoSo said:
Mal als Ideen:
Prüfe doch mal eine Maschine vor dem Migration mit "sfc/scannow" ob hier evtl. Fehler vorliegen.
Die Treiber der VMware Tools sind aktuell, auf den Maschinen identisch und noch installiert?
Click to expand...
VMWare Tool sind identisch und noch drauf da die aktuell noch genutzt werden.
Den check lass ich mal laufen. Das hatte ich mal gar nicht auf dem Schirm.
 
salatbar said:
Die VM vorher lief als UEFI+GPT
Reihenfolge der Disks im Bios stimmt auch ist nur eine. Da steht der Windows Boot Manager oben.

Was mich an der ganzen Sache ja so irritiert ist das die VMs auf dem ESX immer nach dem gleichen Schema erstellt wurden. Da gibt es eine klare Handlungsanweisung zu und die wird auch jedes mal befolgt wenn eine neue VM hinzu kommt.
Manche laufen halt direkt und lassen sich auch direkt im Nachgang noch auf SCSI Umstellen, andere die wirklich bis auf die schon oben genannten Einstellungen identisch sind wollen nicht.

Ich werde den Kollegen wohl jetzt erst einmal vorschlagen die VM die nicht laufen neu anzulegen. Dann müssen die sich dann im Nachgang Ihre Kisten neu einrichten. Knoten im Kopf kurz vor dem Wochenende ist nicht gut auch wenn ich jetzt schon weis das mich das Thema auch am WE beschäftigen wird.
Click to expand...
Eventuell mal die UEFI Disk testweise entfernen, damit die Windows angelegte UEFI Partition genutzt wird, eventuell funktioniert es dann oder es kommt vielleicht eine andere Meldung.
 
You must log in or register to reply here.
Top Bottom