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
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
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.
libvirtError: Node device not found: no node device with matching name
To manage notifications about this bug go to:
ubuntu-bugs mailing list