Windows VM nach Konvertierung von vmware nach pve langsamer als neu gebaute vm

A

aschiefer

Member
Dec 5, 2019
11
1
23
Cologne, Germany
www.vision4it.de
Ich habe ein PVE 8.1 Cluster mit Ceph reef Cluster aktiv.
Das Ceph Cluster besteht aus reinen HDD Platten und NVMEs als WAL/DB. Angebunden ist es mit 10G.

Auf den Proxmox laufen neu erstelle Windows Server 2022 VMs und auch welche die von VMWare nach Proxmox konvertiert wurden.
Die Installationen sind bei den VMs gleich (HDD Anzahl und Größe weichen schon mal ab).
Es sind immer SCSI Platten auf VirtIO SCSI Single Controller.
Hier die Conf von einer konvertierten VM:

Code: 
agent: 1,fstrim_cloned_disks=1
balloon: 0
bios: ovmf
boot: order=scsi1;ide2;net0
cores: 16
cpu: x86-64-v2-AES
efidisk0: vmstore:vm-114-disk-1,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: none,media=cdrom
machine: pc-q35-8.1
memory: 32768
meta: creation-qemu=7.2.0,ctime=1685567503
name: vBKP01
net0: virtio=00:50:56:ad:c2:4e,bridge=vmbr0,firewall=1,tag=40
numa: 0
ostype: win11
parent: autodaily231130000817
scsi1: vmstore:vm-114-disk-0,cache=writeback,discard=on,iothread=1,size=250G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=388b288e-2e95-4e8e-ab3e-a51bd7b75870
sockets: 1
tags: aktiv
vmgenid: 9dfca340-6021-4a06-b1d8-17470db8e750

pveversion Info:
Code: 
proxmox-ve: 8.1.0 (running kernel: 6.2.16-15-pve)
pve-manager: 8.1.3 (running version: 8.1.3/b46aac3b42da5d15)
proxmox-kernel-helper: 8.1.0
pve-kernel-6.2: 8.0.5
pve-kernel-5.15: 7.4-7
proxmox-kernel-6.5: 6.5.11-6
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
proxmox-kernel-6.5.11-4-pve-signed: 6.5.11-4
proxmox-kernel-6.2.16-19-pve: 6.2.16-19
proxmox-kernel-6.2: 6.2.16-19
proxmox-kernel-6.2.16-15-pve: 6.2.16-15
pve-kernel-6.2.16-11-bpo11-pve: 6.2.16-11~bpo11+2
pve-kernel-6.2.16-4-bpo11-pve: 6.2.16-4~bpo11+1
pve-kernel-5.15.126-1-pve: 5.15.126-1
pve-kernel-5.15.102-1-pve: 5.15.102-1
ceph: 18.2.0-pve2
ceph-fuse: 18.2.0-pve2
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx7
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.1
libpve-access-control: 8.0.7
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.1.0
libpve-guest-common-perl: 5.0.6
libpve-http-server-perl: 5.0.5
libpve-network-perl: 0.9.4
libpve-rs-perl: 0.8.7
libpve-storage-perl: 8.0.5
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-3
openvswitch-switch: 3.1.0-2
proxmox-backup-client: 3.0.4-1
proxmox-backup-file-restore: 3.0.4-1
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.2
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.1.3
pve-cluster: 8.0.5
pve-container: 5.0.8
pve-docs: 8.1.3
pve-edk2-firmware: 4.2023.08-2
pve-firewall: 5.0.3
pve-firmware: 3.9-1
pve-ha-manager: 4.0.3
pve-i18n: 3.1.2
pve-qemu-kvm: 8.1.2-4
pve-xtermjs: 5.3.0-2
qemu-server: 8.0.10
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.0-pve4

Problem ist aber das die HDD Performance der konvertierten wesentlich schlechter ist als die der neu erstellten VMs.
Wir lesen bei den konvertierten HDDs mit 30 MB/s und bei den neuen VMs mit 200 MB/s.
Die Werte habe ich ganz simpel mit Powershell und dem Befehl
Code: 
winsat disk -seq -read -drive C
ermittelt.
Aber auch bei der Nutzung merkt man die Trägheit der Platte.

Was kann man machen?
Sind noch alte VMWare Treiber Fragmente drin? Die VMWare Tools wurden entfernt und die aktuellen VirtIO Treiber installiert.

Danke für eure Hilfe und Anregungen im Voraus
Andreas
 
Last edited:
Wenn du also mit exakt der gleichen Konfiguration eine neue VM erstellst, sind die Werte unterschiedlich? Oder hast du vielleicht doch Abweichungen drin? Zeig uns doch bitte mal dazu die Config von einer neuen VM, die schneller sein soll.

Hast sich an der Hardware etwas maßgeblich geändert oder sind es noch die gleichen HV?
 
sb-jw said:
Wenn du also mit exakt der gleichen Konfiguration eine neue VM erstellst, sind die Werte unterschiedlich? Oder hast du vielleicht doch Abweichungen drin? Zeig uns doch bitte mal dazu die Config von einer neuen VM, die schneller sein soll.

Hast sich an der Hardware etwas maßgeblich geändert oder sind es noch die gleichen HV?
Click to expand...
Hier eine Config eines schnelleren neuen Systems:

Code: 
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi1;ide2;net0
cores: 8
cpu: x86-64-v2-AES
efidisk0: vmstore:vm-130-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: none,media=cdrom
machine: pc-q35-8.1
memory: 8192
meta: creation-qemu=7.2.0,ctime=1686229830
name: vDC01
net0: virtio=00:50:56:ad:50:52,bridge=vmbr0,tag=20
numa: 1
ostype: win11
parent: autodaily231130000329
scsi1: vmstore:vm-130-disk-1,cache=writeback,discard=on,iothread=1,size=100G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=242b6670-f443-492d-b5d2-f973b811e435
sockets: 1
tags: aktiv
vmgenid: 0d299f85-3d0b-4c65-b0e4-b81335f5421d

Die beiden VMs sind gleich alt auf dem Proxmox.
Das Ceph Cluster wurde um weitere HDDs und Server erweitert.
Updates gab es von Proxmox 7 auf 8.1 und Ceph von 17 auf 18.
 
Last edited:
Sind total unterschiedliche Anzahl an Cores und Memory.

Neue VM: 8 cores und 8 GB RAM
Convertierte VM: 16 cores und 32 GB RAM

Bitte stell mal bei der convertierten VM ebenfalls 8 cores und 8 GB RAM ein und teste nochmals.

---

Wie sind die Ressourcen deines Hosts bezüglich Gesamt-Cores und Gesamt-RAM?

Zum Removen von Ghost-Devices innerhalb deiner Windows-VMs kannst du folgendes Script verwenden: https://github.com/istvans/scripts/blob/master/removeGhosts.ps1
 
Last edited:
JohnRanger said:
Bitte stell mal bei der convertierten VM ebenfalls 8 cores und 8 GB RAM ein und teste nochmals.
Click to expand...
Was genau ist denn deine Theorie dazu? Ich kann dir nämlich nicht folgen, die konvertiere hat ja weniger Disk I/O aber mehr RAM und CPU, jetzt willst du der geschwächten VM noch weniger Leistung geben und erwartest dann genau was?

Ich hätte vielleicht eher noch auf ein NUMA Problem getippt, da das aus Sicht der Architektur nämlich ein viel größeres Problem sein kann. Hier wäre aber die Hardware noch interessant.
 
sb-jw said:
Was genau ist denn deine Theorie dazu? Ich kann dir nämlich nicht folgen, die konvertiere hat ja weniger Disk I/O aber mehr RAM und CPU, jetzt willst du der geschwächten VM noch weniger Leistung geben und erwartest dann genau was?

Ich hätte vielleicht eher noch auf ein NUMA Problem getippt, da das aus Sicht der Architektur nämlich ein viel größeres Problem sein kann. Hier wäre aber die Hardware noch interessant.
Click to expand...
Die Proxmox Server / Ceph Server sind leider nicht alle identisch.
Der auf dem die beiden VMs laufen die hier verglichen werden - wobei es egal ist auf welchem Proxmox sie laufen - ist mit dieser Hardware ausgestattet:

Supermicro X10SRA
1 x Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
8 x 64GiB DIMM DDR4 Synchronous 3200 MHz (0.3 ns)
1 x 120GB Samsung SSD 750 Bootsystem / Proxmox
2 x Ethernet Controller 10-Gigabit X540-AT2
Mehrere HDDs für Ceph und 2 nvme für Ceph WAL/DB

die anderen sind aber in ähnlicher Ausstattung.

Wir haben schon mit Memory und CPU gespielt, was aber nichts an Perfomance brachte.
 
Ich vermute mal, dass die CPU und RAM Einstellungen dabei auch egal sind. Das Flag NUMA könnte das interne Handling von Windows beeinflussen, wobei auch das schon eine entferntere Theorie wäre.

Ich habe noch eine andere Theorie, nämlich dass mit dem Disk Layout irgendwo was in die Hose gegangen ist. Um das herauszufinden oder ggf. zu lösen, könntest du mal die betroffene Disk klonen und in die andere VM hängen die gut funktioniert. Da versucht du einfach noch mal einen Speedtest auf beiden virtuellen Disks auszuführen. Damit hättest du zumindest die Gewissheit, dass das Problem auf der virtuellen Disk hängt oder nicht.
Die andere Möglichkeit wäre vielleicht noch, dass du die VM klonst oder den Storage auf lokal verschiebst, dann wieder auf CEPH zurück und dann noch mal schaust. Eventuell würde das zurückspielen der Disk in CEPH hier auch auf dem Storage wieder was gerade ziehen. Das könntest du z. B. auch versuchen mit einem Backup (entweder so oder auch).

Ansonsten könnte das Problem tiefer begraben liegen und könnte z. B. was mit NTFS zu tun haben. Wenn möglich, dann versucht mal zu vergleichen ob auf dem VMware Storage vorher ähnliche Parameter wie im CEPH gesetzt sind. Wenn Ihr vSan verwendet habt, dann bitte versuchen unterschiede im vSAN zu finden.

Alles andere erscheint mir persönlich einfach nicht mehr als logisch in diesem Fall - meiner Ansicht nach muss es etwas mit der virtuellen Platte oder dem FS zu tun haben.
 
@aschiefer kannst du mal die Ausgabe der folgenden Befehle posten?

List die Infos der RBD Images auf dem CEPH für die konvertierte und nicht konvertierte aus:
Code: 
rbd info vmstore/vm-114-disk-0
rbd info vmstore/vm-130-disk-1

Auf beiden VMs dann noch in der PowerShell den folgenden Befehl, dass man mal sieht ob die FS gleich konfiguriert sind.
Code: 
Get-CimInstance -ClassName Win32_Volume | Select-Object DriveLetter, FileSystem, BlockSize | Format-Table -AutoSize
 
  • Like
Reactions: fireon
CPU kann natürlich auch etwas ausmachen.
Generell würde ich die VMs auf Typ „host“ oder der CPU Typ von der ältesten CPU.
Warum die Disks so langsam sind, liegt garantiert an der Art, der Konvertierung.
Wenn man beim Konvertieren nicht aufpasst, geht das Alignment des Filesystems in die Hose und du hast dann pro I/O der VM, das doppelte an Backend I/O als eine neue Maschine.
Gerade bei nur 10 GBit und Ceph Cluster sowie Client laufen zusammen, läufst du dann schnell in ein Bottleneck.
 
sb-jw said:
@aschiefer kannst du mal die Ausgabe der folgenden Befehle posten?

List die Infos der RBD Images auf dem CEPH für die konvertierte und nicht konvertierte aus:
Code: 
rbd info vmstore/vm-114-disk-0
rbd info vmstore/vm-130-disk-1

Auf beiden VMs dann noch in der PowerShell den folgenden Befehl, dass man mal sieht ob die FS gleich konfiguriert sind.
Code: 
Get-CimInstance -ClassName Win32_Volume | Select-Object DriveLetter, FileSystem, BlockSize | Format-Table -AutoSize
Click to expand...

Code: 
rbd image 'vm-114-disk-0':
        size 250 GiB in 64000 objects
        order 22 (4 MiB objects)
        snapshot_count: 4
        id: c27fd1136c3d1
        block_name_prefix: rbd_data.c27fd1136c3d1
        format: 2
        features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
        op_features:
        flags:
        create_timestamp: Tue Jun  6 18:17:27 2023
        access_timestamp: Tue Oct 17 17:07:56 2023
        modify_timestamp: Tue Oct 17 17:07:33 2023

rbd image 'vm-130-disk-1':
        size 100 GiB in 25600 objects
        order 22 (4 MiB objects)
        snapshot_count: 6
        id: 162987aa8cedde
        block_name_prefix: rbd_data.162987aa8cedde
        format: 2
        features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
        op_features:
        flags:
        create_timestamp: Thu Jun  8 15:11:55 2023
        access_timestamp: Tue Oct 17 17:06:35 2023
        modify_timestamp: Tue Oct 17 17:06:33 2023

vom langsamen System das Powershell Ergebnis:
Code: 
DriveLetter FileSystem BlockSize
----------- ---------- ---------
C:          NTFS            4096
            NTFS            4096
            FAT32           1024
D:

vom schnellen System das Powershell Ergebnis:
Code: 
DriveLetter FileSystem BlockSize
----------- ---------- ---------
C:          NTFS            4096
            NTFS            4096
            FAT32           1024
D:
 
Falk R. said:
CPU kann natürlich auch etwas ausmachen.
Generell würde ich die VMs auf Typ „host“ oder der CPU Typ von der ältesten CPU.
Warum die Disks so langsam sind, liegt garantiert an der Art, der Konvertierung.
Wenn man beim Konvertieren nicht aufpasst, geht das Alignment des Filesystems in die Hose und du hast dann pro I/O der VM, das doppelte an Backend I/O als eine neue Maschine.
Gerade bei nur 10 GBit und Ceph Cluster sowie Client laufen zusammen, läufst du dann schnell in ein Bottleneck.
Click to expand...

Als CPU nehmen wir den neuen Typ aus Proxmox 8: x86-64-v2-AES
Wenn es ein Konvertierungsfehler ist, dann müsste aber eine weitere Platte die neu erstellt und eingebunden wird schneller sein?
 
@aschiefer wie alt und groß sind denn die Snapshots?

Entweder via PVE auslesen oder direkt per RBD:
Code: 
rbd snap ls vmstore/vm-114-disk-0
rbd snap ls vmstore/vm-130-disk-1

Ist zwar nur eine entfernte Theorie, aber vielleicht hilft es wenn du mal alle Snapshots löscht.

Ansonsten schau mal, ob vielleicht persistent Cache für die eine VM aktiviert ist und für die andere nicht:
Code: 
rbd status vmstore/vm-114-disk-0
rbd status vmstore/vm-130-disk-1

aschiefer said:
Wenn es ein Konvertierungsfehler ist, dann müsste aber eine weitere Platte die neu erstellt und eingebunden wird schneller sein?
Click to expand...
Du kannst natürlich mal versuchen eine neue Platte zusätzlich einzuhängen. Umgekehrt kannst du es auch machen und die problematische Disk klonen und in eine andere VM einhängen.

Hast du ansonsten mal chkdsk ausprobiert? Vielleicht findet das ja noch irgendwelche Fehler, was das Problem behebt oder zumindest weitere Rückschlüsse gibt.

Ist die Komprimierung auf dem Laufwerk vielleicht aktiviert und bei dem anderen nicht? Hast du mal z. B. Crystaldiskmark probiert? Kannst du auch mal schauen ob vielleicht der Cache innerhalb der VM deaktiviert ist (Get-PhysicalDisk | Get-StorageAdvancedProperty)?

aschiefer said:
Die VMWare Tools wurden entfernt und die aktuellen VirtIO Treiber installiert.
Click to expand...
Hattest du noch mal geschaut, ob es zwischenzeitlich ein Update gegeben hat, was vielleicht hilft? Hast du die Treiber über "virtio-win-guest-tools" installiert oder einzeln über die Ordner? Steht im Gerätemanager vielleicht noch was auf unknown?
 
aschiefer said:
Als CPU nehmen wir den neuen Typ aus Proxmox 8: x86-64-v2-AES
Click to expand...
Das ist der neue Standard für minimalstes Featureset bei Maximaler Kompatibilität. In der Regel läuft ein aktuelles OS fast doppelt so schnell mit der Option "host".
aschiefer said:
Wenn es ein Konvertierungsfehler ist, dann müsste aber eine weitere Platte die neu erstellt und eingebunden wird schneller sein?
Click to expand...
Jupp, da bei einer neuen Disk das Alignment sauber vom OS erkannt wird und dann passend formatiert wird.
 
Ich würde dann das ganze auf jeden Fall mal mit fio vergleichen. Hier ein paar Beispiele aus dem ZFS. Bitte auf ein File umschreiben.
Code: 
# Random Read - IOPS - bs=4k (Restore)

fio --rw=randread --name=iops-randread --bs=4k --direct=1 --sync=1 --size=100G --sync=1 --filename=<zvol> --numjobs=4 --ioengine=libaio --iodepth=32 --refill_buffers --group_reporting --runtime=600 --time_based

# Random Read - Bandwidth - bs=4M (Restore)

fio --rw=randread --name=bw-randread --bs=4M --direct=1 --sync=1 --size=100G --sync=1 --filename=<zvol> --numjobs=4 --ioengine=libaio --iodepth=32 --refill_buffers --group_reporting --runtime=600 --time_based

# Normaler Lesetest 4M

fio --ioengine=psync --direct=1 --sync=1 --rw=read --bs=4M --numjobs=1 --iodepth=1 --runtime=60 --time_based --name read_4M --filename=<zvol> --size=50G

# Schreibtest 4M

fio --ioengine=psync --direct=1 --sync=1 --rw=write --bs=4M --numjobs=1 --iodepth=1 --runtime=60 --time_based --name write_4M --filename=<zvol> --size=50G
 
@aschiefer hast du mal geschaut ob z. B. Der Cache deaktiviert (Befehl siehe meinen vorherigen post) ist oder die Komprimierung aktiviert?
 
aschiefer said:
okay, also eine weitere Platte reingehangen und auf der ist die Performance so wie sie sein soll. Also dürfte das Alignment unsauber sein.
Kann man das mit Boardmitteln korrigieren?
Click to expand...
Ja, neu formatieren.
Deshalb hänge ich die VMDKs direkt in die PVE VMs und migriere die Disks mit Boardmitteln auf andere Datastores. Da bleibt das Alignment zu 99.9% erhalten.
 
  • Like
Reactions: fireon
Falk R. said:
Ja, neu formatieren.
Click to expand...
und ich hatte gehofft es gäbe da was aus der Apotheke.

Falk R. said:
Deshalb hänge ich die VMDKs direkt in die PVE VMs und migriere die Disks mit Boardmitteln auf andere Datastores. Da bleibt das Alignment zu 99.9% erhalten.
Click to expand...
die VMDKs direkt in die PVE VMs hängen heißt mit "qm imortdisk " auf eine lokales Storage und danach mit der Proxmox WebGUI nach Ceph schieben und nicht direkt mit diesem Befehl auf Ceph importieren?
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back