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 "