September 2013 - Devel - libvirt List Archives

[libvirt] [PATCH] build: fix 'make -C src check' under subset builds
by Eric Blake 03 Oct '13

03 Oct '13

Another build failure detected on cygwin, where lxc is not built. The lxc_monitor_protocol.c file requires the use of $(XDR_CFLAGS), but should only be built on platforms where WITH_LXC is true; however, 'make -C src check' was unconditionally trying to build the .o file (and with the wrong CFLAGS) in order to validate the matching -structs file. Rework the checks to only test files that are built for the current configuration. * src/Makefile.am (PROTOCOL_STRUCTS): Split list by which files are currently being compiled. (EXTRA_DIST): Ensure that -structs files are shipped even when not built. (check-protocol): Declare unconditionally, now that the condition has been moved into PROTOCOL_STRUCTS. (libvirt_driver_lxc_impl_la_CFLAGS): Add $(XDR_CFLAGS). (libvirt_net_rpc_la_SOURCES): List generated files more compactly. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- This is a build-breaker, but I'm still in the middle of running a (lengthy) 'make distcheck' on several platforms before pushing, so a review wouldn't hurt. src/Makefile.am | 35 ++++++++++++++++++++++------------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 09311b7..20ba1c8 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -428,18 +428,35 @@ check-symsorting: EXTRA_DIST += check-symfile.pl check-symsorting.pl # Keep this list synced with RPC_PROBE_FILES -PROTOCOL_STRUCTS = \ +PROTOCOL_STRUCTS = +if WITH_REMOTE +PROTOCOL_STRUCTS += \ $(srcdir)/remote_protocol-structs \ $(srcdir)/lxc_protocol-structs \ $(srcdir)/qemu_protocol-structs \ + $(NULL) +endif WITH_REMOTE +PROTOCOL_STRUCTS += \ $(srcdir)/virnetprotocol-structs \ $(srcdir)/virkeepaliveprotocol-structs \ + $(NULL) +if WITH_LXC +PROTOCOL_STRUCTS += \ $(srcdir)/lxc_monitor_protocol-structs \ + $(NULL) +endif WITH_LXC +if WITH_LIBVIRTD +PROTOCOL_STRUCTS += \ $(srcdir)/lock_protocol-structs \ $(NULL) +endif WITH_LIBVIRTD + +# The various -structs files live in git, because they are only +# conditionally generated; ship one -structs file for each .x file. +EXTRA_DIST += $(notdir $(RPC_PROBE_FILES:.x=-structs))) -if WITH_REMOTE check-protocol: $(PROTOCOL_STRUCTS) $(PROTOCOL_STRUCTS:structs=struct) +.PHONY: check-protocol $(PROTOCOL_STRUCTS:structs=struct) # The .o file that pdwtags parses is created as a side effect of running # libtool; but from make's perspective we depend on the .lo file. @@ -458,13 +475,6 @@ $(srcdir)/lock_protocol-struct: \ $(srcdir)/%-struct: locking/lockd_la-%.lo $(PDWTAGS) -else !WITH_REMOTE -# The $(PROTOCOL_STRUCTS) files must live in git, because they cannot be -# re-generated when configured --without-remote. -check-protocol: -endif !WITH_REMOTE -EXTRA_DIST += $(PROTOCOL_STRUCTS) - check-drivername: $(AM_V_GEN)$(PERL) $(srcdir)/check-drivername.pl \ $(srcdir)/driver.h \ @@ -538,7 +548,6 @@ EXTRA_DIST += check-driverimpls.pl check-aclrules.pl check-aclperms.pl check-local: check-protocol check-symfile check-symsorting \ check-drivername check-driverimpls check-aclrules \ check-aclperms -.PHONY: check-protocol $(PROTOCOL_STRUCTS:structs=struct) # Mock driver, covering domains, storage, networks, etc TEST_DRIVER_SOURCES = \ @@ -1183,6 +1192,7 @@ endif ! WITH_DRIVER_MODULES libvirt_driver_lxc_impl_la_CFLAGS = \ $(LIBNL_CFLAGS) \ + $(XDR_CFLAGS) \ $(FUSE_CFLAGS) \ -I$(top_srcdir)/src/access \ -I$(top_srcdir)/src/conf \ @@ -2203,10 +2213,9 @@ BUILT_SOURCES += $(VIR_NET_RPC_GENERATED) libvirt_net_rpc_la_SOURCES = \ rpc/virnetmessage.h rpc/virnetmessage.c \ - rpc/virnetprotocol.h rpc/virnetprotocol.c \ rpc/virnetsocket.h rpc/virnetsocket.c \ - rpc/virkeepaliveprotocol.h rpc/virkeepaliveprotocol.c \ - rpc/virkeepalive.h rpc/virkeepalive.c + rpc/virkeepalive.h rpc/virkeepalive.c \ + $(VIR_NET_RPC_GENERATED) if WITH_SSH2 libvirt_net_rpc_la_SOURCES += \ rpc/virnetsshsession.h rpc/virnetsshsession.c -- 1.8.3.1

1 1

[libvirt] [PATCH] Fix crash in libvirtd when events are registered & ACLs active
by Daniel P. Berrange 03 Oct '13

03 Oct '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> When a client disconnects from libvirtd, all event callbacks must be removed. This involves running the public API virConnectDomainEventDeregisterAny This code does not run in normal API dispatch context, so no identity was set. The result was that the access control drivers denied the attempt to deregister callbacks. The callbacks thus continued to trigger after the client was free'd causing fairly predictable use of free memory & a crash. This can be triggered by any client with readonly access when the ACL drivers are active. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- daemon/remote.c | 6 ++++++ 1 file changed, 6 insertions(+) NB, this bug is a publically reported security flaw and I'll be backporting it to other stable branches. A CVE will be assigned soon and will notify when that info is available. diff --git a/daemon/remote.c b/daemon/remote.c index 9497cc1..f3de6a0 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -666,8 +666,11 @@ void remoteClientFreeFunc(void *data) /* Deregister event delivery callback */ if (priv->conn) { + virIdentityPtr sysident = virIdentityGetSystem(); size_t i; + virIdentitySetCurrent(sysident); + for (i = 0; i < VIR_DOMAIN_EVENT_ID_LAST; i++) { if (priv->domainEventCallbackID[i] != -1) { VIR_DEBUG("Deregistering to relay remote events %zu", i); @@ -678,6 +681,9 @@ void remoteClientFreeFunc(void *data) } virConnectClose(priv->conn); + + virIdentitySetCurrent(NULL); + virObjectUnref(sysident); } VIR_FREE(priv); -- 1.8.3.1

2 2

[libvirt] ANNOUNCE: libvirt 1.0.5.6 maintenance release
by Cole Robinson 03 Oct '13

03 Oct '13

libvirt 1.0.5.6 maintenance release is now available. This is libvirt 1.0.5 with additional bugfixes that have accumulated upstream since the initial release. This release can be downloaded at: http://libvirt.org/sources/stable_updates/libvirt-1.0.5.6.tar.gz Changes in this version: * virsh: fix change-media bug on disk block type * Fix crash in remoteDispatchDomainMemoryStats (CVE-2013-4296) * Add support for using 3-arg pkcheck syntax for process (CVE-2013-4311) * Include process start time when doing polkit checks * qemuDomainChangeGraphics: Check listen address change by listen type * security: provide supplemental groups even when parsing label (CVE-2013-4291) * python: return dictionary without value in case of no blockjob * virbitmap: Refactor virBitmapParse to avoid access beyond bounds of array For info about past maintenance releases, see: http://wiki.libvirt.org/page/Maintenance_Releases Thanks, Cole

5 11

Re: [libvirt] [Qemu-devel] Attaching PCI devices to the PCIe root complex
by Michael S. Tsirkin 02 Oct '13

02 Oct '13

On Wed, Sep 25, 2013 at 11:48:28AM +0300, Marcel Apfelbaum wrote: > On Wed, 2013-09-25 at 10:01 +0300, Michael S. Tsirkin wrote: > > On Tue, Sep 24, 2013 at 06:01:02AM -0400, Laine Stump wrote: > > > When I added support for the Q35-based machinetypes to libvirt, I > > > specifically prohibited attaching any PCI devices (with the exception of > > > graphics controllers) to the PCIe root complex, > > > > That's wrong I think. Anything attached to RC is an integrated > > endpoint, and these can be PCI devices. > I couldn't find on PCIe spec any mention that "Root Complex Integrated EndPoint" > must be PCIe. But, from spec 1.3.2.3: > - A Root Complex Integrated Endpoint must not require I/O resources claimed through BAR(s). > - A Root Complex Integrated Endpoint must not generate I/O Requests. > - A Root Complex Integrated Endpoint is required to support MSI or MSI-X or both if an > interrupt resource is requested. Heh PCI-SIG keeps fighting against legacy interrupts and IO. But lots of hardware happily ignores these rules. And the reason is simple: software does not enforce them. Here's integrated stuff on my laptop: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21cf Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 So it has an IO BAR. 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo Device 21cf Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at f252a000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci-pci So IRQ but no MSI. > I suppose that this restriction can be removed for PCI devices that > 1. Actually work when plugged in into RC Integrated EndPoint > 2. Respond to the above limitations These limitations are just guidance for future devices. They can't change the past, such devices were made. > > > > > and had planned to > > > prevent attaching them to PCIe root ports (ioh3420 device) and PCIe > > > downstream switch ports (xio-3130 device) as well. I did this because, > > > even though qemu currently allows attaching a normal PCI device in any > > > of these three places, the restriction exists for real hardware and I > > > didn't see any guarantee that qemu wouldn't add the restriction in the > > > future in order to more closely emulate real hardware. > > > > > > However, since I did that, I've learned that many of the qemu "pci" > > > devices really should be considered as "pci or pcie". Gerd Hoffman lists > > > some of these cases in a bug he filed against libvirt: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1003983 > > > > > > I would like to loosen up the restrictions in libvirt, but want to make > > > sure that I don't allow something that could later be forbidden by qemu > > > (thus creating a compatibility problem during upgrades). Beyond Gerd's > > > specific requests to allow ehci, uhci, and hda controllers to attach to > > > PCIe ports, are there any other devices that I specifically should or > > > shouldn't allow? (I would rather be conservative in what I allow - it's > > > easy to allow more things later, but nearly impossible to revoke > > > permission once it's been allowed). > For the moment I would not remove any restrictions, but only the ones > requested and verified by somebody. > > > > > IMO, we really need to grow an interface to query this kind of thing. > Basically libvirt needs to know: > 1. for (libvirt) controllers: what kind of devices can be plugged in > 2. for devices (controller is also a device) > - to which controllers can it be plugged in > - does it support hot-plug? > 3. implicit controllers of the machine types (q35 - "pcie-root", i440fx - "pci-root") > All the above must be exported to libvirt > > Implementation options: > 1. Add a compliance field on PCI/PCIe devices and controllers stating if it supports > PCI/PCIe or both (and maybe hot-plug) > - consider plug type + compliance to figure out whether a plug can go into a socket > > 2. Use Markus Armbruster idea of introducing a concept of "plug and sockets": > - dividing the devices into adapters and plugs > - adding sockets to bridges(buses?). > In this way it would be clear which devices can connect to bridges > > Any thoughts? > Thanks, > Marcel It's all not too hard to implement, we just need to know what kind of interface makes sense for management. So Cc libvir-list(a)redhat.com . > > > > >

2 2

[libvirt] libvirt-glib fails to compile with CLANG compiler
by Jason Helfman 02 Oct '13

02 Oct '13

When compiling libvirt-glib with CLANG, I get the following error. 16 warnings generated. CCLD libvirt-glib-1.0.la GEN LibvirtGLib-1.0.gir /usr/local/lib/libvirt.so: undefined reference to `__stack_chk_fail_local' clang: error: linker command failed with exit code 1 (use -v to see invocation) linking of temporary binary failed: Command '['/usr/local/bin/libtool', '--mode=link', '--tag=CC', '--silent', 'clang', '-o', '/usr/home/helfman/workspace/ports/devel/libvirt-glib/work/libvirt-glib-0.1.7/libvirt-glib/tmp-introspectOO6vqG/LibvirtGLib-1.0', '-export-dynamic', '-O2', '-pipe', '-fno-strict-aliasing', '-L/usr/local/lib', '-fstack-protector', '/usr/home/helfman/workspace/ports/devel/libvirt-glib/work/libvirt-glib-0.1.7/libvirt-glib/tmp-introspectOO6vqG/LibvirtGLib-1.0.o', '-L.', './libvirt-glib-1.0.la', '-lgio-2.0', '-lgobject-2.0', '-Wl,--export-dynamic', '-lgmodule-2.0', '-lgthread-2.0', '-pthread', '-L/usr/local/lib', '-lglib-2.0', '-lintl']' returned non-zero exit status 1 gmake[2]: *** [LibvirtGLib-1.0.gir] Error 1 gmake[2]: Leaving directory `/usr/home/helfman/workspace/ports/devel/libvirt-glib/work/libvirt-glib-0.1.7/libvirt-glib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/helfman/workspace/ports/devel/libvirt-glib/work/libvirt-glib-0.1.7' gmake: *** [all] Error 2 *** [do-build] Error code 1 -jgh -- Jason Helfman | FreeBSD Committer jgh(a)FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve

3 7

[libvirt] [PATCH] LXC: Detect fs support. Mount only supported fs in containers
by Bogdan Purcareata 01 Oct '13

01 Oct '13

Some filesystems - specifically securityfs - are not supported in all systems running libvirt containers. When starting a container, mount only the filesystems that are supported on the host. Detection of filesystem support is done at runtime. Signed-off-by: Bogdan Purcareata <bogdan.purcareata(a)freescale.com> --- src/lxc/lxc_container.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index c60f5d8..eff9a24 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -509,6 +509,61 @@ static int lxcContainerChildMountSort(const void *a, const void *b) # define MS_SLAVE (1<<19) #endif +/* + * This function attempts to detect kernel support + * for a specific filesystem type. This is done by + * inspecting /proc/filesystems. + */ +static int lxcCheckFSSupport(const char *fs_type) +{ + FILE *fp = NULL; + int ret = -1; + const char *fslist = "/proc/filesystems"; + char *line = NULL; + const char *type; + + if (!fs_type) + return 1; + + VIR_DEBUG("Checking kernel support for %s", fs_type); + + VIR_DEBUG("Open %s", fslist); + if (!(fp = fopen(fslist, "r"))) { + if (errno == ENOENT) + + virReportSystemError(errno, + _("Unable to read %s"), + fslist); + goto cleanup; + } + + while (!feof(fp)) { + size_t n; + VIR_FREE(line); + if (getline(&line, &n, fp) <= 0) { + if (feof(fp)) + break; + + goto cleanup; + } + + type = strstr(line, fs_type); + if (type) { + ret = 1; + goto cleanup; + } + } + + VIR_DEBUG("No kernel support for %s", fs_type); + + ret = 0; + +cleanup: + VIR_FREE(line); + VIR_FORCE_FCLOSE(fp); + return ret; +} + static int lxcContainerGetSubtree(const char *prefix, char ***mountsret, size_t *nmountsret) @@ -855,17 +910,23 @@ static int lxcContainerMountBasicFS(bool userns_enabled) for (i = 0; i < ARRAY_CARDINALITY(lxcBasicMounts); i++) { virLXCBasicMountInfo const *mnt = &lxcBasicMounts[i]; const char *srcpath = NULL; + const char *dstpath = NULL; VIR_DEBUG("Processing %s -> %s", mnt->src, mnt->dst); srcpath = mnt->src; + dstpath = mnt->dst; /* Skip if mount doesn't exist in source */ if ((srcpath[0] == '/') && (access(srcpath, R_OK) < 0)) continue; + if ((access(dstpath, R_OK) < 0) || /* mount is not present on host */ + (!lxcCheckFSSupport(mnt->type))) /* no fs support in kernel */ + continue; + #if WITH_SELINUX if (STREQ(mnt->src, SELINUX_MOUNT) && (!is_selinux_enabled() || userns_enabled)) -- 1.7.11.7

3 2

[libvirt] networking restart after redefinition
by Mihamina Rakotomandimby 01 Oct '13

01 Oct '13

Hi all, Running Fedora 18 and the bundled libvirt and virt-tools. Desktop use. As I like to access my guests with a hostname and not a numerical IP address, I fix the IP addressing in the network configuration: http://pastebin.com/rfMKn40j Unfortunately, I cant find a way to add a host without loosing the whole networking, as when I add a ahost, I destroy and redefine the network. Restarting libvirtd is not the solution. How would you recommend to have networking UP after network redefinition? -- RMA.

2 2

[libvirt] [PATCH] libvirt: hostdev SCSI AdapterId retrieval fix
by Boris Fiuczynski 01 Oct '13

01 Oct '13

Fixed the retrieval of the AdapterId from the AdapterName of the hostdev source so it does return an error instead of leaving the adapter_id uninitialized. Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> Reviewed-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- src/util/virscsi.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/src/util/virscsi.c b/src/util/virscsi.c index 43658c0..7aca9e6 100644 --- a/src/util/virscsi.c +++ b/src/util/virscsi.c @@ -88,16 +88,13 @@ static int virSCSIDeviceGetAdapterId(const char *adapter, unsigned int *adapter_id) { - if (STRPREFIX(adapter, "scsi_host")) { - if (virStrToLong_ui(adapter + strlen("scsi_host"), - NULL, 0, adapter_id) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Cannot parse adapter '%s'"), adapter); - return -1; - } - } - - return 0; + if (STRPREFIX(adapter, "scsi_host") && + virStrToLong_ui(adapter + strlen("scsi_host"), + NULL, 0, adapter_id) == 0) + return 0; + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Cannot parse adapter '%s'"), adapter); + return -1; } char * -- 1.8.3.1

2 3

[libvirt] FreeBSD-8.3 build failure for amd64/i386, build archive included
by Jason Helfman 01 Oct '13

01 Oct '13

Libvirt no longer builds on FreeBSD 8.3. I had brought this up awhile ago, but didn't have the resources to get the requested information. A fellow committer was able to build, and send me an archive of the complete build failure for analysis. Here is a link to build archive for investigation. http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz Please let me know if there is any information you need. Thanks! -jgh -- Jason Helfman | FreeBSD Committer jgh(a)FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve

5 12

[libvirt] [PATCH] VMware: Add Fusion version test
by Doug Goldstein 01 Oct '13

01 Oct '13

This adds a test for the version string of VMware Fusion. --- Not sure how but this was dropped from my series adding VMware Fusion that was added prior to 1.1.3-rc2. This should be safe for 1.1.3 and probably encouraged --- tests/vmwareverdata/fusion-5.0.3.txt | 3 +++ tests/vmwarevertest.c | 1 + 2 files changed, 4 insertions(+) create mode 100644 tests/vmwareverdata/fusion-5.0.3.txt diff --git a/tests/vmwareverdata/fusion-5.0.3.txt b/tests/vmwareverdata/fusion-5.0.3.txt new file mode 100644 index 0000000..9fae811 --- /dev/null +++ b/tests/vmwareverdata/fusion-5.0.3.txt @@ -0,0 +1,3 @@ + +VMware Fusion Information: +VMware Fusion 5.0.3 build-1040386 Release diff --git a/tests/vmwarevertest.c b/tests/vmwarevertest.c index f5ccb06..47c250c 100644 --- a/tests/vmwarevertest.c +++ b/tests/vmwarevertest.c @@ -88,6 +88,7 @@ mymain(void) } while (0) DO_TEST("ws", "workstation-7.0.0", 7000000); + DO_TEST("fusion", "fusion-5.0.3", 5000003); return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } -- 1.8.1.5

2 2