- Devel - libvirt List Archives

[libvirt] Trying to debug "Received unexpected event 3" from libvirt
by Yaniv Kaul 16 Jan '16

16 Jan '16

Hi, I'm trying to debug this issue, which may be affecting my inability to perform live snapshot. 1. I'm not sure what 'Waking up a tragedian" in the debug log means - what exactly is a tragedian? 2. In any case, it'd be great if the WARN would mention mon->await_event - is it the event libvirt is actually waiting for? (Both from qemu/qemu_agent.c) 3. I reckon event 3 is QEMU_AGENT_EVENT_RESET ? (from qemu/qemu_agent.h) 4. I'm also getting 'End of file while reading data: Input/output error' messages, not sure what they mean yet. (using 1.2.18.2-1 on FC23, trying to live-snapshot VMs (with Centos 6 & 7 in them, all with qemu guest agent, AFAIK). TIA, Y.

2 5

[libvirt] [PATCH 0/3] Misc fixes
by Cédric Bosdonnat 15 Jan '16

15 Jan '16

Hi all, Here are a few patches without strong connection together. The first one only allows us not to package virt-login-shell even with lxc driver enabled. The other ones are related to mounts security. I'm wondering if changing the default dropped capabilities in the lxc driver is acceptable... dropping sys_admin makes sense, but it can introduce incompatibilities for users needing it as they will need to explicitely enable it. Cédric Bosdonnat (3): Allow building lxc without virt-login-shell virt-aa-helper: don't deny writes to readonly mounts lxc: drop sys_admin caps by default configure.ac | 14 ++++++++++++++ src/lxc/lxc_container.c | 1 + src/security/virt-aa-helper.c | 5 ++++- tools/Makefile.am | 12 ++++++------ 4 files changed, 25 insertions(+), 7 deletions(-) -- 2.1.4

5 8

[libvirt] [PATCH v2 0/4] Adjustment to recent cgroup/cpuset changes (for 1.3.1)
by John Ferlan 15 Jan '16

15 Jan '16

v1: http://www.redhat.com/archives/libvir-list/2016-January/msg00511.html As discussed during the replies of the v1 - revert Henning's first two patches, plus the one I made as a result of those. Patch 4/4 is already ACK'd John Ferlan (4): Revert "qemu: do not put a task into machine cgroup" Revert "util: cgroups do not implicitly add task to new machine cgroup" Revert "lxc_cgroup: Add check for NULL cgroup before AddTask call" cgroup: Fix possible bug as a result of code motion for vcpu cgroup setup src/lxc/lxc_cgroup.c | 13 +------------ src/qemu/qemu_cgroup.c | 9 +-------- src/qemu/qemu_process.c | 12 ++++++------ src/util/vircgroup.c | 22 ++++++++++++++++++++++ 4 files changed, 30 insertions(+), 26 deletions(-) -- 2.5.0

3 8

[libvirt] [PATCH] security: Do not restore labels on device tree binary
by Jiri Denemark 15 Jan '16

15 Jan '16

A device tree binary file specified by /domain/os/dtb element is a read-only resource similar to kernel and initrd files. We shouldn't restore its label when destroying a domain to avoid breaking other domains configure with the same device tree. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/security/security_dac.c | 4 ---- src/security/security_selinux.c | 4 ---- 2 files changed, 8 deletions(-) diff --git a/src/security/security_dac.c b/src/security/security_dac.c index 378b922..a09aba5 100644 --- a/src/security/security_dac.c +++ b/src/security/security_dac.c @@ -1128,10 +1128,6 @@ virSecurityDACRestoreAllLabel(virSecurityManagerPtr mgr, virSecurityDACRestoreFileLabel(priv, def->os.loader->nvram) < 0) rc = -1; - if (def->os.dtb && - virSecurityDACRestoreFileLabel(priv, def->os.dtb) < 0) - rc = -1; - return rc; } diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 475cdbc..9e98635 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -2034,10 +2034,6 @@ virSecuritySELinuxRestoreAllLabel(virSecurityManagerPtr mgr, virSecuritySELinuxRestoreFileLabel(mgr, def->os.loader->nvram) < 0) rc = -1; - if (def->os.dtb && - virSecuritySELinuxRestoreFileLabel(mgr, def->os.dtb) < 0) - rc = -1; - return rc; } -- 2.7.0

2 1

[libvirt] [PATCH] Fix make check with gcc version 5
by Martin Kletzander 15 Jan '16

15 Jan '16

When building with gcc-5 (particularly gcc-5.3.0 now) and having pdwtags installed (package dwarves) make check fails with the following error: $ make lock_protocol-struct GEN lock_protocol-struct --- lock_protocol-structs 2016-01-13 15:04:59.318809607 +0100 +++ lock_protocol-struct-t3 2016-01-13 15:05:17.703501234 +0100 @@ -26,10 +26,6 @@ virLockSpaceProtocolNonNullString name; u_int flags; }; -enum virLockSpaceProtocolAcquireResourceFlags { - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = 1, - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = 2, -}; struct virLockSpaceProtocolAcquireResourceArgs { virLockSpaceProtocolNonNullString path; virLockSpaceProtocolNonNullString name; Makefile:10415: recipe for target 'lock_protocol-struct' failed make: *** [lock_protocol-struct] Error 1 That happens because without any specific options gcc doesn't keep enum information in the resulting binary object. I managed to isolate the parameters of gcc that caused this issue to disappear, however I remember that they influenced the resulting binaries quite a bit and were definitely not something we would want to add as mandatory to the build process. So to deal with this cleanly, let's take that enum and separate it out to its own header file. Since it is only used in the lockd driver and the protocol, lock_driver_lockd.h feels like a suitable name. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/Makefile.am | 1 + src/lock_protocol-structs | 4 ---- src/locking/lock_driver_lockd.c | 2 ++ src/locking/lock_driver_lockd.h | 30 ++++++++++++++++++++++++++++++ src/locking/lock_protocol.x | 6 +----- 5 files changed, 34 insertions(+), 9 deletions(-) create mode 100644 src/locking/lock_driver_lockd.h diff --git a/src/Makefile.am b/src/Makefile.am index aa5ab6929b91..0e0db9bac6da 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -249,6 +249,7 @@ MAINTAINERCLEANFILES += $(LOCK_DAEMON_GENERATED) LOCK_DRIVER_LOCKD_SOURCES = \ locking/lock_driver_lockd.c \ + locking/lock_driver_lockd.h \ $(NULL) LOCK_DAEMON_SOURCES = \ diff --git a/src/lock_protocol-structs b/src/lock_protocol-structs index 8e8b84fb3b50..41be9ce34717 100644 --- a/src/lock_protocol-structs +++ b/src/lock_protocol-structs @@ -26,10 +26,6 @@ struct virLockSpaceProtocolDeleteResourceArgs { virLockSpaceProtocolNonNullString name; u_int flags; }; -enum virLockSpaceProtocolAcquireResourceFlags { - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = 1, - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = 2, -}; struct virLockSpaceProtocolAcquireResourceArgs { virLockSpaceProtocolNonNullString path; virLockSpaceProtocolNonNullString name; diff --git a/src/locking/lock_driver_lockd.c b/src/locking/lock_driver_lockd.c index 5b89ca142b0b..181261170506 100644 --- a/src/locking/lock_driver_lockd.c +++ b/src/locking/lock_driver_lockd.c @@ -34,6 +34,8 @@ #include "configmake.h" #include "virstring.h" +#include "lock_driver_lockd.h" + #define VIR_FROM_THIS VIR_FROM_LOCKING VIR_LOG_INIT("locking.lock_driver_lockd"); diff --git a/src/locking/lock_driver_lockd.h b/src/locking/lock_driver_lockd.h new file mode 100644 index 000000000000..baf346adaf6c --- /dev/null +++ b/src/locking/lock_driver_lockd.h @@ -0,0 +1,30 @@ +/* + * lock_driver_lockd.h: Locking for domain lifecycle operations + * + * Copyright (C) 2010-2011 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + * + */ + +#ifndef __VIR_LOCK_DRIVER_LOCKD_H__ +# define __VIR_LOCK_DRIVER_LOCKD_H__ + +enum virLockSpaceProtocolAcquireResourceFlags { + VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = 1, + VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = 2, +}; + +#endif /* __VIR_LOCK_DRIVER_LOCKD_H__ */ diff --git a/src/locking/lock_protocol.x b/src/locking/lock_protocol.x index a77a78490cb6..6d4cec39e244 100644 --- a/src/locking/lock_protocol.x +++ b/src/locking/lock_protocol.x @@ -2,6 +2,7 @@ */ %#include "internal.h" +%#include "lock_driver_lockd.h" typedef opaque virLockSpaceProtocolUUID[VIR_UUID_BUFLEN]; @@ -50,11 +51,6 @@ struct virLockSpaceProtocolDeleteResourceArgs { unsigned int flags; }; -enum virLockSpaceProtocolAcquireResourceFlags { - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = 1, - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = 2 -}; - struct virLockSpaceProtocolAcquireResourceArgs { virLockSpaceProtocolNonNullString path; virLockSpaceProtocolNonNullString name; -- 2.7.0

2 1

[libvirt] [PATCH] security: Do not restore kernel and initrd labels
by Jiri Denemark 15 Jan '16

15 Jan '16

Kernel/initrd files are essentially read-only shareable images and thus should be handled in the same way. We already use the appropriate label for kernel/initrd files when starting a domain, but when a domain gets destroyed we would remove the labels which would make other running domains using the same files very unhappy. https://bugzilla.redhat.com/show_bug.cgi?id=921135 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/security/security_dac.c | 8 -------- src/security/security_selinux.c | 8 -------- 2 files changed, 16 deletions(-) diff --git a/src/security/security_dac.c b/src/security/security_dac.c index 80709fe..378b922 100644 --- a/src/security/security_dac.c +++ b/src/security/security_dac.c @@ -1128,14 +1128,6 @@ virSecurityDACRestoreAllLabel(virSecurityManagerPtr mgr, virSecurityDACRestoreFileLabel(priv, def->os.loader->nvram) < 0) rc = -1; - if (def->os.kernel && - virSecurityDACRestoreFileLabel(priv, def->os.kernel) < 0) - rc = -1; - - if (def->os.initrd && - virSecurityDACRestoreFileLabel(priv, def->os.initrd) < 0) - rc = -1; - if (def->os.dtb && virSecurityDACRestoreFileLabel(priv, def->os.dtb) < 0) rc = -1; diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 721c451..475cdbc 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -2034,14 +2034,6 @@ virSecuritySELinuxRestoreAllLabel(virSecurityManagerPtr mgr, virSecuritySELinuxRestoreFileLabel(mgr, def->os.loader->nvram) < 0) rc = -1; - if (def->os.kernel && - virSecuritySELinuxRestoreFileLabel(mgr, def->os.kernel) < 0) - rc = -1; - - if (def->os.initrd && - virSecuritySELinuxRestoreFileLabel(mgr, def->os.initrd) < 0) - rc = -1; - if (def->os.dtb && virSecuritySELinuxRestoreFileLabel(mgr, def->os.dtb) < 0) rc = -1; -- 2.7.0

4 5

[libvirt] Entering freeze for libvirt-1.3.1
by Daniel Veillard 15 Jan '16

15 Jan '16

As suggested this w.e., I just tagged the release candidate 1 in git and pushed signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ This works fine with my limited testing, but obviously more people need to give it some trial especially on other platforms. The output from CentOS CI is mostly green which is a good sign with just libvirt-daemon-rpm and virt-manager-test in the red, someone probably need to have a look before we release. The rc2 should come in 2 days on Thursday, and unless there is some blocker I plan to push 1.3.1 over the week-end, so please give it some testing ! Thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

4 9

[libvirt] Quantifying libvirt errors in launching the libguestfs appliance
by Richard W.M. Jones 15 Jan '16

15 Jan '16

As people may know, we frequently encounter errors caused by libvirt when running the libguestfs appliance. I wanted to find out exactly how frequently these happen and classify the errors, so I ran the 'virt-df' tool overnight 1700 times. This tool runs several parallel qemu:///session libvirt connections both creating a short-lived appliance guest. Note that I have added Cole's patch to fix https://bugzilla.redhat.com/1271183 "XML-RPC error : Cannot write data: Transport endpoint is not connected" Results: The test failed 538 times (32% of the time), which is pretty dismal. To be fair, virt-df is aggressive about how it launches parallel libvirt connections. Most other virt-* tools use only a single libvirt connection and are consequently more reliable. Of the failures, 518 (96%) were of the form: process exited while connecting to monitor: qemu: could not load kernel '/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel': Permission denied which is https://bugzilla.redhat.com/921135 or maybe https://bugzilla.redhat.com/1269975. It's not clear to me if these bugs have different causes, but if they do then potentially we're seeing a mix of both since my test has no way to distinguish them. 19 of the failures (4%) were of the form: process exited while connecting to monitor: fread() failed which I believe is a previously unknown bug. I have filed it as https://bugzilla.redhat.com/1298122 Finally there was 1 failure: Unable to read from monitor: Connection reset by peer which I believe is also a new bug. I have filed it as https://bugzilla.redhat.com/1298124 I would be good if libvirt could routinely test the case of multiple parallel launches of qemu:///session, since it still contains bugs even after Cole's fixes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

7 15

[libvirt] [REPOST 0/4] Adjustment to recent cgroup/cpuset changes (for 1.3.1)
by John Ferlan 14 Jan '16

14 Jan '16

Reposting my cgroup fixes series: http://www.redhat.com/archives/libvir-list/2016-January/msg00236.html partially because I originally forgot to CC the author (Henning Schild) of the original series for which these patch fix a couple of issues discovered during regression testing (virt-test memtune failures in Red Hat regression environment), but also to bring them up to date with the top of libvirt git. NB: I did send Henning the changes after the fact, but my resend using the same message-id skills so that replies are left in the onlist series are lacking. Henning has looked at the first patch - with a response here: http://www.redhat.com/archives/libvir-list/2016-January/msg00443.html Finally, I think these changes should go into 1.3.1 since that's when the regression was introduced. John Ferlan (4): cgroup: Fix possible bug as a result of code motion for vcpu cgroup setup qemu: Add check for NULL cgroup return from virCgroupNewMachine Revert "qemu: do not put a task into machine cgroup" qemu: Put the emulator cgroup pid into the right task file src/qemu/qemu_cgroup.c | 18 +++++++++++++----- src/qemu/qemu_process.c | 12 ++++++------ 2 files changed, 19 insertions(+), 11 deletions(-) -- 2.5.0

4 22

[libvirt] [PATCH v4 0/7] Per domain bandwidth settings
by Alexander Burluka 14 Jan '16

14 Jan '16

We decide to make a global per domain bandwidth setting as were discussed in mailing list earlier. This patchset implements hierarchy top level cpu.cfs_period_us and cpu.cfs_quota_us control knob. I've named this parameters as global_period and global_quota. Changes in v2: add XML validation test Changes in v3: remove unneccessary cgroup copying Changes in v4: fix little rebase error Alexander Burluka (7): Add global period definitions Add global quota parameter necessary definitions Add error checking on global quota and period Add global_period and global_quota XML validation test Rename qemuSetupCgroupVcpuBW to qemuSetupBandwidthCgroup Implement qemuSetupGlobalCpuCgroup Implement handling of per-domain bandwidth settings docs/schemas/domaincommon.rng | 10 +++ include/libvirt/libvirt-domain.h | 32 ++++++++ src/conf/domain_conf.c | 37 +++++++++ src/conf/domain_conf.h | 2 + src/qemu/qemu_cgroup.c | 68 ++++++++++++++-- src/qemu/qemu_cgroup.h | 7 +- src/qemu/qemu_command.c | 3 +- src/qemu/qemu_driver.c | 102 ++++++++++++++++++++++-- src/qemu/qemu_process.c | 4 + tests/qemuxml2argvdata/qemuxml2argv-cputune.xml | 2 + 10 files changed, 251 insertions(+), 16 deletions(-) -- 1.8.3.1

1 7