mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-24 14:45:24 +00:00
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.
08d42b52f1
Justin Clift reported a problem with adding virStoragePoolIsPersistent
to virsh's pool-info command, resulting in a strange problem. Here's
an example:
virsh # pool-create-as images_dir3 dir - - - - "/home/images2"
Pool images_dir3 created
virsh # pool-info images_dir3
Name: images_dir3
UUID: 90301885-94eb-4ca7-14c2-f30b25a29a36
State: running
Capacity: 395.20 GB
Allocation: 30.88 GB
Available: 364.33 GB
virsh # pool-destroy images_dir3
Pool images_dir3 destroyed
At this point the images_dir3 pool should be gone (because it was
transient) and we should be able to create a new pool with the same name:
virsh # pool-create-as images_dir3 dir - - - - "/home/images2"
Pool images_dir3 created
virsh # pool-info images_dir3
Name: images_dir3
UUID: 90301885-94eb-4ca7-14c2-f30b25a29a36
error: Storage pool not found
The new pool got the same UUID as the first one, but we didn't specify
one. libvirt should have picked a random UUID, but it didn't.
It turned out that virStoragePoolIsPersistent leaks a reference to the
storage pool object (actually remoteDispatchStoragePoolIsPersistent does).
As a result, pool-destroy doesn't remove the virStoragePool for the
"images_dir3" pool from the virConnectPtr's storagePools hash on libvirtd's
side. Then the second pool-create-as get's the stale virStoragePool object
associated with the "images_dir3" name. But this object has the old UUID.
This commit ensures that all get_nonnull_* and make_nonnull_* calls for
libvirt objects are matched properly with vir*Free calls. This fixes the
reference leaks and the reported problem.
All remoteDispatch*IsActive and remoteDispatch*IsPersistent functions were
affected. But also remoteDispatchDomainMigrateFinish2 was affected in the
success path. I wonder why that didn't surface earlier. Probably because
domainMigrateFinish2 is executed on the destination host and in the common
case this connection is opened especially for the migration and gets closed
after the migration is done. So there was no chance to run into a problem
because of the leaked reference.
|
||
|---|---|---|
| .gnulib@1629006348 | ||
| build-aux | ||
| daemon | ||
| docs | ||
| examples | ||
| include | ||
| m4 | ||
| po | ||
| proxy | ||
| python | ||
| src | ||
| tests | ||
| tools | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| .x-sc_avoid_ctype_macros | ||
| .x-sc_avoid_if_before_free | ||
| .x-sc_avoid_write | ||
| .x-sc_m4_quote_check | ||
| .x-sc_prohibit_always_true_header_tests | ||
| .x-sc_prohibit_asprintf | ||
| .x-sc_prohibit_gethostby | ||
| .x-sc_prohibit_gethostname | ||
| .x-sc_prohibit_gettext_noop | ||
| .x-sc_prohibit_have_config_h | ||
| .x-sc_prohibit_HAVE_MBRTOWC | ||
| .x-sc_prohibit_nonreentrant | ||
| .x-sc_prohibit_readlink | ||
| .x-sc_prohibit_strcmp | ||
| .x-sc_prohibit_strcmp_and_strncmp | ||
| .x-sc_prohibit_strncpy | ||
| .x-sc_prohibit_test_minus_ao | ||
| .x-sc_prohibit_VIR_ERR_NO_MEMORY | ||
| .x-sc_require_config_h | ||
| .x-sc_require_config_h_first | ||
| .x-sc_trailing_blank | ||
| .x-sc_unmarked_diagnostics | ||
| acinclude.m4 | ||
| AUTHORS | ||
| autobuild.sh | ||
| autogen.sh | ||
| bootstrap | ||
| bootstrap.conf | ||
| cfg.mk | ||
| ChangeLog-old | ||
| configure.ac | ||
| COPYING.LIB | ||
| HACKING | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| Makefile.am | ||
| Makefile.nonreentrant | ||
| mingw32-libvirt.spec.in | ||
| README | ||
| README-hacking | ||
| TODO | ||
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>