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>
Bei Containern schreibt pvesh den Fortschritt vor die UPID, alles in eine
Zeile:
Creating snap: 100% complete...done."UPID:node:...:vzsnapshot:100:..."
Die UPID wurde zeilenweise mit startswith() gesucht und deshalb nicht
gefunden. Ohne UPID liess sich der Task nicht verfolgen - ein Fehlschlag
blieb damit unbemerkt und pvesnap protokollierte "Snapshot angelegt",
obwohl Proxmox nur einen halbfertigen Eintrag (snapstate "prepare") in der
Konfiguration hinterlassen hatte. Genau so sind die beiden Leichen bei
LXC 100 entstanden.
* Die UPID wird jetzt per Suchmuster aus der gesamten Ausgabe geholt,
egal woran sie haengt.
* Zusaetzlich wird nach dem Anlegen nachgesehen, ob der Snapshot wirklich
da und vollstaendig ist. Damit faellt ein stiller Fehlschlag auch dann
auf, wenn weder Rueckgabewert noch Task ihn melden.
Auf pvetest01 mit Container 100 geprueft: anlegen (Task wird verfolgt,
Eintrag vollstaendig, rbd-Snapshot vorhanden), einbinden (rootfs als ext4,
/etc/hostname liefert "unifi"), Explorer und Web-Oberflaeche inklusive
ZIP, sowie loeschen ueber die Vorhaltezahl.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei gemeldete Fehler.
1. Im rechten Fenster des Explorers liessen sich weder Verzeichnisse
oeffnen noch ".." benutzen. Die Pruefung "bleibt der Pfad innerhalb der
Wurzel?" haengte an die Wurzel ein "/" an - bei der Wurzel "/" des
lokalen Fensters wurde daraus "//", worauf kein Pfad passt. Damit gab
open_current() immer False zurueck. Die Pruefung steckt jetzt in
within() und behandelt diesen Fall; die Web-Oberflaeche benutzt
dieselbe Funktion.
2. "Snapshots vom LXC aufrufen geht nicht": der Container hatte gar keine
brauchbaren Snapshots. In seiner Konfiguration standen nur zwei
Eintraege mit snapstate "prepare" und "delete" - Reste aus der Zeit, in
der jeder Snapshot am cfs-Lock scheiterte. Auf dem Storage liegt
dahinter nichts (rbd snap ls ist leer), oeffnen kann man sie also
nicht.
Solche Eintraege werden jetzt als das behandelt, was sie sind:
* Explorer und Web-Oberflaeche bieten sie nicht mehr zum Oeffnen an
und nennen den Aufraeumbefehl.
* "pvesnap list" markiert sie mit "!".
* Beim Aufraeumen entfernt der Dienst sie zuerst, und zwar mit
--force, weil sich ein Eintrag ohne Storage-Snapshot sonst nicht
loeschen laesst. Vorher waeren sie ewig liegen geblieben und haetten
zusaetzlich die Zahl der behaltenen Snapshots verfaelscht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher stand im Fehlerfall nur der Exit-Status da ("cfs-lock ... error: got
lock request timeout"), nicht aber, was Proxmox davor protokolliert hat.
Fuer die Fehlersuche fehlte damit genau der interessante Teil.
* Schlaegt ein Task fehl, werden die letzten Zeilen des Task-Logs an die
Meldung angehaengt; identische Wiederholungen werden zusammengefasst
("trying to acquire cfs lock 'storage-data' ... (9x)").
* Die Meldung wiederholt nicht mehr VM und Snapshot-Namen, die der
Aufrufer ohnehin voranstellt.
Ausserdem ein Fehler in der Wiederholung: schlug der Task fehl, blieb der
Snapshot-Eintrag teils in der VM-Konfiguration stehen. Der zweite Versuch
lief dann in "snapshot already exists" - und diese Meldung verdeckte die
eigentliche Ursache. Ist der Snapshot bereits vorhanden, wird jetzt nicht
wiederholt und der urspruengliche Fehler gemeldet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auf einem echten Host schlugen Snapshots reihenweise mit
"cfs-lock 'storage-NAME' error: got lock request timeout" fehl.
Ursache: 'pvesh create .../snapshot' lief mit dem allgemeinen
Kommando-Zeitlimit von 60s. Genau so lange wartet Proxmox aber auf den
Storage-Lock. Lief der Aufruf in unser Zeitlimit, ging es mit der naechsten
VM weiter, waehrend der Task noch lief - und die naechste VM scheiterte
dann an derselben Sperre. Eine VM konnte so einen ganzen Lauf umwerfen.
* Snapshot-Aktionen laufen jetzt mit dem langen task_timeout statt mit dem
kurzen Zeitlimit fuer Lesezugriffe.
* Ohne UPID in der Antwort wird ersatzweise gewartet, bis der Gast nicht
mehr gesperrt ist, statt sofort weiterzumachen.
* Sperr-Fehler gelten als voruebergehend und werden 'retries'-mal mit
'retry_delay' Abstand wiederholt; echte Fehler wie "storage does not
support snapshots" nicht.
* Neu: 'pause_between' fuer eine Pause zwischen zwei Gaesten.
Ausserdem: Kommentare hinter einem Wert ("retries = 2 # ...") wurden nicht
abgeschnitten und machten die Konfiguration ungueltig - das eigene
Beispiel war davon betroffen. 'description' bleibt bewusst unangetastet,
damit ein '#' in der Beschreibung erhalten bleibt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5