Commit Graph
3 Commits
Author SHA1 Message Date
duffyduckandClaude Opus 5 804224d2da Transfer-Laufwerke: NTFS raus, Partitionstyp explizit auf msftdata
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>
2026-07-31 20:29:19 +02:00
duffyduckandClaude Opus 5 46ffc54059 Transfer-Laufwerke: exFAT als Vorgabe, Bezeichnungen kuerzen
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>
2026-07-31 20:26:19 +02:00
duffyduckandClaude Opus 5 f44ad0e34a Transfer-Laufwerke: Engine und Werkzeugpruefung im Installer
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>
2026-07-31 20:24:22 +02:00