71345f91d7
Commit 795e9e05c3 (libvirt-7.7.0) refactored the code in virpci.c and virnetdev.c that gathered lists of the Virtual Functions (VF) of an SRIOV Physical Function (PF) to simplify the code. Unfortunately the simplification made the assumption, in the new function virPCIGetVirtualFunctionsFull(), that a VF's netdev interface name should only be retrieved if the PF had a valid phys_port_id. That is an incorrect assumption - only a small handful of (now previous-generation) Mellanox SRIOV cards actually use phys_port_id (this is for an odd design where there are multiple physical network ports on a single PCI address); all other SRIOV cards (including new Mellanox cards) have a file in sysfs called phys_port_id, but it can't be read, and so the pfPhysPortID string is NULL. The result of this logic error is that virtual networks that are a pool of VFs to be used for macvtap connections will be unable to start, giving an errror like this: VF 0 of SRIOV PF enp130s0f0 couldn't be added to the interface pool because it isn't bound to a network driver - possibly in use elsewhere This error message is misinformed - the caller of virNetDevGetVirtualFunctionsFull() only *thinks* that the VF isn't bound to a network driver because it doesn't see a netdev name for the VF in the list. But that's only because virNetDevGetVirtualFunctionsFull() didn't even try to get the names! We do need a way for virPCIGetVirtualFunctionsFull() to sometimes retrieve the netdev names and sometimes not. One way of doing that would be to send down the netdev name of the PF whenever we also want to know the netdev names of the VFs, but send a NULL when we don't. This can conveniently be done by just *replacing* pfPhysPortID in the arglist with pfNetDevName - pfPhysPortID is determined by simply calling virNetDevGetPhysPortID(pfNetDevName) so we can just make that call down in virPCIGetVirtualFunctionsFull() (when needed). This solves the regression introduced by commit 795e9e05c3, and also nicely sets us up to (in a subsequent commit) move the call to virNetDevGetPhysPortID() down one layer further to virPCIGetNetName(), where it really belongs! Resolves: https://bugzilla.redhat.com/2025432 Fixes: 795e9e05c3b6b9ef3abe6f6078a6373a136ec23b Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Libvirt API for virtualization
Libvirt provides a portable, long term stable C API for managing the virtualization technologies provided by many operating systems. It includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER Hypervisor.
For some of these hypervisors, it provides a stateful management daemon which runs on the virtualization host allowing access to the API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other languages including Python, Perl, PHP, Go, Java, OCaml, as well as mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the website:
License
The libvirt C API is distributed under the terms of GNU Lesser
General Public License, version 2.1 (or later). Some parts of the code
that are not part of the C library may have the more restrictive GNU
General Public License, version 2.0 (or later). See the files
COPYING.LESSER and COPYING for full license
terms & conditions.
Installation
Instructions on building and installing libvirt can be found on the website:
https://libvirt.org/compiling.html
Contributing
The libvirt project welcomes contributions in many ways. For most components the best way to contribute is to send patches to the primary development mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
The libvirt project has two primary mailing lists:
- libvirt-users@redhat.com (for user discussions)
- libvir-list@redhat.com (for development only)
Further details on contacting the project are available on the website: