Proxmox local HDD kopieren verbessern

[chrigiboy]

Hallo,
man nehme 2 Proxmox v6 oder v7 Server im Verbund. 1 VM mit 3 Tbyte Diskspace. Mounte diese als IDE, startet die VM und migriert die VM live, von Proxmox 1 auf Proxmox 2 (local LVM zu Local LVM). Der Kopiervorgang startet innerhalb von wenigen Minuten, die % Anzeige wird im Status angezeigt , die CPU Last ist nicht hoch, die Netzwerklast geht auf 100%. Der Kopiervorgang funktioniert wie erwartet.

Man wiederhole den Vorgang und verwendet anstatt IDE nun virtSCSI, virtIO für die laufende Maschine.
Der Kopiervorgang startet erst viel später, je nach dem erst nach Stunden, die % Anzeige startet nicht sofort, die CPU Last geht auf 100%, die Netzwerklast ist 0%. Während diesem Vorgang wir die Festplatte auf dem Zielsystem angelegt (ersichtlich durch die HDD Auslastungsstatistik), ich vermute es werden alles 0 geschrieben. Aus meiner Sicht macht das aber absolut keinen Sinn, denn egal ob IDE, SCSI oder Virtio die HDD die dahinter hängt ist ja immer die gleiche, deshalb kann man auch eine HDD abhängen und wieder als SCSI, IDE oder Virtio anhängen ohne die Festplatte kopieren zu müssen. Deshlab bin ich der Meinung sollte das Kopieren von IDE oder virtIO oder SCSI immer gleich sein. Da muss ein Fehler sein, weil der Kopiervorgang muss sich aus meiner Sicht sich wie eine IDE Festplatte verhalten.
Nach ein paar Stunden, beginnt dann erst der eigentliche Kopiervorgang, der sich dann wie bei IDE verhält. Hier in diesem Fall, war die Festplatte am Zielort nach 1 Stunde und 16 Minuten erstellt. In dieser Zeit waren 128 CPU's auf 100% Auslastung, etwas das bei IDE nicht passiert. Anschliessend startete der Kopiervorgang wie bei IDE. Proxmox benötigt nun für 29 MByte ganze 76 Minuten! Man verliert dadurch Zeit und verbrennt unsinnigerweise Strom.

bei IDE:
2021-07-29 16:38:39 starting migration of VM 101 to node 'proxmox2' (192.168.1.2)
2021-07-29 16:38:39 found local disk 'local-lvm:vm-101-disk-1' (in current VM config)
2021-07-29 16:38:39 starting VM 101 on remote node 'proxmox2'
2021-07-29 16:38:41 volume 'local-lvm:vm-101-disk-1' is 'local-lvm:vm-101-disk-0' on the target
2021-07-29 16:38:41 start remote tunnel
2021-07-29 16:38:41 ssh tunnel ver 1
2021-07-29 16:38:41 starting storage migration
2021-07-29 16:38:41 ide0: start migration to nbd:unix:/run/qemu-server/101_nbd.migrate:exportname=drive-ide0
drive mirror is starting for drive-ide0
drive-ide0: transferred 0.0 B of 1.9 TiB (0.00%) in 0s
drive-ide0: transferred 104 MiB of 1.9 TiB (0.01%) in 1s
drive-ide0: transferred 215 MiB of 1.9 TiB (0.01%) in 2s
drive-ide0: transferred 328 MiB of 1.9 TiB (0.02%) in 3s
drive-ide0: transferred 440 MiB of 1.9 TiB (0.02%) in 4s



bei SCSI
2021-08-05 10:37:49 starting migration of VM 101 to node 'proxmox2' (192.168.1.2)
2021-08-05 10:37:49 found local disk 'local-lvm:vm-101-disk-1' (in current VM config)
2021-08-05 10:37:49 starting VM 101 on remote node 'proxmox2'
2021-08-05 10:37:51 volume 'local-lvm:vm-101-disk-1' is 'local-lvm:vm-101-disk-0' on the target
2021-08-05 10:37:51 start remote tunnel
2021-08-05 10:37:52 ssh tunnel ver 1
2021-08-05 10:37:52 starting storage migration
2021-08-05 10:37:52 scsi0: start migration to nbd:unix:/run/qemu-server/101_nbd.migrate:exportname=drive-scsi0
drive mirror is starting for drive-scsi0
drive-scsi0: transferred 29.0 MiB of 1.9 TiB (0.00%) in 1h 16m 2s
drive-scsi0: transferred 141.0 MiB of 1.9 TiB (0.01%) in 1h 16m 3s
drive-scsi0: transferred 253.0 MiB of 1.9 TiB (0.01%) in 1h 16m 4s
drive-scsi0: transferred 365.0 MiB of 1.9 TiB (0.02%) in 1h 16m 5s
drive-scsi0: transferred 477.0 MiB of 1.9 TiB (0.02%) in 1h 16m 6s
drive-scsi0: transferred 589.0 MiB of 1.9 TiB (0.03%) in 1h 16m 7s
drive-scsi0: transferred 703.0 MiB of 1.9 TiB (0.04%) in 1h 16m 8s
drive-scsi0: transferred 815.0 MiB of 1.9 TiB (0.04%) in 1h 16m 9s
drive-scsi0: transferred 926.0 MiB of 1.9 TiB (0.05%) in 1h 16m 10s
drive-scsi0: transferred 1.0 GiB of 1.9 TiB (0.05%) in 1h 16m 11s
drive-scsi0: transferred 1.1 GiB of 1.9 TiB (0.06%) in 1h 16m 12s
drive-scsi0: transferred 1.2 GiB of 1.9 TiB (0.06%) in 1h 16m 13s
drive-scsi0: transferred 1.3 GiB of 1.9 TiB (0.07%) in 1h 16m 14s
drive-scsi0: transferred 1.4 GiB of 1.9 TiB (0.08%) in 1h 16m 15s

 

[s-mendyka]

Ich habe das gleiche Problem!

Der Task steht gefühlt ewig an dem Punkt:

2021-08-08 22:28:29 scsi1: start migration to nbd:unix:/run/qemu-server/502_nbd.migrate:exportname=drive-scsi1

Auf dem Zielserver steigt die IO-Last auf über 70%, was dazu führt das die laufenden VM´s auf dem Server Probleme haben.

Sobald er wirklich anfängt Traffic zu verursachen / Daten zu verschieben, geht die IO wieder runter und alles läuft wie erwartet.
Unsere VM´s haben alle folgende Settings:

- Ballooning aktiv
- Numa aktiv
- SCSI Controller "Virtio SCSI single"
- Hard Disk: cache=writeback,discard=on,iothread=1, replicate=0

P.S. Ich selbst habe "IDE" als Typ noch nicht getestet!



Viele Grüße
Sebastian

 

[s-mendyka]

Nachtrag:

Bei mir ist es praktisch egal ob virtio-blk sata oder ide, das Problem erscheint bei jedem Format

Auffällig ist, dass am Ziel Server folgender Prozess erscheint und erstmal 100% Auslastung des IO-Subsystems verursacht:
io_wqe_worker (ca. 8x als worker 0 und 1)

kann man diesen Prozess (wahrscheinlich zum reservieren des SPACE?) einen IONICER mitgeben?

Nachtrag2:

Wenn das Storage am PROXMOX vom Typ "dir" ist anstatt "lvm-thin" startet die Migration sofort! ohne hoher IO

 

[s-mendyka]

Ich konnte das Problem nun identifizieren. Sobald bei der VM die migriert werden soll. "discard" aktiv ist, kommt es während der Migration am Zielserver zu der hohen IO Last. Es scheint so, als würde der migrate Prozess vorerst die "nullen" schreiben, bevor er mit der Übertragung anfängt

Wenn "discard" an den VMs deaktiviert ist, fängt der migrate Prozess sofort an, Daten übers Netzwerk zu schaufeln.

Viele Grüße

 

[chrigiboy]

Hallo,
kann ich bestätigen! Der Bug liegt an Discard. Ich hoffe das wird schnell gefixt!