Proxmox LXC mit Bind Mounts migrieren: shared=1 und die Pitfalls beim Restore

In Frankreich laufen bei mir zwei Proxmox-Nodes als Cluster. Als ich ein paar Container von einem Node auf den anderen schieben wollte, hat Proxmox sich bei genau den Containern geweigert, die einen Bind Mount auf mein NAS haben, ein UniFi UNAS Pro*. Bei Containern ohne Mounts ging es sofort. In diesem Guide steht, was Proxmox da erwartet, wie die Migration bei mir abgelaufen ist und welcher Fehler mir schon vorher bei einem Restore passiert ist.

Warum Proxmox die Migration ablehnt

Ein Bind Mount in einem LXC ist ein Mount Point (mp0, mp1 usw.), der direkt auf einen Pfad des Hosts zeigt. Bei mir ist das der NAS-Share, den Proxmox auf dem Host unter /mnt/pve/nas einhängt. Im Container erscheint er zum Beispiel als /mnt/media.

Proxmox weiß aber nicht, ob dieser Host-Pfad auf dem Ziel-Node genauso existiert. Es könnte ja ein lokales Verzeichnis sein, das es nur auf einem Server gibt. Deshalb blockt es die Migration, bis du den Mount Point mit shared=1 markierst. Damit sagst du Proxmox, dass der Pfad auf jedem Node vorhanden ist:

pct set <id> -mp0 /mnt/pve/nas,mp=/mnt/media,shared=1

Proxmox prüft das nicht nach. Wenn der Pfad auf dem Ziel-Node fehlt, startet der Container dort nicht oder sieht ein leeres Verzeichnis. Bei einem NAS, das als Storage im Cluster eingebunden ist, hängt der Share auf allen Nodes am gleichen Pfad, dann passt das.

Wenn du die Zeile lieber direkt in der Config anpasst, liegt sie unter /etc/pve/lxc/<id>.conf:

mp0: /mnt/pve/nas,mp=/mnt/media,shared=1

Vorher: Backup aufs NAS

Vor der Migration habe ich von jedem betroffenen Container ein vzdump-Backup auf das NAS geschrieben. Das geht im Webinterface unter Backup oder in der Shell:

vzdump <id> --storage <nas-storage> --mode stop --compress zstd

Wichtig zu wissen: Die Daten auf dem Bind Mount sind in diesem Backup nicht drin. vzdump sichert das Root-Dateisystem des Containers und die Volumes, die Proxmox selbst verwaltet. Ein Bind Mount auf einen Host-Pfad wird übersprungen. Bei mir ist das gewollt, die Mediathek liegt ja auf dem NAS und soll nicht in jedem Container-Backup landen. Die Daten dort brauchen also ein eigenes Backup.

Die Migration: offline

Proxmox bietet für Container einen Restart-Modus an, der den Container stoppt, verschiebt und wieder startet. Für meine Container mit Bind Mount wurde der abgelehnt. Also habe ich es klassisch offline gemacht:

pct shutdown <id>
pct migrate <id> <ziel-node>
# danach auf dem Ziel-Node:
pct start <id>

Die IP-Adressen sind gleich geblieben. Die Container holen sich ihre Adresse per DHCP, und im Router gibt es für jede MAC-Adresse eine Reservierung. Die MAC wandert mit der Container-Config mit, also bekommt der Container auf dem neuen Node dieselbe IP. Reverse Proxy, Monitoring und alles andere, was auf die IP zeigt, musste ich nicht anfassen.

GPU-Pfade können sich ändern

Wenn eine App im Container die GPU des Hosts nutzt, schau dir nach der Migration den Device-Pfad an. Auf dem neuen Host kann die GPU unter einem anderen Pfad hängen. Bei mir musste ich in Plex den HardwareDevicePath auf das neue Device umstellen. Welche Devices es auf dem Host gibt, zeigt:

ls -l /dev/dri/

Prüf auch die dev0– bzw. lxc.mount.entry-Zeilen in der Container-Config, damit dort das richtige Device durchgereicht wird.

Der zweite Pitfall: pct restore verliert den Bind Mount

Das hier ist mir schon früher passiert. Ich hatte einen Container aus Versehen mit einer viel zu großen Disk angelegt. Verkleinern kann Proxmox eine Container-Disk nicht direkt, aber beim Restore lässt sich die Größe neu festlegen:

pct restore <id> /mnt/pve/nas/dump/vzdump-lxc-<id>-<datum>.tar.zst --rootfs local-lvm:32 --force

Die neue 32-GB-Disk war da, aber die mp0-Zeile mit dem Bind Mount fehlte in der neuen Config. Ohne sie sieht der Container den NAS-Share nicht. Ich musste die Zeile wieder eintragen:

pct set <id> -mp0 /mnt/pve/nas,mp=/mnt/media,shared=1

Seitdem vergleiche ich nach jedem Restore die aktuelle Config mit der, die im Backup steckt. Die liegt im Archiv unter ./etc/vzdump/pct.conf und lässt sich ohne Entpacken anzeigen:

tar --zstd -xOf /mnt/pve/nas/dump/vzdump-lxc-<id>-<datum>.tar.zst ./etc/vzdump/pct.conf
pct config <id>

Alles, was in der ersten Ausgabe steht und in der zweiten fehlt, trägst du mit pct set nach. Bei mir war es nur die mp0-Zeile.

Kurz zusammengefasst

• Bind Mounts, die auf allen Nodes existieren, mit shared=1 markieren, sonst gibt es keine Migration.
• Vorher ein vzdump-Backup machen und daran denken, dass der Inhalt des Bind Mounts dort fehlt.
• Wenn der Restart-Modus nicht geht, offline migrieren: stoppen, pct migrate, starten.
• Mit DHCP-Reservierung per MAC bleibt die IP gleich.
• Nach der Migration GPU-Pfade in Apps wie Plex prüfen.
• Nach einem pct restore die Config mit der pct.conf aus dem Archiv vergleichen.

Hast du Container mit Bind Mounts schon zwischen Nodes verschoben und bist auf andere Probleme gestoßen? Schreib es in die Kommentare.

* Affiliate-Link: Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Für dich ändert sich am Preis nichts. Mehr dazu