lxc network interface created but not removed

mstefan

Member
Jan 3, 2022
24
9
8
34
hi,

yesterday I added a second networkinterface to a container.
After some testing I removed it again, everything with the pve webgui.

After some rebooting of the container I realized thenetworking Service failed.
ifup could not get up eth2. eth2 was removed previously.
I took a look into /etc/network/interfaces and there eth2 exists. It got not removed.

For testing I created a fresh lxc and tested it again. Same behavior.
Adding a nic works. Removing not.

PVE 8, last updated yesterday
LXC: Debian 12


Is this bug only on my site or is it known?
 
I'm currently running into this myself as well using the default Debian container templates. I'm running Proxmox pve-manager/8.4.1/2a5fa54a8503f96d (running kernel: 6.8.12-10-pve).

When I add interfaces they still end up staying around in /etc/network/interfaces as described above. It causes systemd-networkd to not start as it doesn't believe the network is ready.
 
Hi,

ifup could not get up eth2. eth2 was removed previously.
I took a look into /etc/network/interfaces and there eth2 exists. It got not removed.
LXC network interfaces are never added to /etc/network/interfaces, but are rather dynamically created when the CT starts.

Did you add them yourself? Did you perhaps run some random scripts of the internet, which often can modify the system in unintended ways?
Could you please post the full output of cat /etc/network/interfaces before creating such an CT, and afterwards?
As well as the output of pct config <vmid>.

All in codetags, please :)
 
Initial config:

Code:
arch: amd64
cores: 1
features: nesting=1
hostname: test-ct
memory: 512
nameserver: 192.168.15.2
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.15.1,hwaddr=BC:24:11:70:43:DB,ip=192.168.15.100/24,ip6=auto,tag=15,type=veth
ostype: debian
rootfs: local-zfs:subvol-126-disk-0,size=8G
swap: 0
unprivileged: 1

Initial interfaces:

Code:
root@test-ct:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.15.100/24
        gateway 192.168.15.1

iface eth0 inet6 auto

root@test-ct:~#

Added second interface via Proxmox GUI, no other changes.

PCT config:

Code:
arch: amd64
cores: 1
features: nesting=1
hostname: test-ct
memory: 512
nameserver: 192.168.15.2
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.15.1,hwaddr=BC:24:11:70:43:DB,ip=192.168.15.100/24,ip6=auto,tag=15,type=veth
net1: name=eth1,bridge=vmbr0,firewall=1,gw=192.168.15.1,hwaddr=BC:24:11:31:02:8E,ip=192.168.15.110/24,ip6=auto,tag=15,type=veth
ostype: debian
rootfs: local-zfs:subvol-126-disk-0,size=8G
swap: 0
unprivileged: 1

In container config:

Code:
root@test-ct:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.15.100/24
        gateway 192.168.15.1

iface eth0 inet6 auto

auto eth1
iface eth1 inet static
        address 192.168.15.110/24
        gateway 192.168.15.1

iface eth1 inet6 auto

root@test-ct:~#

Now removing that interface:

PCT config:

Code:
arch: amd64
cores: 1
features: nesting=1
hostname: test-ct
memory: 512
nameserver: 192.168.15.2
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.15.1,hwaddr=BC:24:11:70:43:DB,ip=192.168.15.100/24,ip6=auto,tag=15,type=veth
ostype: debian
rootfs: local-zfs:subvol-126-disk-0,size=8G
swap: 0
unprivileged: 1

Container config still contains eth1:

Code:
root@test-ct:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.15.100/24
        gateway 192.168.15.1

iface eth0 inet6 auto

auto eth1
iface eth1 inet static
        address 192.168.15.110/24
        gateway 192.168.15.1

iface eth1 inet6 auto

root@test-ct:~#

All this was tested using the debian-12-standard_12.7-1_amd64.tar.zst template using the Proxmox version I posted about above. No other changes were made to the container nor was it rebooted between adding/removing interfaces. Everything was done through the Proxmox GUI. One thing I know I did wrong was set a gateway for both interfaces, just rushed putting the new interface on. Same thing happens even without that oversight.

Hopefully this can help.