Sie standen schwarz auf gruen - und zwar mit A_BOLD. Genau das war die Falle:
Fettschrift schaltet im Terminal die Farben 0-7 auf 8-15, aus Schwarz (0) wird
also Hellschwarz (8), sprich Grau. Grau auf Gruen ist Matsch.
vorher \e[0;1m \e[30m \e[42m fett + schwarz auf gruen
nachher \e[0;1m \e[37m \e[44m fett + weiss auf blau
Dabei zeigte sich, dass in derselben Farbe zwei verschiedene Dinge steckten:
die Meldungsleiste ueber die ganze Zeile und Statustexte wie "Zustand:
running". Beide sind jetzt getrennt:
C_MSG weiss auf blau nur die Meldungsleiste, bleibt fett lesbar
C_OK gruen auf Vorgabe Statustexte als Schriftfarbe statt als Block
Alle uebrigen A_BOLD-Stellen haben helle Schrift (weiss, gelb) - die wird
durch Fett heller statt dunkler und war nie betroffen.
Die Aenderung sitzt in curses_util.py und gilt damit fuer alle Oberflaechen:
Konfigurationseditor, Explorer, Wiederherstellung und Transfer-Laufwerke.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"e Auswerfen" verschwieg die Haelfte - dieselbe Taste holt das Laufwerk auch
wieder herein. Steht jetzt als "e Auswerfen/Einklinken" da; im Text darueber
stand es schon.
Dazu v fuer die Laufwerksverwaltung. Ein ausgeworfenes Laufwerk gehoert dem
Host und will genau in diesem Moment befuellt oder ausgelesen werden - dafuer
erst zwei Ebenen zurueck in die Uebersicht zu muessen, ist unnoetig.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beim Entfernen des alten Austauschlaufwerks habe ich Textbereiche zwischen
zwei Marken herausgeschnitten - und dabei zwei Funktionen mitgenommen, die
zufaellig darin lagen:
_swap() Auswerfen und Einklinken in der Detailansicht. Taste e
endete in "NameError: name '_swap' is not defined".
cmd_flatten() der gesamte Unterbefehl "flatten" haette beim Aufruf
abgebrochen - unbemerkt, weil ihn danach niemand mehr
aufgerufen hat.
Beide sind wieder da. Dass es beim Uebersetzen nicht auffiel, liegt an Python:
ein Name, der erst zur Laufzeit nachgeschlagen wird, stoert den Compiler
nicht. Gefunden mit einem Abgleich aller geladenen gegen alle definierten
Namen je Modul - der haette beide Faelle sofort gezeigt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auf dem Proxmox-Host loest der Node-Name auf, am Arbeitsplatz meist nicht -
und dann ist der noVNC-Verweis wertlos. Die Adresse kommt jetzt aus
/etc/pve/.members (lokale Datei, kein API-Aufruf); ist dort nichts zu finden,
bleibt es beim Namen.
vorher https://pvetest01:8006/?console=kvm&novnc=1&vmid=102&node=pvetest01
nachher https://172.0.4.1:8006/?console=kvm&novnc=1&vmid=102&node=pvetest01
Der Node bleibt als Name im Verweis stehen - so erwartet Proxmox ihn.
Dasselbe betraf zwei weitere Stellen: den scp-Hinweis beim SPICE-Befehl und
den proxy-Eintrag in der .vv-Datei. Letzterer trug ebenfalls den Hostnamen,
womit auch remote-viewer nicht durchgekommen waere. Die TLS-Pruefung laeuft
ueber "host-subject" und bleibt davon unberuehrt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Wer merkt, dass ihm ein Laufwerk fehlt, merkt es genau dort - beim Blick auf
"Transfer-Laufwerke: keine". Bisher schickte der Hinweistext ihn dafuer zwei
Ebenen zurueck in die Uebersicht. Jetzt oeffnet v die Verwaltung direkt aus
der Maske, und beim Zurueckkommen steht der Balken auf der Auswahlzeile - also
da, wo man das eben Angelegte gleich anhaken will.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Anlass: ein Software-Schutzmodul am USB-Port. Normalerweise haengt so ein
Dongle an einem USB-Server im Netz - eine abgeschottete Wiederherstellung hat
aber keins. Ueber SPICE kommt das Geraet vom Rechner des Bedieners, nicht ueber
das Gastnetz. Die Maschine bleibt also ohne Netzwerk und hat trotzdem ihren
Dongle.
--spice SPICE-Anzeige (vga: qxl), zusaetzlich zu noVNC
--usb <n> so viele USB-Weiterleitungen
--iso <volid> Abbild als CD einlegen
spice <vmid> Verbindungsdatei fuer remote-viewer (.vv)
Zwei Dinge zeigte erst der Test, beide haetten die Sache still unbrauchbar
gemacht:
vga: qxl zerstoert den geladenen Arbeitsspeicher. qxl hat 64 MB
Grafikspeicher, die Vorgabe 16 - beim Laden kommt "Size mismatch:
vga.vram", und die Maschine bleibt angehalten stehen. Wieder mit TASK OK.
Wird jetzt abgelehnt, mit den drei Auswegen in der Meldung. Der dauerhafte
ist, am Original 'vga: qxl' zu setzen - dann tragen alle kuenftigen
Snapshots es mit und beides geht gleichzeitig.
USB ohne SPICE ist wirkungslos. QEMU legt die usbredir-Geraete zwar an, aber
ohne SPICE-Server gibt es keinen Kanal dafuer - spiceproxy sagt schlicht "no
spice port". --usb schaltet die Anzeige deshalb mit ein.
Ausserdem korrigiert: in der .vv-Datei darf das Zertifikat nicht in echte
Zeilenumbrueche uebersetzt werden. virt-viewer erwartet die Zeichenfolge \n als
zwei Zeichen in einer einzigen Zeile; sonst steht nur die erste hinter "ca=".
tools/get-guest-tools.sh holt virtio-win auf einen ISO-Storage. Fuer den
Dongle wird davon nichts gebraucht - die Tools sind nur fuer Zwischenablage,
Aufloesung und Mauszeiger.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher warnte der Installer "Auf Port 8823 lauscht bereits etwas" - dabei war
das der eigene, laufende Dienst. Der Hinweis war also falsch und verdeckte
zugleich einen echten Fall: wenn wirklich etwas Fremdes den Port haelt.
Jetzt wird unterschieden. Laeuft pvesnap-web, wird das als Normalfall einer
Aktualisierung behandelt und der Dienst angehalten, bevor der Code unter ihm
ausgetauscht wird - beim Stoppen bekommt er sein SIGTERM und haengt offene
Snapshots sauber aus. Am Ende faehrt er wieder hoch. Haelt dagegen ein anderer
Prozess den Port, steht die Warnung weiterhin da, jetzt mit der Angabe, wer es
ist (ss -ltnp).
Bewusst kein "pvesnap-explorer --cleanup" an der Stelle: das wuerde auch die
Einbindungen einer Sitzung loesen, die jemand gerade in einem anderen Terminal
offen hat.
Geprueft: Installation ueber den laufenden Dienst hinweg (anhalten, ersetzen,
wieder starten, HTTP 401 = Anmeldemaske), und mit einem fremden Prozess auf
dem Port (Warnung samt PID, Dienste nicht gestartet).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Es tat dasselbe wie die Transfer-Laufwerke, nur schlechter: namenlos, nicht
vorher befuellbar, nicht wiederverwendbar, und es starb mit der Maschine. Zwei
Mechanismen fuer dieselbe Sache sind schlechter als einer.
Entfernt: --exchange, --exchange-storage, --exchange-fs, --exchange-dir, die
Unterbefehle pull und release, das Formatieren und Einhaengen auf dem Host
samt Mount-Merkliste. Was davon gebraucht wurde, steckt jetzt in transfer.py -
dort aber benannt, dauerhaft und im laufenden Betrieb wechselbar.
Aeltere Eintraege in der Merkliste stoeren nicht: ihr Austauschlaufwerk ist
ein gewoehnliches Volume der Maschine und wird beim Verwerfen ohnehin von
Proxmox mitgeloescht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auswerfen und wieder einklinken, ohne die Maschine anzufassen - damit laesst
sich mehrfach nachladen und abholen, statt nur einmal am Ende.
eject_transfer() zieht die Platte ab, danach gehoert sie dem Host
insert_transfer() gibt sie zurueck in denselben Steckplatz
transfer_state() was gerade wirklich steckt
In der Detailansicht auf Taste e; bei mehreren Laufwerken mit Auswahl. Vor dem
Auswerfen wird nachgefragt, mit dem Hinweis, im Gast vorher auszuhaengen -
Proxmox meldet das Geraet zwar ab, aber ein Dateisystem, das noch beschrieben
wird, nimmt das uebel. Schlaegt es fehl, weil der Gast es festhaelt, steht das
auch so in der Meldung.
Beim Container gibt es nichts zu wechseln und das wird auch so gesagt: dort
ist das Verzeichnis durchgereicht, Host und Gast sehen dieselben Dateien
ohnehin gleichzeitig.
Dabei ein Fehler aufgefallen, den erst der Test zeigte: bei einer Maschine mit
geladenem Arbeitsspeicher steckte das Transfer-Laufwerk in der kalten
Konfiguration - der Gast haette es nie bemerkt. Dieselbe Falle wie beim
Austauschlaufwerk, dort schon behoben, hier vergessen. Beide gehen jetzt durch
dieselbe Nachsteck-Logik.
Am laufenden System durchgespielt, mit RAM-Zustand:
Start "Stecke Transfer-Laufwerk 'hotswap' als scsi2 an"
auswerfen eingesteckt=False, Laufwerk wieder frei
befuellen runde2.txt vom Host, VM lief weiter
einklinken scsi2: /dev/loop0,backup=0,size=1G
Ende beide Dateien da, VM durchgehend running
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ein einziges Dateisystem, mit Absicht: exFAT koennen Windows und Linux beide
von Haus aus, es kennt keine Besitzrechte auf dem Datentraeger und hat anders
als FAT32 keine 4-GB-Grenze je Datei. Die Auswahl faellt damit weg - eine
Entscheidung weniger, wenn es schnell gehen muss.
Neu in der Oberflaeche:
Taste v Uebersicht der Laufwerke mit Zustand
Enter darauf haengt am Host ein und startet den Commander - links das
Laufwerk, rechts der eigene Rechner
n / u / l anlegen, aushaengen, loeschen
Optionsmaske Mehrfachauswahl statt Groessenangabe
--transfer NAME dasselbe auf der Kommandozeile, mehrfach moeglich
Am laufenden System durchgespielt: Laufwerk angelegt, vom Host ein Skript
hineingelegt, Wiederherstellung damit gestartet, im Gast gelesen, ausgefuehrt
und geschrieben, Wiederherstellung verworfen - das Laufwerk lebte samt
Ergebnis weiter.
Zwei Rechtefallen dabei gefunden und geschlossen:
Der Gast konnte lesen, aber nicht schreiben. exFAT hat keine Besitzrechte
auf der Platte, die entstehen beim Einhaengen - mit der Vorgabe gehoert
alles root, und der root eines unprivilegierten Containers ist auf dem Host
uid 100000. Wird jetzt mit umask=0000 eingehaengt.
Ein durchgereichtes Laufwerk galt als "am Host eingehaengt", weil beim
Container genau das der Fall ist. Wer das sah, haette es aushaengen und dem
laufenden Gast den Boden wegziehen koennen. Die Belegung wird jetzt auch aus
Container-Konfigurationen gelesen, der Gast hat Vorrang in der Anzeige, und
Aushaengen wird abgelehnt, solange jemand darauf arbeitet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ext4 speichert Besitzer und Rechte auf dem Datentraeger. Das Wurzelverzeichnis
gehoerte root, weil der Host es angelegt hat - im Gast sitzt davor aber ein
gewoehnlicher Benutzer, der dann nichts hineinschreiben kann. Das sieht aus
wie ein schreibgeschuetzter Datentraeger, ist aber eine Rechtefrage.
Das Wurzelverzeichnis wird beim Anlegen jetzt auf 0777 gesetzt - in beiden
Wegen, dem alten --exchange und den neuen Transfer-Laufwerken. Bei exFAT und
FAT laeuft das ins Leere, weil sie ueberhaupt keine Besitzrechte kennen; dort
entscheidet der Einhaengevorgang, und der Automounter im Gast setzt den
angemeldeten Benutzer als Eigentuemer. Genau deshalb ist exFAT auch fuer
Linux-Gaeste die unkompliziertere Wahl.
vorher drwxr-xr-x root -> Benutzer im Gast kann nur lesen
nachher drwxrwxrwx root -> schreiben moeglich
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NTFS wird nicht mehr angeboten und nirgends mehr erwaehnt - exFAT deckt den
Windows-Fall ab, ohne dass etwas nachinstalliert werden muss, das 'fuse' und
damit pve-cluster gefaehrdet. In snapfs.py bleibt ntfs stehen: dort geht es
ums Lesen von Windows-Gast-Snapshots, eine ganz andere Sache.
parted legt nur noch die Partition an, ohne Dateisystem-Hinweis. Dabei ist
aufgefallen, dass genau dieser Hinweis vorher die Typ-Kennung gesetzt hatte:
ohne ihn vergibt parted 0FC63DAF-... ("Linux filesystem"), und Windows haengt
so eine Partition nicht ein. Die Kennung wird jetzt ausdruecklich gesetzt:
parted ... mkpart primary 1MiB 100% set 1 msftdata on
-> EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Nur darauf vergibt Windows von selbst einen Laufwerksbuchstaben.
Das alte --exchange kennt jetzt ebenfalls exfat statt ntfs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
exFAT kann Windows wie Linux nativ, und anders als FAT32 gibt es keine
4-GB-Grenze je Datei. Damit ist es die richtige Vorgabe fuer ein Medium, das
zwischen Host und beliebigen Gaesten pendelt. Fehlt der Formatierer, faellt
die Wahl auf ext4 zurueck.
Dabei ein eigener Fehler aufgefallen: exFAT und FAT lassen nur 11 Zeichen
Datentraegerbezeichnung zu, "PVESNAP-DUMPS" waeren 13 gewesen - mkfs haette
abgebrochen. Die Bezeichnung ist jetzt schlicht der Name in Grossbuchstaben,
je Dateisystem gekuerzt. Im Gast genuegt damit:
mount /dev/disk/by-label/DUMPS /mnt
Geprueft: GPT-Partition mit msftdata-Kennung (dafuer vergibt Windows sofort
einen Laufwerksbuchstaben), blkid meldet TYPE="exfat" LABEL="DUMPS".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Benannte, dauerhafte Austauschmedien zwischen Host und Gast - Abbilddateien
unter /var/lib/pvesnap/transfer, die zu keinem Gast gehoeren und jede
Wiederherstellung ueberleben.
Zwei Entwurfsentscheidungen, beide am Host geprueft:
Datei statt Proxmox-Volume. Ein Volume wuerde beim Entfernen der Maschine
mitgeloescht, auch aus der Weboberflaeche heraus - die vorbereitete
Werkzeugsammlung waere weg. Pfade ueberspringt destroy_vm ausdruecklich
("return if $volid =~ m|^/|"). Nachgestellt: VM mit --purge entfernt, das
Abbild lebte samt Inhalt weiter.
Loop-Geraet statt direktem Pfad. Eine Abbilddatei als scsi3 einzutragen
lehnt Proxmox ab ("unable to associate path to any storage"), /dev/... wird
dagegen durchgereicht. Ueber losetup -P bekommt der Gast eine Platte mit
Partitionstabelle - ohne die zeigt Windows nur "nicht initialisiert".
Verriegelung, am laufenden System geprueft: ein Laufwerk ist entweder am Host
eingehaengt oder an einem Gast, nie beides. Alle drei Wege wurden abgelehnt -
anhaengen waehrend Host-Mount, Host-Mount waehrend angehaengt, loeschen
waehrend in Benutzung. Der Gast-Zustand wird aus den Konfigurationsdateien
gelesen, gilt also auch fuer gestoppte Maschinen.
Installer: parted und exfatprogs werden bei Bedarf nachinstalliert
(--no-install-deps schaltet das ab). ntfs-3g bewusst nicht - apt entfernt
dafuer 'fuse', an dem pve-cluster (/etc/pve) und ceph-fuse haengen. Dazu gibt
es nur einen Hinweis samt Begruendung; fuer Windows ist exFAT ohnehin die
einfachere Wahl.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Abhaengigkeit vom Quell-Snapshot ist eine Ceph-Eigenheit. Bisher meldete
flatten alles andere pauschal als "kein Ceph-Datentraeger" - das klingt nach
Einschraenkung, ist bei LVM-thin aber das Gegenteil.
Nachgemessen auf local-lvm: ein Thin-Snapshot teilt sich die Bloecke im Pool
(256 MB Nutzdaten liegen dort nur einmal), ist aber trotzdem eigenstaendig -
Quell-Snapshot und Original liessen sich loeschen, waehrend der Klon existiert,
und seine Pruefsumme blieb unveraendert. Dort gibt es also weder geschuetzte
Snapshots noch etwas zu flatten.
lvmthin nicht noetig, Klon ist von sich aus unabhaengig
zfspool nicht moeglich, ginge nur ueber zfs send | zfs recv
rbd noetig fuer den Dauerbetrieb
lvm dick PVE kann dort gar keine Snapshots
Der Hinweis in der Zusammenfassung richtet sich jetzt ebenfalls nach dem
Storage-Typ, statt immer zum Flatten zu raten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Gemessen an einem Container, der durchgehend schrieb, waehrend abgekoppelt
wurde:
64 MB vor dem Flatten geschrieben -> SHA-256 danach OK
192 MB waehrend des Flatten -> SHA-256 danach OK
12 Schreibvorgaenge im Zeitfenster 19:35:48 - 19:36:10
Flatten selbst 19:35:48 - 19:36:11
Gast durchgehend running
rbd flatten fuellt nur Bloecke auf, die der Klon nicht selbst besitzt - was
der Gast geschrieben hat, gehoert ihm und wird nicht ueberschrieben.
Dazu die Einordnung gegenueber dem Live-Restore des Proxmox Backup Servers:
dort wird im Hintergrund nachgeladen, hier nicht. Der Klon ist von Anfang an
vollstaendig und - weil Copy-on-Write nichts kopiert - unabhaengig von der
Groesse in etwa einer Sekunde fertig. Eine 2-TB-VM wird also nicht erst
stundenlang kopiert, sondern ist sofort in Betrieb.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Am ganzen Durchlauf gemessen: VM 9802 aus einem 802-Snapshot mit geladenem
Arbeitsspeicher gestartet, dann geflattet, waehrend sie lief.
32-GiB-Platte, 13 GiB kopiert, rund 70s
bei jeder Messung qmpstatus=running, QEMU-Monitor antwortete
Uhr auf der Konsole lief weiter (10:38 -> 10:39, mit Bildschirmanimation)
danach kein PARENT mehr, Quell-Snapshots entschuetzt
Kostenschaetzung sagte 14.1G vorher - kopiert wurden 13 GiB
Anders als beim Live-Restore des Proxmox Backup Servers wird nichts
nachgeladen: der Klon liegt im selben Pool und ist von Anfang an vollstaendig.
flatten loest nur die Abhaengigkeit, nicht die Verfuegbarkeit.
Nebenbei: ein Datentraeger, den es gar nicht mehr gibt - etwa der kopierte
Arbeitsspeicher, den Proxmox nach dem Fortsetzen selbst freigibt - wurde als
"war schon eigenstaendig" gemeldet. Er wird jetzt uebergangen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Wird mit geladenem Arbeitsspeicher angelegt, steht die Platte erst nach dem
Fortsetzen in der Gast-Konfiguration. Wer die Maschine nie startet und dann
verwirft, haette sie liegen lassen: Proxmox raeumt nur ab, was in der
Konfiguration steht.
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>
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>
Der Abschnitt zur Web-Oberflaeche beschreibt jetzt beides ausfuehrlich:
die Einrichtung als Dienst ueber install.sh --with-webexplorer --port
(mit Beispielen fuer eigene Adresse und --no-start), das Nachtraegliche
Aendern ueber /etc/pvesnap/web.conf und die ueblichen systemctl-Befehle -
sowie den Start von Hand mit einer Tabelle aller Parameter und
Beispielen fuer die typischen Faelle: SSH-Tunnel, Backup-Team mit
VM.Backup statt VM.Snapshot, einzelner Dienstleister ueber --allow-user,
Zugangsschluessel statt Anmeldung, freies Verzeichnis, Aufraeumen.
Der Explorer hat ebenfalls eine Parametertabelle bekommen.
Dabei fiel auf, dass "pvesnap-web <vmid>" ohne Snapshot-Namen bisher gar
nichts bewirkte - man bekam trotzdem die vollstaendige Gastliste. Jetzt
schraenkt die Angabe die Oberflaeche wirklich auf diesen Gast ein, und
zwar auch gegen Aufrufe ueber die Adresszeile.
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>
install.sh --with-webexplorer --port <nummer> richtet pvesnap-web.service
ein. Fehlt der Port, bricht das Skript mit einer Erklaerung ab; --port
ohne --with-webexplorer, ein Port ausserhalb 1-65535, etwas anderes als
eine Zahl und Port 8006 (Proxmox selbst) werden ebenfalls abgefangen -
und zwar vor der root-Pruefung, damit ein Tippfehler sofort auffaellt.
--help beschreibt jetzt alle Optionen mit Beispielen.
Port, Adresse und Anmeldeart stehen in /etc/pvesnap/web.conf und lassen
sich dort aendern, ohne die Unit anzufassen.
Angemeldet wird mit den Benutzern von Proxmox VE: dieselbe Maske aus
Benutzer, Passwort und Realm-Auswahl, geprueft ueber POST /access/ticket
auf der lokalen API - also derselbe Weg wie im Proxmox-Webinterface. Alle
Realms funktionieren damit automatisch; Zwei-Faktor-Anmeldungen werden
abgewiesen statt halb durchgewinkt.
Ein gueltiges Passwort allein reicht nicht: zusaetzlich braucht der
Benutzer auf dem Gast das Recht VM.Snapshot (geprueft auf /, /vms,
/vms/<id> und dem Pool). Sonst koennte jeder Proxmox-Benutzer saemtliche
Dateien aller Gaeste lesen. In der Gastliste erscheinen nur erlaubte
Gaeste, root@pam sieht wie in Proxmox alles. Anpassbar ueber
--require-privilege und --allow-user.
Ausserdem: SIGTERM haengt einen offenen Snapshot wieder aus (ohne das
bliebe er bei "systemctl stop" eingebunden), und beim Start werden Reste
von Prozessen abgeraeumt, die es nicht mehr gibt - parallel laufende
Sitzungen bleiben dabei unangetastet.
Auf pvetest01 geprueft: Dienststart ueber systemd, Anmeldemaske mit den
Realms des Hosts, Abweisung ohne und mit falschen Zugangsdaten (401,
protokolliert mit Absender-IP), Zugriff ohne Recht (403 auf Snapshot-
Liste und Oeffnen), vollstaendiger Ablauf als Berechtigter bis zum
Datei-Download, Abmelden macht die Sitzung ungueltig, und SIGTERM
hinterlaesst weder rbd-Maps noch Mountpunkte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Haelt __pycache__, Sicherungskopien der Konfiguration und Laufzeitdateien
(state.json, Sperrdateien) aus dem Repository heraus.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5