3 Commits
Author SHA1 Message Date
duffyduckandClaude Opus 5 3acbebce6f Lokales Fenster war nicht navigierbar; halbfertige Snapshots erkennen
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>
2026-07-31 10:21:59 +02:00
duffyduckandClaude Opus 5 e9aeaf9e62 Snapshot-Laeufe gegen cfs-Sperren des Storages absichern
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>
2026-07-31 01:54:59 +02:00
duffyduck 87f1b4d555 first commit 2026-07-30 16:52:58 +02:00