[libvirt] [PATCH] qemu: Start nested job in qemuDomainCheckEjectableMedia
by Jiri Denemark
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
12 years, 1 month
[libvirt] [RH-BZ #595428] 'virsh list' should output more information 'xm list'
by Maxim Sditanov
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
12 years, 1 month
[libvirt] call for volunteer: FLOSS weekly podcast opportunity
by Eric Blake
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
12 years, 1 month
[libvirt] [PATCH] qemu: fix memory leak in virDomainGetVcpus
by Laine Stump
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
12 years, 1 month
[libvirt] [PATCH] python: improve conversion validation
by Eric Blake
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
12 years, 1 month
Re: [libvirt] Start of freeze for libvirt-0.9.11 and availability of rc1
by Maxim Sditanov
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
12 years, 1 month
[libvirt] [PATCH] libvirt:qemu: fix max_balloon less than cur_balloon
by Zhou Peng
In qemuDomainGetXMLDesc, if cur_balloon is bigger than max_balloon,
max_balloon should be updated too, otherwise the currentMemory is
bigger than memory in dumped xml, which will produce invalid
checkpoint by virsh-save.
The bug appears like this below:
$virsh save vm-num foo.ckp
$virsh restore foo.ckp
error: XML error: current memory '824320k' exceeds maximum '824288k'
Signed-off-by: Zhou Peng <ailvpeng25(a)gmail.com>
---
src/qemu/qemu_driver.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 0d3b0bd..96d3219 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -4485,7 +4485,13 @@ endjob:
if (err < 0)
goto cleanup;
if (err > 0)
+ {
vm->def->mem.cur_balloon = balloon;
+ if (balloon > vm->def->mem.max_balloon)
+ {
+ vm->def->mem.max_balloon = balloon;
+ }
+ }
/* err == 0 indicates no balloon support, so ignore it */
}
}
--
1.7.7.6
12 years, 1 month
