I tracked down why libvirt generates the message "internal error: The PF device for VF XXX has no network device name" on startup when built in bionic, but not in xenial. When populating device capabilities, we see:
However, virNetDevSwitchdevFeature() is stubbed out at build time unless HAVE_DECL_DEVLINK_CMD_ESWITCH_GET is defined. In bionic, this is defined in /usr/include/linux/devlink.h, which didn't exist in xenial.
Since all of our OpenStack/arm64 testing on bionic is blocked because our test systems all happen to be impacted by https://bugs.linaro.org/show_bug.cgi?id=3778 , I'm wondering if there's some kind of temporary hack we can carry to detect these devices, disable some set of (currently broken) features, and allow our testing to proceed until this problem is addressed upstream.
My understanding is that our testing succeeds with xenial, but fails with bionic, while the source version of libvirt remains constant. I therefore wonder if virNetDevSwitchdevFeature() is the (only) thing causing this to escalate to nova failure. In that case, could we e.g. compare vendor/device ids, and add a hack to return 0 if they match?
I've pushed a libvirt build to ppa:dannf/test with such a hack, if someone w/ a full arm64 openstack setup can try it to see if it would be able to unblock us.
I tracked down why libvirt generates the message "internal error: The PF device for VF XXX has no network device name" on startup when built in bionic, but not in xenial. When populating device capabilities, we see:
virNetDevGetFea tures() : chdevFeature( ): tPhysicalFuncti on()
virNetDevSwit
virNetDevGe
However, virNetDevSwitch devFeature( ) is stubbed out at build time unless HAVE_DECL_ DEVLINK_ CMD_ESWITCH_ GET is defined. In bionic, this is defined in /usr/include/ linux/devlink. h, which didn't exist in xenial.
Since all of our OpenStack/arm64 testing on bionic is blocked because our test systems all happen to be impacted by https:/ /bugs.linaro. org/show_ bug.cgi? id=3778 , I'm wondering if there's some kind of temporary hack we can carry to detect these devices, disable some set of (currently broken) features, and allow our testing to proceed until this problem is addressed upstream.
My understanding is that our testing succeeds with xenial, but fails with bionic, while the source version of libvirt remains constant. I therefore wonder if virNetDevSwitch devFeature( ) is the (only) thing causing this to escalate to nova failure. In that case, could we e.g. compare vendor/device ids, and add a hack to return 0 if they match?
I've pushed a libvirt build to ppa:dannf/test with such a hack, if someone w/ a full arm64 openstack setup can try it to see if it would be able to unblock us.