Proxmox lxc container nicht mehr vom Web erreichbar

Hallo,

gibt es eigentlich zu dem Thema neue Erkenntnisse ?

Den alten Kernel zu nutzen funktioniert bei mir nur bei einem Teil der LXC's.

Die anderen verlieren nach einiger Zeit ( Stunden ) einfach ihre IP-Adresse, Restart vom Netzwerk oder DHCP bringen nicht, nur eben Reboot und langsam nervt es mich gewaltig.

EDIT: hab nen Bugreport aufgemacht
 
Last edited:
Hi
Hallo,

gibt es eigentlich zu dem Thema neue Erkenntnisse ?

Den alten Kernel zu nutzen funktioniert bei mir nur bei einem Teil der LXC's.

Die anderen verlieren nach einiger Zeit ( Stunden ) einfach ihre IP-Adresse, Restart vom Netzwerk oder DHCP bringen nicht, nur eben Reboot und langsam nervt es mich gewaltig.

EDIT: hab nen Bugreport aufgemacht
Hallo,
bitte zunächst die container config pct config VMID --current sowie die Netzwerk config cat /etc/network/interfaces posten. Gibt es irgendwelche Fehlermeldungen im systemd journal um die Zeit herum, wo der Container scheinbar die IP Addresse verliert? journalctl --since <DATETIME> --until <DATETIME> kann zum Inspizieren des Journals sowohl auf dem PVE host als auch im LXC verwendet werden.

Edit: Es scheint mir nicht ein Problem wie im ursprünglichen Post zu sein, dabei handelte es sich ja um einen Zertifikatsfehler weil das Zertifikat überschrieben wurde.
 
Last edited:
doppelte IP's können es nicht sein, die werden per DHCP-Reservation fest vergeben
Eventuell auch die DHCP settings und lease time checken, vielleicht liegt es ja auch am DHCP...
 
Hi

Hallo,
bitte zunächst die container config pct config VMID --current sowie die Netzwerk config cat /etc/network/interfaces posten. Gibt es irgendwelche Fehlermeldungen im systemd journal um die Zeit herum, wo der Container scheinbar die IP Addresse verliert? journalctl --since <DATETIME> --until <DATETIME> kann zum Inspizieren des Journals sowohl auf dem PVE host als auch im LXC verwendet werden.

Edit: Es scheint mir nicht ein Problem wie im ursprünglichen Post zu sein, dabei handelte es sich ja um einen Zertifikatsfehler weil das Zertifikat überschrieben wurde.
Liefer ich nach, wenn die LXC das nächste mal ausgestiegen sind - vermuttlich heute abend.

DHCP ist es definitiv nicht, dann würde die LXC mit 22.x LTS Ubuntu auch betroffen, sind sie aber nicht, nur was LTS 24.x nutzt.
 
Was mir spontan einfällt , evt. lxc container geclont ? Hatte bei mir zu Problemen geführt da er die MAC Addresse 1:1 übernommen hat & irgendwann nicht mehr erreichbar war...
 
Was mir spontan einfällt , evt. lxc container geclont ? Hatte bei mir zu Problemen geführt da er die MAC Addresse 1:1 übernommen hat & irgendwann nicht mehr erreichbar war...
Das mache ich schon seit Jahren so, hat nie Probleme gemacht. Die MAC-Adressen sind auch nicht gleich bei den ganzen LXC's.

Die Problem fingen eindeutig mit dem Upgrade von Proxmox 8.2 und Ubuntu LTS 24.x an - alles LXC's, die noch LTS 22.x haben, funktionieren ja problemlos.
 
Liefer ich nach, wenn die LXC das nächste mal ausgestiegen sind - vermuttlich heute abend.

DHCP ist es definitiv nicht, dann würde die LXC mit 22.x LTS Ubuntu auch betroffen, sind sie aber nicht, nur was LTS 24.x nutzt.
Das schließt nicht aus, dass es sich um ein DHCP Problem in den 24.x Containern handelt. Das systemd journal des Containers kann da eventuell weiterhelfen.
 
I see you attached the logs in the ticket here https://bugzilla.proxmox.com/show_bug.cgi?id=5633. Maybe best to keep the discussion in the forum for now, otherwise this might get harder to keep track.

Please provide also the requested container and network config. Further, what is the status of systemctl status systemd-networkd in the container?
 
Keine Problem, schreiben wir hier - Sprich was gegen Deutsch ?
Ich hatte vorhin noch zwei journalctl Auszüge von gestern abend in den Bugreport geschrieben.


hier der Auszug nach dem Reboot eines LXC, der wieder erreichbar ist
Code:
root@influxdb:~# systemctl status systemd-networkd
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2024-07-30 10:04:59 CEST; 14min ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
             man:org.freedesktop.network1(5)
   Main PID: 92 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 76370)
   FD Store: 0 (limit: 512)
     Memory: 3.5M (peak: 3.8M)
        CPU: 48ms
     CGroup: /system.slice/systemd-networkd.service
             └─92 /usr/lib/systemd/systemd-networkd

Jul 30 10:04:59 influxdb systemd-networkd[92]: lo: Gained carrier
Jul 30 10:04:59 influxdb systemd-networkd[92]: eth0: Configuring with /etc/systemd/network/eth0.network.
Jul 30 10:04:59 influxdb systemd-networkd[92]: Enumeration completed
Jul 30 10:04:59 influxdb systemd[1]: Started systemd-networkd.service - Network Configuration.
Jul 30 10:04:59 influxdb systemd-networkd[92]: eth0: Link UP
Jul 30 10:04:59 influxdb systemd-networkd[92]: eth0: Gained carrier
Jul 30 10:04:59 influxdb systemd-networkd[92]: eth0: DHCPv4 address 10.0.10.37/24, gateway 10.0.10.1 acquired from 10.0.10.1
Jul 30 10:05:00 influxdb systemd-networkd[92]: eth0: Gained IPv6LL
Jul 30 10:05:01 influxdb systemd-networkd[92]: eth0: Could not acquire DHCPv6 lease on NDisc request: Address already in use
Jul 30 10:05:01 influxdb systemd-networkd[92]: eth0: Failed


und hier das ganze von einem der aktuell Probleme hat:

Code:
root@calibre:~# systemctl status systemd-networkd
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-07-29 16:42:38 CEST; 17h ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
             man:org.freedesktop.network1(5)
   Main PID: 95 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 76370)
   FD Store: 0 (limit: 512)
     Memory: 3.7M (peak: 4.2M)
        CPU: 185ms
     CGroup: /system.slice/systemd-networkd.service
             └─95 /usr/lib/systemd/systemd-networkd

Jul 29 16:42:38 calibre systemd-networkd[95]: lo: Gained carrier
Jul 29 16:42:38 calibre systemd-networkd[95]: eth0: Configuring with /etc/systemd/network/eth0.network.
Jul 29 16:42:38 calibre systemd-networkd[95]: Enumeration completed
Jul 29 16:42:38 calibre systemd[1]: Started systemd-networkd.service - Network Configuration.
Jul 29 16:42:38 calibre systemd-networkd[95]: eth0: Link UP
Jul 29 16:42:38 calibre systemd-networkd[95]: eth0: Gained carrier
Jul 29 16:42:38 calibre systemd-networkd[95]: eth0: DHCPv4 address 10.0.10.35/24, gateway 10.0.10.1 acquired fr>
Jul 29 16:42:40 calibre systemd-networkd[95]: eth0: Gained IPv6LL
Jul 29 16:42:41 calibre systemd-networkd[95]: eth0: Could not acquire DHCPv6 lease on NDisc request: Address al>
Jul 29 16:42:41 calibre systemd-networkd[95]: eth0: Failed


root@calibre:~# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:3e:64:0c brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::be24:11ff:fe3e:640c/64 scope link
       valid_lft forever preferred_lft forever


´Vermuttlich, das es ein DHCP-Problem auf dem Client ist, wie schon geschrieben IPv6 funktioniert ha auch nicht mehr.

Bis zum Update der LXC 's mit "do-release-upgrade" liefen die LXC alle wunderbar, auch mit IPv6.


Merkwürdig finde ich, das dies erst nach einiger Zeit auftritt, als wenn jemanden den "Lan-Stecker" zieht.
 
Keine Problem, schreiben wir hier - Sprich was gegen Deutsch ?
Nein, war nur wegen des bugreport mit den Sprachen etwas durcheinander gekommen ;)

Kann es sein das sowohl systemd-networkd als auch dhcpcd aktiv sind? systemd-networkd sollte das exclusiv übernehmen.
eth0: Could not acquire DHCPv6 lease on NDisc request: Address already in use
dies weist zumindest darauf hin, dass hier etwas nicht passt und ein DHCP issue sein wird.

Bis zum Update der LXC 's mit "do-release-upgrade" liefen die LXC alle wunderbar, auch mit IPv6.
Vermutlich weil nun durch das release upgrade ein weiteres service dhcp client macht? Bitte sicherstellen, dass da kein weiteres service dazwischengeht.
 
Kann es sein das sowohl systemd-networkd als auch dhcpcd aktiv sind? systemd-networkd sollte das exclusiv übernehmen.
dies weist zumindest darauf hin, dass hier etwas nicht passt und ein DHCP issue sein wird.
Jau, das sieht genau so aus.

Hab den dhcpd gestoppt / disabled - reboot und schon funktioniert IPv6 auch wieder.

Warten wir mal bis heute abend, ob die dann immer noch laufen - meist hielt es nicht mehr als 2 Std.


EDIT: vermuttlich wird es auch die Ubuntu 23.04 Container betreffen, da läuft auch beides, hab gerade mal zwei gestartet
 
Last edited:
Hallo,

Fehler ist behoben, die LXC's laufen seit 24h ohne Probleme, egal ob mit LTS 24.x oder Ubunut 23.x

Ich hab den "dhcpcd" von allen deinstalliert - IPv6 funktioniert seit dem auch wieder.


Neue erstellte LXC's mit LTS 24.x die ich per HelperSript erstellt hatte, waren nicht betroffen, da war "dhcpcd" erst garnicht mehr drauf.


Danke für den Support !
 
  • Like
Reactions: Chris

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!