Zwei Luecken, die seit dem Umbau offenstanden.
1. Transfer-Laufwerke waren aus dem Explorer nicht erreichbar
F2 zeigte nur die Dateisysteme des Snapshots. Jetzt stehen die
Transfer-Laufwerke in derselben Liste - aus Sicht des Bedieners ist es
dieselbe Frage ("wo soll ich hinschauen?"), und der Weg ueber
pvesnap-recovery entfaellt.
Das gewaehlte Laufwerk landet im rechten Fenster, links bleibt der
Snapshot. Damit laesst sich direkt aus einem Snapshot auf das
Austauschmedium kopieren, das anschliessend in die wiederhergestellte
Maschine wandert - ohne Zwischenlager auf dem Host.
Ausgehaengt wird beim Verlassen, und zwar nur, was wir selbst eingehaengt
haben: ein Laufwerk, das schon vorher am Host hing, gehoert jemand
anderem. Das finally faengt auch Absturz und Strg-C ab - bliebe es
eingehaengt, gaelte es spaeter als belegt.
2. cleanup fand geschuetzte Snapshots ohne Klon nicht
Loescht jemand eine Wiederherstellung in der Proxmox-Oberflaeche, raeumt
Proxmox den Klon durchaus mit ab - aber nicht den Schutz seines
Quell-Snapshots (rbd snap protect, den setzt es beim Klonen selbst).
Zurueck bleibt ein geschuetzter Snapshot ohne Klon: die Vorhaltezeit
scheitert an ihm jede Nacht mit "snapshot is protected", und
find_orphans() findet prinzipiell nichts, weil es den Datentraeger, nach
dem es sucht, wirklich nicht mehr gibt. Dasselbe entsteht nach einem von
Hand ausgefuehrten rbd flatten.
find_stale_protections() sucht deshalb direkt nach der Ursache: jeder
geschuetzte Snapshot, an dem kein Klon haengt. Ein solcher Schutz hat
keinen Zweck - er existiert einzig dafuer, dass ein Klon seine Grundlage
behaelt. Geloest wird nur der Schutz, geloescht wird nichts. Vor jedem
Loesen wird ein zweites Mal nachgesehen, ob inzwischen doch ein Klon
daran haengt.
cleanup laeuft damit in zwei Durchgaengen und liegt neu auch in der
Oberflaeche auf Taste c - man sucht sonst lange nach einem Befehl, den
man nur im Notfall braucht.
Getestet gegen die Kulisse der Handbuch-Werkstatt: die rbd-Attrappe
kennt jetzt snap ls und children und enthaelt beide Zustaende
nebeneinander - ein geschuetzter Snapshot mit Klon (muss in Ruhe
gelassen werden) und einer ohne (muss gefunden werden).
Handbuch und README nachgezogen, zwei Bildschirmfotos dazu.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
In set_display() stand die Sicherung "USB ohne SPICE ist wirkungslos, also
SPICE mit einschalten". Beim Ausschalten sind die Anschluesse aber noch da -
die Regel hat die Absage prompt ueberstimmt und SPICE wieder eingeschaltet.
Weil sich dadurch nichts aenderte, kam am Ende "War schon so eingestellt".
Die Regel gehoert nur ins Anlegen, wo --usb die Anzeige mit hochzieht. Beim
nachtraeglichen Umstellen ist "aus" die staerkere Aussage: die Anschluesse
fallen mit weg, mit Hinweis.
einschalten -> vga=qxl, usb0, usb1
ausschalten -> entfernt vga, usb0, usb1
nochmal aus -> nichts zu tun
aus trotz usb=2 -> Hinweis, dann trotzdem aus
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beim Umstellen der Anzeige habe ich die Maschine mit stop+start neu gestartet -
also mit "qm stop", einem virtuellen Stromausfall. Bei einer laufenden Maschine
mit eingehaengten Dateisystemen genau das Falsche.
Jetzt uebernimmt das Proxmox' eigener reboot-Endpunkt: er faehrt den Gast per
ACPI herunter, der haengt seine Dateisysteme selbst aus, danach geht er wieder
hoch - und dabei werden vorgemerkte Aenderungen wirksam ("Applies pending
changes"). Antwortet der Gast nicht, schlaegt es fehl statt ihm den Strom zu
ziehen; das ist die richtige Richtung.
Der naheliegende Gedanke, im Gast selbst neu zu starten, hilft hier nicht: dabei
setzt sich nur die Maschine zurueck, der QEMU-Prozess laeuft mit der alten
Grafikkarte weiter und die Aenderung bliebe vorgemerkt liegen. Steht so auch im
Warnhinweis.
Gemessen: eintragen, Neustart in 5s, danach vga=qxl und der SPICE-Kanal da.
Ausserdem reichte spice_file() das nackte "no spice port" von Proxmox durch.
Das heisst schlicht, dass die Maschine ohne qxl laeuft - steht jetzt auch so
da, mitsamt dem Weg dorthin.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher liess sich beides nur beim Anlegen waehlen. Wer erst spaeter merkt, dass
er den Dongle braucht, musste die Maschine wegwerfen und neu bauen. Jetzt geht
es in der Detailansicht auf Taste p, mit dem Ist-Zustand im Dialog.
Was dabei geht und was nicht, ist am laufenden System durchgemessen:
SPICE ein/aus Neustart noetig - die Grafikkarte laesst sich einer
laufenden Maschine nicht unterschieben
USB dazu/weg sofort, solange der SPICE-Kanal schon steht
USB ohne SPICE schaltet SPICE mit ein, sonst waeren die Anschluesse
wirkungslos
Vor einem noetigen Neustart wird gewarnt, und bei einer Maschine mit geladenem
Arbeitsspeicher besonders deutlich: der ist danach endgueltig weg, weil
Proxmox ihn schon beim ersten Start freigibt. Ein zweiter startet kalt, offene
Programme und ungespeicherte Daten sind verloren.
Beim Abschalten wird der vga-Eintrag entfernt statt auf "std" gesetzt - dann
steht die Maschine wieder genau so da wie vorher, ohne eine Zeile, die es nie
gab.
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>
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>
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>
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>
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>
duffyduckandClaude Opus 5