flatten
Linked Clones haengen fuer immer am Quell-Snapshot: der wird unloeschbar,
und die Original-Platte muss bestehen bleiben. Fuer "mal reinschauen" egal,
fuer eine dauerhaft uebernommene Maschine nicht. `pvesnap-recovery flatten`
loest sie ueber `rbd flatten`, hebt danach den Schutz auf und meldet die
Maschine als eigenstaendig. In der Oberflaeche Taste f; die Detailansicht
zeigt an, ob eine Instanz noch verlinkt ist.
Vorher wird gemessen, wieviel kopiert werden muss - `rbd du` zeigt je
Snapshot nur den Zuwachs, kopiert wird aber der gesamte sichtbare Inhalt.
Im Test: Snapshot-Zeile 56 MiB, tatsaechlicher Bedarf ueber 8 GB.
Und es wird geprueft, ob der Platz reicht. Der Grund ist Erfahrung: laeuft
ein Ceph-Pool beim Kopieren voll, blockiert er alle Schreibvorgaenge. Dann
steht jede VM auf dem Storage - und Aufraeumen geht auch nicht mehr, weil
Loeschen ebenfalls ein Schreibvorgang ist.
cleanup
Wird eine Wiederherstellung in der Proxmox-Oberflaeche geloescht statt mit
destroy, bleiben Klon und Snapshot-Schutz liegen. `cleanup` findet das.
Als Wahrheit ueber vergebene VMIDs dienen die Konfigurationsdateien unter
/etc/pve/nodes/* - nicht /cluster/resources: dort fehlt ein Gast auf einem
abgemeldeten Node moeglicherweise, und dann wuerden wir die Platten einer
lebenden Maschine loeschen. Ohne Elternteil wird nichts angefasst, und der
Schutz faellt nur, wenn kein Klon mehr daran haengt.
Nebenbei: Abfragen antworten bei fehlender Eingabe mit "nein", statt einen
Stacktrace zu werfen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-y soll Routinefragen sparen, nicht die eine Frage abschalten, bei der es
weh tut. Der Fall "Original laeuft und die Wiederherstellung geht mit
denselben MAC-Adressen ans Netz" ist jetzt als kritisch gefuehrt:
-y wird abgewiesen (Exit 2), Hinweis auf --force
interaktiv das Wort "ja" muss ausgeschrieben werden, "j" reicht nicht
--force laeuft durch
Oberflaeche zweite Rueckfrage, die den Grund beim Namen nennt statt
nur "Warnungen gelesen?" zu fragen
Ausserdem wird stdout vor der Fehlerausgabe geleert - sonst stand die
Begruendung beim Umleiten ueber dem, worauf sie sich bezieht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Betriebsarten:
live abgeschottet ohne Netzwerk - zum Hineinschauen ueber die
noVNC-Konsole, Dump ziehen, Daten ueber ein Austauschlaufwerk
herausholen
recovery mit Netzwerk und gleicher Identitaet (SMBIOS-UUID, vmgenid,
MAC-Adressen, Hostname) - warnt, wenn das Original noch laeuft
Die Datentraeger werden ueber PVE::Storage::vdisk_clone geklont, also mit
derselben Funktion und Cluster-Sperre, die Proxmox selbst verwendet. Auf
Ceph/ZFS/LVM-thin ist das Copy-on-Write: 32 GiB waren im Test in 0,8s
geklont, das Original bleibt unberuehrt.
Enthaelt der Snapshot den Arbeitsspeicher, wird er mitkopiert - die Maschine
laeuft dann genau dort weiter, wo sie stand, statt zu booten. Dafuer muss die
Geraeteausstattung exakt passen:
- vmgenid und smbios1 bleiben erhalten (ohne vmgenid bricht das Laden mit
"Unknown savevm section" ab)
- runningmachine/runningcpu werden uebernommen
- die Netzwerkkarte wird abgeklemmt statt entfernt
- das Austauschlaufwerk kommt erst nach dem Fortsetzen per Hotplug dazu,
sonst bemerkt der Gast es nie (nachgewiesen ueber "info virtio-status")
Proxmox meldet einen fehlgeschlagenen RAM-Ladevorgang als TASK OK und laesst
die Maschine angehalten stehen - deshalb wird das Task-Protokoll mitgelesen,
fortgesetzt und deutlich gemeldet, wenn stattdessen kalt gebootet wurde.
Austausch mit dem Host: bei VMs eine formatierte Zusatzplatte, bei
Containern ein durchgereichtes Verzeichnis - dort passt auch ein bereits
eingehaengtes Netzlaufwerk.
Verworfen wird restlos, samt Aufheben des rbd-Snapshot-Schutzes, den das
Klonen setzt - sonst koennte die Vorhaltezeit den Snapshot nie mehr loeschen.
Angefasst wird nur, was den Tag pvesnap-recovery traegt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5