- Devel - libvirt List Archives

[libvirt] [PATCH 0/3] qemu_hotplug: dead code removal
by Ján Tomko 17 Dec '15

17 Dec '15

Originally posted as a part of https://www.redhat.com/archives/libvir-list/2015-August/msg00521.html Ján Tomko (3): qemu_hotplug: remove qemuDomainAttachDeviceControllerLive Remove dead code from qemuDomainAttachControllerDevice mark virDomainVirtioSerialAddrSetAddController as static. src/conf/domain_addr.c | 23 +---------------------- src/conf/domain_addr.h | 8 -------- src/libvirt_private.syms | 2 -- src/qemu/qemu_driver.c | 23 +---------------------- src/qemu/qemu_hotplug.c | 25 +++++++------------------ 5 files changed, 9 insertions(+), 72 deletions(-) -- 2.4.6

2 7

[libvirt] [PATCH v2] Allow building lxc without virt-login-shell
by Cédric Bosdonnat 17 Dec '15

17 Dec '15

Add a configure option to disable virt-login-shell build even if lxc is enabled. --- Diff to V1: * moved the configure.ac code into m4/virt-login-shell.m4 * allow building virt-login-shell without lxc * Introduce WITH_SETUID_RPC_CLIENT to have it built if either lxc or virt-login-shell is built. configure.ac | 9 +++++++++ m4/virt-login-shell.m4 | 27 +++++++++++++++++++++++++++ src/Makefile.am | 4 ++-- tools/Makefile.am | 12 ++++++------ 4 files changed, 44 insertions(+), 8 deletions(-) create mode 100644 m4/virt-login-shell.m4 diff --git a/configure.ac b/configure.ac index f481c50..6fef728 100644 --- a/configure.ac +++ b/configure.ac @@ -1075,6 +1075,14 @@ fi AM_CONDITIONAL([WITH_LXC], [test "$with_lxc" = "yes"]) dnl +dnl Check for virt-login-shell +dnl + +LIBVIRT_CHECK_LOGIN_SHELL + +AM_CONDITIONAL([WITH_SETUID_RPC_CLIENT], [test "$with_lxc$with_login_shell" != "nono"]) + +dnl dnl Checks for the Parallels driver dnl @@ -2974,6 +2982,7 @@ AC_MSG_NOTICE([ Init script: $with_init_script]) AC_MSG_NOTICE([Char device locks: $with_chrdev_lock_files]) AC_MSG_NOTICE([ Default Editor: $DEFAULT_EDITOR]) AC_MSG_NOTICE([ Loader/NVRAM: $with_loader_nvram]) +AC_MSG_NOTICE([ virt-login-shell: $with_login_shell]) AC_MSG_NOTICE([]) AC_MSG_NOTICE([Developer Tools]) AC_MSG_NOTICE([]) diff --git a/m4/virt-login-shell.m4 b/m4/virt-login-shell.m4 new file mode 100644 index 0000000..0701054 --- /dev/null +++ b/m4/virt-login-shell.m4 @@ -0,0 +1,27 @@ +dnl Copyright (c) 2015 SUSE LINUX Products GmbH, Nuernberg, Germany. +dnl +dnl This library is free software; you can redistribute it and/or +dnl modify it under the terms of the GNU Lesser General Public +dnl License as published by the Free Software Foundation; either +dnl version 2.1 of the License, or (at your option) any later version. +dnl +dnl This library is distributed in the hope that it will be useful, +dnl but WITHOUT ANY WARRANTY; without even the implied warranty of +dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +dnl Lesser General Public License for more details. +dnl +dnl You should have received a copy of the GNU Lesser General Public +dnl License along with this library. If not, see +dnl <http://www.gnu.org/licenses/>. + +AC_DEFUN([LIBVIRT_CHECK_LOGIN_SHELL], [ + AC_ARG_WITH([login_shell], + [AS_HELP_STRING([--with-login-shell], + [build virt-login-shell @<:@default=yes@:>@])]) + m4_divert_text([DEFAULTS], [with_login_shell=yes]) + + if test "$with_login_shell" ; then + AC_DEFINE_UNQUOTED([WITH_LOGIN_SHELL], 1, [whether virt-login-shell is built]) + fi + AM_CONDITIONAL([WITH_LOGIN_SHELL], [test "$with_login_shell" = "yes"]) +]) diff --git a/src/Makefile.am b/src/Makefile.am index 99b4993..2f40910 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -2225,7 +2225,7 @@ libvirt_lxc_la_LIBADD = libvirt.la $(CYGWIN_EXTRA_LIBADD) # have a RPC client for local UNIX socket access only. We use # the ../config-post.h header to disable all external deps that # we don't want -if WITH_LXC +if WITH_SETUID_RPC_CLIENT noinst_LTLIBRARIES += libvirt-setuid-rpc-client.la libvirt_setuid_rpc_client_la_SOURCES = \ @@ -2302,7 +2302,7 @@ libvirt_setuid_rpc_client_la_CFLAGS = \ $(SECDRIVER_CFLAGS) \ $(XDR_CFLAGS) \ $(NULL) -endif WITH_LXC +endif WITH_SETUID_RPC_CLIENT lockdriverdir = $(libdir)/libvirt/lock-driver lockdriver_LTLIBRARIES = diff --git a/tools/Makefile.am b/tools/Makefile.am index d5638d9..d005035 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -71,12 +71,12 @@ sbin_SCRIPTS = virt-sanlock-cleanup DISTCLEANFILES += virt-sanlock-cleanup endif WITH_SANLOCK -if WITH_LXC +if WITH_LOGIN_SHELL conf_DATA += virt-login-shell.conf bin_PROGRAMS += virt-login-shell -else ! WITH_LXC +else ! WITH_LOGIN_SHELL EXTRA_DIST += virt-login-shell.conf -endif ! WITH_LXC +endif ! WITH_LOGIN_SHELL dist_man1_MANS = \ @@ -84,11 +84,11 @@ dist_man1_MANS = \ virt-pki-validate.1 \ virt-xml-validate.1 \ virsh.1 -if WITH_LXC +if WITH_LOGIN_SHELL dist_man1_MANS += virt-login-shell.1 -else ! WITH_LXC +else ! WITH_LOGIN_SHELL EXTRA_DIST += virt-login-shell.1 -endif ! WITH_LXC +endif ! WITH_LOGIN_SHELL if WITH_SANLOCK dist_man8_MANS = virt-sanlock-cleanup.8 endif WITH_SANLOCK -- 2.1.4

2 1

[libvirt] [PATCH] schema: interleave domain name and uuid with other elements
by Ján Tomko 17 Dec '15

17 Dec '15

Allow <name> and <uuid> anywhere under <domain>, not just at the top: error:XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Expecting an element name, got nothing Invalid sequence in interleave Element domain failed to validate content Introduced with the first RelaxNG schema in commit c642103. https://bugzilla.redhat.com/show_bug.cgi?id=1292131 --- docs/schemas/domaincommon.rng | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 4804c69..01d99f0 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -30,8 +30,8 @@ <define name="domain"> <element name="domain"> <ref name="hvs"/> - <ref name="ids"/> <interleave> + <ref name="ids"/> <optional> <ref name="title"/> </optional> -- 2.4.6

3 3

[libvirt] [PATCH] qemu: Fix event generated for qemuDomainRevertToSnapshot (pause->run)
by John Ferlan 17 Dec '15

17 Dec '15

A closer review of the code shows that for the transition from paused to running which was supposed to emit the VIR_DOMAIN_EVENT_RESUMED - no event would be generated. Rather the event is generated when going from running to running. Following the 'was_running' boolean shows it is set when the domain obj is active and the domain obj state is VIR_DOMAIN_RUNNING. So rather than using was_running to generate the RESUMED event, use !was_running Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- I hope I've read the bread crumbs in the code correctly regarding state transitions! Saw this while reviewing something else: http://www.redhat.com/archives/libvir-list/2015-December/msg00330.html src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 783a7cd..deeffc1 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15549,7 +15549,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, event = virDomainEventLifecycleNewFromObj(vm, VIR_DOMAIN_EVENT_STARTED, detail); - } else if (was_running) { + } else if (!was_running) { /* Transition 8 */ detail = VIR_DOMAIN_EVENT_RESUMED; event = virDomainEventLifecycleNewFromObj(vm, -- 2.5.0

2 2

[libvirt] [PATCH] storage: Fix startup issue for logical pool
by John Ferlan 17 Dec '15

17 Dec '15

Commit id '71b803ac' assumed that the storage pool source device path was required for a 'logical' pool. This resulted in a failure to start a pool without any device path defined. So, adjust the virStorageBackendLogicalMatchPoolSource logic to return success if at least the pool name matches the vgs output when no pool source device path is/are provided. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/storage/storage_backend_logical.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index c52782f..f59684a 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -541,6 +541,15 @@ virStorageBackendLogicalMatchPoolSource(virStoragePoolObjPtr pool) goto cleanup; } + /* If the pool has defined source device(s), then let's make sure + * they match as well; otherwise, matching can only occur on the + * pool's name. + */ + if (!pool->def->source.ndevice) { + ret = true; + goto cleanup; + } + /* Let's make sure the pool's device(s) match what the pvs output has * for volume group devices. */ -- 2.5.0

2 1

[libvirt] [PATCH v2] storage: Attempt to refresh volume after successful wipe volume
by John Ferlan 17 Dec '15

17 Dec '15

https://bugzilla.redhat.com/show_bug.cgi?id=1270709 When a volume wipe is successful, perform a volume refresh afterwards to update any volume data that may be used in future volume commands, such as volume resize. For a raw file volume, a wipe could truncate the file and a followup volume resize the capacity may fail because the volume target allocation isn't updated to reflect the wipe activity. Since the documentation doesn't mention this side effect of the zero algorithm for a raw file volume, update the various documentation to describe the results. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: http://www.redhat.com/archives/libvir-list/2015-December/msg00085.html Changes since v1: * Use the preferred call format from review * Cause error if refreshVol fails * Add wording to docs regarding zero wipe algorithm and truncating the raw file. src/libvirt-storage.c | 9 +++++++-- src/storage/storage_driver.c | 9 ++++++++- tools/virsh.pod | 5 +++++ 3 files changed, 20 insertions(+), 3 deletions(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 66dd9f0..62bb999 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1725,7 +1725,9 @@ virStorageVolDelete(virStorageVolPtr vol, * @vol: pointer to storage volume * @flags: extra flags; not used yet, so callers should always pass 0 * - * Ensure data previously on a volume is not accessible to future reads + * Ensure data previously on a volume is not accessible to future reads. + * Use of this function is equivalent to calling virStorageVolWipePattern + * with the VIR_STORAGE_VOL_WIPE_ALG_ZERO for the algorithm. * * Returns 0 on success, or -1 on error */ @@ -1766,7 +1768,10 @@ virStorageVolWipe(virStorageVolPtr vol, * @flags: future flags, use 0 for now * * Similar to virStorageVolWipe, but one can choose - * between different wiping algorithms. + * between different wiping algorithms. When choosing the + * zero algorithm (VIR_STORAGE_VOL_WIPE_ALG_ZERO), it is + * possible the target storage backend will truncate the + * file rather than writing a stream of zeroes. * * Returns 0 on success, or -1 on error. */ diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index bbf21f6..2531a88 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2436,7 +2436,14 @@ storageVolWipePattern(virStorageVolPtr obj, goto cleanup; } - ret = backend->wipeVol(obj->conn, pool, vol, algorithm, flags); + if (backend->wipeVol(obj->conn, pool, vol, algorithm, flags) < 0) + goto cleanup; + + if (backend->refreshVol && + backend->refreshVol(obj->conn, pool, vol) < 0) + goto cleanup; + + ret = 0; cleanup: virStoragePoolObjUnlock(pool); diff --git a/tools/virsh.pod b/tools/virsh.pod index 21ae4a3..7f6dc8d 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -3509,6 +3509,11 @@ B<Supported algorithms> B<Note>: The availability of algorithms may be limited by the version of the C<scrub> binary installed on the host. +B<Note>: Use of the zero algorithm for some storage backends may result +in the truncation of the target file instead of writing all zeroes to the +file. The Storage Driver will refresh the volume allocation and capacity +after successful volume wipe completion. + =item B<vol-dumpxml> [I<--pool> I<pool-or-uuid>] I<vol-name-or-key-or-path> Output the volume information as an XML dump to stdout. -- 2.5.0

4 6

[libvirt] [PATCH 0/5] virStorageBackendWipeLocal cleanups
by Ján Tomko 17 Dec '15

17 Dec '15

The first patch fixes the return values of virStorageWipe on non-sparse local files in the case of a partial wipe or a fdatasync error. The rest reduces the number of parameters of virStorageBackendWipe{Extent,}Local. Ján Tomko (5): storage: fix return values of virStorageBackendWipeExtentLocal storage: move buffer allocation inside virStorageBackendWipeExtentLocal storage: drop 'Extent' from virStorageBackendWipeExtentLocal virStorageBackendWipeLocal: use unsigned long long instead of off_t virStorageBackendWipeLocal: remove bytes_wiped argument src/storage/storage_backend.c | 53 +++++++++++++++++-------------------------- 1 file changed, 21 insertions(+), 32 deletions(-) -- 2.4.6

2 8

[libvirt] [PATCH v2 0/7] Memory locking limit improvements
by Andrea Bolognani 17 Dec '15

17 Dec '15

During my testing, I've realized that even with the series applied there's still one case in which we're unable to restore the previous memory locking limit after removing the last PCI hostdev from the guest. If an x86 guest contains a PCI hostdev in its XML definition, then the memory locking limit will be set correctly, but virCommandGetMaxMemLock() will be used instead of virProcessGetMaxMemLock(), and the limit will be set right before calling exec() to spawn the qemu binary. In this context, we have no access to the virDomainObj or even virDomainDef instances, so I see no way of storing the original limit for later retrieval. The series is still an improvement as it covers all other cases. Still, I thought this was worth mentioning. Changes since v1[1]: * reorder commits according to John's suggestions * don't fail if we can't retrieve the current memory locking limit * small changes here and there as pointed out during review Cheers. [1] https://www.redhat.com/archives/libvir-list/2015-November/msg01021.html Andrea Bolognani (7): process: Allow virProcessPrLimit() to get current limit process: Add virProcessGetMaxMemLock() qemu: Add qemuDomainAdjustMaxMemLock() qemu: Use qemuDomainAdjustMaxMemLock() qemu: Reduce memlock limit after detaching PCI hostdev qemu: Allow qemuDomainAdjustMaxMemLock() to restore previous value qemu: Replace Mlock with MemLock in function names configure.ac | 2 +- src/conf/domain_conf.h | 3 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 4 ++-- src/qemu/qemu_domain.c | 53 ++++++++++++++++++++++++++++++++++++++--- src/qemu/qemu_domain.h | 5 ++-- src/qemu/qemu_hotplug.c | 45 ++++++++++++++--------------------- src/util/virprocess.c | 61 +++++++++++++++++++++++++++++++++++++++++++----- src/util/virprocess.h | 2 ++ 9 files changed, 135 insertions(+), 41 deletions(-) -- 2.5.0

2 9

[libvirt] [PATCH] build: disable vbox on cygwin
by Eric Blake 17 Dec '15

17 Dec '15

Cygwin cannot build the vbox driver yet: CC vbox/libvirt_driver_vbox_impl_la-vbox_glue.lo In file included from vbox/vbox_glue.c:27:0: vblox/vbox_XPCOMCGlue.c:63:3: error: #error "Port me" # error "Port me" ^ In file included from vbox/vbox_XPCOMCGlue.c:45:0, from vbox/vbox_glue.c:27: vbox/vbox_XPCOMCGlue.c: In function 'tryLoadOne': vbox/vbox_XPCOMCGlue.c:98:46: error: 'DYNLIB_NAME' undeclared (first use in this function) if (virAsprintf(&name, "%s/%s", dir, DYNLIB_NAME) < 0) ^ ./util/virstring.h:245:31: note: in definition of macro 'virAsprintf' strp, __VA_ARGS__) ^ Rather than trying to figure out how to get dynamic loading of vbox to work under cygwin (since I don't even have a working vbox setup to test whether it works), I'm going to be lazy and just default to not even trying vbox on cygwin. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Not technically a build-breaker, since I can './configure --without-vbox' to work around it, so I'll wait for a review. configure.ac | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 75e95b7..2c34333 100644 --- a/configure.ac +++ b/configure.ac @@ -175,12 +175,13 @@ dnl are also linux specific. The "network" and storage_fs drivers are known dnl to not work on MacOS X presently, so we also make a note if compiling dnl for that -with_linux=no with_osx=no with_freebsd=no +with_linux=no with_osx=no with_freebsd=no with_win=no with_cygwin=no case $host in *-*-linux*) with_linux=yes ;; *-*-darwin*) with_osx=yes ;; *-*-freebsd*) with_freebsd=yes ;; *-*-mingw* | *-*-msvc* ) with_win=yes ;; + *-*-cygwin*) with_cygwin=yes ;; esac if test $with_linux = no; then @@ -192,9 +193,12 @@ if test $with_linux = no; then fi if test $with_freebsd = yes; then - want_ifconfig=yes + want_ifconfig=yes + with_firewalld=no +fi - with_firewalld=no +if test $with_cygwin = yes; then + with_vbox=no fi AM_CONDITIONAL([WITH_LINUX], [test "$with_linux" = "yes"]) -- 2.4.3

2 2

[libvirt] LSN-2015-0004: CVE-2015-5313: ACL bypass using ../ to access beyond storage pool
by Eric Blake 16 Dec '15

16 Dec '15

Libvirt Security Notice: LSN-2015-0004 ====================================== Summary: ACL bypass using ../ to access beyond storage pool Reported on: 20151030 Published on: 20151211 Fixed on: 20151211 Reported by: Ossi Herrala <vulncoord(a)ficora.fi> Joonas Kuorilehto <vulncoord(a)ficora.fi> Patched by: Eric Blake <eblake(a)redhat.com> See also: CVE-2015-5313, FICORA bug #876194 Description ----------- Various virStorageVol* API operate on user-supplied volume names by concatenating the volume name to the pool location. Note that the virStoragePoolListVolumes API, when used on a storage pool backed by a directory in a file system, will only list volumes immediately in that directory (there is no traversal into subdirectories). However, other APIs such as virStorageVolCreateXML were not checking if a potential volume name represented one of the volumes that could be returned by virStoragePoolListVolumes; because they were not rejecting the use of '/' in a volume name. Impact ------ Because no checking was done on volume names, a user could supply a potential volume name of something like '../../../etc/passwd' to attempt to access a file not belonging to the storage pool. When fine-grained Access Control Lists (ACL) are in effect, a user with storage_vol:create ACL permission but lacking domain:write permssion could thus abuse virStorageVolCreateXML and similar APIs to gain access to files not normally permitted to that user. Fortunately, it appears that the only APIs that could leak information or corrupt files require read-write connection to libvirtd; and when ACLs are not in use (the default without any further configuration), a user with read-write access can already be considered to have full access to the machine, and without an escalation of privilege there is no security problem. Workaround ---------- If fine-grained ACLs must be used, administrators must consider all of the storage_vol:* permissions as equivalent to domain:write when running an impacted version of libvirt. The easiest way to prevent untrusted users from gaining unauthorized access to volumes outside of permitted pools is by disabling the use of fine-graned ACLs, and ensuring that such users do not have read-write access to libvirtd. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v1.1.0 Broken in: v1.1.1 Broken in: v1.1.2 Broken in: v1.1.3 Broken in: v1.1.4 Broken in: v1.2.0 Broken in: v1.2.1 Broken in: v1.2.2 Broken in: v1.2.3 Broken in: v1.2.4 Broken in: v1.2.5 Broken in: v1.2.6 Broken in: v1.2.7 Broken in: v1.2.8 Broken in: v1.2.9 Broken in: v1.2.10 Broken in: v1.2.11 Broken in: v1.2.12 Broken in: v1.2.13 Broken in: v1.2.14 Broken in: v1.2.15 Broken in: v1.2.16 Broken in: v1.2.17 Broken in: v1.2.18 Broken in: v1.2.19 Broken in: v1.2.20 Broken in: v1.2.20 Broken in: v1.3.0 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 034e47c338b13a95cf02106a3af912c1c5f818d7 Branch: v1.1.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 14828a59eadc7221326198a8d7af817a6b8b8c13 Branch: v1.1.1-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 692ce509efa0a07f2811d0fe3b7202b020c874e0 Branch: v1.1.2-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: e8643ef68c99e9f5068f6ff64ea0acab94cac7f6 Branch: v1.1.3-maint Broken in: v1.1.3.1 Broken in: v1.1.3.2 Broken in: v1.1.3.3 Broken in: v1.1.3.4 Broken in: v1.1.3.5 Broken in: v1.1.3.6 Broken in: v1.1.3.7 Broken in: v1.1.3.8 Broken in: v1.1.3.9 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: dcce665904b8ebc9ac3e5109db179a567b33e1a2 Branch: v1.1.4-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: dc2db111a9ba074589c54b90c89f33c01b1e4941 Branch: v1.2.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: d414ecb8e1714704e6515ab01ef9386d89b8051e Branch: v1.2.1-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 02d365dae595a3453fe0e438bc274ccf3c18e20d Branch: v1.2.2-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6542e643024ca4272f14e9052b3786378f6eec62 Branch: v1.2.3-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 91898c606496b14e0891af31dfca7eb77ba9fee3 Branch: v1.2.4-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: c9450f4f855736ef3024dfbab403a849110d8bb5 Branch: v1.2.5-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 890fc0f1ffcc479b08b9fd01de31b62e3d9e7427 Branch: v1.2.6-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6ae433938377e1b7e657c34cca39e52426347cb4 Branch: v1.2.7-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 4ed8074672f9b847a10464d9c6be77d428c1eb1c Branch: v1.2.8-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 54be99a717873524798d39f8baf49e45054192c8 Branch: v1.2.9-maint Broken in: v1.2.9.1 Broken in: v1.2.9.2 Broken in: v1.2.9.3 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b0f88836e5eb5b7156bda99c005cf4aa0456ed0d Branch: v1.2.10-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 53ae31bf4df364a2110f636d5482b21af4e4a0cc Branch: v1.2.11-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 0060c4ee9e70a9f6f297373cb4fd2ace6c187be0 Branch: v1.2.12-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b5ddfbc0fe13a7910c2303056ddd5df749bcf8b0 Branch: v1.2.13-maint Broken in: v1.2.13.1 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b553ec764f7ecdf8962efbf849a0e8524bae610c Branch: v1.2.14-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6410a22743fadc3b554b2f0866c9ab8008ff4908 Branch: v1.2.15-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 01cbfeb7d81498db3c644404980c9c1aa9cac048 Branch: v1.2.16-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 3e6b40e5aa3edf47443f017a42ec7b87855ed847 Branch: v1.2.17-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 08acad56ce2e5bcfcca8600a4e4074d3aaeb44dd Branch: v1.2.18-maint Broken in: v1.2.18.1 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: d035796675ca42795953828d11f902f691fa6b29 Branch: v1.2.19-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 69548d200409d2b0dd6356fccfd59570fb58e23a Branch: v1.2.20-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: edeef640db625d23700011dc94adff6e29b85cd3 Branch: v1.2.21-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 29b4ce46798519b93a6a17a5e3734ea4f68ea69d Branch: v1.3.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 1d8bcbb7c68d3f35689daf727bc74fcf80a3a6b1 -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0