Thanks for the logs. I generally don't see anything *fatal* to libvirt. In the nova logs, I can see that virsh capabilities returns host information. It certainly is failing to find the VFs on the SRIOV device; it's not clear if that's because the device is misbehaving (we can see the kernel events indicating the driver is being reset, enP2p1s0f1 renamed eth0, eth0 renamed to enP2p1s0f1 which can only happen if the driver has been reset) or if the probing of device's PCI address space is triggering a reset.
Note that netplan has no skin in this game; it applies a DHCP and DNS config to enP2p1s0f3 which stays up the whole time, juju even bridges en..f3 etc. The other interfaces found during boot are set to "manual" config; that is netplan writes a .link file for setting the name, but note that the name is the predictable name it gets from the default udev policy anyhow. At this point, we can compare the logs to Xenial, but I think the next step is back to the charms/nova-compute to determine how a node reports back to openstack that a compute node is ready. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1771662 Title: libvirtError: Node device not found: no node device with matching name To manage notifications about this bug go to: https://bugs.launchpad.net/charm-nova-compute/+bug/1771662/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
