- Devel - libvirt List Archives

[libvirt] Problems with live migration
by Toni F. [ackstorm] 14 Mar '13

14 Mar '13

Hi all, I have working with Openstack Folsom and with Glusterfs as shared storage for /instances. All working fine, but when i'm trying to use "nova live-migration": 2013-03-07 18:33:42 3140 ERROR nova.virt.libvirt.driver [-] [instance: 773164b5-5e5c-4328-a762-d91f50f2ac33] Live Migration failure: Timed out during operation: cannot acquire state change lock I know that the real command that openstack executes virsh migrate --live instance-00000036 qemu+ssh://nova-compute-lnx001/system When i execute that command the same error is showed error: Timed out during operation: cannot acquire state change lock Versions: ii libvirt-bin 0.9.13-0ubuntu12.2~cloud0 programs for the libvirt library ii libvirt0 0.9.13-0ubuntu12.2~cloud0 library for interfacing with different virtualization systems ii python-libvirt 0.9.13-0ubuntu12.2~cloud0 libvirt Python bindings ii qemu-kvm 1.0+noroms-0ubuntu14.7 Full virtualization on i386 and amd64 hardware Any idea about this error? Thanks for advance Regards

1 0

[libvirt] Problems with live migration
by Toni F. [ackstorm] 14 Mar '13

14 Mar '13

Hi all, I have working with Openstack Folsom and with Glusterfs as shared storage for /instances. All working fine, but when i'm trying to use "nova live-migration": 2013-03-07 18:33:42 3140 ERROR nova.virt.libvirt.driver [-] [instance: 773164b5-5e5c-4328-a762-d91f50f2ac33] Live Migration failure: Timed out during operation: cannot acquire state change lock I know that the real command that openstack executes virsh migrate --live instance-00000036 qemu+ssh://nova-compute-lnx001/system When i execute that command the same error is showed error: Timed out during operation: cannot acquire state change lock Versions: ii libvirt-bin 0.9.13-0ubuntu12.2~cloud0 programs for the libvirt library ii libvirt0 0.9.13-0ubuntu12.2~cloud0 library for interfacing with different virtualization systems ii python-libvirt 0.9.13-0ubuntu12.2~cloud0 libvirt Python bindings ii qemu-kvm 1.0+noroms-0ubuntu14.7 Full virtualization on i386 and amd64 hardware Any idea about this error? Thanks for advance Regards

1 0

[libvirt] [PATCHv4 0/5] S390: Support for native CCW bus
by Viktor Mihajlovski 14 Mar '13

14 Mar '13

Originally, QEMU did not implement a native I/O bus for s390. The initial implementation had a machine type 's390-virtio' featuring a fully paravirtualized I/O system with an artificial bus type 'virtio-s390'. This bus had a number of short-comings, like the need for a non-standard device discovery mechanism, a limited number of devices, limited hotplugging capabilites and the lack of persistent device addresses. To resolve these issues a new machine type 's390-ccw-virtio' has been recently added to QEMU which implementa the native s390 CCW I/O bus. Guests with arch='s390x' and machine='s390-ccw-virtio' can now be defined with up to 262144 virtio devices. This series adds the support for the s390-ccw-virtio machine type and the CCW bus to libvirt. As usual we start with the documentation/schema, the generic configuration stuff, continue with the QEMU driver including device hotplug and finally add qemu2xml testcases. V2 Changes - use an attribute triple cssid, ssid, schid instead of devno to better represent the libvirt CCW address structure - rebase to current upstream, mainly address qemuCapsXXX rename V3 Changes - skip already acked patches 1/5 and 2/5 - revert machine-based capabilities - use machine definition from domain object V4 Changes - schid was technically wrong, the attribute name has to be devno: changed all occurrences accordingly - re-introduce reverted patches 1/5 and 2/5 with schid/devno correction - rebase to current upstream J.B. Joret (1): S390: Add hotplug support for s390 virtio devices Viktor Mihajlovski (4): S390: Documentation for CCW address type S390: domain_conf support for CCW S390: QEMU driver support for CCW addresses S390: Testcases for virtio-ccw machines docs/formatdomain.html.in | 14 + docs/schemas/domaincommon.rng | 52 ++++ src/conf/domain_conf.c | 107 +++++++- src/conf/domain_conf.h | 16 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 7 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 279 ++++++++++++++++++-- src/qemu/qemu_command.h | 6 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 3 + src/qemu/qemu_driver.c | 6 +- src/qemu/qemu_hotplug.c | 152 +++++++---- src/qemu/qemu_hotplug.h | 14 +- src/qemu/qemu_process.c | 3 + .../qemuxml2argv-console-virtio-ccw.args | 10 + .../qemuxml2argv-console-virtio-ccw.xml | 27 ++ .../qemuxml2argv-console-virtio-s390.args | 4 +- .../qemuxml2argv-console-virtio-s390.xml | 2 +- .../qemuxml2argv-disk-virtio-ccw-many.args | 12 + .../qemuxml2argv-disk-virtio-ccw-many.xml | 40 +++ .../qemuxml2argv-disk-virtio-ccw.args | 8 + .../qemuxml2argv-disk-virtio-ccw.xml | 30 +++ .../qemuxml2argv-net-virtio-ccw.args | 8 + .../qemuxml2argv-net-virtio-ccw.xml | 30 +++ tests/qemuxml2argvtest.c | 12 +- tests/testutilsqemu.c | 3 +- 27 files changed, 766 insertions(+), 82 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-console-virtio-ccw.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-console-virtio-ccw.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw-many.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw-many.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-ccw.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-ccw.xml -- 1.7.9.5

4 14

[libvirt] separate module for pci passthrough device assigning and in-use tracking
by Chunyan Liu 14 Mar '13

14 Mar '13

Hi, Shradha, Laine Some time before I found you had a thread discussing in-use tracking for network and pci-passthrough devices[1], it mentioned code for tracking pci device allocation should be better as a separate module rather than a part of qemu, so that it could solve data sharing problem between hypervisor drivers and network driver. And after that, we wanted to add pci passthrough support to libxl driver[2], which turned to be the same problem, data sharing between libxl driver and other drivers, and there were code duplication between libxl and qemu driver. Laine suggested again to write code in common library as a separate module. Now I wonder if there is anyone already worked and pushed this thing to some status? If not, I am willing to try it. Thanks, Chunyan

1 0

[libvirt] [PATCH v4 0/2] qemu: -dtb option support
by Olivia Yin 14 Mar '13

14 Mar '13

Sometime QEMU need load specific device tree binary images. These patches provide -dtb option support and update docs/tests. Olivia Yin (2): qemu: add support for dtb option conf: Add support for dtb option in QEMU src/qemu/qemu_capabilities.c | 6 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 6 ++++ tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args | 1 + tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.xml | 28 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 + docs/formatdomain.html.in | 5 +++++ docs/schemas/domaincommon.rng | 5 +++++ src/conf/domain_conf.c | 4 ++++ src/conf/domain_conf.h | 1 +

4 10

[libvirt] [PATCH] lxc: Init activeUsbHostdevs
by Guido Günther 14 Mar '13

14 Mar '13

otherwise we crash with #0 virUSBDeviceListFind (list=0x0, dev=dev@entry=0x8193d70) at util/virusb.c:526 #1 0xb1a4995b in virLXCPrepareHostdevUSBDevices (driver=driver@entry=0x815d9a0, name=0x815dbf8 "debian-700267", list=list@entry=0x81d8f08) at lxc/lxc_hostdev.c:88 #2 0xb1a49fce in virLXCPrepareHostUSBDevices (def=0x8193af8, driver=0x815d9a0) at lxc/lxc_hostdev.c:261 #3 virLXCPrepareHostDevices (driver=driver@entry=0x815d9a0, def=0x8193af8) at lxc/lxc_hostdev.c:328 #4 0xb1a4c5b1 in virLXCProcessStart (conn=0x817d3f8, driver=driver@entry=0x815d9a0, vm=vm@entry=0x8190908, autoDestroy=autoDestroy@entry=false, reason=reason@entry=VIR_DOMAIN_RUNNING_BOOTED) at lxc/lxc_process.c:1068 #5 0xb1a57e00 in lxcDomainStartWithFlags (dom=dom@entry=0x815e460, flags=flags@entry=0) at lxc/lxc_driver.c:1014 #6 0xb1a57fc3 in lxcDomainStart (dom=0x815e460) at lxc/lxc_driver.c:1046 #7 0xb79c8375 in virDomainCreate (domain=domain@entry=0x815e460) at libvirt.c:8450 #8 0x08078959 in remoteDispatchDomainCreate (args=0x81920a0, rerr=0xb65c21d0, client=0xb0d00490, server=<optimized out>, msg=<optimized out>) at remote_dispatch.h:1066 #9 remoteDispatchDomainCreateHelper (server=0x80c4928, client=0xb0d00490, msg=0xb0d005b0, rerr=0xb65c21d0, args=0x81920a0, ret=0x815d208) at remote_dispatch.h:1044 #10 0xb7a36901 in virNetServerProgramDispatchCall (msg=0xb0d005b0, client=0xb0d00490, server=0x80c4928, prog=0x80c6438) at rpc/virnetserverprogram.c:432 #11 virNetServerProgramDispatch (prog=0x80c6438, server=server@entry=0x80c4928, client=0xb0d00490, msg=0xb0d005b0) at rpc/virnetserverprogram.c:305 #12 0xb7a300a7 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0x80c4928) at rpc/virnetserver.c:162 #13 virNetServerHandleJob (jobOpaque=0xb0d00510, opaque=0x80c4928) at rpc/virnetserver.c:183 #14 0xb7924f98 in virThreadPoolWorker (opaque=opaque@entry=0x80a94b0) at util/virthreadpool.c:144 #15 0xb7924515 in virThreadHelper (data=0x80a9440) at util/virthreadpthread.c:161 #16 0xb7887c39 in start_thread (arg=0xb65c2b70) at pthread_create.c:304 #17 0xb77eb78e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 when adding a domain with a usb device. This is Debian bug http://bugs.debian.org/700267 --- src/lxc/lxc_driver.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index f136df2..338b8eb 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -1469,6 +1469,9 @@ static int lxcStartup(bool privileged, if (lxcSecurityInit(lxc_driver) < 0) goto cleanup; + if ((lxc_driver->activeUsbHostdevs = virUSBDeviceListNew()) == NULL) + goto cleanup; + if ((lxc_driver->caps = lxcCapsInit(lxc_driver)) == NULL) goto cleanup; @@ -1559,6 +1562,7 @@ static int lxcShutdown(void) virLXCProcessAutoDestroyShutdown(lxc_driver); + virObjectUnref(lxc_driver->activeUsbHostdevs); virObjectUnref(lxc_driver->caps); virObjectUnref(lxc_driver->securityManager); VIR_FREE(lxc_driver->configDir); -- 1.7.10.4

3 3

[libvirt] [PATCH] virsh: fix snapshot-create with no xmlfile
by Ján Tomko 14 Mar '13

14 Mar '13

Properly check the return value of vshCommandOptStringReq for xmlfile: * error out on incorrect input (--xmlfile '') * use default XML <domainsnapshot/> with no --xmlfile specified (Broken by commit b2e8585) Bug: https://bugzilla.redhat.com/show_bug.cgi?id=919826 --- tools/virsh-snapshot.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index ed41014..d994fd9 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -211,7 +211,9 @@ cmdSnapshotCreate(vshControl *ctl, const vshCmd *cmd) if (!(dom = vshCommandOptDomain(ctl, cmd, NULL))) goto cleanup; - if (vshCommandOptStringReq(ctl, cmd, "xmlfile", &from) < 0) { + if (vshCommandOptStringReq(ctl, cmd, "xmlfile", &from) < 0) + goto cleanup; + if (!from) { buffer = vshStrdup(ctl, "<domainsnapshot/>"); } else { if (virFileReadAll(from, VSH_MAX_XML_FILE, &buffer) < 0) { -- 1.7.12.4

4 4

[libvirt] [PATCH] lxc: include sys/{types,stat}.h
by Guido Günther 14 Mar '13

14 Mar '13

This fixes the build on Debian Wheezy which otherwise fails with: CC libvirt_driver_lxc_impl_la-lxc_process.lo lxc/lxc_process.c: In function 'virLXCProcessGetNsInode': lxc/lxc_process.c:648:5: error: implicit declaration of function 'stat' [-Werror=implicit-function-declaration] lxc/lxc_process.c:648:5: error: nested extern declaration of 'stat' [-Werror=nested-externs] cc1: all warnings being treated as errors --- src/lxc/lxc_process.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c index 0d5a070..ecfac50 100644 --- a/src/lxc/lxc_process.c +++ b/src/lxc/lxc_process.c @@ -21,6 +21,8 @@ #include <config.h> +#include <sys/types.h> +#include <sys/stat.h> #include <unistd.h> #include <fcntl.h> #include <signal.h> -- 1.7.10.4

3 3

[libvirt] [PATCH 0/2]fix two bugs when using virsh memtune
by Guannan Ren 14 Mar '13

14 Mar '13

Patch 2/2 fix BZ: https://bugzilla.redhat.com/show_bug.cgi?id=911998 Guannan Ren(2) [PATCH 1/2] util: fix a integer boundary error [PATCH 2/2] qemu: update domain live xml for virsh memtune with src/qemu/qemu_driver.c | 36 +++++++++++++++++++++--------------- src/util/virutil.c | 2 +- 2 files changed, 22 insertions(+), 16 deletions(-)

3 7

[libvirt] [PATCH] Daemonize fuse thread in libvirt_lxc
by Daniel P. Berrange 14 Mar '13

14 Mar '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> In some startup failure modes, the fuse thread may get itself wedged. This will cause the entire libvirt_lxc process to hang trying to the join the thread. There is no compelling reason to wait for the thread to exit if the whole process is exiting, so kust daemonize the fus thread instead. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_fuse.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/lxc/lxc_fuse.c b/src/lxc/lxc_fuse.c index b6808da..c4be58e 100644 --- a/src/lxc/lxc_fuse.c +++ b/src/lxc/lxc_fuse.c @@ -320,7 +320,7 @@ int lxcSetupFuse(virLXCFusePtr *f, virDomainDefPtr def) goto cleanup1; } - if (virThreadCreate(&fuse->thread, true, lxcFuseRun, + if (virThreadCreate(&fuse->thread, false, lxcFuseRun, (void *)fuse) < 0) { lxcFuseDestroy(fuse); goto cleanup1; @@ -351,8 +351,6 @@ void lxcFreeFuse(virLXCFusePtr *f) fuse_exit(fuse->fuse); virMutexUnlock(&fuse->lock); - virThreadJoin(&fuse->thread); - VIR_FREE(fuse->mountpoint); VIR_FREE(*f); } -- 1.7.11.7

4 3