[SOLVED] VMWare zu Proxmox mit Veeam Herausforderungen

R

Ralf Wolbers

New Member
Proxmox Subscriber
May 3, 2025
13
1
3
Ich habe den ganzen Tag versucht diverse Windows und eine Debian VM von VMWare ESXI 6 nach Proxmox 8.4 zu migrieren. Das soll ja gehen. Die Debian VM läuft soweit. Die Windows VMs, Win 10 und Server 2022 laufen erst hoch und dann endet es mit dem helblauen Bildschirm und einem Neustart in den Reparaturmodus. Schaut man mit der Eingabeaufforderung auf die Festplatte, dann ist das Ganze nun auf Laufwerk x:\ Eine virtualisierte Windows 11 VM läuft gut. Was läuft da falsch?
 
Nun mal auf die Stelle gesagt, arbeite erstmal ein Jahr mit Proxmox VE und spiele alle Konfigurationen selbst durch. wähle die richtige speicherplattform, Prozessor und Raumausstattung und dann versuche dich natürlich auch in einer Windows 11 Installation. Da wird man dann sehen, dass man noch Treiber vorher installieren muss, bevor man das System nutzen möchte und nicht einfach den Binärcode ausführen kann, das geht natürlich nicht. Virtio-win.
 
  • Like
Reactions: itNGO
news said:
Nun mal auf die Stelle gesagt, arbeite erstmal ein Jahr mit Proxmox VE und spiele alle Konfigurationen selbst durch. wähle die richtige speicherplattform, Prozessor und Raumausstattung und dann versuche dich natürlich auch in einer Windows 11 Installation. Da wird man dann sehen, dass man noch Treiber vorher installieren muss, bevor man das System nutzen möchte und nicht einfach den Binärcode ausführen kann, das geht natürlich nicht. Virtio-win.
Click to expand...

Danke für diesen tollen Kommentar. Wie geschrieben läuft die Win11 Installation bereits problewemlos, und das man Treiber installieren muss ist auch klar. Ein Jahr Zeit habe ich bestimmt nicht um das Problem zu lösen.
 
root@pve:~# qm config 102

agent: 1

bios: seabios

boot: order=scsi0

cores: 4

machine: pc-i440fx-9.2+pve1

memory: 32768

meta: creation-qemu=9.2.0,ctime=1746387259

name: Windows-2022-Server-102

net0: virtio=BC:24:11:81:6F:A5,bridge=vmbr0,firewall=1

ostype: win10

scsi0: local-ZFS:vm-102-disk-0,size=500G

scsihw: virtio-scsi-single

smbios1: uuid=8b23e334-e854-424b-a987-783a26691e89

sockets: 2

vmgenid: 2ccbe514-dee4-4afd-a95c-d397f285cc78

root@pve:~# ^C

root@pve:~#

============================================================

root@pve:~# qm config 103

agent: 1,fstrim_cloned_disks=1

bios: seabios

boot: order=scsi0;ide2;ide3

cores: 4

ide2: local:iso/Win10Enterprise_1809_x64_DE.ISO,media=cdrom,size=4930020K

ide3: local:iso/virtio-win-0.1.271.iso,media=cdrom,size=709474K

machine: pc-i440fx-9.2+pve1

memory: 16384

meta: creation-qemu=9.2.0,ctime=1746390430

name: Windows-10-Ent-01

net0: virtio=BC:24:11:71:11:C0,bridge=vmbr0,firewall=1

ostype: win10

scsi0: local-ZFS:vm-103-disk-0,cache=writeback,discard=on,iothread=1,size=150G,ssd=1

scsihw: virtio-scsi-single

smbios1: uuid=a271a07b-cccf-48db-a9dc-c6d62efd4372

sockets: 2

vmgenid: d38dfb3c-7c0e-44c2-973e-c4e366995bda

root@pve:~#
 
Ralf Wolbers said:
Ich habe den ganzen Tag versucht diverse Windows und eine Debian VM von VMWare ESXI 6 nach Proxmox 8.4 zu migrieren. Das soll ja gehen. Die Debian VM läuft soweit. Die Windows VMs, Win 10 und Server 2022 laufen erst hoch und dann endet es mit dem helblauen Bildschirm und einem Neustart in den Reparaturmodus. Schaut man mit der Eingabeaufforderung auf die Festplatte, dann ist das Ganze nun auf Laufwerk x:\ Eine virtualisierte Windows 11 VM läuft gut. Was läuft da falsch?
Click to expand...

Kannst du den STOP Code auf dem BSOD erkennen?

Dann habe ich gesehen, das Du die "iso/virtio-win-0.1.271.iso," Treiber nutzt. Bisherige Erfahrungen empfehlen die Nutzung der "ISO - 248". Diese würde ich auf jeden Fall auch vor der Migration einspielen.

Das hast schon gecheckt : https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Migration ?

Waren die VM online bei der Migration oder down?
Gab es noch Snapshots?

Das Laufwerk X: war im Reparaturmodus? - Das wäre im Reparaturmodus auch ok - da läuft ja ein WinRE System
Check mal vor der Migration noch mit "sfc /scannow" und mach evtl noch ein "chkdsk /f".
 
Last edited:
  • Like
Reactions: Johannes S
ThoSo said:
Kannst du den STOP Code auf dem BSOD erkennen?

Dann habe ich gesehen, das Du die "iso/virtio-win-0.1.271.iso," Treiber nutzt. Bisherige Erfahrungen empfehlen die Nutzung der "ISO - 248". Ich würde ich auf jeden Fall auch vor der Migration einspielen.

Das hast schon gecheckt : https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Migration ?

Waren die VM online bei der Migration oder down?
Gab es noch Snapshots?

Das Laufwerk X: war im Reparaturmodus? - Check mal vor der Migration noch mit "sfc /scannow" und mach evtl noch ein "chkdsk /f".
Click to expand...

Stopcode habe ich nicht notiert

Ich habe Veeam genutzt so wie es auch in Tutorials gezeigt wird. Ich habe bei verschiedenen Situationen gesichert. Vorher die VMWare tools deinstalliet. Snapshots waren keine da. Laufwerk X:\ habe ich nicht. Warum in Proxmox eine Festplatte x:\ anstatt c:\ ist und wie man das korrigiert wäre der erste Ansatz.
die virtio-win Treiber arbeiten ja erst wenn man die VM hochgefahren hat. Das klappt aber eben nicht.
 
Oder (um die Downtime zu minimieren): https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime)

Wegen der Treiber: Im Forum gab es immer mal wieder Berichte, dass neuere Versionen als 248 Probleme machen, die man mit der Version 248 nicht hatte: https://forum.proxmox.com/search/8364204/?page=3&q=virtio+248&o=date

Ich würde also mal versuchen, ob es mit der Version besser klappt ;)

Für allgemeine Hinweise zu best practices bei diversen Windows-Versionen im Wiki die entsprechenden Howtos aus https://pve.proxmox.com/wiki/Category:HOWTO anschauen.
Für deine also: https://pve.proxmox.com/wiki/Windows_2022_guest_best_practices und https://pve.proxmox.com/wiki/Windows_10_guest_best_practices und https://pve.proxmox.com/wiki/Windows_11_guest_best_practices

Neuerdings wurde im Forum allerdings öfters berichtet, dass bei neueren CPUs (neuer als 2015) Mitigations von Windows für bekannte Vulnerabilities in den CPUs aktiv sind, sobald man den CPU-Typ "host" setzt, was dann direkte Performanceprobleme zur Folge hat, darum sollte man dann X86-64-v2-aes statt host nehmen:
D

Thread 'CPU type `host` is significantly SLOWER than `x86-64-v2-AES`'

I am shocked to discover what seems absolutely counter-intuitive to me, but maybe someone can explain me?

I have a stock Win11 24H2 and I initially set it up with x86-64-v2-AES and it was zipping along as one would expect.

1734300836343.png

Then I realized there is a 'host' CPU type and since I have a 128 GB 72 Core Dual Xeon (Lenovo Thinkstation P710) Proxmox server, I figured I'd just allocate directly as "native" HAS to be better/faster than emulated (anything) right? Wrong.

What I didn't expect is that the VM is barely usable!? The CPUs ALL peg at 100% and eventually...
  • Like
M

Thread 'Server 2025 VMs unglaublich träge'

Guten Tag zusammen,

wir haben auf unserem Cluster das Problem das Win Server 2025 VMs unglaublich träge sind.
die 2022er, 2019er, alle Linux Maschinen haben keinerlei Probleme und reagieren flüssig.
Einzig allein die 2025er reagieren langsam, File Explorer starten heißt Icon anklicken, bis 5 zählen, Fenster baut sich auf.

Vielleicht hat jemand einen Tip, wir haben verschiedene Versionen der VirtIO Treiber probiert, Hardware der VMs rumgespielt, uns an die Tips hier im Forum und in der Doku gehalten, aber nichts hilft.

Kann ja fast nicht sein das wir die einzigen sind die diese Probleme...
K

Thread 'The Reasons for poor performance of Windows when the CPU type is host'

Hey guys, I did some experiments recently and I think I finally found out why Windows performs poorly when the CPU type is host. You can check the complete experiment process and conclusion in my blog (Chinese, use google translate!)

In short, the experiment finally found that the reason was that the two flags md_clear and flush_l1d caused performance problems. They would activate the CPU vulnerability mitigation measures of Windows, which would cause a significant increase in memory read latency, thus causing Windows to freeze.

The two flags md_clear and flush_l1d are not passed...
  • Like
 
  • Like
Reactions: ThoSo
Ralf Wolbers said:
Ich habe den ganzen Tag versucht diverse Windows und eine Debian VM von VMWare ESXI 6 nach Proxmox 8.4 zu migrieren. Das soll ja gehen. Die Debian VM läuft soweit. Die Windows VMs, Win 10 und Server 2022 laufen erst hoch und dann endet es mit dem helblauen Bildschirm und einem Neustart in den Reparaturmodus. Schaut man mit der Eingabeaufforderung auf die Festplatte, dann ist das Ganze nun auf Laufwerk x:\ Eine virtualisierte Windows 11 VM läuft gut. Was läuft da falsch?
Click to expand...
Alles ganz normal, du hast den migrierten Windows VMs einen VirtIO SCSi Controller zugewiesen, aber Windows hat keinen Treiber dafür. Auch wenn du die virtio Tools vorher installierst, macht Windows dir den Treiber nicht Bootfähig.
Hänge die OS Disk mal per IDE oder SATA ein, boote das Windows normal, dann gib der VM eine SCSI Disk (Dummy) dann im Gerätemanager checken ob der Treiber geladen wurde. Wenn die Disk und der SCSI Controller angezeigt werden, kannst du wieder ausschalten, die DummyDisk löschen und die OS Disk wieder per SCSI einhängen. (Bootreihenfolge beachten)
Das ist leider bei Windows so und kann man nicht anders machen.
 
  • Like
Reactions: Ralf Wolbers, Johannes S and news
Klassisches Windows Problem mit Storage Treibern, tritt genau so auf wenn man von Mainboard A nach B wechselt, und das einen anderen Chipsatz hat. Wenn über Image Programme, dann idealerweise mit "Bereinigung" der Storage Treiber, oder V2V / P2V Konvertierung. Pragon Hard Disk Manager oder Acronis kann das. Oder manuell die Registry bearbeiten.

Weiterhin bitte prüfen, ob die Ausgangs VM im Legacy Bios Mode oder UEFI installiert wurde, und ob TPM verwendet wurde.

Nach der erfolgreichen Portierung muss WIndows dann noch neu aktivert werden.
 
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom