From 2d7418ca6925442bbdeaf143fac097659c5a214c Mon Sep 17 00:00:00 2001 From: duffyduck Date: Fri, 31 Jul 2026 19:11:00 +0200 Subject: [PATCH] flatten laeuft im laufenden Betrieb - belegt, nicht behauptet Am ganzen Durchlauf gemessen: VM 9802 aus einem 802-Snapshot mit geladenem Arbeitsspeicher gestartet, dann geflattet, waehrend sie lief. 32-GiB-Platte, 13 GiB kopiert, rund 70s bei jeder Messung qmpstatus=running, QEMU-Monitor antwortete Uhr auf der Konsole lief weiter (10:38 -> 10:39, mit Bildschirmanimation) danach kein PARENT mehr, Quell-Snapshots entschuetzt Kostenschaetzung sagte 14.1G vorher - kopiert wurden 13 GiB Anders als beim Live-Restore des Proxmox Backup Servers wird nichts nachgeladen: der Klon liegt im selben Pool und ist von Anfang an vollstaendig. flatten loest nur die Abhaengigkeit, nicht die Verfuegbarkeit. Nebenbei: ein Datentraeger, den es gar nicht mehr gibt - etwa der kopierte Arbeitsspeicher, den Proxmox nach dem Fortsetzen selbst freigibt - wurde als "war schon eigenstaendig" gemeldet. Er wird jetzt uebergangen. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 11 ++++++++++- pvesnap/recovery.py | 7 ++++++- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e5a2e21..bec78df 100644 --- a/README.md +++ b/README.md @@ -636,9 +636,18 @@ schwierig, weil Löschen ebenfalls ein Schreibvorgang ist. `flatten` bricht deshalb ab, wenn weniger als das 1,15-fache des Bedarfs frei ist; `--force` setzt sich darüber hinweg. -Schnell ist es, solange Platz da ist: 3,1 GB waren im Test in 26 Sekunden +Schnell ist es, solange Platz da ist: 13 GB waren im Test in rund 70 Sekunden kopiert. +**Die Maschine läuft dabei weiter.** `rbd flatten` ist eine Online-Operation — +anders als beim Live-Restore des Proxmox Backup Servers wird hier nichts +nachgeladen: Der Linked Clone liegt im selben Pool und ist aus Sicht des Gastes +von Sekunde eins an vollständig. `flatten` löst nur die *Abhängigkeit*, nicht +die Verfügbarkeit. Im Test blieb die VM über den gesamten Vorgang auf +`qmpstatus: running`, der QEMU-Monitor antwortete durchgehend, und die Uhr auf +der Konsole lief weiter (10:38 → 10:39, mit sichtbarer Bildschirmanimation) — +inklusive geladenem RAM-Zustand. + ### Wenn außerhalb von pvesnap gelöscht wurde — `cleanup` Wird eine Wiederherstellung in der Proxmox-Oberfläche entfernt statt mit diff --git a/pvesnap/recovery.py b/pvesnap/recovery.py index 9b08663..a867e61 100644 --- a/pvesnap/recovery.py +++ b/pvesnap/recovery.py @@ -383,7 +383,12 @@ def flatten(proxmox, instance, progress=None, stream=False, force=False): unsupported.append(volid) continue args, image = context - if "parent:" not in run(args + ["info", image], check=False, timeout=60): + described = run(args + ["info", image], check=False, timeout=60) + if not described or "No such file" in described or "does not exist" in described: + # Gibt es nicht mehr - etwa der kopierte Arbeitsspeicher, den + # Proxmox nach dem Fortsetzen selbst wieder freigegeben hat. + continue + if "parent:" not in described: already.append(volid) continue step("Loese %s vom Quell-Snapshot - dabei werden die Daten wirklich "