747116e0b9
The mlx4 (Mellanox) netdev driver implements the sysfs phys_port_id file for both VFs and PFs, so you can find the VF netdev plugged into the same physical port as any given PF netdev by comparing the contents of phys_port_id of the respective netdevs. That's what libvirt does when attempting to find the PF netdev for a given VF netdev (or vice versa). Most other netdev's drivers don't implement phys_port_id, so the file is visible in sysfs directory listing, but attempts to read it result in ENOTSUPP. In these cases, libvirt is unable to read phys_port_id of either the PF or the VF, so it just returns the first entry in the PF/VF's list of netdevs. But we've found that the i40e driver is in between those two situations - it implements phys_port_id for PF netdevs, but doesn't implement it for VF netdevs. So libvirt would successfully read the phys_port_id of the PF netdev, then try to find a VF netdev with matching phys_port_id, but would fail because phys_port_id is NULL for all VFs. This would result in a message like the following: Could not find network device with phys_port_id '3cfdfe9edc39' under PCI device at /sys/class/net/ens4f1/device/virtfn0 To solve this problem in a way that won't break functionality for anyone else, this patch saves the first netdev name we find for the device, and returns that if we fail to find a netdev with the desired phys_port_id. |
||
|---|---|---|
| .gnulib@8d116e3f65 | ||
| build-aux | ||
| daemon | ||
| docs | ||
| examples | ||
| gnulib | ||
| include/libvirt | ||
| m4 | ||
| po | ||
| src | ||
| tests | ||
| tools | ||
| .color_coded.in | ||
| .ctags | ||
| .dir-locals.el | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| .travis.yml | ||
| .ycm_extra_conf.py.in | ||
| AUTHORS.in | ||
| autogen.sh | ||
| bootstrap | ||
| bootstrap.conf | ||
| cfg.mk | ||
| ChangeLog-old | ||
| config-post.h | ||
| configure.ac | ||
| COPYING | ||
| COPYING.LESSER | ||
| libvirt-admin.pc.in | ||
| libvirt-lxc.pc.in | ||
| libvirt-qemu.pc.in | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| Makefile.am | ||
| Makefile.nonreentrant | ||
| mingw-libvirt.spec.in | ||
| README | ||
| README-hacking | ||
| README.md | ||
| run.in | ||
| TODO | ||
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.1 (or later). See the files COPYING.LESSER
and COPYING for full license terms & conditions.
Installation
Libvirt uses the GNU Autotools build system, so in general can be built and installed with the usual commands. For example, to build in a manner that is suitable for installing as root, use:
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make
$ sudo make install
While to build & install as an unprivileged user
$ ./configure --prefix=$HOME/usr
$ make
$ make install
The libvirt code relies on a large number of 3rd party libraries. These will
be detected during execution of the configure script and a summary printed
which lists any missing (optional) dependencies.
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: