Plötzlich auftretende Probleme beim Bewegen von HDDs auf Shared Storage

[stefan.schumacher]

Hallo liebe Proxmox-Gemeinde,

Wir haben ein Problem beim Bewegen einer virtuellen HDD vom lokalen Thin-LVM auf den Shared Storage (Dell, 2x10Gbits Glaseranbindung. Also keine Hobbyhardware).
Wir hatten auf dem Thin_LVM mit Snapshots während eines Upgrades gearbeitet. Nun soll das HDD-Image zurück in den Shared_Storage. Ich mache also ein Move_Disk und
folgender Bildschirm erscheint.

create full clone of drive scsi0 (lvm_thin:vm-1034-disk-0)
Logical volume "vm-1034-disk-4" created.
drive mirror is starting for drive-scsi0

Danach passiert erstmal nichts und dann sprechen die Monitoring-Systeme an weil unsere VMs nicht mehr zu erreichen sind. Ich musste nach 7 Minuten abbrechen, weil, alle anderen VMs auf dem Cluster, also nicht nur der lokalen Node, ausgefallen sind. Ich vermute, daß die Netzwerkverbindung zum Storage durch das Bewegen der Festplatte (Größe übrigens 250GB) irgendwie so saturiert worden ist, daß die Festplatten der VM ihre Anbindung an den Storage verloren haben.

Dies verwundert mich extrem, wir haben nämlich genau das selbe schon mindestens 80 mal gemacht, als wir Maschinen von unseren alten Xen-Servern nach Proxmox migriert haben. In einen Zusammenhang bringen kann ich das nur mit der Tatsache, daß ich - siehe dazu den entsprechenden Thread - auf allen Nodes des Clusters gestern ein Upgrade installiert habe. Das ist natürlich nur eine Vermutung. Ich bitte um Empfehlung wie ich weiter vorgehen soll. Ich nehme an an dieser Stelle ist das erstmal noch eine Frage der weiteren Diagnose - aber so gut kenne ich mich in Proxmox noch nicht aus.

Im Voraus dankt
Stefan Schumacher

 

[mira]

Bitte die Storage Config (/etc/pve/storage.cfg) posten. Um welchen Storage handelt es sich?
Zusätzlich bitte auch den Output von pveversion -v und qm config 1034 posten.

 

[stefan.schumacher]

Hallo Mira,

anbei erhälst du die Ausgabe der beiden Befehle und die storage.cfg. Leider möchte das Forum immer eine Dateiendung, deswegen das unnütze .txt.

Wir möchten die HDD von

lvmthin: lvm_thin
thinpool data
vgname pve
content images,rootdir

nach
lvm: nf_lvm
vgname nf-lvmstorage
content rootdir,images
shared 1

bewegen. Das ist wie erwähnt ein Shared LVM und via iSCSI angebunden.

Viele Grüße
Stefan

 

[stefan.schumacher]

Ich habe eben auf einer anderen Node des Clusters ein Template nach local-lvm geklont und dann versucht dieses in den Shared Storage zu verschieben. Auch hier ging die CPU-Last (Der Server hat 2 Sockets und 2 Xeon Silver mit 8 Cores, also insgesamt 32 vCPUs. Normalerweise idlet der bei knapp 10 Prozent) so schnell hoch, daß ich den Vorgang abbrechen mußte damit es bei den VMs keine Ausfälle gibt. Ich schaue mir mal gleich den Vorgang mit einem Mitarbeiter des Rechenzentrums an. Gibt es von eurer. d.h. der Proxmox-Seite noch Bedarf an Informationen, die helfen könnten das Problem zu diagnostizieren? Ich kann ja meine VMs nicht unbegrenzt auf dem lokalen Storage anlegen - das sind nämlich nur ein paar hundert Gigabyte Thin.

Nochmal: Die Probleme fangen an wenn der Upload zum Storage noch bei 0% ist. Weiter komme ich nur wenn ich meine Live-Systeme auf der anderen Node gegen die Wand fahren lasse und das mag mein Chef vermutlich nicht so gerne.


Viele Grüße
Stefan

 

[Thomas15]

Hallo,

ich bin ebenfalls in dem Thema involviert. Beim Testklon einer VM mit 25GB wird dieser Befehl generiert, der das Image vom alten auf den neuen Storage kopiert:

/usr/bin/qemu-img convert -p -n -f raw -O raw /dev/pve2/vm-9999-disk-0 /dev/nf-lvmstorage/vm-9999-disk-0

Dadurch entsteht auf dem Zielstorage (/nf-lvmstorage) eine hohe I/O load, wodurch es zu IO delay auf allen Hosts kommt, die VMs auf diesem Storage ausführen. Es besteht keine CPU Load. Die VM mit 25GB geht noch durch, ohne, dass alles in die Knie geht. Sobald der Tasks den Fortschritt in Prozentwerten anzeigt, geht der IO delay auch runter.

Wenn ich allerdings die größere VM mit 300GB Speicher migriere ist nichts zu machen. Ich habe versucht das zu beheben, indem ich den Quell- und Zielstorage durch bwlimits auf 10MB/s reduziert habe, das hilft auch nicht. Ich muss den Tasks abbrechen, bevor ein Fortschritt angezeigt wird.

Der IO delay ist dennoch extrem (> 80%) die Load explodiert in der kurzen Zeit (>80) und die VMs auf dem shared LVM reagieren nahezu nicht mehr, alle QEMU Prozesse sind im D state.

create full clone of drive scsi0 (lvm_thin:vm-1049-disk-0)
  Logical volume "vm-1049-disk-1" created.
drive mirror is starting for drive-scsi0 with bandwidth limit: 10240 KB/s
drive-scsi0: Cancelling block job

 

[Thomas15]

Hallo,

ich möchte mich noch einmal hierzu melden und eine Frage stellen, mit der ich das Problem hoffentlich besser prüfen kann.

Welche Tasks werden im Hintergrund bei einem movedisk abgearbeitet, wenn ich von einer VG in eine andere VG migriere? Wenn ich das genau weiß kann ich vielleicht ermitteln, wo das Problem liegt.

Sämtliche Benchmarks auf das große shared Storage sehen gut aus und lassen nicht darauf schließen, dass es generelle Performanceprobleme gibt. Im normalen Betrieb gibt es quasi keinen i/o wait. Der shared Storage ist in allen Belangen IOPS, read und writespeed deutlich schneller als der lokale Storage. Daher ist für mich unklar, wie der shared Storage so in die Knie gehen kann, wenn von lokal darauf geschoben wird.

 

[mira]

Je nachdem, wenn die VM läuft, wird ein drive-mirror über nbd ausgeführt. Wenn die VM nicht läuft, wird mit qemu-img convert der Inhalt der Disk kopiert. Den Code findet man in /usr/share/perl5/PVE/QemuServer.pm. Hier nach 'sub clone_disk' suchen.
Den Code rund ums qemu-img convert findet man wenn man nach 'sub qemu_img_convert' sucht in dem File.

 

[Thomas15]

Super, vielen Dank für die Antwort, da schaue ich gleich mal rein. Ich bin in der Zwischenzeit aber auch ein Stück weiter gekommen denke ich. Ich habe einen Movedisk ausgeführt und mit iotop -aP geschaut, was passiert, es wird ein solcher Befehl gebaut:

qemu-img convert -p -n -f raw -O raw /vz/images/999/vm-999-disk-1.raw /dev/nf-lvmstorage/test

Dieser Befehl sorgt nun tatsächlich dafür, dass sich der shared Storage sozusagen völlig verabschiedet. Alle VMs auf diesem Storage in der selben Volumegroup, egal auf welcher Node sie liegen, gehen dann in die Knie. Ich muss also leider nach wenigen Sekunden abbrechen, sonst gibt es Downtimes. Auf dem Storage selber ist aber keine Last festzustellen. Andere Nutzer bzw. andere Volumegroups sind nicht negativ beeinflusst.

Mit iotop -aP sieht das beim Ausführen jedenfalls nach kurzer Zeit so aus:

0.00 B 0.00 B 0.00 % 27.37 % qemu-img convert -p -n -f raw -O raw /vz/images/999/vm-999-disk-1.raw /dev/nf-lvmstorage/vm-999-disk-0

Interessanterweise geht die I/O Wait schnell durch die Decke, der Befehl scheint aber keinerlei read und write zu verursachen. Das ist sicherlich interessant. Der Progress (-p) blieb bis zum relativ zügig notwendigen Abbruch bei 0%, sicherlich weil noch keine Daten bewegt wurden.

Ich habe den Befehl auch manuell ausgeführt, ohne Proxmox Kontext, das Ergebnis ist das Gleiche. Damit wäre wohl schon einmal klar, dass es keine Proxmox Issue ist. Vielleicht ist irgendetwas mit der Einbindung des Storage nicht ideal, es könnte ein Problem mit multipath oder sonst etwas vorliegen.

Falls jemand Tipps hat bin ich dankbar, auch wenn es ganz offensichtlich kein Proxmox Problem ist.

 

[showiproute]

Hallo,

ich hatte das Problem auch: VM disk von einer auf die andere physische HDD verschoben, alle anderen VMs hingen, waren mehr oder minder nicht ansprechbar.

Was mir persönlich geholfen hat, waren die Kernel Parameter hier: https://gist.github.com/sergey-dryabzhinsky/bcc1a15cb7d06f3d4606823fcc834824


Es ist zwar immer noch so, dass die CPU + Load durch die Decke gehen (aktuell Load bei knapp 60), aber der IO Delay ist < 20 % und ich kann damit noch problemlos arbeiten.

Vielleicht hilft euch das irgendwie!?

 

[Thomas15]

Danke für den Input. Da muss man aber etwas aufpassen, da sind auch Dinge drin, die wir nicht wollen. Ich befürchte aber leider auch, dass uns das bei unserem Problem vermutlich nicht helfen wird. Wir haben in dem Sinne kein Performanceproblem, weil wir ein Stück Hardware an den Rand bringen, sondern wir haben hier einfach eine Fehlfunktion nehme ich an. Ich habe mir nun auch mal ein strace des qemu-img convert Befehls angeschaut, ich persönlich kann damit auf die Schnelle aber auch nicht mehr viel anfangen. Vielleicht gibt es hier jemanden, der aus dem Trace etwas Brauchbares auslesen kann. Ich werde mich da aber auch mal durcharbeiten wollen.

root@zeus:~# strace -ffp 20263
strace: Process 20263 attached with 3 threads
[pid 20264] futex(0x563c698f9b48, FUTEX_WAIT, 4294967295, NULL <unfinished ...>
[pid 20263] ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8 <unfinished ...>
[pid 20265] write(7, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 20265] futex(0x7fcd90651e38, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1606991023, tv_nsec=525056000}, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 20263] <... ppoll resumed> ) = 1 ([{fd=7, revents=POLLIN}])
[pid 20263] read(7, "\1\0\0\0\0\0\0\0", 512) = 8
[pid 20263] rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
[pid 20263] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd8edfa000
[pid 20263] mprotect(0x7fcd8edfa000, 4096, PROT_NONE) = 0
[pid 20263] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0
[pid 20263] rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
[pid 20263] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd8ecf9000
[pid 20263] mprotect(0x7fcd8ecf9000, 4096, PROT_NONE) = 0
[pid 20263] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0
[pid 20263] futex(0x7fcd90651e38, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 20265] <... futex resumed> ) = 0
[pid 20263] <... futex resumed> ) = 1
[pid 20265] fallocate(10, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 4294966272, 2147483136 <unfinished ...>
[pid 20263] ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8 <unfinished ...>
[pid 20265] <... fallocate resumed> ) = 0
[pid 20265] write(7, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 20265] futex(0x7fcd90651e38, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1606991030, tv_nsec=78806000}, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 20263] <... ppoll resumed> ) = 1 ([{fd=7, revents=POLLIN}])
[pid 20263] read(7, "\1\0\0\0\0\0\0\0", 512) = 8
[pid 20263] rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
[pid 20263] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd8ebf8000
[pid 20263] mprotect(0x7fcd8ebf8000, 4096, PROT_NONE) = 0
[pid 20263] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0
[pid 20263] rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
[pid 20263] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd8eaf7000
[pid 20263] mprotect(0x7fcd8eaf7000, 4096, PROT_NONE) = 0
[pid 20263] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0
[pid 20263] futex(0x7fcd90651e38, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 20265] <... futex resumed> ) = 0
[pid 20263] <... futex resumed> ) = 1
[pid 20265] fallocate(10, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 6442449408, 2147483136 <unfinished ...>
[pid 20263] ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8 <unfinished ...>
[pid 20265] <... fallocate resumed> ) = 0
[pid 20265] write(7, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 20265] futex(0x7fcd90651e38, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1606991036, tv_nsec=450158000}, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 20263] <... ppoll resumed> ) = 1 ([{fd=7, revents=POLLIN}])
[pid 20263] read(7, "\1\0\0\0\0\0\0\0", 512) = 8
[pid 20263] rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
[pid 20263] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd8e9f6000
[pid 20263] mprotect(0x7fcd8e9f6000, 4096, PROT_NONE) = 0
[pid 20263] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0
[pid 20263] rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0
[pid 20263] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd8e8f5000
[pid 20263] mprotect(0x7fcd8e8f5000, 4096, PROT_NONE) = 0
[pid 20263] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0
[pid 20263] futex(0x7fcd90651e38, FUTEX_WAKE_PRIVATE, 1) = 1
[pid 20263] ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8 <unfinished ...>
[pid 20265] <... futex resumed> ) = 0
[pid 20265] fallocate(10, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 8589932544, 2147483136 <unfinished ...>
[pid 20263] <... ppoll resumed> ) = ? ERESTARTNOHAND (To be restarted if no handler)
[pid 20263] --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
[pid 20264] <... futex resumed> ) = ? <unavailable>
[pid 20264] +++ killed by SIGINT +++
[pid 20265] <... fallocate resumed>) = ?
[pid 20265] +++ killed by SIGINT +++
+++ killed by SIGINT +++

 

[Thomas15]

Je nachdem, wenn die VM läuft, wird ein drive-mirror über nbd ausgeführt. Wenn die VM nicht läuft, wird mit qemu-img convert der Inhalt der Disk kopiert. Den Code findet man in /usr/share/perl5/PVE/QemuServer.pm. Hier nach 'sub clone_disk' suchen.
Den Code rund ums qemu-img convert findet man wenn man nach 'sub qemu_img_convert' sucht in dem File.

Ich habe mir den Code jetzt auch mal angesehen und glaube, dass wir da am Zeroinit hängen. Wenn das LVM angelegt wird, wird es vermutlich direkt mit Nullen vollgeschrieben nehme ich an. Das ist glaube ich der Punkt, wo unser Storage in die Knie geht. Das erklärt auch, warum es bei kleinen Disk deutlich weniger lange dauert, bis die Progressbar erscheint. Sobald dann nämlich tatsächlich Daten verschoben werden lebt der Storage offenbar wieder.

Warum geht hier offenbar beim Schreiben der Nullen alles komplett in die Knie?

    if (!$dst_is_iscsi && $is_zero_initialized) {
        push @$cmd, "zeroinit:$dst_path";
    } else {
        push @$cmd, $dst_path;
    }

    my $parser = sub {
        my $line = shift;
        if($line =~ m/\((\S+)\/100\%\)/){
            my $percent = $1;
            my $transferred = int($size * $percent / 100);
            my $remaining = $size - $transferred;

            print "transferred: $transferred bytes remaining: $remaining bytes total: $size bytes progression: $percent %\n";
        }

    };

 

[Thomas15]

Tut mir leid, dass ich zum dritten Mal hintereinander poste, allerdings konnten wir das Problem soweit offenbar lösen.

Wir haben manuell eine andere Version von qemu-img installiert (5.2.50), wodurch das Problem bei den Offlinemigrationen verschwunden ist. Bei den Onlinemigrationen mit qemu-nbd besteht das Problem noch weiterhin. Hier würde ich auch davon ausgehen, dass ein Update das Problem behebt. Wir haben für Onlinemigrationen vom den lokalen Storage auf das LUN mit LVM allerdings kaum Use-Cases, daher bauen wir das nicht manuell.

Wir nutzen regulär Proxmox Virtual Environment 6.2-15 , die mitgelieferte Version von qemu-img (5.1.0) hat da also offenbar ein Problem.

 

[pakuzaz]

PVE 6.2 ist doch schon ein wenig älter, versuch doch mal ein Update zu machen ggf. hilft das schon.

 

[Thomas15]

Ja, das wäre der nächste Schritt und würde ein Update auf 5.1 bedeuten. Das Problem bisher ist, dass wir eine Node nach der anderen updaten wollten (wir haben noch 2 im Cluster) und entsprechend alle VMs wegmigrieren wollten, um Downtime zu verhindern. Die, die noch nicht im shared Storage waren haben uns dann geblockt, weil wir sie nicht wegbekommen haben, ohne alles lahmzulegen. Wir haben es jetzt übrigens doch
auch mit qemu-nbd probiert, da besteht das Problem leider auch mit der neuen Version.

 

[mira]

Es könnte der folgende Commit sein:

edafc70c0c8510862f2f213a3acf7067113bcd08
qemu-img convert: Don't pre-zero images

Dieser sollte jedoch in 5.1 auch schon vorhanden sein.

 

[Thomas15]

Es könnte der folgende Commit sein:

edafc70c0c8510862f2f213a3acf7067113bcd08
qemu-img convert: Don't pre-zero images

Dieser sollte jedoch in 5.1 auch schon vorhanden sein.

Ja, das klingt absolut sinnvoll, danke fürs raussuchen. Warum das zeroing alles in die Knie zwingt müsste man mal noch ansehen. Bei qemu-nbd existiert diese Anpassung wohl leider noch nicht. Also muss ich die VMs vor der Migration wohl leider abschalten.

 

[Thomas15]

Leider besteht das Problem in PVE 6.3-3 mit der mitgelieferten QEMU Version weiterhin. Hier scheint wohl erst eine aktuellere Version Abhilfe schaffen zu können.