2011/5/4 Laine Stump la...@laine.org:
On 05/03/2011 03:10 PM, Eric Blake wrote:
Detected by clang.
* src/esx/esx_driver.c (esxDomainGetInfo): Fail early on error.
---
src/esx/esx_driver.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/esx/esx_driver.c
2011/5/4 Eric Blake ebl...@redhat.com:
Detected by clang.
* src/esx/esx_util.c (esxUtil_ParseDatastorePath): No need to
increment.
---
src/esx/esx_util.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/esx/esx_util.c b/src/esx/esx_util.c
index
On Wed, May 04, 2011 at 12:30:07AM -0400, Laine Stump wrote:
On 05/03/2011 05:49 PM, Eric Blake wrote:
Clang detected a dead store to rc. It turns out that in fixing this,
I also found a FILE* leak.
* src/util/cgroup.c (virCgroupKillInternal): Abort rather than
resuming loop on fscanf
On Tue, May 03, 2011 at 05:31:02PM -0500, Anthony Liguori wrote:
On 05/03/2011 09:33 AM, Daniel P. Berrange wrote:
On Mon, May 02, 2011 at 08:09:07AM -0700, Badari Pulavarty wrote:
Hi,
How can I make use of multifunction functionality to support
more than 32 virtio devices in QEMU through
Creating a domU on a freshly booted dom0 does not work,
because the libxl driver does not allocate memory for the domU.
After creating a domain with xl libvirt is able to create domains too.
This patch reserves enough memory for the domU first.
---
src/libxl/libxl_driver.c | 48
On Wed, May 04, 2011 at 12:17:06PM +0200, Markus Groß wrote:
Creating a domU on a freshly booted dom0 does not work,
because the libxl driver does not allocate memory for the domU.
After creating a domain with xl libvirt is able to create domains too.
This patch reserves enough memory for the
Wire up logging of VM taintint to the QEMU driver
- If running QEMU as root user/group or without capabilities
being cleared
- If passing custom QEMU command line args
- If issuing custom QEMU monitor commands
- If using a network interface config with an associated
shell script
- If
There are various configurations for virtual domains that we allow,
but do not wish to actively support in production environments.
The support situation is similar to that of binary only or non-GPL
kernel modules, so borrow the kernel's idea of tainting.
When an undesirable configuration is used
Some configuration setups for guests are allowed, but strongly
discouraged and unsupportable in production systems. Introduce
a concept of 'tainting' to virDomainObjPtr to allow such setups
to be identified. Drivers can then log warnings at suitable
times
* src/conf/domain_conf.c,
Open the domain log file for hotplug and custom monitor command
usage to write taint warnings.
* src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Add
qemuDomainOpenLogWrite/qemuDomainOpenLogRead methods
* src/qemu/qemu_process.c: Remove qemuProcessOpenLogFD
and qemuProcessReadLogFD methods
Hi,
I encounter a problem that the eth can't be up in the VM by using VT-d.
I boot the VM using virsh create vt_d.xml.
The VM could recongize the NIC which was assigned .then I do in VM as
follows:
#cat /sys/class/net/eth0/operstate
down
#ifconfig eth0 up
#cat /sys/class/net/eth0/operstate
down
On Wed, May 04, 2011 at 12:28:45PM +0100, Daniel P. Berrange wrote:
There are various configurations for virtual domains that we allow,
but do not wish to actively support in production environments.
The support situation is similar to that of binary only or non-GPL
kernel modules, so borrow
To cope with the QEMU binary being changed while a VM is running,
it is neccessary to persist the original qemu capabilities at the
time the VM is booted.
* src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add
an enum for a string rep of every capability
* src/qemu/qemu_domain.c,
Currently, whenever we require QEMU capabilities data, we rerun
QEMU to extract the info. This isn't desirable because it is
inefficient and the QEMU binary may have changed since we started
the guest. This series makes us keep a copy of the capability
data around for lifetime of the VM process
* src/qemu/qemu_hotplug.h, src/qemu/qemu_hotplug.c: Remove
qemuCaps parameters from all methods
* src/qemu/qemu_driver.c: Don't create pass qemuCaps to
hotplug methods
---
src/qemu/qemu_driver.c | 71 +++---
src/qemu/qemu_hotplug.c | 185
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Remove
qemuCaps parameters use cached data
* src/qemu/qemu_driver.c: Don't create pass qemuCaps to
migration methods
---
src/qemu/qemu_driver.c| 11 ++-
src/qemu/qemu_migration.c | 32 ++--
On 05/04/2011 06:23 AM, Laine Stump wrote:
This definitely fixes the FILE* leak, but do we really want to abort
the loop (stop looking for more pidfiles) when fscanf fails on one
pidfile? (dunno, just asking)
Personally, I think that since pidfiles are always generated by the
kernel, they
---
src/driver.h |5 +
src/esx/esx_driver.c |1 +
src/libxl/libxl_driver.c |1 +
src/lxc/lxc_driver.c |1 +
src/openvz/openvz_driver.c |1 +
src/phyp/phyp_driver.c |1 +
src/qemu/qemu_driver.c |1 +
src/remote/remote_driver.c |
---
src/libvirt.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index e74e977..5cd20ce 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -3173,6 +3173,53 @@ error:
}
/**
+ *
This new API solves several problems:
- calling virDomainGetInfo for just getting domain status is an overkill since
it may result in sending requests to guest OS
- since virDomainGetInfo can hang when guest OS is not responding and it is
used by virsh list, listing domains can hang
-
This API is supposed to replace virDomainGetInfo when the only purpose
of calling it is getting current domain status.
---
include/libvirt/libvirt.h.in| 55 +++
python/generator.py |1 +
python/libvirt-override-api.xml |5 +++
---
tools/virsh.c | 195 +++--
1 files changed, 162 insertions(+), 33 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 5d8b025..6dae9fa 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -223,6 +223,8 @@ typedef struct __vshControl
---
daemon/remote.c | 33 +
daemon/remote_dispatch_prototypes.h |8
daemon/remote_dispatch_table.h |5 +
src/remote/remote_protocol.c| 20
src/remote/remote_protocol.h| 16
---
src/remote/remote_driver.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 9796bb5..3baedf0 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -2861,6
Reason is currently always set to 0 (i.e., *_UNKNOWN).
---
src/esx/esx_driver.c | 54 -
src/libxl/libxl_driver.c | 31 +-
src/lxc/lxc_driver.c | 33 ++-
src/openvz/openvz_driver.c | 32 ++-
src/phyp/phyp_driver.c
On 05/04/2011 05:28 AM, Daniel P. Berrange wrote:
+bool virDomainObjTaint(virDomainObjPtr obj,
+ int taint)
+{
+int flag = (1 taint);
Undefined behavior if taint is out of bounds (= 31). Do we need a
sanity check, or to change the 'int taint' parameter to instead
On 05/03/2011 10:32 PM, Laine Stump wrote:
On 05/03/2011 06:14 PM, Eric Blake wrote:
clang didn't like the last increment to nargs. But why even
track nargs ourselves, when virCommand does it for us?
* src/storage/storage_backend_iscsi.c
(virStorageBackendISCSIConnection): Switch to
On 05/03/2011 10:47 PM, Laine Stump wrote:
+++ b/src/qemu/qemu_migration.c
@@ -1311,7 +1311,6 @@ qemuMigrationToFile(struct qemud_driver *driver,
virDomainObjPtr vm,
if (virSecurityManagerSetFDLabel(driver-securityManager, vm,
compressor ?
Detected by gcc:
libxl/libxl_driver.c: In function 'libxlDomainDestroy':
libxl/libxl_drier.c:1351:30: error: variable 'priv' set but not used
[-Werror=unused-but-set-variable]
* src/libxl/libxl_driver.c (libxlDomainDestroy): Delete unused
variable.
---
Trivial, so pushing under the
On 05/03/2011 10:48 PM, Laine Stump wrote:
On 05/03/2011 05:04 PM, Eric Blake wrote:
Clang noticed a dead assignment, which turned out to be the use
of the wrong variable. rc starts life as -1, and is only ever
assigned to 0 just before a successful cleanup.
ACK.
Thanks; pushed.
--
On 05/03/2011 10:50 PM, Laine Stump wrote:
On 05/03/2011 04:29 PM, Eric Blake wrote:
Clang complained about this, and it was easy enough to fix.
* src/util/util.c (virFileOpenAs): Drop dead assignment.
---
src/util/util.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
On 05/03/2011 11:02 PM, Laine Stump wrote:
On 05/03/2011 04:22 PM, Eric Blake wrote:
Clang warned about a dead assignment. In the process, I noticed
that we are only using the function for a bool value. I audited
all other callers in qemu_{migration,cgroup,driver,hotplug), and
all were
On 05/04/2011 07:49 AM, Daniel P. Berrange wrote:
To cope with the QEMU binary being changed while a VM is running,
it is neccessary to persist the original qemu capabilities at the
time the VM is booted.
Yay! About time.
@@ -1986,13 +1984,16 @@ qemuProcessReconnect(void *payload, const void
On 05/04/2011 07:49 AM, Daniel P. Berrange wrote:
* src/qemu/qemu_hotplug.h, src/qemu/qemu_hotplug.c: Remove
qemuCaps parameters from all methods
* src/qemu/qemu_driver.c: Don't create pass qemuCaps to
hotplug methods
---
src/qemu/qemu_driver.c | 71 +++---
On 05/04/2011 07:49 AM, Daniel P. Berrange wrote:
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Remove
qemuCaps parameters use cached data
* src/qemu/qemu_driver.c: Don't create pass qemuCaps to
migration methods
---
src/qemu/qemu_driver.c| 11 ++-
Hi,
Please see the below discussion with the spice community.
libvirt is adding a parameter about video ram to qemu process and this
parameter might be responsible of a crash in the qxl at higher resolutions.
Spice people tell me that their default ram should be 64 Mbytes.
I'm using libvirt
On Wed, May 04, 2011 at 07:52:37PM +0400, Emre Erenoglu wrote:
Hi,
Please see the below discussion with the spice community.
libvirt is adding a parameter about video ram to qemu process and this
parameter might be responsible of a crash in the qxl at higher resolutions.
Spice people tell
On 05/03/2011 11:18 PM, Laine Stump wrote:
On 05/03/2011 01:58 PM, Eric Blake wrote:
Detected by clang. NULL deref added in commit 343a27a (Mar 11),
but leak of voldef present since commit 2cd9b2d (Apr 09).
* src/storage/storage_driver.c (storageVolumeCreateXML): Don't
leak voldef or
On 05/04/2011 10:40 AM, Eric Blake wrote:
On 05/04/2011 06:23 AM, Laine Stump wrote:
This definitely fixes the FILE* leak, but do we really want to abort
the loop (stop looking for more pidfiles) when fscanf fails on one
pidfile? (dunno, just asking)
Personally, I think that since pidfiles are
2011/5/4 Eric Blake ebl...@redhat.com:
On 05/04/2011 01:16 AM, Matthias Bolte wrote:
This fixes the problem, but I prefer the attached patch.
As do I. ACK to your version.
Thanks, pushed.
Matthias
--
libvir-list mailing list
libvir-list@redhat.com
On Tue, May 03, 2011 at 11:28:30AM -0600, Eric Blake wrote:
Clang found three instances of uninitialized use of nparams in
the cleanup path. Unfortunately, one is a false positive: clang
couldn't see that ret-params.params_val is guaranteed to be
NULL unless allocated within a function, and
On 05/04/2011 08:45 AM, Jiri Denemark wrote:
This new API solves several problems:
- calling virDomainGetInfo for just getting domain status is an overkill since
it may result in sending requests to guest OS
- since virDomainGetInfo can hang when guest OS is not responding and it is
On 05/04/2011 08:45 AM, Jiri Denemark wrote:
This API is supposed to replace virDomainGetInfo when the only purpose
of calling it is getting current domain status.
@@ -674,6 +726,9 @@ int virDomainCoreDump
(virDomainPtr domain,
*/
int
On 05/04/2011 12:05 PM, Daniel P. Berrange wrote:
On Wed, May 04, 2011 at 07:52:37PM +0400, Emre Erenoglu wrote:
Hi,
Please see the below discussion with the spice community.
libvirt is adding a parameter about video ram to qemu process and this
parameter might be responsible of a crash in
On 05/04/2011 12:05 PM, Daniel P. Berrange wrote:
On Wed, May 04, 2011 at 07:52:37PM +0400, Emre Erenoglu wrote:
Hi,
Please see the below discussion with the spice community.
libvirt is adding a parameter about video ram to qemu process and this
parameter might be responsible of a crash in
Detected by clang. NULL deref added in commit 343a27a (Mar 11),
but leak of voldef present since commit 2cd9b2d (Apr 09).
* src/storage/storage_driver.c (storageVolumeCreateXML): Don't
leak voldef or dereference null volobj.
---
v2: don't leave pool-volumes.objs pointing to stale memory on
On 05/04/2011 10:38 AM, Daniel P. Berrange wrote:
On Tue, May 03, 2011 at 11:28:30AM -0600, Eric Blake wrote:
Clang found three instances of uninitialized use of nparams in
the cleanup path. Unfortunately, one is a false positive: clang
couldn't see that ret-params.params_val is guaranteed to
On 05/04/2011 08:45 AM, Jiri Denemark wrote:
---
src/driver.h |5 +
src/esx/esx_driver.c |1 +
src/libxl/libxl_driver.c |1 +
src/lxc/lxc_driver.c |1 +
src/openvz/openvz_driver.c |1 +
src/phyp/phyp_driver.c |1 +
On 05/04/2011 08:45 AM, Jiri Denemark wrote:
---
src/libvirt.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index e74e977..5cd20ce 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@
On 05/04/2011 12:52 PM, Eric Blake wrote:
Detected by clang. NULL deref added in commit 343a27a (Mar 11),
but leak of voldef present since commit 2cd9b2d (Apr 09).
* src/storage/storage_driver.c (storageVolumeCreateXML): Don't
leak voldef or dereference null volobj.
---
v2: don't leave
Inline...
-Original Message-
From: libvir-list-boun...@redhat.com [mailto:libvir-list-
boun...@redhat.com] On Behalf Of Oved Ourfalli
Sent: Thursday, April 28, 2011 1:15 AM
To: Laine Stump; libvir-list@redhat.com
Subject: Re: [libvirt] migration of vnlink VMs
- Original
2011/5/4 Daniel Veillard veill...@redhat.com:
On Wed, May 04, 2011 at 08:38:43AM +0200, Matthias Bolte wrote:
2011/5/4 Laine Stump la...@laine.org:
On 05/03/2011 03:10 PM, Eric Blake wrote:
Detected by clang.
* src/esx/esx_driver.c (esxDomainGetInfo): Fail early on error.
---
On Wed, May 4, 2011 at 6:05 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, May 04, 2011 at 07:52:37PM +0400, Emre Erenoglu wrote:
Hi,
Please see the below discussion with the spice community.
libvirt is adding a parameter about video ram to qemu process and this
parameter might
On Wed, May 4, 2011 at 11:40 PM, Gianluca Cecchi
gianluca.cec...@gmail.comwrote:
On Wed, May 4, 2011 at 6:05 PM, Daniel P. Berrange berra...@redhat.com
wrote:
On Wed, May 04, 2011 at 07:52:37PM +0400, Emre Erenoglu wrote:
Hi,
Please see the below discussion with the spice community.
On 05/04/2011 11:56 AM, Laine Stump wrote:
On 05/04/2011 12:52 PM, Eric Blake wrote:
Detected by clang. NULL deref added in commit 343a27a (Mar 11),
but leak of voldef present since commit 2cd9b2d (Apr 09).
* src/storage/storage_driver.c (storageVolumeCreateXML): Don't
leak voldef or
In Fedora 15, with clang 2.8, 'scan-build env' shows:
CCC_ANALYZER_ANALYSIS=-analyzer-check-objc-mem
-analyzer-check-security-syntactic -analyzer-check-dead-stores
-analyzer-check-objc-unused-ivars -analyzer-check-objc-methodsigs
But in rawhide, with clang 2.9, the same variable is set but
On 05/04/2011 08:45 AM, Jiri Denemark wrote:
---
daemon/remote.c | 33 +
daemon/remote_dispatch_prototypes.h |8
daemon/remote_dispatch_table.h |5 +
src/remote/remote_protocol.c| 20
On 05/04/2011 08:45 AM, Jiri Denemark wrote:
---
tools/virsh.c | 195
+++--
1 files changed, 162 insertions(+), 33 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 5d8b025..6dae9fa 100644
--- a/tools/virsh.c
+++
If we plow on after udev_device_get_syspath fails, we will hit a NULL
dereference. Clang found one due to strdup later in udevSetParent,
but in fact we hit a NULL dereference sooner because of the use of
STREQ within virNodeDeviceFindBySysfsPath.
* src/conf/node_device_conf.h
No syntactic effect; this merely silences some clang warnings.
* src/libxl/libxl_driver.c (libxlDomainSetVcpusFlags): Drop
redundant ret=0 statement.
* src/qemu/qemu_monitor_text.c (qemuMonitorTextDriveDel):
Likewise.
---
More clang fallout, found by switching over to rawhide.
1. this file is automatically generated at compile-time, so rm it
to avoid further commit to this file.
2. any update should made to file src/remote/remote_protocol.x.
---
daemon/remote_dispatch_table.h | 1054
1 files changed, 0 insertions(+), 1054
As planned and after most of the clang detected problems got fixed
(thanks Eric !) the new release is available at:
ftp://libvirt.org/libvirt/
It's a mixed release, it includes a number of improvements as
well as many bug fixes and a few new features:
Features:
- support various
62 matches
Mail list logo