mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-02-22 11:22:23 +00:00
1f92aa454a
Chaining bitmaps for checkpoints (disabling the active one and creating a new) severely overcomplicated all operations in regards to bitmaps. Specifically it requires us re-matching the on-disk state to the internal metadata and in case of merging during block jobs it makes it almost impossible to cover all corner cases. Since the checkpoints and incremental backups were not yet enabled, let's change the design to keep one bitmap per checkpoint. In case of layered snapshots this will be filled in by using dirty-bitmap-populate. Finally the main reason for this unnecessary complexity was the fear that qemu's performance could degrade. In the end I think that addressing the performance issue will be better done in qemu (e.g by keeping an internal bitmap updated with changes and merging it periodically back to the real bitmaps. QEMU writes out changes to disk at shutdown so consistency is not a problem). Removing the relationships between bitmaps frees us from complex handling and also makes all the surrounding code more robust as one broken bitmap doesn't necessarily invalidate whole chains of backups. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
.. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
:target: https://gitlab.com/libvirt/libvirt/pipelines
:alt: GitLab CI Build Status
.. image:: https://travis-ci.org/libvirt/libvirt.svg
:target: https://travis-ci.org/libvirt/libvirt
:alt: Travis CI Build Status
.. image:: https://bestpractices.coreinfrastructure.org/projects/355/badge
:target: https://bestpractices.coreinfrastructure.org/projects/355
:alt: CII Best Practices
.. image:: https://translate.fedoraproject.org/widgets/libvirt/-/libvirt/svg-badge.svg
:target: https://translate.fedoraproject.org/engage/libvirt/
:alt: Translation status
==============================
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:
https://libvirt.org
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:
https://libvirt.org/contact.html