Live-Migration - Extreme Disk-I/O in der initialen Phase auf dem Zielserver

J

jacotec

New Member
Nov 19, 2024
16
1
3
Kerpen, DE
Guten Morgen,

ich migriere gerade mein gesamtes Homelab von ESXi auf Proxmox. Dazu importiere ich jede einzelne VM vom ESXi-Server auf einen "Proxmox-Temporärserver", wo sie dann laufen, mache dann den eigentlichen Server platt, installiere Proxmox, füge ihn zum Cluster hinzu und mache dann eine Live-Migration der VM vom "Temporärserver" zurück auf den Zielserver.

Dateisystem ist LVM-Thin. Nach viel Lesen im Vorfeld ist das auf den Hardware-RAIDs meiner Dell-R720 für mich die bessere Lösung als IT-Mode und ZFS.

Nun zum eigentlichen Problem: In der Phase 1 der Live-Migration "bläst" der Zielserver ja erstmal den Datastore um die maximale Größe der virtuellen Festplatte der zu migrierenden VM auf, startet dann die Übertragung der gesamten Maximalgröße über das Netzwerk, und schrumpft dann die virtuelle Festplatte per guest-trim wieder zusammen.

Hierbei habe ich ein Problem, welches ich zukünftig gerne "entschärfen" möchte:

Wenn schon einige VMs auf dem Zielserver laufen (und demnach Disk-I/O verursachen), haut das initiale "Aufblasen" vor der eigentlichen Datenübertragung auf dem Datastore die IO-Verzögerung auf 25-30% hoch. In dieser Zeit laufen alle VMs auf dem Zielserver quasi so gut wie gar nicht, weil der IO-Wait extremst hoch ist. Gibt es einen Weg, dieses "Aufblasen" zu "entspannen" (also ihm deutlich geringere Priorätät) zu geben? Also quasi das "Aufblasen" mit einem IO-Nice zu versehen? Der Betrieb der vorhandenen VMs hat in meinen Augen deutlich Priorität.

Bei meiner aktuellen Migration (VM mit 500GB Disk, 80GB belegt) hat das "Aufblasen" den kompletten Server quasi gute 10 Minuten lahmgelegt. Sobald die Übertragung der Daten über das LAN beginnt, ist alles wieder fein.


Da ich gerne die Dinge, die da passieren, technisch auch in der Tiefe verstehen möchte: Warum ist das initiale "Aufblasen" und das anschließende komplette Übertragen der gesamten Diskgröße bei Proxmox eigentlich notwendig? Wenn ich zum Beispiel eine VM mit einer virtuellen 1TB-Platte habe, von der nur 120GB wirklich verwendet sind (und die auch nur 120GB Platz im Thin-Datastore verbraucht) - dann müsste doch eigentlich auf dem Zielserver die gleiche Größe angelegt und auch nur die 120GB über das LAN geschickt werden? Es werden aber erst einmal 1TB auf dem Zielserver "reserviert" und auch wirklich 1TB über das LAN geschickt. Sind das alles "Nullen"?

Vielleicht hat ja jemand eine Erklärung für mich :cool:

Nach den ersten Tagen finde ich Proxmox wirklich in fast allen Belangen dem ESXi deutlich überlegen und bin ein richtiger "Fan" geworden ... aber der Punkt geht leider noch an ESXi. ;)

Viele Grüße,
Marco
 
Falk R. said:
Wie migrierst du denn? Dun kannst ja je nachdem wo die VMDK liegen einfach (NFS/SSHFS) einfach die VMDKs sichtbar machen und entweder mit qm importdisk importieren, da kopiert er nur echte Daten oder nimme diese Anleitung:
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime)
Click to expand...
Hi Falk,

das Problem liegt nach der Migration, die Migration funktioniert wunderbar entweder über die Import-Funktion oder über Veeam. Das Problem tritt auf, wenn ich die bereits nach Proxmox migrierte VM von meinem "Proxmox-Übergangsserver" nach Umstellung auf Proxmox wieder auf den eigentlichen Server innerhalb des Proxmox-Clusters Live-Migriere.

Ich habe inzwischen herausgefunden, dass dieses extrem IO-lastige "Aufblasen" des Datastore auf dem Zielserver nicht passiert, wenn ich die VM vor der Live-Migration ausschalte. Nur habe ich eben dann nochmals eine längere Downtime - und der Effekt wird jedesmal passieren, wenn ich eine laufende VM von einem Proxmox-Node zum nächsten Live-Migriere.
 
Welche Typen Datastores hast du denn auf Quell und Zielseite?
 
Was für ein Hardware Raid hast du da drunter? Ist da ein Batteriecache verbaut? Wenn du so hohen Delay hast, vermutlich nicht oder falsch konfiguriert.
 
  • Like
Reactions: Johannes S
Falk R. said:
Was für ein Hardware Raid hast du da drunter? Ist da ein Batteriecache verbaut? Wenn du so hohen Delay hast, vermutlich nicht oder falsch konfiguriert.
Click to expand...
Ist ein Perc H710 mit Cache und Backup-Batterie, ja. Aber alles richtig konfiguriert und lief schon jahrelang ohne Probleme mit ESXi.

Es geht mir mehr darum warum dieses "Aufblasen" bei Proxmox bei der Live-Migration nötig ist und vor allem, warum es mit allem was es hat irre hohe Disk-IO während dieser Phase macht. Und ob man die Disk-I/O während dieser "Aufblasphase" irgendwie begrenzen kann.
 
Das Problem bei der Live Migration auf LVM thin ist, dass die Disk vorher fertig initialisiert werden muss. Wenn Discard aktiv ist auf der Disk, wird dann alles mit 0 befüllt bevor die eigentlichen Daten migriert werden [0].
Das passiert alles im QEMU. Dafür gibt es derzeit keinen Workaround. Es betrifft auch nur LVM thin.

Und ob man die Disk-I/O während dieser "Aufblasphase" irgendwie begrenzen kann.
Click to expand...
Nein, bisher nicht.

[0] https://forum.proxmox.com/threads/v...iscard-results-in-high-i-o.97647/#post-423059
 
  • Like
Reactions: jacotec and Johannes S
Das er die Nullen mit migrieren möchte, liegt daran, dass die Datenkonsistenz immer gewährleistet sein muss, auch wenn verschiedene Storages/Features genutzt werden. Wenn die RAID Batterie OK wäre, dürftest du gar nix davon merken, denn dann würde der Cache alles annehmen und die Nullen verwerfen.
 
  • Like
Reactions: jacotec and Johannes S
mira said:
Das Problem bei der Live Migration auf LVM thin ist, dass die Disk vorher fertig initialisiert werden muss. Wenn Discard aktiv ist auf der Disk, wird dann alles mit 0 befüllt bevor die eigentlichen Daten migriert werden [0].
Das passiert alles im QEMU. Dafür gibt es derzeit keinen Workaround. Es betrifft auch nur LVM thin.


Nein, bisher nicht.

[0] https://forum.proxmox.com/threads/v...iscard-results-in-high-i-o.97647/#post-423059
Click to expand...
Es betrifft auch LVM, z.B. auf Shared LUNs.
Da haut der I/O richtig rein.
 
  • Like
Reactions: jacotec and Johannes S
mira said:
Das Problem bei der Live Migration auf LVM thin ist, dass die Disk vorher fertig initialisiert werden muss. Wenn Discard aktiv ist auf der Disk, wird dann alles mit 0 befüllt bevor die eigentlichen Daten migriert werden [0].
Das passiert alles im QEMU. Dafür gibt es derzeit keinen Workaround. Es betrifft auch nur LVM thin.


Nein, bisher nicht.

[0] https://forum.proxmox.com/threads/v...iscard-results-in-high-i-o.97647/#post-423059
Click to expand...
Danke für die Erklärung, Mira :)

Ich bin noch nicht ganz dahintergestiegen, was passieren würde wenn Discard nicht aktiv ist. Belegt der VM dann immer den kompletten Diskspeicher? (Also wie, als Thick provisioniert wäre)?
 
Heißt das unter dem Strich, ich könnte es wie folgt machen:

- Discard aus
- Live Migration ohne das I/O-lastige füllen der Maximalgröße mit Nullen auf dem Zielserver
- Discard nach Migration wieder an, damit die Disk klein bleibt
 
Ohne Discard muss dafür bei der Migration die ganze Disk, inklusive Nullen kopiert werden. Hier sollte aber dann das Bandbreitenlimit greifen.
 
  • Like
Reactions: Johannes S
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