[libvirt] Greetings and next release
by Daniel Veillard
Hello everybody,
Happy new year and best wishes for 2013 !
When we planned the 1.0.1 release we took the option of taking a bit
of extra time to push mid-december and planning the following one for
the end of January. Based on this I suggest to enter the freeze for
libvirt-1.0.2 on the Thursday 24 so that we have a week to push for a
final release on the end of the month. We are already over 110 commits
since 1.0.1 so 3 weeks from now I would expect enough changes for a
interesting release :-)
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
11 years, 10 months
[libvirt] Coverity scan
by John Ferlan
First allow me to introduce myself - I'm John Ferlan a new Red Hat employee (3 weeks). I came from the closed world at HP where for the last 7 years I worked in a group developing/supporting HP's Integrity Virtual Machine software prior to it being outsourced to India this past May. I primarily worked in the CLI/API and daemon space, although I also spent quite a bit of time in the lower virtualization layers which mimicked the Integrity instructions. I am very happy to be in the open world and look forward to contributing. Everyone has to start some where.
My first task here at Red Hat was to triage a Coverity scan executed against libvirt-1.0.0-1.fc19.src.rpm done in late November. There were 285 issues documented. I quickly found that some of the defects found there were already fixed in later submits upstream, so I ran a new Coverity scan last Friday and it came back with 297 issues broken down as follows:
1 ARRAY_VS_SINGLETON
33 BAD_SIZEOF
17 CHECKED_RETURN
1 CONSTANT_EXPRESSION_RESULT
5 COPY_PASTE_ERROR
13 DEADCODE
46 FORWARD_NULL
2 MISSING_RETURN
2 NEGATIVE_RETURNS
7 NULL_RETURNS
1 OVERRUN
137 RESOURCE_LEAK
18 REVERSE_INULL
1 SIGN_EXTENSION
3 UNINIT
8 UNUSED_VALUE
2 USE_AFTER_FREE
Of the defects found there are quite a few which can be considered as "false positives", some are trivial issues, a few complex issues, and the rest while resulting in a core usually occur in some error path. The bulk of the BAD_SIZEOF errors are the result of using a %p in the PROBE macro on structure pointers - it's a false positive, yet annoying. The bulk of FORWARD_NULL defects are from a false positive in vbox_templ.c. The bulk of RESOURCE_LEAK defects are from the use of macros to build code in esx_vi_types - which is where I'm triaging now. Of all the errors listed, "only" 62 files are affected.
Over the next few weeks, I'll start sending patch requests starting with some of the trivial problems just so I can get my feet wet with the process as it's certainly different than my closed world experiences. Since part of that process is to communicate early so people know what you're doing and what's coming - that's what I'm doing!
Also, now that I have a bit of experience with Coverity - I can run it again (more frequently) against the latest upstream bits.
John Ferlan
11 years, 10 months
[libvirt] [PATCH 0/3]add usb-audio support
by Guannan Ren
This set of patches is trying to add qemu usb-audio virtual device
support.
usb-audio XML example:
<devices>
<sound model='usb-audio'>
<buffer>1536</buffer>
<address type='usb' bus='0' port='1'/>
</sound>
</devices>
qemu ${other_vm_args} \
-device usb-audio,id=sound0,buffer=1536,bus=usb.0,port=1
There is an optional sub-element <buffer> to customize
the buffer size of usb audio device, if missing,
the default size is 1536(defined in qemu code).
Special size of value 0 means no buffer will be used,
so we use bool 'customized_buffer'to differentiate
user-defined 0 from being using default buffer value 1536.
Guannan Ren(3)
[PATCH 1/3] qemu: add usb-audio caps flag
[PATCH 2/3] qemu: parse usb-audio audio device XML and docs
[PATCH 3/3] test: add usb-audio testcase
docs/formatdomain.html.in | 10 ++++++++--
docs/schemas/basictypes.rng | 11 +++++++++++
docs/schemas/domaincommon.rng | 9 +++++++++
docs/schemas/nwfilter.rng | 15 ---------------
src/conf/domain_conf.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++-
src/conf/domain_conf.h | 5 +++++
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 19 ++++++++++++++++++-
tests/qemuhelptest.c | 9 ++++++---
tests/qemuxml2argvdata/qemuxml2argv-usb-audio.args | 7 +++++++
tests/qemuxml2argvdata/qemuxml2argv-usb-audio.xml | 31 +++++++++++++++++++++++++++++++
tests/qemuxml2argvtest.c | 3 +++
13 files changed, 149 insertions(+), 22 deletions(-)
11 years, 10 months
[libvirt] [RFC] Refactoring bridge driver for portability
by Roman Bogorodskiy
Hi,
Few weeks ago when I have submitted my all-in-one huge FreeBSD,
Eric made some comments on the networking part:
http://www.redhat.com/archives/libvir-list/2012-December/msg00432.html
Now when we're done with most of the other things, I'd like
to discuss networking in more detail.
Basically, the main question that bothers me is what would be the
best way to refactor network/bridge_driver.c?
Currently it contains a number of things:
- dnsmasq routines, static, but cross-platform, doesn't need
any changes (at least major ones)
- the same for radvd
- minor firewalld bits, that are linux specifc
- iptables routines. There are quite a lot of that code
and it's also gets called from many places in the file
I'm thinking about an approach that Eric mentioned for virthread.c:
- keep dnsmasq and radvd in bridge_driver.c
- move out all linux specific code to bridge_driver_linux.c and
#include it in a way similar to virthread.c
- in a similar way create bridge_driver_freebsd.c
Does it sound reasonable?
Roman Bogorodskiy
11 years, 10 months
[libvirt] [PATCH] build: use autobuild module to make build logs nicer
by Eric Blake
A recent build failure made me realize that we could usefully add
a bit more information to configure output, for aid in analysis of
failed builds. Pulling in the autobuild module merely adds these
four lines to configure output:
configure: autobuild project... libvirt
configure: autobuild revision... 1.0.1
configure: autobuild hostname... myhost
configure: autobuild timestamp... 20130102T181342Z
which can be useful even if not using the Autobuild project to parse
build logs.
* bootstrap.conf (gnulib_modules): Add autobuild.
---
I'll wait for a review on this one. Hmm, I also realized that
there are other things that might be useful for autobuild to
log, such as uname output; I'll ask upstream if it is worth
enhancing the autobuild output, and if upstream agrees, then
we would pick up that enhanced information next time we sync
from gnulib.
bootstrap.conf | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/bootstrap.conf b/bootstrap.conf
index 37a0ae1..4b45a4f 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -1,6 +1,6 @@
# Bootstrap configuration.
-# Copyright (C) 2010-2012 Red Hat, Inc.
+# Copyright (C) 2010-2013 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
@@ -20,6 +20,7 @@
gnulib_modules='
accept
areadlink
+autobuild
base64
bind
bitrotate
--
1.8.0.2
11 years, 10 months
[libvirt] [PATCH] maint: update to latest gnulib
by Michal Privoznik
The update results in bootstrap being updated as well.
---
.gnulib | 2 +-
bootstrap | 15 ++++++++-------
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/.gnulib b/.gnulib
index d245e6d..964bbc2 160000
--- a/.gnulib
+++ b/.gnulib
@@ -1 +1 @@
-Subproject commit d245e6ddd6ab2624d0d83acd8f111454f984f50f
+Subproject commit 964bbc2d419584e93fe629ddbc40595612f62083
diff --git a/bootstrap b/bootstrap
index e3e270b..c84d249 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,6 +1,6 @@
#! /bin/sh
# Print a version string.
-scriptversion=2012-07-19.14; # UTC
+scriptversion=2012-12-28.10; # UTC
# Bootstrap this package from checked-out sources.
@@ -889,20 +889,21 @@ find "$m4_base" "$source_base" \
-depth \( -name '*.m4' -o -name '*.[ch]' \) \
-type l -xtype l -delete > /dev/null 2>&1
+# Invoke autoreconf with --force --install to ensure upgrades of tools
+# such as ylwrap.
+AUTORECONFFLAGS="--verbose --install --force -I $m4_base $ACLOCAL_FLAGS"
+
# Some systems (RHEL 5) are using ancient autotools, for which the
# --no-recursive option had not been invented. Detect that lack and
# omit the option when it's not supported. FIXME in 2017: remove this
# hack when RHEL 5 autotools are updated, or when they become irrelevant.
-no_recursive=
case $($AUTORECONF --help) in
- *--no-recursive*) no_recursive=--no-recursive;;
+ *--no-recursive*) AUTORECONFFLAGS="$AUTORECONFFLAGS --no-recursive";;
esac
# Tell autoreconf not to invoke autopoint or libtoolize; they were run above.
-echo "running: AUTOPOINT=true LIBTOOLIZE=true " \
- "$AUTORECONF --verbose --install $no_recursive -I $m4_base $ACLOCAL_FLAGS"
-AUTOPOINT=true LIBTOOLIZE=true \
- $AUTORECONF --verbose --install $no_recursive -I $m4_base $ACLOCAL_FLAGS \
+echo "running: AUTOPOINT=true LIBTOOLIZE=true $AUTORECONF $AUTORECONFFLAGS"
+AUTOPOINT=true LIBTOOLIZE=true $AUTORECONF $AUTORECONFFLAGS \
|| die "autoreconf failed"
# Get some extra files from gnulib, overriding existing files.
--
1.8.0.2
11 years, 10 months
[libvirt] [PATCH] Remove the inexistent function in comments
by Osier Yang
virNodeDeviceLookupByKey is inexistent.
---
Pushed under trivial rule.
---
include/libvirt/libvirt.h.in | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index c6739d7..2de6835 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -3113,10 +3113,9 @@ typedef struct _virNodeDevice virNodeDevice;
* virNodeDevicePtr:
*
* A virNodeDevicePtr is a pointer to a virNodeDevice structure. Get
- * one via virNodeDeviceLookupByKey, virNodeDeviceLookupByName, or
- * virNodeDeviceCreate. Be sure to Call virNodeDeviceFree when done
- * using a virNodeDevicePtr obtained from any of the above functions to
- * avoid leaking memory.
+ * one via, virNodeDeviceLookupByName, or virNodeDeviceCreate. Be sure
+ * to Call virNodeDeviceFree when done using a virNodeDevicePtr obtained
+ * from any of the above functions to avoid leaking memory.
*/
typedef virNodeDevice *virNodeDevicePtr;
--
1.7.7.6
11 years, 10 months
[libvirt] [PATCH] qemu: Adapt to new log format
by Michal Privoznik
Since 586502189edf9fd0f89a83de96717a2ea826fdb0 qemu commit, the log
lines reporting chardev's path has changed from:
$ ./x86_64-softmmu/qemu-system-x86_64 -serial pty -serial pty -monitor pty
char device redirected to /dev/pts/5
char device redirected to /dev/pts/6
char device redirected to /dev/pts/7
to:
$ ./x86_64-softmmu/qemu-system-x86_64 -serial pty -serial pty -monitor pty
char device compat_monitor0 redirected to /dev/pts/5
char device serial0 redirected to /dev/pts/6
char device serial1 redirected to /dev/pts/7
However, with current code we are not prepared for such change, which
results in us being unable to start any domain.
---
src/qemu/qemu_process.c | 33 +++++++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index eac6553..29bd082 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -1431,22 +1431,43 @@ cleanup:
*
* char device redirected to /dev/pts/3
*
+ * However, since 1.4 the line we are looking for has changed to:
+ *
+ * char device <alias> redirected to /some/path
+ *
* Returns -1 for error, 0 success, 1 continue reading
*/
static int
qemuProcessExtractTTYPath(const char *haystack,
size_t *offset,
+ const char *alias,
char **path)
{
- static const char needle[] = "char device redirected to";
- char *tmp, *dev;
+ static const char *needle[] = {"char device", "redirected to"};
+ const char *tmp, *dev;
VIR_FREE(*path);
/* First look for our magic string */
- if (!(tmp = strstr(haystack + *offset, needle))) {
+ if (!(tmp = strstr(haystack + *offset, needle[0])))
return 1;
+
+ tmp += strlen(needle[0]);
+ virSkipSpaces(&tmp);
+
+ if (STRPREFIX(tmp, "char")) {
+ /* we are dealing with new style */
+ tmp += strlen("char");
+ if (!STRPREFIX(tmp, alias))
+ return 1;
+
+ tmp += strlen(alias);
+ virSkipSpaces(&tmp);
}
- tmp += sizeof(needle);
+
+ if (!STRPREFIX(tmp, needle[1]))
+ return 1;
+
+ tmp += strlen(needle[1]);
dev = tmp;
/*
@@ -1569,6 +1590,7 @@ qemuProcessFindCharDevicePTYs(virDomainObjPtr vm,
virDomainChrDefPtr chr = vm->def->serials[i];
if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
if ((ret = qemuProcessExtractTTYPath(output, &offset,
+ chr->info.alias,
&chr->source.data.file.path)) != 0)
return ret;
}
@@ -1579,6 +1601,7 @@ qemuProcessFindCharDevicePTYs(virDomainObjPtr vm,
virDomainChrDefPtr chr = vm->def->parallels[i];
if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
if ((ret = qemuProcessExtractTTYPath(output, &offset,
+ chr->info.alias,
&chr->source.data.file.path)) != 0)
return ret;
}
@@ -1589,6 +1612,7 @@ qemuProcessFindCharDevicePTYs(virDomainObjPtr vm,
virDomainChrDefPtr chr = vm->def->channels[i];
if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
if ((ret = qemuProcessExtractTTYPath(output, &offset,
+ chr->info.alias,
&chr->source.data.file.path)) != 0)
return ret;
}
@@ -1608,6 +1632,7 @@ qemuProcessFindCharDevicePTYs(virDomainObjPtr vm,
if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY &&
chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO) {
if ((ret = qemuProcessExtractTTYPath(output, &offset,
+ chr->info.alias,
&chr->source.data.file.path)) != 0)
return ret;
}
--
1.8.0.2
11 years, 10 months
[libvirt] ESX error while freeing inherited objects
by Ata Bohra
Hi All, Freeing of an object having inheritance depth >=2 throws an error such as:" internal error Call to esxVI_<grand_parent>_Free for unexpected type 'Child'. " For instance: Below code snippet is from esx_vi_generator.input (modified) object VirtualDevice
Int key r
Description deviceInfo o
VirtualDeviceBackingInfo backing o
VirtualDeviceConnectInfo connectable o
Int controllerKey o
Int unitNumber o
end
object VirtualController extends VirtualDevice
Int busNumber r
Int device ol
end
object VirtualIDEController extends VirtualController
end object VirtualDeviceConfigSpec
VirtualDeviceConfigSpecOperation operation o
VirtualDeviceConfigSpecFileOperation fileOperation o
VirtualDevice device r
end
object VirtualMachineConfigSpec...
VirtualDeviceConfigSpec deviceChange ol..end On free of "VirtualMachineConfigSpec", I hit below error:"libvir: ESX Driver error : internal error Call to esxVI_VirtualDevice_Free for unexpected type 'VirtualIDEController'" But if I remove VirtualController and include its fields directly to VirtualIDEController, error is resolved. Please let me know if I'm missing anything, else, it seems like a bug with generated code. While debugging the error seems to come from: esx_vi_types.c: /*
* Macros to implement dynamic dispatched functions
*/#define ESX_VI__TEMPLATE__DISPATCH(_actual_type, _actual_type_name, __type, \
_dispatch, _error_return) \
switch (_actual_type) { \
_dispatch \
\
case esxVI_Type_##__type: \
break; \
\
default: \
virReportError(VIR_ERR_INTERNAL_ERROR, \
_("Call to %s for unexpected type '%s'"), \
__FUNCTION__, _actual_type_name); \
return _error_return; \
}
Thanks!Ata
11 years, 10 months
