July 2015 - Devel - libvirt List Archives

[libvirt] [PATCH] qemuProcessStart: Be tolerant to relabel errors for session mode
by Michal Privoznik 05 Aug '15

05 Aug '15

https://bugzilla.redhat.com/show_bug.cgi?id=1124841 When the daemon is running under unprivileged user, that is under qemu:///session, there are plenty of operations we can't do. What we can do is to go with best effort. One of such cases is relabeling domain resources (be it disks, sockets, regular files, etc.) during domain startup process. While we may successfully set DAC labels, we can be fairly certain that any attempt to change SELinux labels will fail. Therefore we should tolerate relabelling errors and just let qemu to try access the resources. If it fails, our error reporting system is strong enough to articulate the exact error to the user anyway. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_process.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 1c0c734..58ed631 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4856,8 +4856,13 @@ int qemuProcessStart(virConnectPtr conn, VIR_DEBUG("Setting domain security labels"); if (virSecurityManagerSetAllLabel(driver->securityManager, - vm->def, stdin_path) < 0) - goto cleanup; + vm->def, stdin_path) < 0) { + /* Be tolerant to relabel errors if we are running unprivileged. */ + if (virQEMUDriverIsPrivileged(driver)) + goto cleanup; + else + VIR_DEBUG("Ignoring relabel errors for unprivileged daemon"); + } /* Security manager labeled all devices, therefore * if any operation from now on fails and we goto cleanup, -- 2.3.6

3 3

[libvirt] mass create vm errors
by Vasiliy Tolstov 04 Aug '15

04 Aug '15

Hi again =). I have another problem then testing libvirt with massive vm start: 2015-07-18 08:25:21.687+0000: 36893: error : qemuMonitorIO:750 : internal error: early end of file from monitor: possible problem: 2015-07-18T08:25:21.586487Z qemu-system-x86_64: -vnc [::]:4,password: Failed to start VNC server: Failed to bind socket: Address already in use As i understand, when libvirt try to detect free port for vnc it fails, because another process already binds to it. How can i avoid this errors? Does it fixed in never libvirt releases? libvirt 1.216 qemu 2.4.0-rc0 -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru

2 3

[libvirt] [PATCH 0/2] Adjustments for configuring volume lun device
by John Ferlan 04 Aug '15

04 Aug '15

Resolve a couple of issues regarding failures seen configuring a disk to be a type='volume' device='lun'. The doc patch just indicates that using an NPIV storage/source pool is a valid option. The second patch allows for a "clearer" error message to be reported. John Ferlan (2): docs: Add Fibre Channel NPIV supported option for volume lun config conf: Allow error reporting in virDomainDiskSourceIsBlockType docs/formatdomain.html.in | 6 ++++-- src/conf/domain_conf.c | 21 ++++++++++++++++++--- src/conf/domain_conf.h | 2 +- src/lxc/lxc_cgroup.c | 2 +- src/lxc/lxc_driver.c | 6 ++---- src/qemu/qemu_command.c | 5 +---- src/qemu/qemu_conf.c | 6 +++--- 7 files changed, 30 insertions(+), 18 deletions(-) -- 2.1.0

2 6

[libvirt] [PATCH v2 0/3] Disable floppy disk for PowerPC VMs
by Kothapally Madhu Pavan 04 Aug '15

04 Aug '15

This is an attempt to fix: Libvirt BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1180486 Libvirt currently assumes ISA_based floppy disks to be available across all architectures and machine types. However, PowerPC Book 3S compatible ('ie pseries) virtual machines do not support Floppy disks. This patch series prevents libvirt from launching ppc64[le] -based 'pseries' VMs with floppy devices. This version of patch attempts to fulfill the coments of Andrea Bolognani and Jan Tomko on previous version of patch. --- Kothapally Madhu Pavan (3): Caps: Disable floppy disk for PowerPC VM Avoid starting a PowerPC VM with floppy disk test: Introduce test case to disallow floppy disk on pseries src/qemu/qemu_capabilities.c | 15 +++++-- src/qemu/qemu_command.c | 8 ++++ .../qemuxml2argv-disk-floppy-pseries.args | 6 +++ .../qemuxml2argv-disk-floppy-pseries.xml | 41 ++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 5 files changed, 67 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-floppy-pseries.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-floppy-pseries.xml -- Kothapally Madhu Pavan

3 6

[libvirt] [PATCH 00/13] Move generic virsh data to a separate module vsh
by Erik Skultety 04 Aug '15

04 Aug '15

The idea behind this is that in order to introduce virt-admin client (and later some commands/APIs), there are lots of methods in virsh that can be easily reused by other potential clients like command and command argument passing or error reporting. !!! IMPORTANT !!! These patches cannot be compiled separately, the series is split more or less logically into chunks only to be more readable by the reviewer. I started this at least 4 times from scratch and still haven't found a way that splitting virsh could be done with several independent applicable commits, rather than having one massive commit in the end. Erik Skultety (13): tools: Introduce new client generic module vsh vsh: Remove client specific data, only generic data are kept tools: apply s/vshX/virshX to all virsh specific data virsh: remove generic data, only client specific are kept virsh: Rename client specific methods in virsh.h vsh: vshControl now includes client private data and client specific progname vsh: Make use of introduced private data vsh: Introduce client hooks vsh: Make use of newly introduced client side hooks vsh: Introduce new global initializer vsh: Make separated generic methods public virsh: Introduce connection handler tools: Update makefile to include 'vsh' sources as well cfg.mk | 2 +- po/POTFILES.in | 3 +- tools/Makefile.am | 4 + tools/virsh-console.c | 13 +- tools/virsh-console.h | 8 +- tools/virsh-domain-monitor.c | 201 ++-- tools/virsh-domain-monitor.h | 4 +- tools/virsh-domain.c | 532 +++++---- tools/virsh-domain.h | 14 +- tools/virsh-edit.c | 8 +- tools/virsh-host.c | 131 ++- tools/virsh-interface.c | 80 +- tools/virsh-interface.h | 12 +- tools/virsh-network.c | 72 +- tools/virsh-network.h | 10 +- tools/virsh-nodedev.c | 37 +- tools/virsh-nwfilter.c | 33 +- tools/virsh-nwfilter.h | 10 +- tools/virsh-pool.c | 104 +- tools/virsh-pool.h | 10 +- tools/virsh-secret.c | 27 +- tools/virsh-snapshot.c | 75 +- tools/virsh-volume.c | 103 +- tools/virsh-volume.h | 14 +- tools/virsh.c | 2673 ++++-------------------------------------- tools/virsh.h | 481 +------- tools/vsh.c | 2332 ++++++++++++++++++++++++++++++++++++ tools/vsh.h | 489 ++++++++ 28 files changed, 3906 insertions(+), 3576 deletions(-) create mode 100644 tools/vsh.c create mode 100644 tools/vsh.h -- 1.9.3

3 20

[libvirt] libvirt 1.2.17 fails
by Jason Helfman 04 Aug '15

04 Aug '15

Hello All, I am getting build failures on the latest build, and it is currently blocking my commit of the update. Looks like xhtml, is a new build requirement. I added it to the list of dependencies, however it is failing to build within our build cluster. http://meatwad.mouf.net/rubick/poudriere/data/93i386-jgh/2015-07-27_15h41m2… (also attached for historical purposes) I am able to get this to build locally, but trying to distinguish what is different compared with a clean system. Here is the listing of files contained in the xhtml package: xhtml-1.0.20020801_4: /usr/local/share/xml/dtd/xhtml/catalog.xml /usr/local/share/xml/dtd/xhtml/xhtml-dcl.soc /usr/local/share/xml/dtd/xhtml/xhtml-lat1.ent /usr/local/share/xml/dtd/xhtml/xhtml-special.ent /usr/local/share/xml/dtd/xhtml/xhtml-symbol.ent /usr/local/share/xml/dtd/xhtml/xhtml.soc /usr/local/share/xml/dtd/xhtml/xhtml1-frameset.dtd /usr/local/share/xml/dtd/xhtml/xhtml1-strict.dtd /usr/local/share/xml/dtd/xhtml/xhtml1-transitional.dtd /usr/local/share/xml/dtd/xhtml/xhtml1.dcl Thanks in advance! Jason -- Jason Helfman | FreeBSD Committer jgh(a)FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve

2 3

[libvirt] [PATCH v11 0/5] nodeinfo: Add support for subcores
by Andrea Bolognani 04 Aug '15

04 Aug '15

Only patch 1/5 has been updated, all the other patches are the same as v8: 2/5 https://www.redhat.com/archives/libvir-list/2015-July/msg01045.html 3/5 https://www.redhat.com/archives/libvir-list/2015-July/msg01048.html 4/5 https://www.redhat.com/archives/libvir-list/2015-July/msg01049.html 5/5 https://www.redhat.com/archives/libvir-list/2015-July/msg01050.html I'm including the full history below. Cheers. Changes in v11: * don't declare variables only used inside a code block guarded by #ifdef outside of said code block * use virBitmapNextSetBit() instead of going through all possible index values and calling virBitmapIsBitSet() for each one Changes in v10: * don't attempt to close a file that wasn't opened * report a detailed error to help with diagnosis Changes in v9: * take into account the fact that kvm might not be loaded or even installed Changes in v8: * shortened test names so that make dist doesn't stop working again Changes in v7: * rebased on top of master now that the series this one builds on have been merged Changes in v6: * updated to work on top of [PATCH v2 00/10] nodeinfo: Various cleanups Changes in v5: * streamlined the logic used to decide whether the subcore configuration is valid and moved it to a separate function * split the tests into separate commits for easier review and to hopefully avoid having trouble with the list due to the message size Changes in v4: * removed a printf() statement * fixed typo in a commit message Changes in v3: * the function to get the number of threads per subcore has been moved to the from virarch.c, which deals with architecture names only and is therefore not the right place to read host configuration, to nodeinfo.c where the rest of this stuff lives * said function has also been given a shorter name * the "valid subcore mode" boolean has been removed: threads_per_subcore will be a positive number if subcores should be taken into account, and if that's not the case (x86 host, tainted configuration) it will simply be zero, so now the code needs to keep track of a single variable instead of two * the test case has been renamed to be more descriptive * the test data has been cleaned up by removing all cpu/cpu*/node* links, which prevented 'make dist' from working due to recursive linking Andrea Bolognani (3): tests: Add subcores1 nodeinfo test tests: Add subcores2 nodeinfo test tests: Add subcores3 nodeinfo test Shivaprasad G Bhat (2): nodeinfo: Fix output on PPC64 KVM hosts tests: Prepare for subcore tests src/libvirt_private.syms | 1 + src/nodeinfo.c | 153 ++++++++++++++++++++- src/nodeinfo.h | 1 + tests/Makefile.am | 6 + [...] tests/nodeinfomock.c | 35 +++++ tests/nodeinfotest.c | 8 +- 1348 files changed, 2134 insertions(+), 6 deletions(-) [...] create mode 100644 tests/nodeinfomock.c -- 2.4.3

2 3

[libvirt] [PATCH] qemu: Remove double unlock for domains
by Martin Kletzander 03 Aug '15

03 Aug '15

The virDomainObjListRemove() function unlocks a domain that it's given due to legacy code. And because of that code, which should be refactored, that last virObjectUnlock() cannot be just removed. So instead, lock it right back for qemu for now. All calls to qemuDomainRemoveInactive() are followed by code that unlocks the domain again, plus the domain should be locked during qemuDomainObjEndJob(), so the right place to lock it is right after virDomainObjListRemove(). The only place where this would cause a problem is the autodestroy callback, so we need to get another reference there and uref+unlock it afterwards. Luckily, returning NULL from that function doesn't mean an error, and only means that it doesn't need to be unlocked anymore. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/qemu/qemu_domain.c | 7 +++++++ src/qemu/qemu_process.c | 7 ++++--- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 8b050a043995..d6d723112638 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -2593,6 +2593,13 @@ qemuDomainRemoveInactive(virQEMUDriverPtr driver, virObjectRef(vm); virDomainObjListRemove(driver->domains, vm); + /* + * virDomainObjListRemove() leaves the domain unlocked so it can + * be unref'd for other drivers that depend on that, but we still + * need to reset a job and we have a reference from the API that + * called this function. So we need to lock it back. + */ + virObjectLock(vm); virObjectUnref(cfg); if (haveJob) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 1c0c734c3811..df38dacdca92 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5696,6 +5696,8 @@ qemuProcessAutoDestroy(virDomainObjPtr dom, VIR_DEBUG("vm=%s, conn=%p", dom->def->name, conn); + virObjectRef(dom); + if (priv->job.asyncJob) { VIR_DEBUG("vm=%s has long-term job active, cancelling", dom->def->name); @@ -5718,15 +5720,14 @@ qemuProcessAutoDestroy(virDomainObjPtr dom, qemuDomainObjEndJob(driver, dom); - if (!dom->persistent) { + if (!dom->persistent) qemuDomainRemoveInactive(driver, dom); - dom = NULL; - } if (event) qemuDomainEventQueue(driver, event); cleanup: + virDomainObjEndAPI(&dom); return dom; } -- 2.4.5

2 5

[libvirt] [PATCH 0/2] qemu: Improve memory alignment handling and fix upcoming powerpc
by Peter Krempa 03 Aug '15

03 Aug '15

Peter Krempa (2): qemu: Make memory alignment helper more universal qemu: ppc64: Align memory sizes to 256MiB src/qemu/qemu_domain.c | 33 ++++++++++++++++------ src/qemu/qemu_domain.h | 3 +- src/qemu/qemu_hotplug.c | 4 +-- .../qemuxml2argv-pseries-cpu-compat.args | 2 +- 4 files changed, 30 insertions(+), 12 deletions(-) -- 2.4.5

2 5

[libvirt] ambiguous ret of qemuDomainDetachVirtioDiskDevice
by zhang bo 03 Aug '15

03 Aug '15

static int qemuDomainDetachVirtioDiskDevice(virQEMUDriverPtr driver, virDomainObjPtr vm, virDomainDiskDefPtr detach) { ....... rc = qemuDomainWaitForDeviceRemoval(vm); if (rc == 0 || rc == 1) ret = qemuDomainRemoveDiskDevice(driver, vm, detach); else ret = 0; /*the return value of 2 is dismissed here, which refers to ETIMEOUT.*/ ........ } ------------------------------------ If it timeouts when qemu tries to del the device, the return value would be modified from 2 to 0 in function qemuDomainDetachVirtioDiskDevice(), which means that, the users would be misleaded that the device has been deleted, however, the device maybe probably failed to be detached after timeout and still in use. That is to say, the function qemuDomainDetachVirtioDiskDevice()'s return value is ambiguous when it's 0, maybe successful, or timeout. Will it be better to pass ETIMEOUT to user? or any other advises? for example, let users themselves dumpxml the guest to check whether the device has been actually detached or not? -- Oscar oscar.zhangbo(a)huawei.com

2 4