[libvirt] compiler warning about unused in_open parameter
by Gustavo Morozowski
Hi,
I am trying to build 0.8.0 for windows using Fedora 12 [1], the
compile is breaking with the message -
make[3]: Entering directory `/home/gustavo/Devel/libvirt-0.8.0/src'
CC libvirt_driver_remote_la-remote_driver.lo
cc1: warnings being treated as errors
remote/remote_driver.c: In function 'remoteAuthenticate':
remote/remote_driver.c:6478: error: unused parameter 'in_open'
[-Wunused-parameter]
It seems 'in_open' is not used when both SASL and POLKIT are disabled.
Gustavo
[1] https://www.redhat.com/archives/libvir-list/2010-March/msg00612.html
14 years, 7 months
[libvirt] [PATCH] Don't ship generated python/libvirt.? files.
by Philipp Hahn
libvirt.c and libvirt.h are auto-generated files. Mentioning their names
in *_SOURCES includes them in the distribution. During an out-of-tree
build these shipped files are included instead of the auto-generated
version, potentially breaking the build (as it happend in 0.8.0, because
the shipped libvirt.h was missing the declaration for
'libvirt_virDomainUpdateDeviceFlags')
Use the nodist_*_SOURCES automake variable instead.
Signed-off-by: Philipp Hahn <hahn(a)univention.de>
---
python/Makefile.am | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
14 years, 7 months
[libvirt] [PATCH] Support for faking emulator in qemuxml2argv tests
by Jiri Denemark
Hi,
I thought I'd need it but turned out I didn't. In case someone else finds a
good use for that, here's the patch. The idea was to provide a way to fake
qemu responses on -M ?, -cpu ?, and the like.
Jirka
>From d1fa129d1018cd66d2bbdadc68a5f72e91bc6b0c Mon Sep 17 00:00:00 2001
Message-Id: <d1fa129d1018cd66d2bbdadc68a5f72e91bc6b0c.1271681198.git.jdenemar(a)redhat.com>
From: Jiri Denemark <jdenemar(a)redhat.com>
Date: Fri, 16 Apr 2010 08:20:33 +0200
Subject: [PATCH] Support for faking emulator in qemuxml2argv tests
Mail-Followup-To: libvir-list(a)redhat.com
This patch allows for using custom scripts instead of /usr/bin/qemu
emulator in domain XML. To do so, one can specify relative path to the
custom script in <emulator/>. The path needs to be relative to
qemuxml2argvdata directory and it will be transparently made absolute in
runtime. The expected command line needs to contain the exact relative
path as was used in domain XML.
---
tests/qemuxml2argvtest.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index beb5dcd..da28c93 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -38,6 +38,7 @@ static int testCompareXMLToArgvFiles(const char *xml,
virDomainDefPtr vmdef = NULL;
virDomainChrDef monitor_chr;
virConnectPtr conn;
+ char *emulator = NULL;
if (!(conn = virGetConnect()))
goto fail;
@@ -49,6 +50,17 @@ static int testCompareXMLToArgvFiles(const char *xml,
VIR_DOMAIN_XML_INACTIVE)))
goto fail;
+ if (vmdef->emulator && *vmdef->emulator != '/') {
+ emulator = vmdef->emulator;
+ vmdef->emulator = NULL;
+ if (virAsprintf(&vmdef->emulator, "%s/qemuxml2argvdata/%s",
+ abs_srcdir, emulator) < 0) {
+ vmdef->emulator = emulator;
+ emulator = NULL;
+ goto fail;
+ }
+ }
+
if (extraFlags & QEMUD_CMD_FLAG_DOMID)
vmdef->id = 6;
else
@@ -86,6 +98,12 @@ static int testCompareXMLToArgvFiles(const char *xml,
NULL, NULL, migrateFrom, NULL) < 0)
goto fail;
+ if (emulator && *argv) {
+ free(*(char**) argv);
+ *argv = emulator;
+ emulator = NULL;
+ }
+
len = 1; /* for trailing newline */
tmp = qenv;
while (*tmp) {
@@ -125,6 +143,7 @@ static int testCompareXMLToArgvFiles(const char *xml,
ret = 0;
fail:
+ free(emulator);
free(actualargv);
if (argv) {
tmp = argv;
--
1.7.0.4
14 years, 7 months
[libvirt] [PATCH 0/6] CPU selection fixes and tests
by Jiri Denemark
4 out of the 8 tests added by patch 2/6 fail with current libvirt. After
5/6 some of them pass and some of them fail in a different way. After
6/6 all of them pass.
Jirka
Jiri Denemark (6):
Fake host CPU for qemu tests
Tests for CPU selection in qemu driver
Deal with CPU models in []
Move MIN macro to util.h so that others can use it
Support removing features when converting data to CPU
Use configured CPU model if possible
src/cpu/cpu.c | 8 +-
src/cpu/cpu.h | 6 +-
src/cpu/cpu_x86.c | 82 +++++++++++++++-----
src/qemu/qemu_conf.c | 39 ++++++++--
src/util/util.c | 4 -
src/util/util.h | 4 +
.../qemuxml2argvdata/qemuxml2argv-cpu-exact1.args | 1 +
tests/qemuxml2argvdata/qemuxml2argv-cpu-exact1.xml | 28 +++++++
.../qemuxml2argvdata/qemuxml2argv-cpu-exact2.args | 1 +
tests/qemuxml2argvdata/qemuxml2argv-cpu-exact2.xml | 35 ++++++++
.../qemuxml2argv-cpu-minimum1.args | 1 +
.../qemuxml2argvdata/qemuxml2argv-cpu-minimum1.xml | 21 +++++
.../qemuxml2argv-cpu-minimum2.args | 1 +
.../qemuxml2argvdata/qemuxml2argv-cpu-minimum2.xml | 25 ++++++
.../qemuxml2argvdata/qemuxml2argv-cpu-strict1.args | 1 +
.../qemuxml2argvdata/qemuxml2argv-cpu-strict1.xml | 38 +++++++++
.../qemuxml2argv-cpu-topology1.args | 1 +
.../qemuxml2argv-cpu-topology1.xml | 21 +++++
.../qemuxml2argv-cpu-topology2.args | 1 +
.../qemuxml2argv-cpu-topology2.xml | 22 +++++
.../qemuxml2argv-cpu-topology3.args | 1 +
.../qemuxml2argv-cpu-topology3.xml | 21 +++++
tests/qemuxml2argvtest.c | 9 ++
tests/testutilsqemu.c | 30 +++++++-
24 files changed, 362 insertions(+), 39 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact1.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact1.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact2.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact2.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum1.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum1.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum2.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum2.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-strict1.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-strict1.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology1.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology1.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology2.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology2.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology3.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology3.xml
14 years, 7 months
[libvirt] [PATCH] Fixup python binding for virDomainSnapshot APIs
by Daniel P. Berrange
The generator code was totally wrong for the virDomainSnapshot
APIs, not generating the wrapper class, and giving methods the
wrong names
* generator.py: Set metadata for virDomainSnapshot type & APIs
* libvirt-override-api.xml, libvirt-override.c: Hand-code the
virDomainSnapshotListNames glue layer
---
python/generator.py | 27 ++++++++++++++++++++++-
python/libvirt-override-api.xml | 6 +++++
python/libvirt-override.c | 46 +++++++++++++++++++++++++++++++++++++++
3 files changed, 78 insertions(+), 1 deletions(-)
diff --git a/python/generator.py b/python/generator.py
index cb9f3d9..6f082e8 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -243,6 +243,9 @@ py_types = {
'const virStream *': ('O', "virStream", "virStreamPtr", "virStreamPtr"),
'virDomainSnapshotPtr': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"),
+ 'const virDomainSnapshotPtr': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"),
+ 'virDomainSnapshot *': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"),
+ 'const virDomainSnapshot *': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"),
}
py_return_types = {
@@ -277,6 +280,7 @@ skip_impl = (
'virConnectListDefinedStorageVols',
'virConnectListDefinedInterfaces',
'virConnectListNWFilters',
+ 'virDomainSnapshotListNames',
'virConnGetLastError',
'virGetLastError',
'virDomainGetInfo',
@@ -643,6 +647,8 @@ classes_type = {
"virStream *": ("._o", "virStream(self, _obj=%s)", "virStream"),
"virConnectPtr": ("._o", "virConnect(_obj=%s)", "virConnect"),
"virConnect *": ("._o", "virConnect(_obj=%s)", "virConnect"),
+ "virDomainSnapshotPtr": ("._o", "virDomainSnapshot(self,_obj=%s)", "virDomainSnapshot"),
+ "virDomainSnapshot *": ("._o", "virDomainSnapshot(self, _obj=%s)", "virDomainSnapshot"),
}
converter_type = {
@@ -651,7 +657,7 @@ converter_type = {
primary_classes = ["virDomain", "virNetwork", "virInterface",
"virStoragePool", "virStorageVol",
"virConnect", "virNodeDevice", "virSecret",
- "virStream"]
+ "virStream", "virDomainSnapshot"]
classes_ancestor = {
}
@@ -663,6 +669,7 @@ classes_destructors = {
"virStorageVol": "virStorageVolFree",
"virNodeDevice" : "virNodeDeviceFree",
"virSecret": "virSecretFree",
+ "virDomainSnapshot": "virDomainSnapshotFree",
# We hand-craft __del__ for this one
#"virStream": "virStreamFree",
}
@@ -767,6 +774,24 @@ def nameFixup(name, classe, type, file):
elif name[0:12] == "virDomainGet":
func = name[12:]
func = string.lower(func[0:1]) + func[1:]
+ elif name[0:29] == "virDomainSnapshotLookupByName":
+ func = name[9:]
+ func = string.lower(func[0:1]) + func[1:]
+ elif name[0:26] == "virDomainSnapshotListNames":
+ func = name[9:]
+ func = string.lower(func[0:1]) + func[1:]
+ elif name[0:20] == "virDomainSnapshotNum":
+ func = name[9:]
+ func = string.lower(func[0:1]) + func[1:]
+ elif name[0:26] == "virDomainSnapshotCreateXML":
+ func = name[9:]
+ func = string.lower(func[0:1]) + func[1:]
+ elif name[0:24] == "virDomainSnapshotCurrent":
+ func = name[9:]
+ func = string.lower(func[0:1]) + func[1:]
+ elif name[0:17] == "virDomainSnapshot":
+ func = name[17:]
+ func = string.lower(func[0:1]) + func[1:]
elif name[0:9] == "virDomain":
func = name[9:]
func = string.lower(func[0:1]) + func[1:]
diff --git a/python/libvirt-override-api.xml b/python/libvirt-override-api.xml
index e95c46a..6f1bc04 100644
--- a/python/libvirt-override-api.xml
+++ b/python/libvirt-override-api.xml
@@ -243,5 +243,11 @@
<arg name='xmlCPUs' type='const char **' info='array of XML descriptions of host CPUs'/>
<arg name='flags' type='unsigned int' info='fine-tuning flags, currently unused, pass 0.'/>
</function>
+ <function name='virDomainSnapshotListNames' file='python'>
+ <info>collect the list of snapshots for the given domain</info>
+ <arg name='dom' type='virDomainPtr' info='pointer to the domain'/>
+ <arg name='flags' type='unsigned int' info='flags, curently unused'/>
+ <return type='str *' info='the list of Names of None in case of error'/>
+ </function>
</symbols>
</api>
diff --git a/python/libvirt-override.c b/python/libvirt-override.c
index 02bc313..ce21f60 100644
--- a/python/libvirt-override.c
+++ b/python/libvirt-override.c
@@ -943,6 +943,51 @@ libvirt_virConnectListDefinedDomains(PyObject *self ATTRIBUTE_UNUSED,
}
static PyObject *
+libvirt_virDomainSnapshotListNames(PyObject *self ATTRIBUTE_UNUSED,
+ PyObject *args) {
+ PyObject *py_retval;
+ char **names = NULL;
+ int c_retval, i;
+ virDomainPtr dom;
+ PyObject *pyobj_dom;
+ int flags;
+
+ if (!PyArg_ParseTuple(args, (char *)"Oi:virDomainSnapshotListNames", &pyobj_dom, &flags))
+ return(NULL);
+ dom = (virDomainPtr) PyvirDomain_Get(pyobj_dom);
+
+ LIBVIRT_BEGIN_ALLOW_THREADS;
+ c_retval = virDomainSnapshotNum(dom, flags);
+ LIBVIRT_END_ALLOW_THREADS;
+ if (c_retval < 0)
+ return VIR_PY_NONE;
+
+ if (c_retval) {
+ names = malloc(sizeof(*names) * c_retval);
+ if (!names)
+ return VIR_PY_NONE;
+ LIBVIRT_BEGIN_ALLOW_THREADS;
+ c_retval = virDomainSnapshotListNames(dom, names, c_retval, flags);
+ LIBVIRT_END_ALLOW_THREADS;
+ if (c_retval < 0) {
+ free(names);
+ return VIR_PY_NONE;
+ }
+ }
+ py_retval = PyList_New(c_retval);
+
+ if (names) {
+ for (i = 0;i < c_retval;i++) {
+ PyList_SetItem(py_retval, i, libvirt_constcharPtrWrap(names[i]));
+ free(names[i]);
+ }
+ free(names);
+ }
+
+ return(py_retval);
+}
+
+static PyObject *
libvirt_virDomainGetInfo(PyObject *self ATTRIBUTE_UNUSED, PyObject *args) {
PyObject *py_retval;
int c_retval;
@@ -3275,6 +3320,7 @@ static PyMethodDef libvirtMethods[] = {
{(char *) "virConnectListDefinedInterfaces", libvirt_virConnectListDefinedInterfaces, METH_VARARGS, NULL},
{(char *) "virConnectBaselineCPU", libvirt_virConnectBaselineCPU, METH_VARARGS, NULL},
{(char *) "virDomainGetJobInfo", libvirt_virDomainGetJobInfo, METH_VARARGS, NULL},
+ {(char *) "virDomainSnapshotListNames", libvirt_virDomainSnapshotListNames, METH_VARARGS, NULL},
{NULL, NULL, 0, NULL}
};
--
1.6.6.1
14 years, 7 months
[libvirt] KVM Forum 2010: Call for Papers
by KVM Forum 2010 Program Committee
=================================================================
CALL FOR PAPERS
KVM Forum 2010
=================================================================
DESCRIPTION
The KVM Forum is back! After a break last year we're proud to present
this year's gathering around KVM again. The idea is to have everyone
involved with KVM development come together to talk about the future
and current state of KVM, teaching everyone some pieces of the puzzle
they might be missing without.
So if you're a KVM developer, mark the dates in your calendar! If
possible, also submit a talk -- we're interested in a wide variety of
KVM topics, so don't hesitate to propose a talk on your work.
If you're not a KVM developer, please read on nevertheless (or jump to
END USER COLLABORATION).
DATES / LOCATION
Conference: August 9 - 10, 2010
Location: Renaissance Boston Waterfront in Boston, MA
Abstracts due: May 14th, 2010
Notification: May 28th, 2010
Yes, we're colocated with LinuxCon. Tickets for the KVM Forum also count
for LinuxCon.
http://events.linuxfoundation.org/component/registrationpro/?func=details...
PROCESS
At first check if it's before May 14th. If you're past that date, you're
out of luck. Now try to think hard and come up with a great idea that
you could talk about. Once you have that set, we need you to write up
a short abstract (~150 words) on it. In your submission please note
how long your talk will take. Slots vary in length up to one hour.
Also include in your proposal the proposal type -- one of: technical talk,
breakout session, or end-user talk. Add that information to the abstract
and submit it at the following URL:
http://events.linuxfoundation.org/cfp/cfp-add
Now, wait until May 24th. You will receive a notification on whether
your talk was accepted or not.
SCOPE OF TALKS
We have a list of suggested presentation topics below. These suggestions
are just for guidance, please feel free to submit a proposal on any
of these or related topics. In general, the more it's about backend
infrastructure, the better.
KVM
- Scaling and performance
- Nested virtualization
- I/O improvements
- Driver domains
- Time keeping
- Memory management (page sharing, swapping, huge pages, etc)
- Fault tolerance
- VEPA, vswitch
Embedded KVM
- KVM on ARM, PPC, MIPS, ...?
- Real-time requirements host/guest
- Device pass-through w/o iommu
- Custom device/platform models
QEMU
- Device model improvements
- New devices
- Security model
- Scaling and performance
- Desktop virtualization
- Increasing robustness
- Management interfaces
- QMP protocol and implementation
- Live migration
Virtio
- Speeding up existing devices
- Vhost
- Alternatives
- Using virtio in non-kvm environments
- Virtio on non-Linux
Management infrastructure
- Libvirt
- Kvm autotest
- Easy networking
- Qemud
BREAKOUT SESSION
We will reserve some time each day to break out for working sessions.
These sessions will be less formal than a presentation and more focused
on developing a solution to some real development issue. If you are
interested in getting developers together to hack on some code, submit
your proposal and just make it clear it's a breakout session proposal.
END-USER COLLABORATION
One of the big challenges as developers is to know what, where and how
people actually use our software. To solve this issue at least a little,
there will be a few slots reserved for end users talking about their
deployments, problems and achievements.
So if you have a KVM based deployment running in production or are about
to roll out one, please also submit a talk (see PROCESS), and simply
mark it asn an end-user collaboration proposal. We would love to have
an open discussion of fields where KVM/Qemu can still improve and you
would have the unique chance to steer that process!
Keep in mind that most of the Forum will be focused on development though,
so we suggest you also come with a good portion of technical interest :-).
And of course, no product marketing please! The purpose is to engage
with KVM developers.
LIGHTNING TALKS
In addition to submitted talks we will also have some room for lightning
talks. So if you have something you think might be done until the KVM
Forum, but you're not sure you could fill 15 minutes with it. Or if you
don't know if you'll make it until there, just keep in mind that you
will still get the chance to talk about it. Lightning talk submissions
and scheduling will be handled on-site at KVM Forum.
Thank you for your interest in KVM. We're looking forward to your
submissions and seeing you at the KVM Forum 2010 in August! Now, start
thinking about that talk you want to give.
Thanks,
your KVM Forum 2010 Program Commitee
Alexander Graf, Novell
Anthony Liguori, IBM
Avi Kivity, Red Hat
Chris Wright, Red Hat
Dor Laor, Red Hat
Jan Kiszka, Siemens
Please contact us with any questions or comments.
KVM-Forum-2010-PC(a)redhat.com
14 years, 7 months
[libvirt] [PATCH] Fix crash in nwfilter driver check
by Daniel P. Berrange
The nwfilterDriverActive() could de-reference a NULL pointer
if it hadn't be started at the point it was called. It was
also not thread safe, since it lacked locking around data
accesses.
* src/nwfilter/nwfilter_driver.c: Fix locking & NULL checks
in nwfilterDriverActive()
---
src/nwfilter/nwfilter_driver.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/nwfilter/nwfilter_driver.c b/src/nwfilter/nwfilter_driver.c
index 58df4e1..412c5b8 100644
--- a/src/nwfilter/nwfilter_driver.c
+++ b/src/nwfilter/nwfilter_driver.c
@@ -153,9 +153,16 @@ nwfilterDriverReload(void) {
*/
static int
nwfilterDriverActive(void) {
- if (!driverState->pools.count)
+ int ret;
+
+ if (!driverState)
return 0;
- return 1;
+
+ nwfilterDriverLock(driverState);
+ ret = driverState->pools.count ? 1 : 0;
+ nwfilterDriverUnlock(driverState);
+
+ return ret;
}
/**
--
1.6.6.1
14 years, 7 months
[libvirt] ESX and inaccessible storage pools
by Matthias Bolte
I'm currently implementing the storage driver for ESX and have a
mapping problem.
libvirt storage pools can be either running or inactive just like the
domain. ESX is a bit different here. A datastore is always active. It
can be inaccessible, e.g. if an NFS is mounted as datastore but the
NFS server went unreachable. I discussed this with Daniel on IRC and
he summarized it like this:
<DV> they are defined, the system knows them, but they are not
available for use
The question is, what should the ESX driver do with inaccessible datastores?
Option 1: They could just be represented as inactive storage pools,
but libvirt's semantic for inactive storage pools includes that the
user can start an inactive storage pool. That's not possible for an
inaccessible datastore, so the driver would report an error if a user
tries to start an inaccessible storage pool.
Option 2: Just ignore inaccessible datastores and make the ESX storage
driver to pretend that they don't exist. But this would hide
information from the user.
Option 3: Extend libvirt's API for inaccessible storage pools.
There are possibly other options and I'd like to hear your comments
and suggestions.
Matthias
14 years, 7 months
[libvirt] [RFC PATCH 0/5] Qemu Monitor Passthrough
by Chris Lalancette
Hello,
As we discussed on the list, here are RFC patches that allow
both qemu monitor passthrough and the ability to specify extra
arguments to be passed on the qemu command-line. I've specifically
not done the more complicated regex command-line editing for now,
since we don't have consensus on it.
There are a few outstanding issues with these patches:
1) Should we have a separate structure for the per-driver qemuMonitorCommand
entry point?
2) Due to the way that virsh parses command-line arguments, it's not
possible to pass it an argument that has spaces (even if you properly
quote it). Therefore I have a hack in place that will convert ^ to
space before passing it along, which is pretty crappy. How should we go about
fixing this? Fix virsh argument parsing, or go about it a different way?
Questions or comments about the patch series are welcome.
Chris Lalancette
14 years, 7 months
