6c6d93bc62
If we use fake reboot then domain goes thru running->shutdown->running state changes with shutdown state only for short period of time. At least this is implementation details leaking into API. And also there is one real case when this is not convinient. I'm doing a backup with the help of temporary block snapshot (with the help of qemu's API which is used in the newly created libvirt's backup API). If guest is shutdowned I want to continue to backup so I don't kill the process and domain is in shutdown state. Later when backup is finished I want to destroy qemu process. So I check if it is in shutdowned state and destroy it if it is. Now if instead of shutdown domain got fake reboot then I can destroy process in the middle of fake reboot process. After shutdown event we also get stop event and now as domain state is running it will be transitioned to paused state and back to running later. Though this is not critical for the described case I guess it is better not to leak these details to user too. So let's leave domain in running state on stop event if fake reboot is in process. Reconnection code handles this patch without modification. It detects that qemu is not running due to shutdown and then calls qemuProcessShutdownOrReboot which reboots as fake reboot flag is set. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Cole Robinson <crobinso@redhat.com> |
||
|---|---|---|
| .ctags.d | ||
| .gnulib@1f6fb368c0 | ||
| build-aux | ||
| ci | ||
| docs | ||
| examples | ||
| gnulib | ||
| include/libvirt | ||
| m4 | ||
| po | ||
| scripts | ||
| src | ||
| tests | ||
| tools | ||
| .color_coded.in | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .gitpublish | ||
| .mailmap | ||
| .travis.yml | ||
| .ycm_extra_conf.py.in | ||
| ABOUT-NLS | ||
| AUTHORS.in | ||
| autogen.sh | ||
| bootstrap | ||
| bootstrap.conf | ||
| ChangeLog | ||
| config-post.h | ||
| configure.ac | ||
| COPYING | ||
| COPYING.LESSER | ||
| gitdm.config | ||
| GNUmakefile | ||
| 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 | ||
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, however, we mandate to have the build directory different than the source directory. For example, to build in a manner that is suitable for installing as root, use:
$ mkdir build && cd build
$ ../configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make
$ sudo make install
While to build & install as an unprivileged user
$ mkdir build && cd build
$ ../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: