I noticed a new test failure on rawhide,
ran valgrind ./qemuxml2xmltest and got this:
==14847== Invalid free() / delete / delete[]
==14847==at 0x4A0609F: free (vg_replace_malloc.c:323)
==14847==by 0x409DF8: qemudParseXML (qemu_conf.c:2149)
==14847==by 0x40CBE0: qemudParseVMDef
Hi Dan,
On a system with stock rawhide kernel (not the xen one), I get two
new test failures because virCapabilitiesSupportsGuestOSType(caps, xen)
returns 0.
$ ./qemuxml2xmltest
1) QEMU XML-2-XML minimal... OK
2) QEMU XML-2-XML boot-cdrom
On Thu, May 15, 2008 at 05:56:57PM +0200, Jim Meyering wrote:
From db0ed598dfc045f3937a3629a432d2d703449f50 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Wed, 14 May 2008 23:06:15 +0200
Subject: [PATCH] start using c-ctype functions
Up to now, we've been avoiding
On Fri, May 16, 2008 at 08:21:07AM +0200, Jim Meyering wrote:
I noticed a new test failure on rawhide,
ran valgrind ./qemuxml2xmltest and got this:
Sure, +1, thanks !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library
Daniel Veillard [EMAIL PROTECTED] wrote:
On Thu, May 15, 2008 at 05:56:57PM +0200, Jim Meyering wrote:
From db0ed598dfc045f3937a3629a432d2d703449f50 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Wed, 14 May 2008 23:06:15 +0200
Subject: [PATCH] start using c-ctype
Daniel Veillard [EMAIL PROTECTED] wrote:
+/* Convert C from hexadecimal character to integer. */
+static int
+hextobin (unsigned char c)
+{
+ switch (c)
+{
+default: return c - '0';
+case 'a': case 'A': return 10;
+case 'b': case 'B': return 11;
+case 'c': case 'C':
On Fri, May 16, 2008 at 09:06:41AM +0200, Jim Meyering wrote:
Hi Dan,
On a system with stock rawhide kernel (not the xen one), I get two
new test failures because virCapabilitiesSupportsGuestOSType(caps, xen)
returns 0.
Yes, the autobuild failed on that too. I'll do a patch to disable those
On Fri, May 16, 2008 at 10:36:09AM +0900, Atsushi SAKAI wrote:
Hi, Dan
Thank you for commenting this.
I am eased to hear this.
I also agrees this issue has many task.
p.s.
I want to know the possibility of fine grained access control in libvirt,
since our young guy is investigating the
On Thu, May 15, 2008 at 08:55:25PM +0200, Gerd Hoffmann wrote:
Daniel P. Berrange wrote:
is required for any serious development work. I *hate* to having to
create a wrapper script each time I need to pass in additional
parameters, and I'd *love* to see libvirt being a bit more developer
This patch makes the code that probes QEMU args explicitly add the -help
argument. This works around a problem with certain KVM builds which refuse
to run if executed without -help, and no KVM modules are present.
It also removes the set of setenv() since that changes libvirtd's environ
and
The QEMU test suites rely on the QEMU/KVM/Xenner binaries being present
in /usr/bin. This has obvious problems and is unneccessary. The solution
is to not use the qemudCapsInit() function which initializes capabilities
based on binaries present. Instead I add a custom impl just for the test
cases
When used with the --daemon arg, libvirtd will write out a pid file to
/var/run/libvirtd.pid and exit if this file already exists. Unfortuantely
it does this quite late in its startup procedure - in particular *after*
the call to qemudInitialize(), which in turns initializes the drivers,
which in
On Fri, 16 May 2008, Daniel P. Berrange wrote:
When used with the --daemon arg, libvirtd will write out a pid file to
/var/run/libvirtd.pid and exit if this file already exists. Unfortuantely
it does this quite late in its startup procedure - in particular *after*
the call to
Daniel P. Berrange [EMAIL PROTECTED] wrote:
This patch makes the code that probes QEMU args explicitly add the -help
argument. This works around a problem with certain KVM builds which refuse
to run if executed without -help, and no KVM modules are present.
Sounds obtuse enough to deserve a
Daniel P. Berrange [EMAIL PROTECTED] wrote:
The QEMU test suites rely on the QEMU/KVM/Xenner binaries being present
in /usr/bin. This has obvious problems and is unneccessary. The solution
is to not use the qemudCapsInit() function which initializes capabilities
based on binaries present.
On Fri, May 16, 2008 at 05:05:08PM +0100, Daniel P. Berrange wrote:
When used with the --daemon arg, libvirtd will write out a pid file to
/var/run/libvirtd.pid and exit if this file already exists. Unfortuantely
it does this quite late in its startup procedure - in particular *after*
the call
Running make check under valgrind exposed at least
the first. Then, I spotted the other.
* src/qemu_conf.c (qemudParseXML): Free obj unconditionally.
---
src/qemu_conf.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index
On Fri, May 16, 2008 at 06:44:48PM +0200, Jim Meyering wrote:
Running make check under valgrind exposed at least
the first. Then, I spotted the other.
ACK.
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o-
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Fri, May 16, 2008 at 06:44:48PM +0200, Jim Meyering wrote:
Running make check under valgrind exposed at least
the first. Then, I spotted the other.
ACK.
speedy ;-)
Committed.
Actually there's one more, but I don't have time for it right now:
On Thu, May 15, 2008 at 10:24:35PM +0100, Daniel P. Berrange wrote:
Xenner doesn't start its help output right at the start of line,
Ah. :/
and there isn't any other output there that causes ambiguity in
current qemu help output:
# qemu-kvm | grep -- -drive
-drive
The patch below fixes an issue in the python bindings with the
vir*Destroy methods. After the object is successfully destroyed,
the payload is cleared, using 'self._o = None'. This unfortunately
screws up virt object reference counts, as the payload should be
free'd using the appropriate vir*Free
KVM added ability to get the thread ID for vCPUs via the monitor
(qemu) info cpus
* CPU #0: pc=0x0000 thread_id=11463
CPU #1: pc=0xfff0 thread_id=11464
CPU #2: pc=0xfff0 thread_id=11465
With this we have enough information to be able to support vCPU
The XML format allows for an initial CPU mask to be specified for a guests
vCPUs. eg with this XML:
vcpu cpuset='1-4,8-20,525'1/vcpu
Since we have CPU pinning support from my previous patch, adding in the
initial pinning is fairly easy. We first pass the '-S' arg to QEMU when
forking it. This
On Fri, 16 May 2008, Daniel P. Berrange wrote:
The XML format allows for an initial CPU mask to be specified for a guests
vCPUs. eg with this XML:
vcpu cpuset='1-4,8-20,525'1/vcpu
Since we have CPU pinning support from my previous patch, adding in the
initial pinning is fairly easy. We
Stefan de Konink wrote:
On Fri, 16 May 2008, Daniel P. Berrange wrote:
The XML format allows for an initial CPU mask to be specified for a guests
vCPUs. eg with this XML:
vcpu cpuset='1-4,8-20,525'1/vcpu
Since we have CPU pinning support from my previous patch, adding in the
initial
Jim Meyering wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
This patch makes the code that probes QEMU args explicitly add the -help
argument. This works around a problem with certain KVM builds which refuse
to run if executed without -help, and no KVM modules are present.
Sounds obtuse
Daniel P. Berrange wrote:
Since we have CPU pinning support from my previous patch, adding in the
initial pinning is fairly easy. We first pass the '-S' arg to QEMU when
forking it.
If -S is always added, this becomes unnecessary (qemu_conf.c:2823):
if (vm-migrateFrom[0]) {
if
27 matches
Mail list logo
