- Devel - libvirt List Archives

[libvirt] [PATCH] Log flags passed to qemuMigrationPrepare{Tunnel, Direct} APIs
by Michal Privoznik 18 Jan '13

18 Jan '13

We are already logging other arguments passed, however, @flags were missing there. --- Pushed as these chunks were ACKed and are not really part of my NBD patchset: https://www.redhat.com/archives/libvir-list/2013-January/msg01306.html src/qemu/qemu_migration.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 465dbc1..d03e361 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1787,9 +1787,10 @@ qemuMigrationPrepareTunnel(virQEMUDriverPtr driver, int ret; VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, " - "cookieout=%p, cookieoutlen=%p, st=%p, dname=%s, dom_xml=%s", + "cookieout=%p, cookieoutlen=%p, st=%p, dname=%s, dom_xml=%s " + "flags=%lx", driver, dconn, NULLSTR(cookiein), cookieinlen, - cookieout, cookieoutlen, st, NULLSTR(dname), dom_xml); + cookieout, cookieoutlen, st, NULLSTR(dname), dom_xml, flags); /* QEMU will be started with -incoming stdio (which qemu_command might * convert to exec:cat or fd:n) @@ -1823,10 +1824,10 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver, VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, " "cookieout=%p, cookieoutlen=%p, uri_in=%s, uri_out=%p, " - "dname=%s, dom_xml=%s", + "dname=%s, dom_xml=%s flags=%lx", driver, dconn, NULLSTR(cookiein), cookieinlen, cookieout, cookieoutlen, NULLSTR(uri_in), uri_out, - NULLSTR(dname), dom_xml); + NULLSTR(dname), dom_xml, flags); /* The URI passed in may be NULL or a string "tcp://somehostname:port". * -- 1.8.0.2

1 0

[libvirt] [PATCH] build: Fix RPM build errors related to libvirt-lxc API
by Viktor Mihajlovski 18 Jan '13

18 Jan '13

Added missing entries to makefile and spec. Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- docs/Makefile.am | 2 +- libvirt.spec.in | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/Makefile.am b/docs/Makefile.am index b1fa77a..c95497f 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -120,7 +120,7 @@ EXTRA_DIST= \ hacking1.xsl hacking2.xsl wrapstring.xsl \ $(dot_html) $(dot_html_in) $(gif) $(apihtml) $(apipng) \ $(devhelphtml) $(devhelppng) $(devhelpcss) $(devhelpxsl) \ - $(xml) $(qemu_xml) $(fig) $(png) $(css) \ + $(xml) $(qemu_xml) $(lxc_xml) $(fig) $(png) $(css) \ $(patches) $(dot_php_in) $(dot_php_code_in) $(dot_php)\ $(internals_html_in) $(internals_html) \ sitemap.html.in \ diff --git a/libvirt.spec.in b/libvirt.spec.in index dca5053..3486d29 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1983,6 +1983,7 @@ fi %doc AUTHORS NEWS README COPYING.LIB %{_libdir}/python*/site-packages/libvirt.py* %{_libdir}/python*/site-packages/libvirt_qemu.py* +%{_libdir}/python*/site-packages/libvirt_lxc.py* %{_libdir}/python*/site-packages/libvirtmod* %doc python/tests/*.py %doc python/TODO -- 1.7.9.5

2 1

[libvirt] Coverity update
by John Ferlan 18 Jan '13

18 Jan '13

Taking Eric's suggestion from: https://www.redhat.com/archives/libvir-list/2013-January/msg01050.html There's two changes that have yet to be reviewed: https://www.redhat.com/archives/libvir-list/2013-January/msg00537.html https://www.redhat.com/archives/libvir-list/2013-January/msg00541.html After this recent set of 10 patches there are about 20 patches remaining. With the 2 above and the 10 from yesterday, the coverity defect list stands at 236 (down from 297). Of those, about 50 are related to a sdt.h macro issue, 50 are false positives requiring a comment change, and another 95 can be fixed/resolved by a very simple (but yet unnecessary) change to src/esx/esx_vi.c and src/esx/esx_vi_types.c. Each module as a __TEMPLATE__FREE() macro which does the following: item=*ptrptr; \ \ _body \ \ VIR_FREE(*ptrptr); \ Coverity has a hard time with the VIR_FREE(*ptrptr) here and in other modules, thus it decides we must be leaking. No amount of tagging completely removes all the warnings (I tried adding them everywhere and only reduced the count, not eliminated). There is a solution, but I really don't like it. If the VIR_FREE(*ptrptr) is changed to: VIR_FREE(item); \ *ptrptr = NULL; \ Coverity is happy. I asked about this on a Coverity community message board, but no one has an answer. I even generated a small program which replicated the issue. In a way I think it could be a Coverity bug, but I'm not sure I want to make that claim yet. John

1 0

[libvirt] [PATCH] qemu: Double mutex unlock in qemuDomainModifyDeviceFlags
by Viktor Mihajlovski 18 Jan '13

18 Jan '13

The driver mutex was unlocked in qemuDomainModifyDeviceFlags before entering qemuDomainObjBeginJobWithDriver where it will be unlocked once more leaving it in an undefined state. The result was that two threads were simultaneously looking up the domain hash table during multiple parallel device attach/detach operations. Luckily this triggered a virHashIterationError. Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- src/qemu/qemu_driver.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 8c39864..c28c223 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6443,7 +6443,6 @@ qemuDomainModifyDeviceFlags(virDomainPtr dom, const char *xml, qemuDriverLock(driver); vm = virDomainFindByUUID(&driver->domains, dom->uuid); - qemuDriverUnlock(driver); if (!vm) { char uuidstr[VIR_UUID_STRING_BUFLEN]; virUUIDFormat(dom->uuid, uuidstr); -- 1.7.9.5

3 4

Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by Carlos O'Donell 18 Jan '13

18 Jan '13

On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger <vapier(a)gentoo.org> wrote: > On Wednesday 16 January 2013 22:15:38 David Miller wrote: >> From: Carlos O'Donell <carlos(a)systemhalted.org> >> Date: Wed, 16 Jan 2013 21:15:03 -0500 >> >> > +/* If a glibc-based userspace has already included in.h, then we will >> > not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. >> > The + * ABI used by the kernel and by glibc match exactly. Neither the >> > kernel + * nor glibc should break this ABI without coordination. >> > + */ >> > +#ifndef _NETINET_IN_H >> > + >> >> I think we should shoot for a non-glibc-centric solution. >> >> I can't imagine that other libc's won't have the same exact problem >> with their netinet/in.h conflicting with the kernel's, redefining >> structures like in6_addr, that we'd want to provide a protection >> scheme for here as well. > > yes, the kernel's use of __GLIBC__ in exported headers has already caused > problems in the past. fortunately, it's been reduced down to just one case > now (stat.h). let's not balloon it back up. > -mike I also see coda.h has grown a __GLIBC__ usage. In the next revision of the patch I created a single libc-compat.h header which encompasses the logic for any libc that wants to coordinate with the kernel headers. It's simple enough to move all of the __GLIBC__ uses into libc-compat.h, then you control userspace libc coordination from one file. Cheers, Carlos.

3 5

[libvirt] [PATCH 00/12] Introduce public APIs for dealing with virTypedParameters
by Jiri Denemark 18 Jan '13

18 Jan '13

Working with virTypedParameters in clients written in C is ugly and requires all clients to duplicate the same code. This set of APIs makes this code for manipulating with virTypedParameters integral part of libvirt so that all clients may benefit from it. Jiri Denemark (12): Add virTypedParams* APIs virsh: Use virTypedParams* APIs in blkdeviotune virsh: Use virTypedParams* APIs in blkiotune virsh: Use virTypedParams* APIs in domiftune virsh: Use virTypedParams* APIs in schedinfo virsh: Use virTypedParams* APIs in domblkstat virsh: Use virTypedParams* APIs in memtune virsh: Use virTypedParams* APIs in numatune virsh: Use virTypedParams* APIs in node-memory-tune virsh: Use virTypedParams* APIs in cpu-stats Introduce virTypedParamsClear public API python: Avoid freeing uninitialized new_params pointer daemon/remote.c | 34 +- include/libvirt/libvirt.h.in | 95 ++++++ python/generator.py | 20 ++ python/libvirt-override.c | 73 ++-- src/libvirt_private.syms | 1 - src/libvirt_public.syms | 18 + src/remote/remote_driver.c | 4 +- src/rpc/gendispatch.pl | 3 +- src/util/virtypedparam.c | 782 ++++++++++++++++++++++++++++++++++++++++++- src/util/virtypedparam.h | 2 - tools/virsh-domain-monitor.c | 5 +- tools/virsh-domain.c | 542 +++++++++++------------------- tools/virsh-host.c | 78 ++--- tools/virsh.c | 20 -- 14 files changed, 1171 insertions(+), 506 deletions(-) -- 1.8.1.1

3 17

[libvirt] [PATCH] storage: Fix lvcreate parameter for backingStore.
by Atsushi Kumagai 18 Jan '13

18 Jan '13

When virStorageBackendLogicalCreateVol() creates a snapshot for a logical volume with backingStore element, it fails with the message below: 2013-01-17 03:10:18.869+0000: 1967: error : virCommandWait:2345 : internal error Child process (/sbin/lvcreate --name lvm-snapshot -L 51200K -s=/dev/lvm-pool/lvm-volume) unexpected exit status 3: /sbin/lvcreate: invalid option -- '=' Error during parsing of command line. This is because virCommandAddArgPair() uses '=' to connect the two parameters, it's unsuitable for -s option of the lvcreate. Signed-off-by: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp> --- src/storage/storage_backend_logical.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index 91db3fd..bb709df 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -736,7 +736,7 @@ virStorageBackendLogicalCreateVol(virConnectPtr conn, } virCommandAddArgFormat(cmd, "%lluK", VIR_DIV_UP(vol->capacity, 1024)); if (vol->backingStore.path) - virCommandAddArgPair(cmd, "-s", vol->backingStore.path); + virCommandAddArgList(cmd, "-s", vol->backingStore.path, NULL); else virCommandAddArg(cmd, pool->def->source.name); -- 1.7.1

2 1

Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by David Miller 18 Jan '13

18 Jan '13

From: Mike Frysinger <vapier(a)gentoo.org> Date: Thu, 17 Jan 2013 23:14:31 -0500 > the kernel already exports many types with a __kernel_ prefix. i changed the > kernel headers in Gentoo for a few releases (2.6.28 - 2.6.34) to do the same > thing to pretty much all the networking headers. a few packages broke, but > the number was low, and trivial to fix (a sed would do it most of the time). > > it's also trivial for userland packages to detect that they need to do this > sort of thing in a local header by using linux/version.h and a set of defines > to redirect the new structure name back to the old one. > > would be a lot cleaner to just break it and be done. We are not at liberty to break something that has legitimately compiled successfully for two decades. Your __kernel_ prefix idea breaks compilation just as equally. One thing you certainly don't have to be is happy about this header file situation, but you cannot use that dissatisfaction as justification to make the situation worse by breaking the build for people outside of the world you directly control.

1 0

Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by David Miller 18 Jan '13

18 Jan '13

From: Mike Frysinger <vapier(a)gentoo.org> Date: Wed, 16 Jan 2013 12:04:56 -0500 > certainly true, but the current expectation is that you don't mix your ABIs. > if you're programming with the C library API, then use the C library headers. > if you're banging directly on the kernel, then use the kernel headers. not > saying it's a perfect solution, but it works for the vast majority of use > cases. This isn't how real life works. GLIBC itself brings in some of the kernel headers, as do various library headers for libraries other than glibc. So you can get these conflicting headers included indirectly, and it is of no fault of any of the various parties involved. We have to make them work when included at the same time somehow, and this is totally unavoidable.

3 5

[libvirt] [PATCH] build: fix build on BSD
by Eric Blake 18 Jan '13

18 Jan '13

A build on FreeBSD failed with: util/virportallocator.c:108: error: storage size of 'addr' isn't known util/virportallocator.c:123: error: 'INADDR_ANY' undeclared (first use in this function) It turns out that while POSIX allows sockaddr_in to leak in through other headers (the way Linux does it), conforming applications are required to get it through netinet/in.h. * src/util/virportallocator.c: Include header for struct sockaddr_in. --- Pushing under the build-breaker rule. src/util/virportallocator.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/util/virportallocator.c b/src/util/virportallocator.c index 35f2157..590bb57 100644 --- a/src/util/virportallocator.c +++ b/src/util/virportallocator.c @@ -23,6 +23,7 @@ #include <sys/socket.h> #include <arpa/inet.h> +#include <netinet/in.h> #include "viralloc.h" #include "virbitmap.h" -- 1.8.0.2

1 0