@Christian: both verify fine for me: $ dpkg -s libvirt-daemon-system | grep ^Version Version: 4.6.0-2ubuntu3.3~ppa1 $ sudo virsh nodedev-list | grep ^net net_enP2p1s0f1_40_8d_5c_b1_e4_44 net_enP2p1s0f2_40_8d_5c_b1_e4_45 net_enP2p1s0f3_40_8d_5c_b1_e4_46
$ dpkg -s libvirt-daemon-system | grep ^Version Version: 4.0.0-1ubuntu8.7~ppa1 $ sudo virsh nodedev-list | grep ^net net_enP2p1s0f1_42_ca_74_64_88_75 net_enP2p1s0f2_42_ca_74_64_88_76 net_enP2p1s0f3_42_ca_74_64_88_77 ** Description changed: [Impact] - * Libvirt has had the assumption that every VF (virtual function) will - have a PF (physical function) assigned, but that does not hold true on - some special Hardware like the Cavium ThunderX + * Libvirt has had the assumption that every VF (virtual function) will + have a PF (physical function) assigned, but that does not hold true on + some special Hardware like the Cavium ThunderX - * Dannf helped some patches initially from Linaro to be accepted upstream - and those we'd want to backport to Bionic and Cosmic + * Dannf helped some patches initially from Linaro to be accepted upstream + and those we'd want to backport to Bionic and Cosmic [Test Case] - * Use VF passthrough to a KVM guest on Cavium thunderX + * Verify that virsh nodedev-list shows the onboard NICs: + $ sudo virsh nodedev-list | grep ^net + net_enP2p1s0f1_42_ca_74_64_88_75 + net_enP2p1s0f2_42_ca_74_64_88_76 + net_enP2p1s0f3_42_ca_74_64_88_77 - * This needs plenty of setup and special HW, but Jason Hobbs & Dannf are - willing to do the verification in our test lab. + * This needs plenty of setup and special HW, but Jason Hobbs & Dannf are + willing to do the verification in our test lab. [Regression Potential] - * Review hasn't spotted any issues, but in theory there could be negative - effects to PF/VF pass-through cases. There is some code cleanup - associated that should not, but might cause issues on that. - I'd ask Jason to also run PF/VF workload on the PPA/SRU with other - Hardware as well (like our x86 test environment) to be sure of that - being ok. + * Review hasn't spotted any issues, but in theory there could be negative + effects to PF/VF pass-through cases. There is some code cleanup + associated that should not, but might cause issues on that. + I'd ask Jason to also run PF/VF workload on the PPA/SRU with other + Hardware as well (like our x86 test environment) to be sure of that + being ok. [Other Info] - - * n/a + + * n/a --- After deploying openstack on arm64 using bionic and queens, no hypervisors show upon. On my compute nodes, I have an error like: 2018-05-16 19:23:08.165 282170 ERROR nova.compute.manager libvirtError: Node device not found: no node device with matching name 'net_enP2p1s0f1_40_8d_5c_ba_b8_d2' In my /var/log/nova/nova-compute.log I'm not sure why this is happening - I don't use enP2p1s0f1 for anything. There are a lot of interesting messages about that interface in syslog: http://paste.ubuntu.com/p/8WT8NqCbCf/ Here is my bundle: http://paste.ubuntu.com/p/fWWs6r8Nr5/ The same bundle works fine for xenial-queens, with the source changed to the cloud-archive, and using stable charms rather than -next. I hit this same issue on bionic queens using either stable or next charms. This thread has some related info, I think: https://www.spinics.net/linux/fedora/libvir/msg160975.html This is with juju 2.4 beta 2. Package versions on affected system: http://paste.ubuntu.com/p/yfQH3KJzng/ -- 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: [bionic] 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
