April 2012 - Devel - libvirt List Archives

[libvirt] [RFC: PATCH 00/13] live block migration via virDomainBlockCopy
by Eric Blake 03 Apr '12

03 Apr '12

This is in response to my discussion with Paolo here: https://www.redhat.com/archives/libvir-list/2012-March/msg01171.html It also picks up an old patch from Adam here (now split into two): https://www.redhat.com/archives/libvir-list/2012-January/msg00562.html Patches 1-12 are in pretty good shape, while patch 13 is still a work in progress. I can test a lot of the pieces, but still have several patches to go before I can fully test the new API. I'm posting this now to at least start some review on the earlier pieces, and to get consensus that the API and XML changes are correct. None of these patches should be applied until after 0.9.11 is released, and even then, we still want confirmation of whether upstream qemu 1.1 will include complete support for block mirroring. For anyone trying to backport this feature to 0.9.10 .so API, I've made sure that you can just omit patches 5 and 6, and that everything else will backport cleanly to give you the new feature through just the public virDomainBlockRebase() call. Adam Litke (2): blockjob: add API for async virDomainBlockJobAbort blockjob: wire up qemu async virDomainBlockJobAbort Eric Blake (11): blockjob: add new API flags blockjob: add 'blockcopy' to virsh blockjob: add virDomainBlockCopy blockjob: enhance virsh 'blockcopy' blockjob: wire up RPC for block copy blockjob: enhance xml to track mirrors across libvirtd restart blockjob: react to active block copy blockjob: expose qemu commands for mirrored storage migration blockjob: query backing file of a disk blockjob: return appropriate event and info WIP: blockjob: implement block copy for qemu docs/apibuild.py | 1 + docs/formatdomain.html.in | 11 ++ docs/schemas/domaincommon.rng | 19 +++- include/libvirt/libvirt.h.in | 50 +++++++++- include/libvirt/virterror.h | 1 + src/conf/domain_conf.c | 77 +++++++++++++++ src/conf/domain_conf.h | 14 +++ src/driver.h | 6 + src/libvirt.c | 216 +++++++++++++++++++++++++++++++++++++++-- src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 + src/qemu/qemu_capabilities.c | 3 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_conf.h | 1 + src/qemu/qemu_driver.c | 211 ++++++++++++++++++++++++++++++++++++++-- src/qemu/qemu_hotplug.c | 7 ++ src/qemu/qemu_monitor.c | 60 +++++++++++- src/qemu/qemu_monitor.h | 23 +++++ src/qemu/qemu_monitor_json.c | 128 ++++++++++++++++++++++-- src/qemu/qemu_monitor_json.h | 21 ++++- src/qemu/qemu_process.c | 19 ++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 13 +++- src/remote_protocol-structs | 10 ++ src/rpc/gendispatch.pl | 1 + src/util/virterror.c | 6 + tools/virsh.c | 135 ++++++++++++++++++++----- tools/virsh.pod | 33 ++++++- 28 files changed, 1007 insertions(+), 68 deletions(-) -- 1.7.7.6

1 13

[libvirt] [PATCH 0/2] use qemu's dump-guest-meory when vm uses host device
by Wen Congyang 03 Apr '12

03 Apr '12

Currently, we use migrate to dump guest's memory. There is one restriction in migrate command: the device's status should be stored in qemu because the device's status should be passed to target machine. If we passthrough a host device to guest, the device's status is stored in the real device. So migrate command will fail. We usually use dump when guest is panicked. So there is no need to store device's status in the vmcore. qemu will have a new monitor command dump-guest-memory to dump guest memory, but it doesn't support async now(it will support later when the common async API is implemented). So I use dump-guest-memory only when the guest uses host device in this patchset. Wen Congyang (2): qemu: implement qemu's dump-guest-memory qemu: try to use qemu's dump-guest-meory when vm uses host device src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 42 ++++++++++++++++++++- src/qemu/qemu_monitor.c | 32 ++++++++++++++++ src/qemu/qemu_monitor.h | 13 +++++++ src/qemu/qemu_monitor_json.c | 42 +++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 7 ++++ src/qemu/qemu_monitor_text.c | 83 ++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_monitor_text.h | 7 ++++ 9 files changed, 226 insertions(+), 2 deletions(-)

2 6

[libvirt] 0.9.11 rc2, FreeBSD
by Jason Helfman 02 Apr '12

02 Apr '12

Hi, I was able to get rc2 to build on FreeBSD. Here are the buildlogs for current release of FreeBSD (9): http://lorie.secnap.net/tb/index.php?action=display_markup_log&build=9-jgh_… http://lorie.secnap.net/tb/index.php?action=display_markup_log&build=9-jgh_… -jgh -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5

2 6

[libvirt] [PATCH] qemu: Start nested job in qemuDomainCheckEjectableMedia
by Jiri Denemark 02 Apr '12

02 Apr '12

Originally, qemuDomainCheckEjectableMedia was entering monitor with qemu driver lock. Commit 2067e31bf97667eab9f111b496f5e9a44e827c5b, which I made to fix that, revealed another issue we had (but didn't notice it since the driver was locked): we didn't set nested job when qemuDomainCheckEjectableMedia is called during migration. Thus the original fix I made was wrong. --- I'll try to come up with something to help avoid such issues in the future. src/qemu/qemu_driver.c | 5 ++++- src/qemu/qemu_hotplug.c | 12 +++++++----- src/qemu/qemu_hotplug.h | 4 +++- src/qemu/qemu_process.c | 2 +- 4 files changed, 15 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 7e6d59c..dd79973 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8816,6 +8816,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain, struct qemud_driver *driver = domain->conn->privateData; virDomainObjPtr vm; char *xml = NULL; + enum qemuDomainAsyncJob asyncJob; virCheckFlags(QEMU_MIGRATION_FLAGS, NULL); @@ -8832,9 +8833,11 @@ qemuDomainMigrateBegin3(virDomainPtr domain, if ((flags & VIR_MIGRATE_CHANGE_PROTECTION)) { if (qemuMigrationJobStart(driver, vm, QEMU_ASYNC_JOB_MIGRATION_OUT) < 0) goto cleanup; + asyncJob = QEMU_ASYNC_JOB_MIGRATION_OUT; } else { if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0) goto cleanup; + asyncJob = QEMU_ASYNC_JOB_NONE; } if (!virDomainObjIsActive(vm)) { @@ -8847,7 +8850,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain, * We don't want to require them on the destination. */ - if (qemuDomainCheckEjectableMedia(driver, vm) < 0) + if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0) goto endjob; if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname, diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 3b6eb9d..857b980 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -155,16 +155,18 @@ error: int qemuDomainCheckEjectableMedia(struct qemud_driver *driver, - virDomainObjPtr vm) + virDomainObjPtr vm, + enum qemuDomainAsyncJob asyncJob) { qemuDomainObjPrivatePtr priv = vm->privateData; - virHashTablePtr table; + virHashTablePtr table = NULL; int ret = -1; int i; - qemuDomainObjEnterMonitorWithDriver(driver, vm); - table = qemuMonitorGetBlockInfo(priv->mon); - qemuDomainObjExitMonitorWithDriver(driver, vm); + if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) == 0) { + table = qemuMonitorGetBlockInfo(priv->mon); + qemuDomainObjExitMonitorWithDriver(driver, vm); + } if (!table) goto cleanup; diff --git a/src/qemu/qemu_hotplug.h b/src/qemu/qemu_hotplug.h index 0310361..e6d7843 100644 --- a/src/qemu/qemu_hotplug.h +++ b/src/qemu/qemu_hotplug.h @@ -25,6 +25,7 @@ # define __QEMU_HOTPLUG_H__ # include "qemu_conf.h" +# include "qemu_domain.h" # include "domain_conf.h" int qemuDomainChangeEjectableMedia(struct qemud_driver *driver, @@ -32,7 +33,8 @@ int qemuDomainChangeEjectableMedia(struct qemud_driver *driver, virDomainDiskDefPtr disk, bool force); int qemuDomainCheckEjectableMedia(struct qemud_driver *driver, - virDomainObjPtr vm); + virDomainObjPtr vm, + enum qemuDomainAsyncJob asyncJob); int qemuDomainAttachPciDiskDevice(virConnectPtr conn, struct qemud_driver *driver, virDomainObjPtr vm, diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 0667a03..622739c 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3106,7 +3106,7 @@ qemuProcessReconnect(void *opaque) if (qemuProcessFiltersInstantiate(conn, obj->def)) goto error; - if (qemuDomainCheckEjectableMedia(driver, obj) < 0) + if (qemuDomainCheckEjectableMedia(driver, obj, QEMU_ASYNC_JOB_NONE) < 0) goto error; if (qemuProcessRecoverJob(driver, obj, conn, &oldjob) < 0) -- 1.7.8.5

2 2

[libvirt] [RH-BZ #595428] 'virsh list' should output more information 'xm list'
by Maxim Sditanov 02 Apr '12

02 Apr '12

Is this new feature request still https://bugs.gentoo.org/show_bug.cgi?id=366561 actual? Because virsh still show not enough information: $./virsh -c qemu:///system list --all Id Name State ---------------------------------------------------- 1 " running - winxp shut off And it will be good idea to show more detailed information or add additional flag, something like --detail. ./virsh -c qemu:///system list --all --detailed Id Name State Memory VCPU Uptime CPU IOPS ---------------------------------- ------------------------------------------------------------- 1 " running 768M 2 3hours 5% 12.1 - winxp shut off 512M 1 --- With best wishes, Maxim Sditanov

1 0

[libvirt] call for volunteer: FLOSS weekly podcast opportunity
by Eric Blake 02 Apr '12

02 Apr '12

The FLOSS weekly podcast is interested in doing an interview about libvirt development on June 6, at 9:30am Los Angeles time (UTC-7). For more information on past podcasts, see: http://twit.tv/show/floss-weekly With prodding from Justin Clift, I have volunteered to take on the task, but the show host, Randal, prefers to have two developers per show, so I'm looking for anyone else who has developed for or with libvirt, who would be interested in sharing the opportunity. You don't have to have a lot of commits under your belt, so much as having enough active interest in the project and what it enables you to do. In fact, having someone not directly tied to Red Hat as the second contact will probably provide a nicer balance to the interview. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] [PATCH] Fix typos and spacing in messages
by Yuri Chornoivan 02 Apr '12

02 Apr '12

2 1

[libvirt] [PATCH] qemu: fix memory leak in virDomainGetVcpus
by Laine Stump 02 Apr '12

02 Apr '12

https://bugzilla.redhat.com/show_bug.cgi?id=808979 The leak is really in virProcessInfoGetAffinity, as shown in the valgrind output given in the above bug report - it calls CPU_ALLOC(), but then fails to call CPU_FREE(). This leak has existed in every version of libvirt since 0.7.5. --- src/util/processinfo.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/util/processinfo.c b/src/util/processinfo.c index b1b1737..af19723 100644 --- a/src/util/processinfo.c +++ b/src/util/processinfo.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2010 Red Hat, Inc. + * Copyright (C) 2009-2010, 2012 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 @@ -140,6 +140,7 @@ realloc: for (i = 0 ; i < maxcpu ; i++) if (CPU_ISSET_S(i, masklen, mask)) VIR_USE_CPU(map, i); + CPU_FREE(mask); # else /* Legacy method uses a fixed size cpu mask, only allows upto 1024 cpus */ cpu_set_t mask; -- 1.7.7.6

2 2

[libvirt] [PATCH] python: improve conversion validation
by Eric Blake 02 Apr '12

02 Apr '12

Laszlo Ersek pointed out that in trying to convert a long to an unsigned int, we used: long long_val = ...; if ((unsigned int)long_val == long_val) According to C99 integer promotion rules, the if statement is equivalent to: (unsigned long)(unsigned int)long_val == (unsigned long)long_val since you get an unsigned comparison if at least one side is unsigned, using the largest rank of the two sides; but on 32-bit platforms, where unsigned long and unsigned int are the same size, this comparison is always true and ends up converting negative long_val into posigive unsigned int values, rather than rejecting the negative value as we had originally intended (python longs are unbounded size, and we don't want to do silent modulo arithmetic when converting to C code). Fix this by using direct comparisons, rather than casting. * python/typewrappers.c (libvirt_intUnwrap, libvirt_uintUnwrap) (libvirt_ulongUnwrap, libvirt_ulonglongUnwrap): Fix conversion checks. --- python/typewrappers.c | 27 ++++++++++++++++++++------- 1 files changed, 20 insertions(+), 7 deletions(-) diff --git a/python/typewrappers.c b/python/typewrappers.c index af209e6..4ae3ee1 100644 --- a/python/typewrappers.c +++ b/python/typewrappers.c @@ -132,7 +132,7 @@ libvirt_intUnwrap(PyObject *obj, int *val) if ((long_val == -1) && PyErr_Occurred()) return -1; - if ((int)long_val == long_val) { + if (long_val <= INT_MAX && long_val >= INT_MIN) { *val = long_val; } else { PyErr_SetString(PyExc_OverflowError, @@ -151,7 +151,7 @@ libvirt_uintUnwrap(PyObject *obj, unsigned int *val) if ((long_val == -1) && PyErr_Occurred()) return -1; - if ((unsigned int)long_val == long_val) { + if (long_val >= 0 && long_val <= UINT_MAX) { *val = long_val; } else { PyErr_SetString(PyExc_OverflowError, @@ -183,7 +183,13 @@ libvirt_ulongUnwrap(PyObject *obj, unsigned long *val) if ((long_val == -1) && PyErr_Occurred()) return -1; - *val = long_val; + if (long_val >= 0) { + *val = long_val; + } else { + PyErr_SetString(PyExc_OverflowError, + "negative Python int cannot be converted to C unsigned long"); + return -1; + } return 0; } @@ -207,16 +213,23 @@ int libvirt_ulonglongUnwrap(PyObject *obj, unsigned long long *val) { unsigned long long ullong_val = -1; + long long llong_val; /* The PyLong_AsUnsignedLongLong doesn't check the type of * obj, only accept argument of PyLong_Type, so we check it instead. */ - if (PyInt_Check(obj)) - ullong_val = PyInt_AsLong(obj); - else if (PyLong_Check(obj)) + if (PyInt_Check(obj)) { + llong_val = PyInt_AsLong(obj); + if (llong_val < 0) + PyErr_SetString(PyExc_OverflowError, + "negative Python int cannot be converted to C unsigned long long"); + else + ullong_val = llong_val; + } else if (PyLong_Check(obj)) { ullong_val = PyLong_AsUnsignedLongLong(obj); - else + } else { PyErr_SetString(PyExc_TypeError, "an integer is required"); + } if ((ullong_val == -1) && PyErr_Occurred()) return -1; -- 1.7.1

3 3

Re: [libvirt] Start of freeze for libvirt-0.9.11 and availability of rc1
by Maxim Sditanov 01 Apr '12

01 Apr '12

2012/4/1 Maxim Sditanov <feniksa(a)rambler.ru> > 2012/4/1 Feniks Gordon Freeman <feniksa(a)rambler.ru> > >> 2012/4/1 Feniks Gordon Freeman <feniksa(a)rambler.ru> >> >>> 2012/4/1 Laine Stump <laine(a)laine.org> >>> >>>> On 03/31/2012 07:56 AM, Daniel Veillard wrote: >>>> > I just made the second release candidate >>>> > >>>> > ftp://libvirt.org/libvirt/libvirt-0.9.11-rc2.tar.gz >>>> > >>>> > along with the rpms and tagged the git tree. >>>> > >>>> > It seems to work okay in my limited testing. If all goes well I would >>>> > probably push on Tuesday, >>>> > >>>> >>>> A gentoo user reported in irc (#virt on irc.oftc.net) earlier today >>>> that >>>> builds were failing for him on a fresh checkout from git: >>>> >>>> <feniksa> hi, when i compile libvirt on my gentoo i get warning: >>>> >>>> cc1: warning: unrecognized command line option >>>> "-Wno-suggest-attribute=const" >>>> cc1: warning: unrecognized command line option >>>> "-Wno-suggest-attribute=pure" >>>> >>>> <feniksa> gcc (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) 4.5.3 >>>> <feniksa> last part of conf: http://pastebin.com/gnT4Y2Ba >>>> and compile log http://pastebin.com/FcSwshzS >>>> <feniksa> laine: 2 weeks ago i didn't see this warning. Now i pull >>>> from master sources and get this warning. But, this is only because i am >>>> using gcc 4.5.3 (this is latest gcc version in gentoo OS). >>>> >>>> I haven't looked at any of this code before, but it looks to me like >>>> ql_WARN_ADD() in gnulib must not be doing the right thing, and is adding >>>> the option even though the compiler apparently doesn't support it. This >>>> probably didn't crop up before because full warnings weren't turned on >>>> in the build until March 27 in commit 851117bd. That commit does things >>>> different for builds of git trees vs. tarballs, so I don't know if this >>>> failure will affect builds of release tarballs (I asked feniksa to try a >>>> build of the rc2 tarball, but he hasn't responded yet). >>>> >>> I compiled rc2 (ftp://libvirt.org/libvirt/libvirt-0.9.11-rc2.tar.gz) Same problem present in release candidate rc2 cc1: warning: unrecognized command line option "-Wno-suggest-attribute=const" cc1: warning: unrecognized command line option "-Wno-suggest-attribute=pure" -- With best wishes, Maxim Sditanov

1 0