f62ce81b8a
When a QEMU netdev is of type "stream", if the socket it uses for connectivity to the host network gets closed, then QEMU will send a NETDEV_STREAM_DISCONNECTED event. We know that any stream netdev we've created is backed by a passt process, and if the socket was closed, that means the passt process has disappeared. When we receive this event, we can respond by starting a new passt process with the same options (including socket path) we originally used. If we have previously created the stream netdev device with a "reconnect" option, then QEMU will automatically reconnect to this new passt process. (If we hadn't used "reconnect", then QEMU will never try to reconnect to the new passt process, so there's no point in starting it.) Note that NETDEV_STREAM_DISCONNECTED is an event sent for the netdev (ie "host side") of the network device, and so it sends the "netdev-id" to specify which device was disconnected. But libvirt's virDomainNetDef (the object used to keep track of network devices) is the internal representation of both the host-side "netdev", and the guest side device, and virDomainNetDef doesn't directly keep track of the netdev-id, only of the device's "alias" (which is the "id" parameter of the *guest* side of the device). Fortunately, by convention libvirt always names the host-side of devices as "host" + alias, so in order to search for the affected NetDef, all we need to do is trim the 1st 4 characters from the netdev-id and look for the NetDef having that resulting trimmed string as its alias. (Contrast this to NIC_RX_FILTER_CHANGED, which is an event received for the guest side of the device, and so directly contains the device alias.) Resolves: https://bugzilla.redhat.com/2172098 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: