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>
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>
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>
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