LXC network not active at creation

ca_maer

Well-Known Member
Dec 5, 2017
181
14
58
45
Hello,

There seems to be a bug when creating a new container where the container is not reachable until you log in the server using the console. I've tested this on multiple servers with the same results.

Steps to reproduce:
1-Create a new CT
2-Start the new CT
3-Ping the CT (Should timeout)
4-Launch web console
5-Log in with root
6- Wait 5 sec
7- Ping again (Should respond)

After that everything works fine even after reboots

Here's my pveversion
Code:
proxmox-ve: 5.1-38 (running kernel: 4.13.13-5-pve)
pve-manager: 5.1-43 (running version: 5.1-43/bdb08029)
pve-kernel-4.13.4-1-pve: 4.13.4-26
pve-kernel-4.13.8-2-pve: 4.13.8-28
pve-kernel-4.13.13-4-pve: 4.13.13-35
pve-kernel-4.13.13-2-pve: 4.13.13-33
pve-kernel-4.13.8-3-pve: 4.13.8-30
pve-kernel-4.13.13-5-pve: 4.13.13-38
pve-kernel-4.13.13-3-pve: 4.13.13-34
pve-kernel-4.13.13-1-pve: 4.13.13-31
libpve-http-server-perl: 2.0-8
lvm2: 2.02.168-pve6
corosync: 2.4.2-pve3
libqb0: 1.0.1-1
pve-cluster: 5.0-19
qemu-server: 5.0-20
pve-firmware: 2.0-3
libpve-common-perl: 5.0-25
libpve-guest-common-perl: 2.0-14
libpve-access-control: 5.0-7
libpve-storage-perl: 5.0-17
pve-libspice-server1: 0.12.8-3
vncterm: 1.5-3
pve-docs: 5.1-16
pve-qemu-kvm: 2.9.1-6
pve-container: 2.0-18
pve-firewall: 3.0-5
pve-ha-manager: 2.0-4
ksm-control-daemon: 1.2-2
glusterfs-client: 3.8.8-1
lxc-pve: 2.1.1-2
lxcfs: 2.0.8-1
criu: 2.11.1-1~bpo90
novnc-pve: 0.6-4
smartmontools: 6.5+svn4324-1
zfsutils-linux: 0.7.4-pve2~bpo9
libpve-apiclient-perl: 2.0-2

Let me know if you need anything else
 
It seems the bug was never fixed. I found a workaround which is to connect to the host, run a ping command to another machine by using lxc-attach which bring the network up. Here's the full command:

Code:
ssh proxmox-1 'sudo lxc-attach -n ct_id -- ping -c 10 any_server

Hopefully it can help others experiencing the same issue.
 
Could this be related to the Switch, where your PVE is connected and thus the container?
It is not uncommon to keep the arp and forwarding entries for quite long on those switches.

Does pinging the container from the PVE-host work?
 
Okay, looks like I was wrong about the PVE host being at fault here. The host can ping the container just fine, but other machines on the network (on the same switch as well as on different switches) cannot access the machine for a few minutes at most. Looks like the switch might be at fault after all, thanks for the hint!

I am using an Ubiquiti Unifi Switch 16-150W as my main switch, I'll see if I can find something that might help in the controller.

For now, the workaround posted by ca_maer does work as expected. I'm using Ansible, so I just run it as as local task before trying to reach the container