Commit Graph
3 Commits
Author SHA1 Message Date
duffyduckandClaude Opus 5 dc5c7d417f recover: -y durfte die Warnung vor dem laufenden Original wegwinken
-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>
2026-07-31 11:56:46 +02:00
duffyduckandClaude Opus 5 3ee5cf3508 Verwerfen uebersah eine noch nicht angesteckte Austauschplatte
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>
2026-07-31 11:40:03 +02:00
duffyduckandClaude Opus 5 725fbf8732 pvesnap-recovery: Snapshots als Maschine starten
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>
2026-07-31 11:38:38 +02:00