Restore von CT Backup funktioniert nicht

[Obviously Forced]

Vorgeschichte:
Ich hatte eine LXC Container (CT) mit der ID 110. Für diesen Container habe ich die folgende Anleitung genutzt um den Container aufzusetzen: https://pve.proxmox.com/wiki/OpenVPN_in_LXC
Statt "direkt" OpenVPN zu installieren habe ich PiVPN installiert (https://www.pivpn.io/)
Außerdem habe ich einen Backup Job eingestellt, der mir täglich ein Backup macht (dabei wird das Backup auch gleich verifiziert)
PBS, welches als eigener LXC auf PVE läuft, hält dabei die letzten 7 Tages sowie 6 Wochenbackups von unter anderem den CT-110 vorrätig
Das Setup hat bisher gut funktioniert

Grund für den Post:
Ich habe ein paar Änderungen an dem LXC Container 110 gemacht, welche leider nicht die erwarteten Lösung gebracht haben. Statt diese händisch wieder zurückzuändern wollte ich das Backup restoren, da ich diesen Ansatz für sauberer halte und dabei keine Änderung "vergessen kann".
Ich bin somit auf das letzte Tagesbackup des Containers gegangen und habe in PVE auf Restore geklickt
Anbei das Log des fehlgeschlagenen Restore Task:

recovering backed-up configuration from 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z'
  Logical volume "vm-110-disk-1" created.
  Logical volume pve/vm-110-disk-1 changed.
Creating filesystem with 2097152 4k blocks and 524288 inodes
Filesystem UUID: a7b86e84-5eb4-4269-ad09-9150972d47cb
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
  Logical volume "vm-110-disk-0" successfully removed.
restoring 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z' now..
Warning: "/var/log/journal" - ACL invalid, attempting restore anyway..
Error: error extracting archive - encountered unexpected error during extraction: error at entry "": failed to leave directory: failed to apply directory metadata: failed to apply acls: EINVAL: Invalid argument
  Logical volume "vm-110-disk-1" successfully removed.
TASK ERROR: unable to restore CT 110 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --repository proxmox@pbs@192.168.1.191:backup-local' failed: exit code 255

Wie man im Log sieht hat der Restore leider nicht funktioniert. Ein paar Gedanken dazu:
1. Das Restore hat nicht funktioniert. Das ist "okay", aber zusätzlich wurde dabei auch noch der Container gelöscht, der restored werden sollte. Nicht ganz meine Erwartungshaltung, aber ehrlicherweise kann der Satz "Restore. This will permanently erase current CT data." das bedeuten. Meine Interpretation dazu war "nur" dass die Daten im Container gelöscht werden und nicht der Container in PVE selbst. Aber das ist ein Nebenschauplatz nicht der Grund für meinen Post.
2. Interessanter finde ich das folgende: Das Problem, dass ich nicht Restoren kann tritt „nur“ bei diesem CT Container 110 auf. Dabei ist egal ob ich die Tages oder Wochenbackups versucht zu restoren. Der Fehler taucht genau so bei allen Backups auf. Meine VM Backups funktionieren problemlos und können ohne Problem restored werden.

Meine Gedanken sowie Fragen für den Post sind:
* Die Fehlermeldung

error extracting archive - encountered unexpected error during extraction: error at entry "": failed to leave directory: failed to apply directory metadata: failed to apply acls: EINVAL: Invalid argument

schaut für mich "interessant" aus, da der Entry leer ist. Ist hier meine Erwartungshaltung falsch oder fehlt hier noch Information für den Endanwender?
* Ich mag Proxmox und würde gerne helfen, falls ich einen Fehler gefunden habe, dass es in Zukunft noch besser wird. Welche Informationen sind noch wichtig, damit ich entweder ein richtiges Bug Ticket eröffnen kann oder verstehe wo genau mein oder der Fehler steckt?

Daten für PVE:

proxmox-ve: 9.1.0 (running kernel: 6.17.13-3-pve)
pve-manager: 9.1.8 (running version: 9.1.8/a8e257e1ad64dd92)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.17: 6.17.13-3
proxmox-kernel-6.17.13-3-pve-signed: 6.17.13-3
proxmox-kernel-6.17.13-2-pve-signed: 6.17.13-2
proxmox-kernel-6.14: 6.14.11-6
proxmox-kernel-6.14.11-6-pve-signed: 6.14.11-6
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
amd64-microcode: 3.20251202.1~bpo13+1
ceph-fuse: 19.2.3-pve1
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.4.1-1+pve1
ifupdown2: 3.3.0-1+pmx12
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.6
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.2
libpve-cluster-perl: 9.1.2
libpve-common-perl: 9.1.9
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.3.0
libpve-rs-perl: 0.13.0
libpve-storage-perl: 9.1.1
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.5-4
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.1.7-2
proxmox-backup-file-restore: 4.1.7-2
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.1
proxmox-kernel-helper: 9.0.4
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.3
proxmox-widget-toolkit: 5.1.9
pve-cluster: 9.1.2
pve-container: 6.1.2
pve-docs: 9.1.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-3
pve-ha-manager: 5.2.0
pve-i18n: 3.7.0
pve-qemu-kvm: 10.1.2-7
pve-xtermjs: 5.5.0-3
qemu-server: 9.1.6
smartmontools: 7.4-pve1
spiceterm: 3.4.1
swtpm: 0.8.0+pve3
vncterm: 1.9.1
zfsutils-linux: 2.4.1-pve1

 

[Impact]

Mal probiert mit einem anderen Privileglevel wiederherzustellen?

 

[Obviously Forced]

Hi Impact,
ja, das habe ich auch schon probiert. Leider ohne Erfolg, egal ob mit "From Backup", "Unprivileged" oder "Priviledged"

 

[TErxleben]

Hi Impact,
ja, das habe ich auch schon probiert. Leider ohne Erfolg, egal ob mit "From Backup", "Unprivileged" oder "Priviledged"

CTs halte ich in Virtualsierungsumgebungen einfach nur für unterirdisch. Du schilderst zusätzlich ein "russisches Püppchen-Problem".
Nimm als Basis eine VM und mache innerhalb dieser deine Schachtelversuche.
Proxmox trifft m.E. überhaupt keine Schuld (außer vielleicht fahrlässig LXC als "Virtualisierung" anzubieten).
P.S.;
Es gibt absolut keinen Grund LXC dem Hypervisor direkt zuzumuten, statt diese vorher in einer VM zu kapseln. Faulheit vielleicht. Performance verlierst du vielleicht lächerliche 5%, hälst dir aber Brainfuck vom Hals.
P.P.S:
Du hast eine 5 Jahre alte Anleitung benutzt. Finde ich recht ambitioniert...

 

[Obviously Forced]

CTs halte ich in Virtualsierungsumgebungen einfach nur für unterirdisch. Du schilderst zusätzlich ein "russisches Püppchen-Problem".
Nimm als Basis eine VM und mache innerhalb dieser deine Schachtelversuche.
Proxmox trifft m.E. überhaupt keine Schuld (außer vielleicht fahrlässig LXC als "Virtualisierung" anzubieten).
P.S.;
Es gibt absolut keinen Grund LXC dem Hypervisor direkt zuzumuten, statt diese vorher in einer VM zu kapseln. Faulheit vielleicht. Performance verlierst du vielleicht lächerliche 5%, hälst dir aber Brainfuck vom Hals.
P.P.S:
Du hast eine 5 Jahre alte Anleitung benutzt. Finde ich recht ambitioniert...

Hi Terxleben,

es klingt für mich als hättest du das Gefühl, dass ich in meinem Originalpost Proxmox eine Schuld zugewiesen habe. Das war weder mein Wunsch noch meine Absicht. Ich versuche Proxmox besser verstehen und kennen zulernen, insbesondere die oben genannte Fehlermeldung bzw. -verhalten.

Mein Ziel mit der Vorgeschichte war eine transparentes Aufzeigen der "Abweichungen" von "Standardeinstellungen" eines CT. Inbesondere da ich nicht 100% abschätzen kann ob dies für den aktuellen Sachverhalt wichtig sind.
In wie fern hat das Alter einer Anleitung zum Aufsetzen eines CT Auswirkungen auf die restore- oder nicht restorfähigkeit eines CT im Allgemeinem? Oder für den oben genannten Fall die dokumentierten Änderungen wie z.B. das setzen von /dev/net/tun Permissions?

Es klingt als wäre für dich der Fakt, dass das Problem bei einem CT auftaucht genug um diesen Fall als unwichtig oder falsch abzustempeln. Ich verstehe, dass für dich persönlich eine VM der passende Weg wäre. Die im original Post gestellten Fragen zielen nicht auf eine Vergleich zwischen CT und VM ab.
Mein Wunsch ist, die von Proxmox zur Verfügung gestellten Features LXC sowie Restore und dessen oben beschriebenes Fehlerverhalten zu verstehen und vielleicht auch für andere in Zukunft verbessern zu können.

 

[bl1mp]

Moin,

magst du ggf. kurz skizzieren welche Änderungen du vorgenommen hast? Innerhalb des CTs oder an der Config?

Vor der Fehlermeldung steht ein Warning.
Warning: "/var/log/journal" - ACL invalid, attempting restore anyway..
Welcher Berechtigungen und welcher User sind dort gesetzt? (ls -la /var/log/journal/ )

Eine leicht aufwendige Methode bei der Analyse ist den Sestore mit einem stacktrace (strace) laufen zu lassen

strace -f lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --repository proxmox@pbs@192.168.1.191:backup-local

(Das sollte einiges an Text generieren also leitest du es am besten direkt in eine Datei um z.B. mit tee )

Die Konfiguration des Containers liegt im FIlesystem überings unter /var/lib/lxc/110/config
und /etc/pve/nodes/<hostname>/lxc/110.conf

Der Vollständigkeit könntest du auch noch die id-ranges für die Container prüfen.

cat /etc/subuid
cat /etc/subgid

Im Zweifelsfall solltest du dir die wichtigsten Files auch einzeln über die WebUI wiederherstellen können,
bzw. wenn du den Restore über die Auswahl im Storage machst (WebUI am Host unter den VMs/Containern), kannst du in Zukunft den Container auch mit einer anderen VMID wiederherstellen.
Dann wird der eigentliche Container nicht gelöscht.

BG, Lucas

 

[CoolTux]

CTs halte ich in Virtualsierungsumgebungen einfach nur für unterirdisch. Du schilderst zusätzlich ein "russisches Püppchen-Problem".
Nimm als Basis eine VM und mache innerhalb dieser deine Schachtelversuche.
Proxmox trifft m.E. überhaupt keine Schuld (außer vielleicht fahrlässig LXC als "Virtualisierung" anzubieten).
P.S.;
Es gibt absolut keinen Grund LXC dem Hypervisor direkt zuzumuten, statt diese vorher in einer VM zu kapseln. Faulheit vielleicht. Performance verlierst du vielleicht lächerliche 5%, hälst dir aber Brainfuck vom Hals.
P.P.S:
Du hast eine 5 Jahre alte Anleitung benutzt. Finde ich recht ambitioniert...

Ich muss gestehen, bezüglich LXCs teile ich Deine Meinung nicht. Ich würde sogar so weit gehen zu sagen das sie in Teilen falsch ist.

Wieso soll man auf einen Hypervisor, welcher bereits LXC Containerisierung unterstützt, erst noch ne VM installieren um dann LXC Containerisierung zu machen? Das halte ich eher für fragwürdig.
Proxmox ist doch genau dafür gedacht, um LXCs zu unterstützen.

Ob das jetzt unbedingt immer die beste Wahl ist mit Systemcontainern zu arbeiten seit dahin gestellt. Es ist vom Feeling her halt wie ne Linux VM nur als Container und mit entsprechender Containerspezifikation.


Grüße

 

[Obviously Forced]

Hallo Luca (bl1mp),

vielen Dank für deine ausführliche Antwort!

Der CT wurde wie folgt aufgebaut:
* Debian 13.2 Image
* Installation von PiVPN
- Nutzung von OpenVPN
- Aktivierung der unattended upgrades (security)
- Das Skript passt auch die Firewall an, damit der OpenVPN Server funktioniert
* Installation von wakeonlan

Sonstige Veränderungen beziehen sich fast aufschließlich auf den Ordner /etc/openvpn
* Anlegen von Clients für OpenVPN über PiVPN
* Erstellung von einen OpenVPN Skript, dass bei einem erfolgreichen Login ein wakeonlan Packet an eine fixe MAC sendet
- Dieses Skript hat in ersten Version in eine eigene Log Datei geschrieben. Seit über einen Monat nutzt das Skript jetzt das Journal für die Logs

CT Konfiguration war laut Backup

()
arch: amd64
cores: 1
features: nesting=1
hostname: pivpn
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.1,hwaddr=AAAAAA,ip=192.168.1.XXX/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-110-disk-0,size=8G
startup: order=3
swap: 512
tags: debian;external
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir

Der Befehl

ls -la /var/log/journal/

funktioniert leider nicht direkt, da der Container beim unerfolgreichen Restore gelöscht worden ist. Ich habe daher mit FUSE das Backup kurzfristig gemounted und den Befehl abgesetzt. Die Daten sind:

root@proxmox:/mnt/restore-ct-110/var/log# ls -la /var/log/journal/
total 16
drwxr-sr-x+  3 root systemd-journal 4096 Nov 19 04:16 .
drwxr-xr-x  16 root root            4096 Apr 21 09:29 ..
drwxr-sr-x+  2 root systemd-journal 4096 Apr 20 05:17 b5ed7d36b16b4793a973f8ae6eb4a16f

Da mir nicht klar welche ID Range du haben wolltest sende ich hiermit beide:
Proxmox

root@proxmox:/etc/pve/nodes/proxmox/lxc# cat /etc/subuid
root:100000:65536
root@proxmox:/etc/pve/nodes/proxmox/lxc# cat /etc/subgid
root:100000:65536

CT 110:

cat subuid
vpn-user:100000:65536
root@proxmox:/mnt/restore-ct-110/etc# cat subgid
vpn-user:100000:65536

Diese sehen auf den ersten Blick für mich gut aus, da sie identisch sind

Ich habe einen StackTrace gemacht und angehängt. Der StaceTrace läuft viele Zeilen durch, dann friert er ein. Im angehängten Log ist ab Zeile 1893 zu sehen. Ich habe nach ein paar Minuten ohne Veränderung die Operation abgebrochen.
Das nachfolgende Snippet ist von einem zweiten Run. Dieser zeigt aber genau das selbe Verhalten.

pid 17487] openat(AT_FDCWD, "/run/user/0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 EACCES (Permission denied)
[pid 17487] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
[pid 17487] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
[pid 17487] ioctl(1, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
[pid 17487] write(1, "Password for \"proxmox@pbs\": ", 28Password for "proxmox@pbs": ) = 28
[pid 17487] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
[pid 17487] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
[pid 17487] ioctl(0, TCSETS, {c_iflag=, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ECHOE|ECHOK|ECHOCTL|ECHOKE, ...}) = 0
                [pid 17487] ioctl(0, TCGETS, {c_iflag=, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ECHOE|ECHOK|ECHOCTL|ECHOKE, ...}) = 0
                                [pid 17487] read(0,

 

[TErxleben]

Hi Terxleben,

es klingt für mich als hättest du das Gefühl, dass ich in meinem Originalpost Proxmox eine Schuld zugewiesen habe. Das war weder mein Wunsch noch meine Absicht. Ich versuche Proxmox besser verstehen und kennen zulernen, insbesondere die oben genannte Fehlermeldung bzw. -verhalten.

Mein Ziel mit der Vorgeschichte war eine transparentes Aufzeigen der "Abweichungen" von "Standardeinstellungen" eines CT. Inbesondere da ich nicht 100% abschätzen kann ob dies für den aktuellen Sachverhalt wichtig sind.
In wie fern hat das Alter einer Anleitung zum Aufsetzen eines CT Auswirkungen auf die restore- oder nicht restorfähigkeit eines CT im Allgemeinem? Oder für den oben genannten Fall die dokumentierten Änderungen wie z.B. das setzen von /dev/net/tun Permissions?

Es klingt als wäre für dich der Fakt, dass das Problem bei einem CT auftaucht genug um diesen Fall als unwichtig oder falsch abzustempeln. Ich verstehe, dass für dich persönlich eine VM der passende Weg wäre. Die im original Post gestellten Fragen zielen nicht auf eine Vergleich zwischen CT und VM ab.
Mein Wunsch ist, die von Proxmox zur Verfügung gestellten Features LXC sowie Restore und dessen oben beschriebenes Fehlerverhalten zu verstehen und vielleicht auch für andere in Zukunft verbessern zu können.

Da hast du mich falsch verstanden. Ich wollte lediglich darauf hinaus, dass Proxmox selbst nur eine Kapselung der darunterliegenden Techniken ist. KVM-VMs sind ihrerseits eine vollständige Kapselung eines fast beliebigen Betriebssystems. LXC-Container hingegen sind mit dem Betriebssystem des darunterliegenden Hypervisors verwoben. Genau das führt dann zu den Kopfschmerzen, mit denen du gerade kämpfst und die man mittels VM eliminieren kann. Der durchaus löbliche Versuch ein Fehlverhalten zu ergründen ähnelt aber, gerade bei Containerisierung, dem Kampf gegen Windmühlen.

 

[mikee]

[...] dass Proxmox selbst nur eine Kapselung der darunterliegenden Techniken ist. [...] LXC-Container hingegen sind mit dem Betriebssystem des darunterliegenden Hypervisors verwoben. [...]

Das hat dir doch eine KI geflüstert, oder?

 

[TErxleben]

Ich muss gestehen, bezüglich LXCs teile ich Deine Meinung nicht. Ich würde sogar so weit gehen zu sagen das sie in Teilen falsch ist.

Wieso soll man auf einen Hypervisor, welcher bereits LXC Containerisierung unterstützt, erst noch ne VM installieren um dann LXC Containerisierung zu machen? Das halte ich eher für fragwürdig.
Proxmox ist doch genau dafür gedacht, um LXCs zu unterstützen.

Ob das jetzt unbedingt immer die beste Wahl ist mit Systemcontainern zu arbeiten seit dahin gestellt. Es ist vom Feeling her halt wie ne Linux VM nur als Container und mit entsprechender Containerspezifikation.


Grüße

Die strikte Trennung von virtueller Maschine und darunterliegenden Betriebssystem ist mir erheblich mehr Wert, als irgendwelche eventuelle Einsparungen. Schon hier im Forum findest du einen riesen Sack an Problemen, die ausschließlich Container betreffen und mit einer VM vermieden werden können. Außerdem sehe ich keinerlei nennenswerte Vorteile, Container in Proxmox zu verwalten, statt eine VM anzulegen in der ich dann mehrere Container orchestrieren kann. Nebenbei hat Containerisierung in den letzten 30J keinesfalls zu den versprochenen Lösungen geführt, sondern noch eine Schippe Probleme drauf gelegt.

 

[TErxleben]

Das hat dir doch eine KI geflüstert, oder?

Wie meinen? Den "Witz" musst du näher erklären.

 

[CoolTux]

Da hast du mich falsch verstanden. Ich wollte lediglich darauf hinaus, dass Proxmox selbst nur eine Kapselung der darunterliegenden Techniken ist. KVM-VMs sind ihrerseits eine vollständige Kapselung eines fast beliebigen Betriebssystems. LXC-Container hingegen sind mit dem Betriebssystem des darunterliegenden Hypervisors verwoben. Genau das führt dann zu den Kopfschmerzen, mit denen du gerade kämpfst und die man mittels VM eliminieren kann. Der durchaus löbliche Versuch ein Fehlverhalten zu ergründen ähnelt aber, gerade bei Containerisierung, dem Kampf gegen Windmühlen.

Diese Aussage ist schlicht falsch.
Containerisierung kommt ohne Hypervisor. Du braucht dafür keinen Hypervisor!!!


Und ja, Containerisierung hat die IT etwas anspruchsvoller gemacht, aber auch leichter zu Handhaben was das Thema deployen von Applikationen an geht.
Ich lasse fast alle meine privaten Anwendungen in einem Kubernetes Cluster laufen und es ist soooo einfach die zu administrieren.

 

[mikee]

Wie meinen? Den "Witz" musst du näher erklären.

Ich habe "gehört", dass KI (LLMs) nicht alles wissen und manchmal Antworten erfinden.

Zu deinen Aussagen:

[...] dass Proxmox selbst nur eine Kapselung der darunterliegenden Techniken ist. [...] LXC-Container hingegen sind mit dem Betriebssystem des darunterliegenden Hypervisors verwoben. [...]

PVE kapselt nichts und LXC braucht keinen Hypervisor!

 

[TErxleben]

Diese Aussage ist schlicht falsch.
Containerisierung kommt ohne Hypervisor. Du braucht dafür keinen Hypervisor!!!

Man kann auch Haare spalten. Das Betriebssystem entspricht einem Hypervisor. Daher ja die potentellen Probleme durch mangelnde Isolation.

Und ja, Containerisierung hat die IT etwas anspruchsvoller gemacht, aber auch leichter zu Handhaben was das Thema deployen von Applikationen an geht.

Genau da liegt der Hund begraben. Irgendwelche Anbieter wollten Geld sparen statt ihre SW in die Paketverwaltungen des jeweiligen Betriebssytems vernünftig zu integrieren.

Ich lasse fast alle meine privaten Anwendungen in einem Kubernetes Cluster laufen und es ist soooo einfach die zu administrieren.

Da stellt sich doch gleich die Frage warum man mit Proxmox Container verwalten sollte, wenn man Kubernetes am Start hat. Hat man das nicht, dann kann ich über den Umweg VM auch Hosts für Container ohne erheblichen Mehraufwand bereitstellen.

 

[Johannes S]

Ich bin mir relativ sicher, dass TErxleben sich seine Argumente nicht von einer KI schreiben lässt

Die Debatte ist nämlich nicht neu und wurde schon öfter geführt:

• https://forum.proxmox.com/threads/i...opnsense-mit-reverse-proxy.182376/post-847092
• https://forum.proxmox.com/threads/proxmox-und-container-in-vms.162181/
• https://forum.proxmox.com/threads/p...ner-vorteile-und-nachteile.166808/post-774851

Seine Sichtweise auf lxc teile ich weitestgehend, wenn ich auch bei den Konsequenzen nicht ganz so weit gehe
Auch wenn er für meinen Geschmack etwas zu weit geht, so ist LXC natürlich ein zusätzlicher Layer unter dem eigentlichen Linux ( genauso wie KVM/qemu), der eben für eine Isolierung zwischen PVE und den Containersystem sorgt. Er ist aber natürlich schwächer als eine VM (die ja besser abgeschottet zum Host ist) und sofern die Anwendung externe Ressourcen (wie durchgereichte Devices, Netzwerkfreigaben o.ä.) oder zusätzliche Rechte benötigt, umständlicher einzurichten, was gerade für Neulinge Sachen unnötig aufwändig werden lässt. "Kampf gegen Windmühlen" finde ich zwar übertrieben (weil die Probleme samt Lösungen ja bekannt sind), aber gerade für Newbies halt unnötige (da über Verwendung einer VM) vermeidbare Schmerzen.

Wo ich nicht mitgehe ist die grundsätzliche Ablehnung von Containern. Tatsächlich (siehe ältere Debatten) haben Anwendungscontainer im Allgemeinen und Kubernetes im besonderes ja tatsächlich Probleme gelöst, die vorher nicht so leicht lösbar waren oder jeder das Rad neu erfinden musste.

Mit dem Problem des OP hat die ganze Debatte aber nichts zu tun

@OP: Hast du mal testweise versucht einen neuen Container mit pivpn aufzusetzen? Und zwar (zum Vergleich) sowohl priviligiert als auch unpriviligiert? Das Durchreichen des tun-Device sollte so oder so gehen. Interessant wäre auch zum Vergleich es mit einer VM zu versuchen. Und last but not least: Warum OpenVPN und nicht Wireguard oder ein darauf basierenden overlay network wie tailscale/headscale oder netbird? Ich finde Wireguard und die darauf aufbauenden overlay networks deutlich schmerzfreier im Setup und Handling oder hast du Anwendungen die nur mit OpenVPN klar kommen?

 

[Johannes S]

Genau da liegt der Hund begraben. Irgendwelche Anbieter wollten Geld sparen statt ihre SW in die Paketverwaltungen des jeweiligen Betriebssytems vernünftig zu integrieren.

Nicht nur die Anbieter, sondern (vor allen) die Betreiber. Auf der Arbeit haben wir mittlerweile neben den Ubuntu-Mirror bestimmt 20 3rd-party-Repositories, weil irgendwelche Entwickler unbedingt die neueste Version von docker oder ihrer Lieblingsdatenbank verwenden wollen. Sobald da ein Upgrade einen breaking change reinbringt, hat man dann das Vergnügen. Da wäre mir die Variante mit den Containern doch deutlich lieber: Damit machen die Entwickler nur ihre eigene Spielwiese kaputt, nicht die vom Rest.

 

[CoolTux]

Da stellt sich doch gleich die Frage warum man mit Proxmox Container verwalten sollte, wenn man Kubernetes am Start hat. Hat man das nicht, dann kann ich über den Umweg VM auch Hosts für Container ohne erheblichen Mehraufwand bereitstellen.

Was sind denn Proxmox Container?

Ich habe 4-5 LXC Container auf dem Proxmox Host laufen, meistens mit Anwendungen die es entweder als OCI Images nicht gab oder einfach zu klein waren um mich dann mit Kubernetes zu beschäftigen

Ich habe 6 VMS als Kubernetes Nodes in Proxmox laufen.

 

[TErxleben]

Ich habe "gehört", dass KI (LLMs) nicht alles wissen und manchmal Antworten erfinden.

Zu deinen Aussagen:

PVE kapselt nichts und LXC braucht keinen Hypervisor!

Ich habe hingegen gehört, dass sinnerfassendes Lesen und Analogieschlüsse schwer sein sollen. Selbstverständlich kapselt PVE. Nämlich die CLIs der darunterliegenden Techniken in einer WebGUI.

LXC braucht natürlich keinen Hypervisor im strengen Sinne. Stattdessen braucht es nur zusätzlich installierte Pakete im Betriebssystem um Container ohne virtuelle Hardware bereitstellen zu können.
Besser so Herr Oberlehrer?

 

[TErxleben]

Was sind denn Proxmox Container?

Ich meinte mit PVE verwaltete Container.

Ich habe 4-5 LXC Container auf dem Proxmox Host laufen, meistens mit Anwendungen die es entweder als OCI Images nicht gab oder einfach zu klein waren um mich dann mit Kubernetes zu beschäftigen

Ich habe 6 VMS als Kubernetes Nodes in Proxmox laufen.

Ist bei mir sehr ähnlich. Nur das ich die Container jeweils in eigenen VMs laufen lasse und mir Kubernetes sparen kann.