January 2014 - Devel - libvirt List Archives

[libvirt] New feature discussion: Grouping multiple libvirt's in a "pool"
by Ahmed Ossama 10 Jan '14

10 Jan '14

Greetings All, I would like to say "Hi" to everyone on the list since this is my first message. I have couple of servers running CentOS and Debian with kvm and libvirt on top. Lately I've been thinking of coordinating them together in a pool like XenServer groups servers in a "Pool". I am totally aware that this feature can be achieved by installing OpenStack or any similar orchestrator on top of libvirt. But I would like to achieve this feature using libvirt alone as I don't want to install any stuff above libvirt. I was also thinking if each libvirt on every server is aware of other resources (Domains, Storage and Network), this could provide better support and view to any higher orchestrator utilizing libvirt. So I am wondering if such feature was discussed previously? And would like to hear thoughts or concerns about it. -- Regards, Ahmed Ossama

2 1

[libvirt] [PATCH] qemu: Add support for changing timeout value to open unix monitor socket
by Pavel Fux 10 Jan '14

10 Jan '14

Hi, I am talking about *Bug 987088*<https://bugzilla.redhat.com/show_bug.cgi?id=987088>, I have added a patch and a description of the fix, this is a copy of my comment on the bug: the default code behavior is wait for 3 seconds and if the socket is not opened yet, print this error and terminate. the code is in src/qemu/qemu_monitor.c in function qemuMonitorOpenUnix. In 2009 there was a patch that added the original 3 seconds retry, the patch can be found here: http://www.redhat.com/archives/libvir-list/2009-July/msg00335.html I have added a patch with this solution: the default behavior stays the same, but a user can add a configuration variable to qemu.conf and change the timeout value. every system needs a different value according to their system configuration but anyway 3 seconds is not suitable for all cases. I am attaching my patch. Pavel Fux.

3 2

[libvirt] [PATCH 0/2] v2: spice: expose the disable file transfer option
by Francesco Romani 10 Jan '14

10 Jan '14

Here it is the second version of the patch which export the spice agent disable file transfer. I followed Eric's advice and added detection of the support in QEMU in the first patch; the second builds upon the first and exports the support to libvirt. The XML format is intentionally similar to the 'clipboard' element, I thought the share enough similiarities; however, suggestions are more than welcome here. Please also feel free to suggest how to extend the testing, and if what was added here is enough. As everyone probably already noticed it's my first libvirt contribution; I tried to follow HACKING's advice caredully but I can have missed something (more). Best regards, Francesco Romani (2): spice: detect if qemu can disable file transfer spice: expose the QEMU disable file transfer option docs/formatdomain.html.in | 8 +++++ docs/schemas/domaincommon.rng | 11 ++++++ src/conf/domain_conf.c | 31 ++++++++++++++++- src/conf/domain_conf.h | 10 ++++++ src/libvirt_private.syms | 2 ++ src/qemu/qemu_capabilities.c | 5 ++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 9 +++++ tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 1 + ...emuxml2argv-graphics-spice-agent-file-xfer.args | 9 +++++ ...qemuxml2argv-graphics-spice-agent-file-xfer.xml | 40 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 6 ++++ 13 files changed, 132 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-graphics-spice-agent-file-xfer.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-graphics-spice-agent-file-xfer.xml -- 1.8.4.2

2 7

[libvirt] [PATCH] Clarify documentation on possible return values in case of errors
by Claudio Bley 10 Jan '14

10 Jan '14

Signed-off-by: Claudio Bley <cbley(a)av-test.de> --- src/libvirt.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index ffd4f8e..73972f2 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -14502,8 +14502,8 @@ virNodeDeviceGetName(virNodeDevicePtr dev) * * Accessor for the parent of the device * - * Returns the name of the device's parent, or NULL if the - * device has no parent. + * Returns the name of the device's parent, or NULL if an + * error occurred or when the device has no parent. */ const char * virNodeDeviceGetParent(virNodeDevicePtr dev) @@ -14537,7 +14537,8 @@ virNodeDeviceGetParent(virNodeDevicePtr dev) * * Accessor for the number of capabilities supported by the device. * - * Returns the number of capabilities supported by the device. + * Returns the number of capabilities supported by the device or -1 + * in case of error. */ int virNodeDeviceNumOfCaps(virNodeDevicePtr dev) @@ -14576,7 +14577,8 @@ error: * * Lists the names of the capabilities supported by the device. * - * Returns the number of capability names listed in @names. + * Returns the number of capability names listed in @names or -1 + * in case of error. */ int virNodeDeviceListCaps(virNodeDevicePtr dev, -- 1.7.9.5

3 4

[libvirt] /var/lib/libvirt/qemu permissions are wrong
by Marcelo Cerri 10 Jan '14

10 Jan '14

Hi, Any directions regarding which is the best approach to correct the bug reported in https://bugzilla.redhat.com/show_bug.cgi?id=1045040 ? Regards, Marcelo

2 3

[libvirt] [PATCH] event: don't queue NULL event on OOM
by Eric Blake 09 Jan '14

09 Jan '14

Ever since commit 61ac8ce, Coverity complained about remoteNetworkBuildEventLifecycle not checking for NULL failure to build an event, compared to other calls in the code base. But the problem is latent from copy and paste; all 17 of our remote*BuildEvent* functions in remote_driver.c have the same issue - if an OOM causes an event to not be built, we happily pass NULL to remoteEventQueue(), but that function has marked event as a nonnull parameter. We were getting lucky (the event queue's first use of the event happened to be a call to virIsObjectClass(), which acts gracefully on NULL, so there was no way to crash); but this is a latent bug waiting to bite us due to the disregard for the nonnull attribute, as well as a waste of resources in the event queue. Better is to just refuse to queue NULL. The discard is silent, since the problem only happens on OOM, and since events are already best effort - if we fail to get an event, it's not like we have any memory left to report the issue, nor any idea of who would benefit from knowing we couldn't create or queue the event. * src/remote/remote_driver.c (remoteEventQueue): Ignore NULL event. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- I don't know if this will actually shut up Coverity, or if we have to modify all 17 calls to remoteEventQueue to do the NULL check there. I'm hoping this simpler solution does the trick. src/remote/remote_driver.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 64d9d92..da9c1c9 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -6801,7 +6801,8 @@ done: static void remoteEventQueue(struct private_data *priv, virObjectEventPtr event) { - virObjectEventStateQueue(priv->eventState, event); + if (event) + virObjectEventStateQueue(priv->eventState, event); } /* get_nonnull_domain and get_nonnull_network turn an on-wire -- 1.8.4.2

2 2

[libvirt] [PATCH v4 0/7] Network events API
by Cédric Bosdonnat 09 Jan '14

09 Jan '14

This patch serie include changes to respond to Eric and Daniel's comments. The event namespace part of the ID is only handled at the object event's level, though we need to strip it out of virObjectEventStateEventID to get the remote driver properly deregister. Cédric Bosdonnat (7): Added Network events API and virNetworkEventLifecycle. test driver: implemented network events Add network events unit tests Add network events to the remote driver Added network events to the bridged network driver Fixed indentation in src/conf/*_event* Added default case with error for object event dispatching daemon/libvirtd.h | 1 + daemon/remote.c | 139 +++++++++++++++++ include/libvirt/libvirt.h.in | 80 ++++++++++ src/Makefile.am | 5 + src/conf/domain_event.c | 286 ++++++++++++++++++++--------------- src/conf/domain_event.h | 271 +++++++++++++++++++-------------- src/conf/network_event.c | 154 +++++++++++++++++++ src/conf/network_event.h | 51 +++++++ src/conf/object_event.c | 50 +++--- src/conf/object_event.h | 1 + src/conf/object_event_private.h | 20 ++- src/driver.h | 14 ++ src/libvirt.c | 125 +++++++++++++++ src/libvirt_private.syms | 2 + src/libvirt_public.syms | 7 + src/network/bridge_driver.c | 90 +++++++++++ src/network/bridge_driver_platform.h | 3 + src/remote/remote_driver.c | 127 ++++++++++++++++ src/remote/remote_protocol.x | 46 +++++- src/test/test_driver.c | 62 ++++++++ tests/objecteventtest.c | 167 ++++++++++++++++++++ 21 files changed, 1444 insertions(+), 257 deletions(-) create mode 100644 src/conf/network_event.c create mode 100644 src/conf/network_event.h -- 1.8.4.4

5 19

[libvirt] [PATCHv2 0/7] lxc: honor mount namespaces
by Eric Blake 09 Jan '14

09 Jan '14

We are still awaiting a CVE number to be assigned, but Reco reported in Debian bug #732394 that a malicious guest could cause virDomainShutdown and virDomainReboot to cause the host to misbehave, if the host blindly follows symlinks in its own mount namespace instead of the guest's namespace. I have not yet tried to patch the bugs in virDomainDeviceAttach dereferencing /dev from the wrong namespace, which also suffers from the same vulnerability, but virProcessRunInMountNamespace should also be usable in that situation. While working on this series, I found several issues with virFork and virt-login-shell; since those are also related to correct namespace usage, I've bundled everything into one series; but the CVE is not fixed until patch 7/7 plus the future patch to /dev. I've done some pretty decent testing on the new virt-login-shell, but did not get as much testing on virDomainReboot. Since this series does address a CVE, and also regressions caused by our previous CVE fix in the same area of code (CVE-2013-4400 is unfortunately a poor example of shipping "fixes" without testing that the code still worked), I'd definitely appreciate a close review. Patch 6/7 is interesting: it uses virFork to use the mount namespace without impacting the parent process. However, since setns() is thread-safe, I wonder if it would be simpler to instead use pthread_create to do the callback within the same process instead of having to create a separate process, as that would make for easier coordination for passing the results back to the remaining threads that have not changed namespace. Thankfully, I think we came up with a good abstraction - I'm fairly confident that 6/7 could be rewritten to use pthread_create without changing the function signatures, in which case patch 7/7 would not need any changes to pick up the changed backend. Eric Blake (7): virt-login-shell: fix regressions in behavior virFork: simplify semantics virt-login-shell: use single instead of double fork virt-login-shell: saner exit value virsh: report exit status of failed lxc-enter-namespace lxc: add virProcessRunInMountNamespace lxc: security fix for virInitctlSetRunLevel src/internal.h | 7 +++ src/libvirt.c | 2 +- src/libvirt_private.syms | 1 + src/lxc/lxc_driver.c | 38 ++++++------ src/util/vircommand.c | 128 +++++++++++++++----------------------- src/util/vircommand.h | 2 +- src/util/virfile.c | 25 ++------ src/util/virinitctl.c | 28 ++++----- src/util/virinitctl.h | 5 +- src/util/virprocess.c | 81 ++++++++++++++++++++++-- src/util/virprocess.h | 11 ++++ tools/virsh-domain.c | 34 ++++++---- tools/virsh.pod | 3 +- tools/virt-login-shell.c | 151 ++++++++++++++++++++------------------------- tools/virt-login-shell.pod | 23 ++++++- 15 files changed, 299 insertions(+), 240 deletions(-) -- 1.8.4.2

4 18

[libvirt] [PATCH 00/24] libvirt.c error handling audit
by Eric Blake 09 Jan '14

09 Jan '14

This series is in response to: https://www.redhat.com/archives/libvir-list/2013-December/msg01101.html It turned into a much bigger cleanup project, where I ended up with a lot of changes; hopefully the division into multiple patches makes review easier, and the end result diffstat shows that the code base is more compact when all is said and done. Eric Blake (24): maint: consistent formatting in libvirt.c maint: improve debug of libvirt-{qemu,lxc} apis maint: move debug statements first in public API maint: improve error condition style in public API maint: don't leave garbage on early API exit maint: reset error on entrance to public API maint: avoid nested public calls maint: improve VIR_ERR_NO_SUPPORT usage maint: improve VIR_ERR_OPERATION_DENIED usage maint: improve VIR_ERR_INVALID_CONN usage maint: inline VIR_IS_CONNECT macro maint: improve VIR_ERR_INVALID_DOMAIN usage maint: inline VIR_IS*_DOMAIN macro maint: improve VIR_ERR_INVALID_NETWORK usage maint: improve VIR_ERR_INVALID_INTERFACE usage maint: improve VIR_ERR_INVALID_STORAGE_POOL usage maint: improve VIR_ERR_INVALID_STORAGE_VOL usage maint: improve VIR_ERR_INVALID_NODE_DEVICE usage maint: improve VIR_ERR_INVALID_SECRET usage maint: improve VIR_ERR_INVALID_STREAM usage maint: improve VIR_ERR_INVALID_NWFILTER usage maint: improve VIR_ERR_INVALID_DOMAIN_SNAPSHOT usage maint: clean up error reporting in migration maint: replace remaining virLib*Error with better names cfg.mk | 10 - docs/api_extension.html.in | 7 +- po/POTFILES.in | 1 - src/datatypes.c | 104 +- src/datatypes.h | 318 ++- src/internal.h | 9 + src/libvirt-lxc.c | 38 +- src/libvirt-qemu.c | 65 +- src/libvirt.c | 5342 +++++++++++++-------------------------- src/locking/lock_daemon.c | 16 +- src/lxc/lxc_driver.c | 2 +- src/qemu/qemu_migration.c | 10 +- src/security/security_manager.c | 46 +- src/util/virerror.c | 2 +- src/util/virerror.h | 8 + src/util/virinitctl.c | 4 +- src/util/virtypedparam.c | 14 +- src/util/viruuid.h | 20 +- src/xen/xen_driver.c | 11 +- 19 files changed, 2250 insertions(+), 3777 deletions(-) -- 1.8.4.2

2 75

[libvirt] [PATCH] storage: fix crash when listing volumes or undefining a pool
by Martin Kletzander 09 Jan '14

09 Jan '14

The commit cad3cf9a951d26da9d2ee0f5b52fb1a2dbb74af1 introduced a crash due to wrong order of parameters being passed to the function. When deleting an element, the function decreased the iterator instead of count and if listing volumes after that (or undefining the pool, NULL was being dereferenced. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/storage/storage_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index aaa0f02..85fc0f2 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1566,7 +1566,7 @@ storageVolDelete(virStorageVolPtr obj, vol->name, pool->def->name); virStorageVolDefFree(vol); - VIR_DELETE_ELEMENT(pool->volumes.objs, pool->volumes.count, i); + VIR_DELETE_ELEMENT(pool->volumes.objs, i, pool->volumes.count); break; } } -- 1.8.5.2

2 2