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