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>

README.md

@@ -84,6 +84,9 @@ check_interval = 60s               # wie oft der Dienst nach Fälligem schaut
 state_file = /var/lib/pvesnap/state.json
 log_level = INFO
 task_timeout = 15m
+retries = 2                        # Wiederholungen, wenn eine Sperre belegt ist
+retry_delay = 60s
+pause_between = 0s                 # Pause zwischen zwei Gästen
 run_on_start = no                  # beim Start sofort einen Durchlauf machen?
 dry_run = no                       # yes = nichts wirklich tun, nur protokollieren
 description = pvesnap | Gruppe: {group} | erstellt: {datetime} | Vorhaltezeit: {keep_time}
@@ -255,6 +258,46 @@ z. B. zum Ausprobieren.
 
 ---
 
+## Wenn Snapshots am Storage-Lock scheitern
+
+```
+trying to acquire cfs lock 'storage-data' ...
+TASK ERROR: cfs-lock 'storage-data' error: got lock request timeout
+```
+
+`storage-data` ist dabei kein falsch gelesener Name — in pmxcfs heißen
+Storage-Sperren immer `storage-<name>`, gemeint ist also das Storage `data`.
+Proxmox nimmt diese Sperre beim Anlegen eines Snapshots und gibt nach 60 s auf,
+wenn sie jemand anderes hält.
+
+pvesnap geht damit so um:
+
+* Der Aufruf wartet, bis der Snapshot-Task in Proxmox **wirklich fertig** ist,
+  bevor die nächste VM drankommt — sonst würden sich die Läufe gegenseitig
+  aussperren.
+* Sperr-Fehler gelten als vorübergehend und werden `retries`-mal mit
+  `retry_delay` Abstand wiederholt. Echte Fehler (etwa „storage does not support
+  snapshots") werden **nicht** wiederholt.
+* Mit `pause_between = 10s` lässt sich zusätzlich Druck vom Storage nehmen, wenn
+  viele VMs auf demselben Storage liegen.
+
+Hält die Sperre dauerhaft, liegt die Ursache außerhalb von pvesnap. Diese
+Kommandos helfen beim Eingrenzen:
+
+```bash
+pvesm status                      # ist das Storage online und erreichbar?
+grep -A6 "^[a-z]*: data" /etc/pve/storage.cfg
+pvesh get /cluster/tasks --output-format json | head    # hängt noch ein Task?
+systemctl status pvestatd pve-cluster
+journalctl -u pvestatd -n 50
+```
+
+Häufigste Ursachen: ein hängender Backup- oder Replikationsjob auf demselben
+Storage, ein nicht erreichbares NFS/CIFS-Storage (dann blockiert `pvestatd`),
+oder ein abgebrochener Task, der die Sperre nicht freigegeben hat.
+
+---
+
 ## Aufbau
 
 ```