4933445a18
Commit f10562799 introduced a regression: if reverting to a snapshot fails early (such as when we refuse to revert to an external snapshot), we lose track of the domain's current snapshot. Before that patch, we were tracking the notion of the domain's current snapshot via two means: vm->current_snapshot (which was left untouched on early exit) and snap->def->current (which only controls what gets written to XML to remember snapshots across libvirtd restarts). That patch was fixing a real bug: if a revert operation failed early, later questions from the same libvirtd did not see any change to the current snapsthot, but restarting libvirtd would now claim there is no current snapshot. But it fixed it in the wrong direction, in that the current snapshot was forgotten unconditionally, rather than only when the snapshot to revert to has a chance of being useful. It didn't help that the code after that patch had two separate spots clearing the old notion of the current snapshot - one after determining the snapshot to revert to was viable, the other unconditionally on all failure exit paths. At any rate, the fix is simple: drop the unconditional cleanup on error paths, and rely only on the normal cleanup after early checks. Sadly, it is not possible to test this bug in the existing tests/virsh-snapshot, as the test driver does not have the same prohibition against reverting to an external snapshot as the qemu driver. See: https://bugzilla.redhat.com/1738747 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190909205242.15406-1-eblake@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.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
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: