Working xcp-ng 8.2 system. Single host. Installed pool updates and rebooted host. Now there is no network traffic outside the host. Using iDrac I can connect to the Dell host and open the xcp-ng console. Network settings still appear normal. Shows all vm’s running. drop to local console and I can ping each vm and XO. I cannot ping the gateway or anything outside the host. I can not access XO or any vm from the rest of the network either.
eth0 and eth1 show connected but no IP address. Xenbr1 has the IP address of XO. What can I check next?
I would check to make sure there is not an issue with the switch they are connected to. Also I would recommend moving to version XCP-ng 8.3.
Thanks Tom. I hesitate to blame the switch as this has been a working system for a couple years. All I did was install the patches and reboot. I presume since I can remotely connect to the idrac (same switch) that it is fine?
I would check the port of the NIC that is not working.
I don’t know if this was the correct way but from the console I ran the Emergency Network reset, assigned the same IP to eth0 (it was showing up on xenbr before) and rebooted. Everything came up as it should. All running fine again. Not sure what happened that caused this but glad it is fixed. Thank you all.
My environment:
XCP-ng 8.2.1 (xcp-ng-8.2.1-20231130.iso ) clean install
interface-rename --list
Name MAC PCI ethN Phys SMBios Driver Version Firmware
eth0 44:a8:42:11:9e:38 0000:02:00.0[0] eth0 em1_1 Embedded NIC 1 tg3 3.137 FFV22.00.6 bc 5720-v1.39
eth1 44:a8:42:11:9e:39 0000:02:00.1[0] eth1 em2_1 Embedded NIC 2 tg3 3.137 FFV22.00.6 bc 5720-v1.39
eth2 44:a8:42:11:9e:3a 0000:03:00.0[0] eth2 em3_1 Embedded NIC 3 tg3 3.137 FFV22.00.6 bc 5720-v1.39
eth3 44:a8:42:11:9e:3b 0000:03:00.1[0] eth3 em4_1 Embedded NIC 4 tg3 3.137 FFV22.00.6 bc 5720-v1.39
eth4 98:b7:85:b7:e2:48 0000:06:00.0[0] eth4 p3p0_1 PCIe Slot 3 bnx2x 1.715.8 storm 7.13.18.0 7.13b.4.1c bc 7.13.75
eth5 98:b7:85:b7:e2:49 0000:06:00.1[0] eth5 p3p0_1 PCIe Slot 3 bnx2x 1.715.8 storm 7.13.18.0 7.13b.4.1c bc 7.13.75
eth6 a0:36:9f:91:c3:9c 0000:0e:00.0[0] eth6 p5p1 PCIe Slot 5 ixgbe 5.9.4 0x80000389, 1.1197.0
eth7 a0:36:9f:91:c3:9e 0000:0e:00.1[0] eth7 p5p2 PCIe Slot 5 ixgbe 5.9.4 0x80000389, 1.1197.0
I experienced the same issue and the only solution was to create a bond from two NICs for the management interface.
But before I noticed that after each reboot OVS port mappings on eth6 (my management NIC port) change ovs-appctl dpif/show which leads to management interface no longer able to communicate with outside.
I performed “emergency network reset” which auto rebooted server and port mapping for the management NIC restored to the same values as it was working before the corruption (however the other NIC mappings still got shuffled, but they were not configured) but with the next reboot I lost network again.
for example this is no bond output that cannot survive reboot:
ovs-appctl dpif/show
system@ovs-system: hit:8756 missed:1185
xenbr0:
eth0 1/4: (system)
xenbr0 65534/3: (internal)
xenbr1:
eth1 1/6: (system)
xenbr1 65534/5: (internal)
xenbr2:
eth2 1/10: (system)
xenbr2 65534/9: (internal)
xenbr3:
eth3 1/14: (system)
xenbr3 65534/13: (internal)
xenbr4:
eth4 1/16: (system)
xenbr4 65534/15: (internal)
xenbr5:
eth5 1/8: (system)
xenbr5 65534/7: (internal)
xenbr6:
eth6 1/2: (system)
xenbr6 65534/1: (internal)
xenbr7:
eth7 1/12: (system)
xenbr7 65534/11: (internal)
and this bonded output:
ovs-appctl dpif/show
system@ovs-system: hit:62643 missed:9715
xapi1:
eth6 1/12: (system)
eth7 2/13: (system)
xapi1 65534/11: (internal)
xenbr0:
eth0 1/15: (system)
xenbr0 65534/14: (internal)
xenbr1:
eth1 1/4: (system)
xenbr1 65534/3: (internal)
xenbr2:
eth2 1/6: (system)
xenbr2 65534/5: (internal)
xenbr3:
eth3 1/10: (system)
xenbr3 65534/9: (internal)
xenbr4:
eth4 1/8: (system)
xenbr4 65534/7: (internal)
xenbr5:
eth5 1/2: (system)
xenbr5 65534/1: (internal)
when the xapi interface is there - everything works after reboots.
I would also tripple-check @LTS_Tom 's switch concern:
I would check to make sure there is not an issue with the switch they are connected to
because another pair of XCP-ng 8.2.1 / 8.3.0 servers connected to another switch dont have this issue.