Detected by valgrind. Leaks are introduced in commit 6e6e9be.
* daemon/libvirtd-config.c (macro GET_CONF_STR): fix memory leaks.
How to reproduce?
% make make -C tests check TESTS=libvirtdconftest
% cd tests valgrind -v --leak-check=full ./libvirtdconftest
actual result:
==11008== 185 bytes
On Wed, Apr 11, 2012 at 05:19:33PM +0100, Daniel P. Berrange wrote:
The concept of 'default usb controllers' seems very policy based
to me different hypervisors will have different views of this.
With respect to hypervisors, since the function has a GVirConfigDomain
parameter, we could use it
On Wed, Apr 11, 2012 at 06:51:48PM +0200, Marc-André Lureau wrote:
On Wed, Apr 11, 2012 at 6:19 PM, Daniel P. Berrange berra...@redhat.com
wrote:
The concept of 'default usb controllers' seems very policy based
to me different hypervisors will have different views of this.
This is a
On Thu, Apr 12, 2012 at 03:24:08PM +0800, Alex Jia wrote:
Detected by valgrind. Leaks are introduced in commit 6e6e9be.
* daemon/libvirtd-config.c (macro GET_CONF_STR): fix memory leaks.
How to reproduce?
% make make -C tests check TESTS=libvirtdconftest
% cd tests valgrind -v
Hey,
On Thu, Apr 12, 2012 at 05:54:25AM +0300, Zeeshan Ali (Khattak) wrote:
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
libvirt-gconfig/libvirt-gconfig-domain-disk.c | 26
+
libvirt-gconfig/libvirt-gconfig-domain-disk.h |9
On 04/12/2012 04:37 PM, Daniel P. Berrange wrote:
On Thu, Apr 12, 2012 at 03:24:08PM +0800, Alex Jia wrote:
Detected by valgrind. Leaks are introduced in commit 6e6e9be.
* daemon/libvirtd-config.c (macro GET_CONF_STR): fix memory leaks.
How to reproduce?
% make make -C tests check
* daemon/libvirtd-config.c (daemonConfigFree): fix memory leaks.
How to reproduce?
% make make -C tests check TESTS=libvirtdconftest
% cd tests valgrind -v --leak-check=full ./libvirtdconftest
actual result:
==11008== 185 bytes in 5 blocks are definitely lost in loss record 3 of 5
==11008==
On Thu, Apr 12, 2012 at 05:12:12PM +0800, Alex Jia wrote:
* daemon/libvirtd-config.c (daemonConfigFree): fix memory leaks.
How to reproduce?
% make make -C tests check TESTS=libvirtdconftest
% cd tests valgrind -v --leak-check=full ./libvirtdconftest
actual result:
==11008== 185
On 04/12/2012 05:12 PM, Daniel P. Berrange wrote:
On Thu, Apr 12, 2012 at 05:12:12PM +0800, Alex Jia wrote:
* daemon/libvirtd-config.c (daemonConfigFree): fix memory leaks.
How to reproduce?
% make make -C tests check TESTS=libvirtdconftest
% cd tests valgrind -v --leak-check=full
On Wed, Apr 11, 2012 at 03:48:09PM +0200, Christophe Fergeau wrote:
[..snip..]
--- a/libvirt-gconfig/libvirt-gconfig.sym
+++ b/libvirt-gconfig/libvirt-gconfig.sym
@@ -69,6 +69,8 @@ LIBVIRT_GCONFIG_0.0.4 {
gvir_config_domain_console_set_target_type;
On Thu, Apr 12, 2012 at 05:54:25AM +0300, Zeeshan Ali (Khattak) wrote:
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
libvirt-gconfig/libvirt-gconfig-domain-disk.c | 26
+
libvirt-gconfig/libvirt-gconfig-domain-disk.h |9
On Thu, Apr 12, 2012 at 12:06:52PM +0200, Guido Günther wrote:
On Wed, Apr 11, 2012 at 03:48:09PM +0200, Christophe Fergeau wrote:
[..snip..]
--- a/libvirt-gconfig/libvirt-gconfig.sym
+++ b/libvirt-gconfig/libvirt-gconfig.sym
@@ -69,6 +69,8 @@ LIBVIRT_GCONFIG_0.0.4 {
On 04/11/2012 04:21 PM, Laine Stump wrote:
ACK to the idea, but NACK to the exact placement of the fix.
On further examination (and actually doing a couple tests), I withdraw
my NACK on the placement. I had mixed up usage of qemuOpenFile and
virFileOpen in my memory - qemuOpenFile already
On 04/11/2012 04:04 PM, Guannan Ren wrote:
activityfilter.py
---
activityfilter.py | 74
+
1 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 activityfilter.py
diff --git a/activityfilter.py b/activityfilter.py
On 04/11/2012 04:04 PM, Guannan Ren wrote:
casecfgcheck.py
---
casecfgcheck.py | 66
+++
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 casecfgcheck.py
diff --git a/casecfgcheck.py b/casecfgcheck.py
new
I don't think pushing this series without a review was a good idea. You
actualy broke all of the tests in the repos/ as you didn't do the
modifications to the parameter checking algorithm in a way that didn't
require modification of the tests, neither did you change the tests to
cope with the
Currently, qemu GA is not providing 'desc' field for errors like
we are used to from qemu monitor. Therefore, we fall back to this
general 'unknown error' string. However, GA is reporting 'class' which
is not perfect, but much more helpful than generic error string.
Thus we should fall back to
On Thu, Apr 12, 2012 at 02:06:21PM +0200, Michal Privoznik wrote:
Currently, qemu GA is not providing 'desc' field for errors like
we are used to from qemu monitor. Therefore, we fall back to this
general 'unknown error' string. However, GA is reporting 'class' which
is not perfect, but much
Hi,
I am using RHEL 6.2 64bit, and the libvirt shipped in it is
libvirt-0.9.4-23.el6.x86_64. I found sometimes the command virsh
list hangs forever, and same issue for virt-manager which is always
in Connecting status. But after restarting the libvirtd service,
this issue is gone.
Is this a bug
On Wed, Apr 11, 2012 at 01:41:20PM +0100, Daniel P. Berrange wrote:
On Wed, Apr 11, 2012 at 01:54:27PM +0200, Guido Günther wrote:
On Tue, Apr 10, 2012 at 09:36:57PM +0100, Daniel P. Berrange wrote:
On Tue, Apr 10, 2012 at 10:29:59PM +0200, Guido Günther wrote:
otherwise the build fails
On 12.04.2012 10:40, Qian Zhang wrote:
Hi,
I am using RHEL 6.2 64bit, and the libvirt shipped in it is
libvirt-0.9.4-23.el6.x86_64. I found sometimes the command virsh
list hangs forever, and same issue for virt-manager which is always
in Connecting status. But after restarting the libvirtd
On 12.04.2012 13:16, Laine Stump wrote:
On 04/11/2012 04:21 PM, Laine Stump wrote:
ACK to the idea, but NACK to the exact placement of the fix.
On further examination (and actually doing a couple tests), I withdraw
my NACK on the placement. I had mixed up usage of qemuOpenFile and
On 12.04.2012 14:14, Daniel P. Berrange wrote:
On Thu, Apr 12, 2012 at 02:06:21PM +0200, Michal Privoznik wrote:
Currently, qemu GA is not providing 'desc' field for errors like
we are used to from qemu monitor. Therefore, we fall back to this
general 'unknown error' string. However, GA is
On 04/12/2012 07:53 PM, Peter Krempa wrote:
I don't think pushing this series without a review was a good idea.
You actualy broke all of the tests in the repos/ as you didn't do the
modifications to the parameter checking algorithm in a way that didn't
require modification of the tests,
This is a re-send as there was some positive feedback but the
patch itself made it into the repo.
-Stefan
From a3198c5c1ae8908818f6c0f0df4237dbe5ddeec7 Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
Date: Thu, 12 Apr 2012 15:32:41 +0200
Subject: [PATCH] libvirt: xen: do
As promised this version does keep the domid 0 check in
order to be clearly keeping the old behavior.
-Stefan
From 18d398d98dc0dc2d9148ffb8673c651248d1bca5 Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
Date: Thu, 12 Apr 2012 09:59:56 +
Subject: [PATCH]
Currently, qemu GA is not providing 'desc' field for errors like
we are used to from qemu monitor. Therefore, we fall back to this
general 'unknown error' string. However, GA is reporting 'class' which
is not perfect, but much more helpful than generic error string.
Thus we should fall back to
Here is a similar issues, please see Jiri's comment:
https://bugzilla.redhat.com/show_bug.cgi?id=797835#c5
Regards,
Alex
- Original Message -
From: Michal Privoznik mpriv...@redhat.com
To: Qian Zhang zhq527...@gmail.com
Cc: libvir-list@redhat.com
Sent: Thursday, April 12, 2012 8:49:21
On 04/12/2012 07:38 PM, Martin Kletzander wrote:
On 04/11/2012 04:04 PM, Guannan Ren wrote:
casecfgcheck.py
---
casecfgcheck.py | 66 +++
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 casecfgcheck.py
diff
On 04/12/2012 09:43 PM, Guannan Ren wrote:
On 04/12/2012 07:53 PM, Peter Krempa wrote:
I don't think pushing this series without a review was a good idea.
You actualy broke all of the tests in the repos/ as you didn't do the
modifications to the parameter checking algorithm in a way that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I was wondering if Sys-Virt needs to coincide with an update to libvirt?
A fellow committer at FreeBSD is running the latest Sys-Virt against the
latest libvirt and is getting this error:
On 03/29/2012 07:15 AM, D. Herrendoerfer wrote:
From: D. Herrendoerfer d.herrendoer...@herrendoerfer.name
This patch adds a netlink callback when migrating a VEPA enabled
virtual machine.
It fixes a Bug where a VM would not request a port association when
it was cleared by lldpad.
This
On Thu, Apr 12, 2012 at 10:16:39AM -0700, Jason Helfman wrote:
Hi,
I was wondering if Sys-Virt needs to coincide with an update to libvirt?
A fellow committer at FreeBSD is running the latest Sys-Virt against the
latest libvirt and is getting this error:
From: Daniel P. Berrange berra...@redhat.com
The policy kit and HAL node device drivers both require a
DBus connection. The HAL device code further requires that
the DBus connection is integrated with the event loop and
provides such glue logic itself.
The forthcoming FirewallD integration also
I'm tired of shell-scripting to wait for completion of a block pull,
when virsh can be taught to do the same. I couldn't quite reuse
vshWatchJob, as this is not a case of a long-running command where
a second thread must be used to probe job status (at least, not unless
I make virsh start doing
On 04/12/2012 01:14 PM, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
The policy kit and HAL node device drivers both require a
DBus connection. The HAL device code further requires that
the DBus connection is integrated with the event loop and
provides such glue
On Thu, Apr 12, 2012 at 02:05:44PM -0600, Eric Blake wrote:
Did you forget to squash this into a prior patch? The commit message
mentions a new file virdbus.h that I don't see here, and since I don't
have virdbus.c, this patch won't apply.
Urgh, yes. Squashed resent
Daniel
--
|:
From: Daniel P. Berrange berra...@redhat.com
The policy kit and HAL node device drivers both require a
DBus connection. The HAL device code further requires that
the DBus connection is integrated with the event loop and
provides such glue logic itself.
The forthcoming FirewallD integration also
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
libvirt-gconfig/libvirt-gconfig-domain-disk.c | 26 +
libvirt-gconfig/libvirt-gconfig-domain-disk.h |9
libvirt-gconfig/libvirt-gconfig.sym |5 +++-
libvirt-gconfig/tests/test-domain-create.c
things we should be thinking about:
On 04/12/2012 02:57 PM, Tom Callaway wrote:
Here is the latest set of changes to the Fedora Packaging Guidelines:
---
Packages which have SysV initscripts that contain 'non-standard service
commands' (commands besides start, stop, reload, restart, or
On 04/12/2012 09:42 AM, Stefan Bader wrote:
As promised this version does keep the domid 0 check in
order to be clearly keeping the old behavior.
-Stefan
From 18d398d98dc0dc2d9148ffb8673c651248d1bca5 Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
Date: Thu, 12 Apr
On 04/12/2012 09:42 AM, Stefan Bader wrote:
This is a re-send as there was some positive feedback but the
patch itself made it into the repo.
-Stefan
From a3198c5c1ae8908818f6c0f0df4237dbe5ddeec7 Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
Date: Thu, 12 Apr 2012
On 04/12/2012 03:50 PM, Cole Robinson wrote:
On 04/12/2012 09:42 AM, Stefan Bader wrote:
As promised this version does keep the domid 0 check in
order to be clearly keeping the old behavior.
-Stefan
From 18d398d98dc0dc2d9148ffb8673c651248d1bca5 Mon Sep 17 00:00:00 2001
From: Stefan Bader
On 04/12/2012 02:07 PM, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
The policy kit and HAL node device drivers both require a
DBus connection. The HAL device code further requires that
the DBus connection is integrated with the event loop and
provides such glue
44 matches
Mail list logo
