No network on LXCs

M

Madd_Dogg98

New Member
Jan 20, 2025
4
0
1
Hello

I have no idea what happened, but my LXCs are no longer getting any IP addresses. My VMs are getting IPs just fine and are fully online, its just the LXCs. I have a Unifi UDM as my DHCP server.

Here is my hosts /etc/network/interfaces
Bash: 
root@rdu-pve01:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface eno4 inet manual

iface eno1 inet manual

iface eno2 inet manual

iface eno3 inet manual

iface enp65s0 inet manual

iface enp65s0d1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.20/24
        gateway 192.168.0.1
        bridge-ports eno4
        bridge-stp off
        bridge-fd 0

auto vmbr1
iface vmbr1 inet manual
        bridge-ports enp65s0d1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 1000 1001 1002 1005 1030 1031 1032

The LXCs are set to DHCP. Below is one of the config from host /etc/pve/lxc/<cid>.conf
Bash: 
root@rdu-pve01:~# cat /etc/pve/lxc/112.conf
arch: amd64
cores: 4
features: nesting=1
hostname: rdu-lxc-pihole
memory: 1024
nameserver: 1.0.0.1
net0: name=eth0,bridge=vmbr1,firewall=1,hwaddr=BC:24:11:13:91:BB,ip=dhcp,tag=1005,type=veth
onboot: 1
ostype: debian
rootfs: data:112/vm-112-disk-0.raw,size=8G
searchdomain: 1.1.1.1
swap: 0
unprivileged: 1

I use DHCP reservations, and not set static IPs on the containers themselves, if that helps any.

I have no idea what could be causing this, any assistance would be appreciated. Let me know if any additional information is required.
 
Hello,

the configuration you posted seems totally common and not unusual.
What is the log inside of the LXC telling regarding the dhcp attempt? Like, is the request declined or doesn't it receive an answer? What happens if you manually repeat the dhcp request in the LXC, does it work then?
Does your UDM provide logs to get some details about the attempts of the LXC, like is it actually receiving a request at all? if yes, is there an error reported?
 
fba said:
Hello,

the configuration you posted seems totally common and not unusual.
What is the log inside of the LXC telling regarding the dhcp attempt? Like, is the request declined or doesn't it receive an answer? What happens if you manually repeat the dhcp request in the LXC, does it work then?
Does your UDM provide logs to get some details about the attempts of the LXC, like is it actually receiving a request at all? if yes, is there an error reported?
Click to expand...
According to journalctl -b from the LXC it is sending out attempts but not getting an offer..snippet below
Bash: 
Jan 19 22:33:12 rdu-lxc-pihole dhclient[90]: No working leases in persistent database - sleeping.
Jan 19 22:38:44 rdu-lxc-pihole dhclient[90]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jan 19 22:38:51 rdu-lxc-pihole dhclient[90]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jan 19 22:38:58 rdu-lxc-pihole dhclient[90]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Jan 19 22:39:01 rdu-lxc-pihole CRON[705]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Jan 19 22:39:01 rdu-lxc-pihole CRON[706]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Jan 19 22:39:01 rdu-lxc-pihole CRON[705]: pam_unix(cron:session): session closed for user root
Jan 19 22:39:10 rdu-lxc-pihole dhclient[90]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jan 19 22:39:17 rdu-lxc-pihole dhclient[90]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Jan 19 22:39:24 rdu-lxc-pihole systemd[1]: Starting phpsessionclean.service - Clean php session files...
Jan 19 22:39:25 rdu-lxc-pihole systemd[1]: phpsessionclean.service: Deactivated successfully.
Jan 19 22:39:25 rdu-lxc-pihole systemd[1]: Finished phpsessionclean.service - Clean php session files.
Jan 19 22:39:29 rdu-lxc-pihole dhclient[90]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Jan 19 22:39:41 rdu-lxc-pihole dhclient[90]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Jan 19 22:39:45 rdu-lxc-pihole dhclient[90]: No DHCPOFFERS received.

It appears to just constantly repeat this.

Restarting networking service just hangs.

The UDM is just showing a bunch of disconnect logs. It is no longer even sees the device as online currently.
 
fba said:
A dhclient eth0 might be faster.

Does the issue persist, if the LXC is rebooted?
Click to expand...
The output for dhclient eth0:
Bash: 
root@rdu-lxc-pihole:~# dhclient -v eth0
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/bc:24:11:13:91:bb
Sending on   LPF/eth0/bc:24:11:13:91:bb
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Yes, the issue persists if the LXC is rebooted.

I did run updates, so I have the latest 8.3.2. Not sure if that matters or not.
 
Depending on what the version was before, there might have been updates to the lxc supporting packages. Running containers keep using the old packages unless they are stopped.
What's the output of pveversion -v?
You could also try running the container from CLI with debug log enabled: pct start 112 --debug
 
fba said:
Depending on what the version was before, there might have been updates to the lxc supporting packages. Running containers keep using the old packages unless they are stopped.
What's the output of pveversion -v?
You could also try running the container from CLI with debug log enabled: pct start 112 --debug
Click to expand...
Here is the output of pveversion -v
Bash: 
root@rdu-pve01:~# pveversion -v
proxmox-ve: 8.3.0 (running kernel: 6.8.12-6-pve)
pve-manager: 8.3.2 (running version: 8.3.2/3e76eec21c4a14a7)
proxmox-kernel-helper: 8.1.0
pve-kernel-5.15: 7.4-7
proxmox-kernel-6.8: 6.8.12-6
proxmox-kernel-6.8.12-6-pve-signed: 6.8.12-6
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
proxmox-kernel-6.8.12-2-pve-signed: 6.8.12-2
proxmox-kernel-6.8.8-2-pve-signed: 6.8.8-2
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7
proxmox-kernel-6.2.16-20-pve: 6.2.16-20
proxmox-kernel-6.2: 6.2.16-20
proxmox-kernel-6.2.16-15-pve: 6.2.16-15
pve-kernel-5.15.126-1-pve: 5.15.126-1
pve-kernel-5.15.116-1-pve: 5.15.116-1
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2+deb12u1
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.1.2
libpve-network-perl: 0.10.0
libpve-rs-perl: 0.9.1
libpve-storage-perl: 8.3.3
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.3.2-1
proxmox-backup-file-restore: 3.3.2-2
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.3.3
pve-cluster: 8.0.10
pve-container: 5.2.3
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-2
pve-ha-manager: 4.0.6
pve-i18n: 3.3.2
pve-qemu-kvm: 9.0.2-4
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.3
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.6-pve1

Attached is the output of pct start 112 --debug
 

Attachments

You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom