Bisher endete das Programm, sobald man den Dateibrowser verliess - wollte
man einen zweiten Snapshot ansehen, musste man es neu starten und sich
wieder durch Gast und Snapshot klicken.
Jetzt gibt es drei Ebenen, aus denen q oder F10 jeweils eine zurueckfuehrt:
Gastauswahl -> Snapshot-Auswahl -> Dateibrowser
Beim Verlassen des Browsers wird der Snapshot ausgehaengt, bevor die
Snapshot-Liste wieder erscheint - dort steht dann auch, was in der
Zwischenzeit dazugekommen ist. Aus der Snapshot-Liste geht es zurueck zur
Gastauswahl, deren Inventar dabei ebenfalls neu gelesen wird.
Das rechte Fenster behaelt sein Verzeichnis ueber mehrere Snapshots
hinweg, damit man aus verschiedenen Snapshots ins selbe Ziel sammeln kann.
Auf pvetest01 gegen echte Snapshots geprueft: beim Wechsel wird der erste
Snapshot restlos abgebaut, bevor der zweite eingebunden wird (nie mehr als
eine Einbindung gleichzeitig), und der regulaere Ausstieg hinterlaesst
weder rbd-Maps noch Mountpunkte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auf dem Testhost (Ceph RBD) meldete lsblk fuer jede Partition eines
eingebundenen Snapshots "kein Dateisystem" - auch fuer eine 31,5-GB-
Partition, auf der offensichtlich ext4 liegt. Nichts liess sich einhaengen.
Grund: lsblk nimmt FSTYPE aus der udev-Datenbank, und die ist bei frisch
gemappten rbd-Geraeten leer, weil udev dort keine blkid-Probe faehrt. Ein
direktes "blkid -p" auf denselben Geraeten liefert dagegen sauber vfat und
ext4. Der Typ wird jetzt so ermittelt, wenn lsblk nichts weiss.
Ausserdem: die Auswahl der Dateisysteme zeigte nur abgeschnittene
Mountpfade, die sich alle glichen, und vorausgewaehlt war das erste
gefundene - in der Praxis gern die 200-MB-EFI-Partition. Jetzt stehen dort
Geraet, Typ, Groesse und ein Hinweis ("Linux-Wurzelverzeichnis",
"Startpartition"), und die wahrscheinlichste Wurzel steht oben.
Auf pvetest01 gegen echte Snapshots geprueft: einbinden, alle drei
Dateisysteme mounten, Explorer, Web-Oberflaeche mit Download und ZIP,
Ausbruchversuch abgewiesen, restloses Aufraeumen auch nach hartem Abbruch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beim Einbinden stuerzte der Explorer mit IndexError ab. Ursache: prepare()
meldete nur dann einen Fehler, wenn gar kein Geraet gefunden wurde - nicht
aber, wenn zwar Geraete da waren, sich davon aber keins einhaengen liess.
Der Aufrufer griff dann blind auf mountpoints[0] zu.
* prepare() meldet jetzt einen Fehler, sobald kein Dateisystem eingehaengt
werden konnte, und nennt dabei die gefundenen Geraete samt Dateisystem-
Typ - sonst raet man beim Suchen nur.
* Der Explorer prueft die Liste zusaetzlich selbst ab.
Der wahrscheinlichste Grund fuer "gefunden, aber nicht mountbar" ist LVM
im Gast: dahinter liegt zunaechst nur ein LVM2_member. Das wird jetzt
unterstuetzt - inklusive der heiklen Stelle: heisst die Volume-Group im
Gast genauso wie eine auf dem Host (typisch 'pve'), waere nicht mehr
eindeutig, welche gemeint ist. Erkannt wird das an gleichem Namen bei
unterschiedlicher UUID; dann wird bewusst nichts aktiviert und der Grund
angezeigt. Beim Aufraeumen wird die Gruppe vor dem Aushaengen des Geraets
wieder deaktiviert.
Ausserdem "udevadm settle" nach dem Einbinden - die Partitionsgeraete
tauchen sonst manchmal erst nach dem Scan auf.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Snapshots anzulegen half bisher nur halb - an die Daten darin kam man nur
ueber einen Rollback. Dafuer jetzt zwei Werkzeuge auf gemeinsamer Basis.
snapfs.py bindet einen Snapshot schreibgeschuetzt ein und liefert einen
gewoehnlichen Pfad; die Oberflaechen wissen dadurch nichts ueber Storages:
rbd (Ceph) rbd map pool/image@snap, bei nicht unterstuetzten
Image-Features faellt es auf rbd-nbd zurueck
zfspool Container ueber .zfs/snapshot, VMs ueber einen Klon
lvmthin/lvm die Snapshot-LV snap_<volume>_<snapname> aktivieren
dir/nfs/cifs qemu-nbd --load-snapshot (nur qcow2)
Gemountet wird mit ro,noload bzw. ro,norecovery,nouuid - Snapshots
laufender Gaeste haben fast immer ein unsauberes Journal. Alles Angelegte
steht in /run/pvesnap/explorer.json und laesst sich nach einem Absturz mit
"--cleanup" wieder abraeumen.
pvesnap-explorer: zwei Fenster wie im Midnight Commander, links der
Snapshot, rechts der lokale Rechner. Markieren, F5, Fortschrittsbalken,
ESC bricht ab, vorhandene Dateien werden abgefragt. In den Snapshot hinein
kann nicht kopiert werden. Geraetedateien und Sockets werden
uebersprungen, symbolische Verweise bleiben Verweise.
pvesnap-web: derselbe Inhalt im Browser, auch vom anderen Rechner.
Einzelne Dateien direkt, Verzeichnisse und Mehrfachauswahl als ZIP, das im
Strom erzeugt wird - ohne Zwischendatei auf der Platte. Zugang nur mit dem
beim Start ausgegebenen Schluessel; Pfade ausserhalb des Snapshots werden
abgewiesen; es wird ausschliesslich gelesen.
Nebenbei: die curses-Bausteine sind aus tui.py nach curses_util.py
gewandert, damit Editor und Explorer sie teilen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Als Dienst schlug jeder Snapshot mit "cfs-lock 'storage-data' error: got
lock request timeout" fehl, waehrend derselbe Aufruf in der Shell
funktionierte.
Ursache war ProtectSystem=full in unserer eigenen Unit: das haengt /etc im
Namespace des Dienstes schreibgeschuetzt ein. pvesh fuehrt die Proxmox-API
im eigenen Prozess aus, der Snapshot-Task ist also ein Kindprozess von
pvesnap und erbt diese Einschraenkung. pmxcfs legt seine Sperren aber als
Verzeichnisse unter /etc/pve/priv/lock/ an - das mkdir scheitert, Proxmox
wiederholt es erfolglos und meldet am Ende einen Lock-Timeout statt eines
Rechtefehlers.
ProtectHome=yes war aus demselben Grund schaedlich: es blendet /root aus,
womit die SSH-Schluessel fuer die uebrigen Cluster-Nodes fehlen.
* Unit enthaelt keine Sandbox-Optionen mehr, mit Kommentar, warum nicht.
* Neu: pvesnap/preflight.py prueft root-Rechte, Schreibzugriff auf /etc/pve
und Sichtbarkeit von /root. Der Dienst schreibt das beim Start ins
Journal, "pvesnap check" zeigt es ebenfalls an - damit faellt so etwas
sofort auf, statt sich als Lock-Timeout zu tarnen.
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>
Nach dem Speichern musste man bisher in die Konsole wechseln, um die
Konfiguration mit "systemctl reload pvesnap" scharf zu schalten. Die
Gruppenliste kann das jetzt selbst:
* 'r' laedt den Dienst neu; ungespeicherte Aenderungen werden vorher zum
Speichern angeboten, ein gestoppter Dienst zum Starten, und wenn das
Neuladen scheitert, wird ein Neustart angeboten.
* Nach 's' fragt der Editor direkt, ob neu geladen werden soll.
* Die Kopfzeile zeigt laufend den Zustand des Dienstes.
* Die Tastenleiste bricht auf schmalen Terminals auf zwei Zeilen um,
statt hinten abgeschnitten zu werden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5