- Devel - libvirt List Archives

[libvirt] [PATCH] Explicitly link libvirt_net_rpc against SELINUX_LIBS
by Guido Günther 14 Sep '13

14 Sep '13

Since virnetsocket conditionally uses selinux we need to link against it otherwise the build fails with: CCLD libvirtd /usr/bin/ld: ../src/.libs/libvirt-lxc.so: undefined reference to symbol 'freecon' /lib/i386-linux-gnu/libselinux.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[3]: *** [libvirtd] Error 1 --- src/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/Makefile.am b/src/Makefile.am index 711da32..1a74435 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -2226,6 +2226,7 @@ libvirt_net_rpc_la_LDFLAGS = \ $(GNUTLS_LIBS) \ $(SASL_LIBS) \ $(SSH2_LIBS)\ + $(SELINUX_LIBS) \ $(AM_LDFLAGS) \ $(CYGWIN_EXTRA_LDFLAGS) \ $(MINGW_EXTRA_LDFLAGS) -- 1.8.4.rc3

2 2

[libvirt] Non-deterministic mail delivery problems
by Daniel P. Berrange 13 Sep '13

13 Sep '13

FYI, we are aware that there are mail delivery problems with this list, that started sometime yesterday. The symptom is mails appearing in the list archive fine, but never making it into your INBOX. We have a ticket open for someone to investigate & resolve this problem. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 2

[libvirt] [PATCH] tools: fix a judgment of equalling zero about an array's length
by lawrancejing 13 Sep '13

13 Sep '13

There is no need to go on executing code when the array's length is zero. --- tools/virsh-snapshot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index e37a5b3..d7a4c7b 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -239,7 +239,7 @@ vshParseSnapshotMemspec(vshControl *ctl, virBufferPtr buf, const char *str) return 0; narray = vshStringToArray(str, &array); - if (narray < 0) + if (narray <= 0) goto cleanup; for (i = 0; i < narray; i++) { -- 1.7.1

2 1

[libvirt] [v0.9.12-maint v3 00/12] Debian's 0.9.12 patches
by Guido Günther 13 Sep '13

13 Sep '13

These are the patches Debian is currently carrying on 0.9.12. Most are straight cherry-picks. Since we're maintaining 0.9.12 for our current stable release I'm happy to push these to v0.9.12-maint. The only change over v2 is the adjuste commit message. Daniel P. Berrange (2): Don't ignore return value of qemuProcessKill Fix race condition when destroying guests Eric Blake (1): build: fix virnetlink on glibc 2.11 Jiri Denemark (3): daemon: Fix crash in virTypedParameterArrayClear Revert "rpc: Discard non-blocking calls only when necessary" qemu: Add support for -no-user-config Luca Tettamanti (1): storage: Need to also VIR_FREE(reg) Martin Kletzander (1): security: Fix libvirtd crash possibility Peter Krempa (4): qemu: Fix off-by-one error while unescaping monitor strings rpc: Fix crash on error paths of message dispatching conf: Remove callback from stream when freeing entries in console hash conf: Remove console stream callback only when freeing console helper cfg.mk | 3 +- daemon/remote.c | 16 +- src/conf/virconsole.c | 13 ++ src/qemu/qemu_capabilities.c | 7 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 11 +- src/qemu/qemu_driver.c | 21 ++- src/qemu/qemu_monitor.c | 11 +- src/rpc/virnetclient.c | 21 +-- src/rpc/virnetserverclient.c | 3 + src/rpc/virnetserverprogram.c | 11 +- src/storage/storage_backend_logical.c | 5 +- src/util/virnetlink.h | 2 + tests/qemuhelpdata/qemu-1.1 | 268 ++++++++++++++++++++++++++++++++++ tests/qemuhelpdata/qemu-1.1-device | 160 ++++++++++++++++++++ tests/qemuhelptest.c | 75 ++++++++++ 16 files changed, 586 insertions(+), 42 deletions(-) create mode 100644 tests/qemuhelpdata/qemu-1.1 create mode 100644 tests/qemuhelpdata/qemu-1.1-device -- 1.8.4.rc3

2 14

[libvirt] [PATCH] docs: mention hostname subtlety
by Eric Blake 13 Sep '13

13 Sep '13

An off-list bug report mentioned some confusion where the public documentation of libvirt.c:virConnectGetHostname did not match the private documentation of util/virutil.c:virGetHostname. * src/libvirt.c (virConnectGetHostname): Tweak docs. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- src/libvirt.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 20a2d4c..a6fcab0 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -1701,9 +1701,10 @@ error: * virConnectGetHostname: * @conn: pointer to a hypervisor connection * - * This returns the system hostname on which the hypervisor is - * running (the result of the gethostname system call). If - * we are connected to a remote system, then this returns the + * This returns a system hostname on which the hypervisor is + * running (based on the result of the gethostname system call, but + * possibly expanded to a fully-qualified domain name via getaddrinfo). + * If we are connected to a remote system, then this returns the * hostname of the remote system. * * Returns the hostname which must be freed by the caller, or -- 1.8.3.1

2 2

[libvirt] [PATCH] tools: add missing 'interface' type and update man page
by Alex Jia 13 Sep '13

13 Sep '13

Signed-off-by: Alex Jia <ajia(a)redhat.com> --- tools/virt-xml-validate.in | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/tools/virt-xml-validate.in b/tools/virt-xml-validate.in index 6bfa68f..8be9595 100644 --- a/tools/virt-xml-validate.in +++ b/tools/virt-xml-validate.in @@ -83,6 +83,9 @@ if [ -z "$TYPE" ]; then *secret*) TYPE="secret" ;; + *interface*) + TYPE="interface" + ;; *) echo "$0: cannot determine schema type for $XMLFILE" >&2 exit 3 @@ -124,6 +127,10 @@ Valid schema names currently include =over 4 +=item C<domainsnapshot> + +The schema for the XML format used by domain snapshot configuration + =item C<domain> The schema for the XML format used by guest domains configuration @@ -148,6 +155,18 @@ The schema for the XML format used by node device descriptions The schema for the XML format used to declare driver capabilities +=item C<nwfilter> + +The schema for the XML format used by network traffic filters + +=item C<secret> + +The schema for the XML format used by secrets descriptions + +=item C<interface> + +The schema for the XML format used by virtual interface + =back =head1 OPTIONS -- 1.7.1

2 1

[libvirt] [PATCH 0/2] tests: Fix virsh-uriprecedence when ran as root
by Martin Kletzander 13 Sep '13

13 Sep '13

Basically v2 of http://www.redhat.com/archives/libvir-list/2013-September/msg00689.html Martin Kletzander (2): test-lib: Make case skipping possible tests: Don't test user config file if ran as root tests/test-lib.sh | 18 ++++++++++++++++++ tests/virsh-uriprecedence | 6 +++++- 2 files changed, 23 insertions(+), 1 deletion(-) -- 1.8.3.2

4 8

[libvirt] [PATCHv2 0/4] Introduce APIs to extract DHCP leases info
by Nehal J Wani 13 Sep '13

13 Sep '13

This API returns the information stored in the DHCP leases file created by dnsmasq for a given virtual network. It contacts the bridge network driver, which parses the leases file. It supports two methods: 1. Return info for all network interfaces connected to a given virtual network 2. Return information for a particular network interface in a given virtual network by providing its MAC Address v2 * Since DHCPv6 is supposed to be suported in future, virNetworkGetDHCPLeasesForMAC changed, prefix and virIPAddrType added in virNetworkDHCPLeases struct. v1 * Refer: https://www.redhat.com/archives/libvir-list/2013-September/msg00620.html * The need for these APIs were result of a RFC was proposed on the list. Refer: http://www.redhat.com/archives/libvir-list/2013-July/msg01603.html Nehal J Wani (4): net-dhcp-leases: Implement the public APIs net-dhcp-leases: Implement the remote protocol net-dhcp-leases: Private implementation inside network driver net-dhcp-leases: Add virsh support daemon/remote.c | 133 +++++++++++++++++++++++++++++ include/libvirt/libvirt.h.in | 33 ++++++++ python/generator.py | 3 + src/driver.h | 13 +++ src/libvirt.c | 173 ++++++++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 1 + src/libvirt_public.syms | 7 ++ src/network/bridge_driver.c | 193 +++++++++++++++++++++++++++++++++++++++++++ src/remote/remote_driver.c | 150 +++++++++++++++++++++++++++++++++ src/remote/remote_protocol.x | 50 ++++++++++- src/remote_protocol-structs | 32 +++++++ src/rpc/gendispatch.pl | 1 + tools/virsh-network.c | 101 ++++++++++++++++++++++ tools/virsh.pod | 6 ++ 14 files changed, 895 insertions(+), 1 deletion(-) -- 1.7.11.7

2 10

[libvirt] USB: USB Passthrough Device Autoconnect Feature
by Gonglei (Arei) 13 Sep '13

13 Sep '13

Hi, all Qemu upstream had achieved USB Passthrough Device Autoconnect Feature for the guest. Such as a USB device is unplugged from the host then plugged back in to the same USB physical port. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provide such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -Gonglei

2 1

[libvirt] rpmbuild libvirt 1.1.2 problem
by jsjshaowentao＠21cn.com 13 Sep '13

13 Sep '13

4 5

[libvirt] [RESEND][PATCHv5 0/4] write separate module for hostdev passthrough
by Chunyan Liu 13 Sep '13

13 Sep '13

[rebased to latest libvirt code for applying and reviewing the patches] These patches implements a separate module for hostdev passthrough so that it could be shared by different drivers and can maintain a global state of a host device. Plus, add passthrough to libxl driver, and change qemu driver and lxc driver to use hostdev common library instead of their own hostdev APIs. --- Changes to v4: * change the way checking hypervisor driver name to decide whether use pciback or pci-stub as stub driver, instead, using driver callback to handle that. * remove get active/inactive list APIs from hostdev common library since currently no code uses them. * add nodedev-detach/reattach/reset to libxl driver * other fixes to Daniel and Jim's comments v4 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00806.html Changes to v3: * fix Jim's comments v3 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00019.html Changes to v2: * add patches for qemu driver and lxc driver, use common library APIs instead of their own hostdev APIs. * add APIs for nodedev-detach and nodedev-reattach calling. * rename functions to use unified prefix 'virHostdev' * use VIR_ONCE_GLOBAL_INIT() as others instead of previous Init and Cleanup. * use VIR_STRDUP instead of strdup * rebase to latest code v2 is here: https://www.redhat.com/archives/libvir-list/2013-June/msg00263.html Chunyan Liu (4): add hostdev passthrough common library add pci passthrough to libxl driver change qemu driver to use hostdev common library change lxc driver to use hostdev common library docs/schemas/domaincommon.rng | 1 + po/POTFILES.in | 3 +- src/Makefile.am | 3 +- src/conf/domain_conf.c | 3 +- src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 15 + src/libxl/libxl_conf.c | 63 ++ src/libxl/libxl_conf.h | 4 + src/libxl/libxl_domain.c | 9 + src/libxl/libxl_driver.c | 443 ++++++++++++++- src/lxc/lxc_conf.h | 4 - src/lxc/lxc_driver.c | 45 +- src/lxc/lxc_hostdev.c | 413 ------------- src/lxc/lxc_hostdev.h | 43 -- src/lxc/lxc_process.c | 21 +- src/qemu/qemu_command.c | 1 - src/qemu/qemu_conf.h | 9 +- src/qemu/qemu_domain.c | 9 + src/qemu/qemu_driver.c | 72 +-- src/qemu/qemu_hostdev.c | 1289 --------------------------------------- src/qemu/qemu_hostdev.h | 72 --- src/qemu/qemu_hotplug.c | 126 ++--- src/qemu/qemu_process.c | 34 +- src/util/virhostdev.c | 1335 +++++++++++++++++++++++++++++++++++++++++ src/util/virhostdev.h | 104 ++++ src/util/virpci.c | 28 +- src/util/virpci.h | 9 +- src/util/virscsi.c | 26 +- src/util/virscsi.h | 8 +- src/util/virusb.c | 27 +- src/util/virusb.h | 8 +- 31 files changed, 2195 insertions(+), 2033 deletions(-) delete mode 100644 src/lxc/lxc_hostdev.c delete mode 100644 src/lxc/lxc_hostdev.h delete mode 100644 src/qemu/qemu_hostdev.c delete mode 100644 src/qemu/qemu_hostdev.h create mode 100644 src/util/virhostdev.c create mode 100644 src/util/virhostdev.h

2 2

[libvirt] [PATCH] tools: fix a judgment of equalling zero about an array's length
by lawrancejing 13 Sep '13

13 Sep '13

There is no need to go on executing code when the array's length is zero. --- tools/virsh-snapshot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index e37a5b3..d7a4c7b 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -239,7 +239,7 @@ vshParseSnapshotMemspec(vshControl *ctl, virBufferPtr buf, const char *str) return 0; narray = vshStringToArray(str, &array); - if (narray < 0) + if (narray <= 0) goto cleanup; for (i = 0; i < narray; i++) { -- 1.7.1

3 2

[libvirt] USB: USB Passthrough Device Autoconnect Feature
by Wangyufei (A) 13 Sep '13

13 Sep '13

Hello, Qemu upstream had achieved USB Passthrough Device Autoconnect Feature for the guest. Such as a USB device is unplugged from the host then plugged back in to the same USB physical port. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provided such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -WangYufei

1 0

[libvirt] [PATCH v2] Add some notes about security considerations when using LXC
by Daniel P. Berrange 13 Sep '13

13 Sep '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Describe some of the issues to be aware of when configuring LXC guests with security isolation as a goal. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/drvlxc.html.in | 103 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) In v2: - Clarify UNIX domain socket issues wrt filesystem & network namespaces diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index 1e6aa1d..66d97e4 100644 --- a/docs/drvlxc.html.in +++ b/docs/drvlxc.html.in @@ -168,6 +168,109 @@ Further block or character devices will be made available to containers depending on their configuration. </p> +<h2><a name="security">Security considerations</a></h2> + +<p> +The libvirt LXC driver is fairly flexible in how it can be configured, +and as such does not enforce a requirement for strict security +separation between a container and the host. This allows it to be used +in scenarios where only resource control capabilities are important, +and resource sharing is desired. Applications wishing to ensure secure +isolation between a container and the host must ensure that they are +writing a suitable configuration. +</p> + +<h3><a name="securenetworking">Network isolation</a></h3> + +<p> +If the guest configuration does not list any network interfaces, +the <code>network</code> namespace will not be activated, and thus +the container will see all the host's network interfaces. This will +allow apps in the container to bind to/connect from TCP/UDP addresses +and ports from the host OS. It also allows applications to access +UNIX domain sockets associated with the host OS, which are in the +abstract namespace. If access to UNIX domains sockets in the abstract +namespace is not wanted, then applications should set the +<code><privnet/></code> flag in the +<code><features>....</features></code> element. +</p> + +<h3><a name="securefs">Filesystem isolation</a></h3> + +<p> +If the guest configuration does not list any filesystems, then +the container will be set up with a root filesystem that matches +the host's root filesystem. As noted earlier, only a few locations +such as <code>/dev</code>, <code>/proc</code> and <code>/sys</code> +will be altered. This means that, in the absence of restrictions +from sVirt, a process running as user/group N:M inside the container +will be able to access almost exactly the same files as a process +running as user/group N:M in the host. +</p> + +<p> +There are multiple options for restricting this. It is possible to +simply map the existing root filesystem through to the container in +read-only mode. Alternatively a completely separate root filesystem +can be configured for the guest. In both cases, further sub-mounts +can be applied to customize the content that is made visible. Note +that in the absence of sVirt controls, it is still possible for the +root user in a container to unmount any sub-mounts applied. The user +namespace feature can also be used to restrict access to files based +on the UID/GID mappings. +</p> + +<p> +Sharing the host filesystem tree, also allows applications to access +UNIX domains sockets associated with the host OS, which are in the +filesystem namespaces. It should be noted that a number of init +systems including at least <code>systemd</code> and <code>upstart</code> +have UNIX domain socket which are used to control their operation. +Thus, if the directory/filesystem holding their UNIX domain socket is +exposed to the container, it will be possible for a user in the container +to invoke operations on the init service in the same way it could if +outside the container. This also applies to other applications in the +host which use UNIX domain sockets in the filesystem, such as DBus, +Libvirtd, and many more. If this is not desired, then applications +should either specify the UID/GID mapping in the configuration to +enable user namespaces & thus block access to the UNIX domain socket +based on permissions, or should ensure the relevant directories have +a bind mount to hide them. This is particularly important for the +<code>/run</code> or <code>/var/run</code> directories. +</p> + + +<h3><a name="secureusers">User and group isolation</a></h3> + +<p> +If the guest configuration does not list any ID mapping, then the +user and group IDs used inside the container will match those used +outside the container. In addition, the capabilities associated with +a process in the container will infer the same privileges they would +for a process in the host. This has obvious implications for security, +since a root user inside the container will be able to access any +file owned by root that is visible to the container, and perform more +or less any privileged kernel operation. In the absence of additional +protection from sVirt, this means that the root user inside a container +is effectively as powerful as the root user in the host. There is no +security isolation of the root user. +</p> + +<p> +The ID mapping facility was introduced to allow for stricter control +over the privileges of users inside the container. It allows apps to +define rules such as "user ID 0 in the container maps to user ID 1000 +in the host". In addition the privileges associated with capabilities +are somewhat reduced so that they can not be used to escape from the +container environment. A full description of user namespaces is outside +the scope of this document, however LWN has +<a href="https://lwn.net/Articles/532593/">a good write-up on the topic</a>. +From the libvirt point of view, the key thing to remember is that defining +an ID mapping for users and groups in the container XML configuration +causes libvirt to activate the user namespace feature. +</p> + + <h2><a name="activation">Systemd Socket Activation Integration</a></h2> <p> -- 1.8.3.1

3 4

[libvirt] [PATCH] Fix naming of permission for detecting storage pools
by Daniel P. Berrange 12 Sep '13

12 Sep '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The VIR_ACCESS_PERM_CONNECT_DETECT_STORAGE_POOLS enum constant had its string format be 'detect_storage_pool', note the missing trailing 's'. This prevent the ACL check from ever succeeding. Fix this and add a simple test script to validate this problem of matching names. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/Makefile.am | 8 ++++- src/access/viraccessperm.c | 2 +- src/check-aclperms.pl | 75 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 83 insertions(+), 2 deletions(-) create mode 100755 src/check-aclperms.pl diff --git a/src/Makefile.am b/src/Makefile.am index 711da32..9f9dcd9 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -528,10 +528,16 @@ check-aclrules: $(REMOTE_PROTOCOL) \ $(addprefix $(srcdir)/,$(filter-out /%,$(STATEFUL_DRIVER_SOURCE_FILES))) +check-aclperms: + $(AM_V_GEN)$(PERL) $(srcdir)/check-aclperms.pl \ + $(srcdir)/access/viraccessperm.h \ + $(srcdir)/access/viraccessperm.c + EXTRA_DIST += check-driverimpls.pl check-aclrules.pl check-local: check-protocol check-symfile check-symsorting \ - check-drivername check-driverimpls check-aclrules + check-drivername check-driverimpls check-aclrules \ + check-aclperms .PHONY: check-protocol $(PROTOCOL_STRUCTS:structs=struct) # Mock driver, covering domains, storage, networks, etc diff --git a/src/access/viraccessperm.c b/src/access/viraccessperm.c index 9c720f9..d517c66 100644 --- a/src/access/viraccessperm.c +++ b/src/access/viraccessperm.c @@ -30,7 +30,7 @@ VIR_ENUM_IMPL(virAccessPermConnect, "search_storage_pools", "search_node_devices", "search_interfaces", "search_secrets", "search_nwfilters", - "detect_storage_pool", "pm_control", + "detect_storage_pools", "pm_control", "interface_transaction"); VIR_ENUM_IMPL(virAccessPermDomain, diff --git a/src/check-aclperms.pl b/src/check-aclperms.pl new file mode 100755 index 0000000..b7fadcd --- /dev/null +++ b/src/check-aclperms.pl @@ -0,0 +1,75 @@ +#!/usr/bin/perl +# +# Copyright (C) 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 +# License as published by the Free Software Foundation; either +# version 2.1 of the License, or (at your option) any later version. +# +# This library is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# Lesser General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public +# License along with this library. If not, see +# <http://www.gnu.org/licenses/>. +# +# This script just validates that the stringified version of +# a virAccessPerm enum matches the enum constant name. We do +# alot of auto-generation of code, so when these don't match +# problems occur, preventing auth from succeeding at all. + +my $hdr = shift; +my $impl = shift; + +my %perms; + +my @perms; + +open HDR, $hdr or die "cannot read $hdr: $!"; + +while (<HDR>) { + if (/^\s+VIR_ACCESS_PERM_([_A-Z]+)(,?|\s|$)/) { + my $perm = $1; + + $perms{$perm} = 1 unless ($perm =~ /_LAST$/); + } +} + +close HDR; + + +open IMPL, $impl or die "cannot read $impl: $!"; + +my $group; +my $warned = 0; + +while (defined (my $line = <IMPL>)) { + if ($line =~ /VIR_ACCESS_PERM_([_A-Z]+)_LAST/) { + $group = $1; + } elsif ($line =~ /"[_a-z]+"/) { + my @bits = split /,/, $line; + foreach my $bit (@bits) { + if ($bit =~ /"([_a-z]+)"/) { + #print $1, "\n"; + + my $perm = uc($group . "_" . $1); + if (!exists $perms{$perm}) { + print STDERR "Unknown perm string $1 for group $group\n"; + $warned = 1; + } + delete $perms{$perm}; + } + } + } +} +close IMPL; + +foreach my $perm (keys %perms) { + print STDERR "Perm $perm had not string form\n"; + $warned = 1; +} + +exit $warned; -- 1.8.3.1

2 2

[libvirt] [PATCH] rbd: Use rbd_create3 to create RBD format 2 images by default
by Wido den Hollander 12 Sep '13

12 Sep '13

This new RBD format supports snapshotting and cloning. By having libvirt create images in format 2 end-users of the created images can benefit of the new RBD format. Signed-off-by: Wido den Hollander <wido(a)widodh.nl> --- src/storage/storage_backend_rbd.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index d9e1789..e79873f 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -435,6 +435,26 @@ cleanup: return ret; } +static int virStorageBackendRBDCreateImage(rados_ioctx_t io, + char *name, long capacity) +{ + int order = 0; + #if LIBRBD_VERSION_CODE > 260 + uint64_t features = 3; + uint64_t stripe_count = 1; + uint64_t stripe_unit = 4194304; + + if (rbd_create3(io, name, capacity, features, &order, + stripe_count, stripe_unit) < 0) { + #else + if (rbd_create(io, name, capacity, &order) < 0) { + #endif + return -1; + } + + return 0; +} + static int virStorageBackendRBDCreateVol(virConnectPtr conn, virStoragePoolObjPtr pool, virStorageVolDefPtr vol) @@ -442,7 +462,6 @@ static int virStorageBackendRBDCreateVol(virConnectPtr conn, virStorageBackendRBDStatePtr ptr; ptr.cluster = NULL; ptr.ioctx = NULL; - int order = 0; int ret = -1; VIR_DEBUG("Creating RBD image %s/%s with size %llu", @@ -467,7 +486,7 @@ static int virStorageBackendRBDCreateVol(virConnectPtr conn, goto cleanup; } - if (rbd_create(ptr.ioctx, vol->name, vol->capacity, &order) < 0) { + if (virStorageBackendRBDCreateImage(ptr.ioctx, vol->name, vol->capacity) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("failed to create volume '%s/%s'"), pool->def->source.name, -- 1.7.9.5

2 2

[libvirt] [PATCH] Allow root users to have their own configuration file
by Martin Kletzander 12 Sep '13

12 Sep '13

Currently, we have two configuration file paths, one global (where "global" means root-only and we're probably not changing this in near future) and one per-user. Unfortunately root user cannot use the second option because until now we were choosing the file path depending only on whether the user is root or not. This patch modifies the mentioned behavior for root only, allowing him to set his own configuration files without changing anything in system-wide configuration folders. This also makes the virsh-uriprecedence test pass its first test case when ran as root. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Notes: I'm playing along previously mentioned "proper behavior" in this patch. However, IMNSHO, our "global" or "system-wide" configuration file (defaulting to '/etc/libvirt/libvirt.conf') should be accessible for all users since this has no security impact (security information may be in files 'libvirtd.conf' or 'qemu.conf'). This file should be also read and used for all users. After that, settings in user configuration file (defaulting to '~/.config/libvirt/libvirt.conf') may override some of these settings for that user. This is how all sensible configurations are loaded and that's also what I'd prefer. Unfortunately some developers feels this should be done in completely different way. src/libvirt.c | 56 ++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 36 insertions(+), 20 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 20a2d4c..bfc466b 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -957,28 +957,34 @@ error: return -1; } -static char * -virConnectGetConfigFilePath(void) +/* + * Return code 0 means no error, but doesn't guarantee path != NULL. + */ +static int +virConnectGetConfigFilePath(char **path, bool global) { - char *path; - if (geteuid() == 0) { - if (virAsprintf(&path, "%s/libvirt/libvirt.conf", + char *userdir = NULL; + int ret = -1; + *path = NULL; + + /* Don't provide the global configuration file to non-root users */ + if (geteuid() != 0 && global) + return 0; + + if (global) { + if (virAsprintf(path, "%s/libvirt/libvirt.conf", SYSCONFDIR) < 0) - return NULL; + goto cleanup; } else { - char *userdir = virGetUserConfigDirectory(); - if (!userdir) - return NULL; - - if (virAsprintf(&path, "%s/libvirt.conf", - userdir) < 0) { - VIR_FREE(userdir); - return NULL; - } - VIR_FREE(userdir); + if (!(userdir = virGetUserConfigDirectory()) || + virAsprintf(path, "%s/libvirt.conf", userdir) < 0) + goto cleanup; } - return path; + ret = 0; + cleanup: + VIR_FREE(userdir); + return ret; } static int @@ -989,12 +995,22 @@ virConnectGetConfigFile(virConfPtr *conf) *conf = NULL; - if (!(filename = virConnectGetConfigFilePath())) + /* Try reading user configuration file unconditionally */ + if (virConnectGetConfigFilePath(&filename, false) < 0) goto cleanup; if (!virFileExists(filename)) { - ret = 0; - goto cleanup; + /* and in case there is none, try the global one. */ + + VIR_FREE(filename); + if (virConnectGetConfigFilePath(&filename, true) < 0) + goto cleanup; + + if (!filename || + !virFileExists(filename)) { + ret = 0; + goto cleanup; + } } VIR_DEBUG("Loading config file '%s'", filename); -- 1.8.3.2

3 6

[libvirt] [PATCHv2] netcf driver: use a single netcf handle for all connections
by Laine Stump 12 Sep '13

12 Sep '13

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=983026 The netcf interface driver previously had no state driver associated with it - as a connection was opened, it would create a new netcf instance just for that connection, and close it when it was finished. the problem with this is that each connection to libvirt used up a netlink socket, and there is a per process maximum of ~1000 netlink sockets. The solution is to create a state driver to go along with the netcf driver. The state driver will opens a netcf instance, then all connections share that same netcf instance, thus only a single netlink socket will be used no matter how many connections are mde to libvirtd. This was rather simple to do - a new virObjectLockable class is created for the single driverState object, which is created in netcfStateInitialize and contains the single netcf handle; instead of creating a new object for each client connection, netcfInterfaceOpen now just increments the driverState object's reference count and puts a pointer to it into the connection's privateData. Similarly, netcfInterfaceClose() just un-refs the driverState object (as does netcfStateCleanup()), and virNetcfInterfaceDriverStateDispose() handles closing the netcf instance. Since all the functions already have locking around them, the static lock functions used by all functions just needed to be changed to call virObjectLock() and virObjectUnlock() instead of directly calling the virMutex* functions. --- Changes from V1: * make driverState a static. * switch to using a virObjectLockable for driverState, at Eric's suggestion. * add a simple error message if ncf_init() fails. Again, I've tried this with a small number of simultaneous connections (including virt-manager), but I don't have a ready-made stress test. src/interface/interface_backend_netcf.c | 173 +++++++++++++++++++++++--------- 1 file changed, 125 insertions(+), 48 deletions(-) diff --git a/src/interface/interface_backend_netcf.c b/src/interface/interface_backend_netcf.c index f47669e..627c225 100644 --- a/src/interface/interface_backend_netcf.c +++ b/src/interface/interface_backend_netcf.c @@ -41,19 +41,119 @@ /* Main driver state */ typedef struct { - virMutex lock; + virObjectLockable parent; struct netcf *netcf; } virNetcfDriverState, *virNetcfDriverStatePtr; +static virClassPtr virNetcfDriverStateClass; +static void virNetcfDriverStateDispose(void *obj); -static void interfaceDriverLock(virNetcfDriverStatePtr driver) +static int +virNetcfDriverStateOnceInit(void) +{ + if (!(virNetcfDriverStateClass = virClassNew(virClassForObjectLockable(), + "virNetcfDriverState", + sizeof(virNetcfDriverState), + virNetcfDriverStateDispose))) + return -1; + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virNetcfDriverState) + +static virNetcfDriverStatePtr driverState = NULL; + +static void +virNetcfDriverStateDispose(void *obj) +{ + virNetcfDriverStatePtr driver = obj; + + if (driver->netcf) + ncf_close(driver->netcf); +} + +static void +interfaceDriverLock(virNetcfDriverStatePtr driver) +{ + virObjectLock(driver); +} + +static void +interfaceDriverUnlock(virNetcfDriverStatePtr driver) +{ + virObjectUnlock(driver); +} + +static int +netcfStateInitialize(bool privileged ATTRIBUTE_UNUSED, + virStateInhibitCallback callback ATTRIBUTE_UNUSED, + void *opaque ATTRIBUTE_UNUSED) +{ + if (virNetcfDriverStateInitialize() < 0) + return -1; + + if (!(driverState = virObjectLockableNew(virNetcfDriverStateClass))) + return -1; + + /* open netcf */ + if (ncf_init(&driverState->netcf, NULL) != 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("failed to initialize netcf")); + virObjectUnref(driverState); + driverState = NULL; + return -1; + } + return 0; +} + +static int +netcfStateCleanup(void) { - virMutexLock(&driver->lock); + if (!driverState) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Attempt to close netcf state driver already closed")); + return -1; + } + + if (virObjectUnref(driverState)) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Attempt to close netcf state driver " + "with open connections")); + return -1; + } + driverState = NULL; + return 0; } -static void interfaceDriverUnlock(virNetcfDriverStatePtr driver) +static int +netcfStateReload(void) { - virMutexUnlock(&driver->lock); + int ret = -1; + + if (!driverState) + return 0; + + interfaceDriverLock(driverState); + ncf_close(driverState->netcf); + if (ncf_init(&driverState->netcf, NULL) != 0) + { + /* this isn't a good situation, because we can't shut down the + * driver as there may still be connections to it. If we set + * the netcf handle to NULL, any subsequent calls to netcf + * will just fail rather than causing a crash. Not ideal, but + * livable (since this should never happen). + */ + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("failed to re-init netcf")); + driverState->netcf = NULL; + goto cleanup; + } + + ret = 0; +cleanup: + interfaceDriverUnlock(driverState); + + return ret; } /* @@ -148,61 +248,30 @@ static struct netcf_if *interfaceDriverGetNetcfIF(struct netcf *ncf, virInterfac return iface; } -static virDrvOpenStatus netcfInterfaceOpen(virConnectPtr conn, - virConnectAuthPtr auth ATTRIBUTE_UNUSED, - unsigned int flags) +static virDrvOpenStatus +netcfInterfaceOpen(virConnectPtr conn, + virConnectAuthPtr auth ATTRIBUTE_UNUSED, + unsigned int flags) { - virNetcfDriverStatePtr driverState; - virCheckFlags(VIR_CONNECT_RO, VIR_DRV_OPEN_ERROR); - if (VIR_ALLOC(driverState) < 0) - goto alloc_error; - - /* initialize non-0 stuff in driverState */ - if (virMutexInit(&driverState->lock) < 0) - { - /* what error to report? */ - goto mutex_error; - } - - /* open netcf */ - if (ncf_init(&driverState->netcf, NULL) != 0) - { - /* what error to report? */ - goto netcf_error; - } + if (!driverState) + return VIR_DRV_OPEN_ERROR; + virObjectRef(driverState); conn->interfacePrivateData = driverState; return VIR_DRV_OPEN_SUCCESS; - -netcf_error: - if (driverState->netcf) - { - ncf_close(driverState->netcf); - } - virMutexDestroy(&driverState->lock); -mutex_error: - VIR_FREE(driverState); -alloc_error: - return VIR_DRV_OPEN_ERROR; } -static int netcfInterfaceClose(virConnectPtr conn) +static int +netcfInterfaceClose(virConnectPtr conn) { if (conn->interfacePrivateData != NULL) { - virNetcfDriverStatePtr driver = conn->interfacePrivateData; - - /* close netcf instance */ - ncf_close(driver->netcf); - /* destroy lock */ - virMutexDestroy(&driver->lock); - /* free driver state */ - VIR_FREE(driver); + virObjectUnref(conn->interfacePrivateData); + conn->interfacePrivateData = NULL; } - conn->interfacePrivateData = NULL; return 0; } @@ -1070,7 +1139,7 @@ static int netcfInterfaceChangeRollback(virConnectPtr conn, unsigned int flags) #endif /* HAVE_NETCF_TRANSACTIONS */ static virInterfaceDriver interfaceDriver = { - "netcf", + .name = INTERFACE_DRIVER_NAME, .interfaceOpen = netcfInterfaceOpen, /* 0.7.0 */ .interfaceClose = netcfInterfaceClose, /* 0.7.0 */ .connectNumOfInterfaces = netcfConnectNumOfInterfaces, /* 0.7.0 */ @@ -1093,11 +1162,19 @@ static virInterfaceDriver interfaceDriver = { #endif /* HAVE_NETCF_TRANSACTIONS */ }; +static virStateDriver interfaceStateDriver = { + .name = INTERFACE_DRIVER_NAME, + .stateInitialize = netcfStateInitialize, + .stateCleanup = netcfStateCleanup, + .stateReload = netcfStateReload, +}; + int netcfIfaceRegister(void) { if (virRegisterInterfaceDriver(&interfaceDriver) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("failed to register netcf interface driver")); return -1; } + virRegisterStateDriver(&interfaceStateDriver); return 0; } -- 1.7.11.7

4 5

[libvirt] Doc: How to use NPIV in libvirt
by Osier Yang 12 Sep '13

12 Sep '13

Before posting it to WIKI or somewhere, I want to see if there is any suggestions on it, or if I missed something. ============================================ How to use NPIV in libvirt I planned to wrote a document about how to use NPIV in libvirt after more features are supported, but it looks like I can't wait till then, got lots lots of questions from both the bugs and mails. So here we go. The document tries to summary up the things about NPIV that libvirt supports till now, and the TODO list. Feedback or suggestion is welcomed. 1) How to find out which HBA(s) support vHBA For libvirt newer than "1.0.4", you can find it out simply by: # virsh nodedev-list --cap vports "--cap vports" is to tell "nodedev-list" only outputs the devices which support "vports" capability, i.e. support vHBA. And also since version "1.0.4", you should be able to know the maximum vports the HBA supports and the current vports number from the HBA's XML, e.g. # virsh nodedev-dumpxml scsi_host5 <device> <name>scsi_host5</name> <parent>pci_0000_04_00_1</parent> <capability type='scsi_host'> <host>5</host> <capability type='fc_host'> <wwnn>2001001b32a9da4e</wwnn> <wwpn>2101001b32a9da4e</wwpn> <fabric_wwn>2001000dec9877c1</fabric_wwn> </capability> <capability type='vport_ops'> <max_vports>164</max_vports> <vports>5</vports> </capability> </capability> </device> For libvirt older than "1.0.4", it's a bit complicated than above: First you need to find out all the HBAs, e.g. # virsh nodedev-list --cap scsi_host scsi_host0 scsi_host1 scsi_host2 scsi_host3 scsi_host4 scsi_host5 And then, to see if the HBA supports vHBA, check if the dumped XML contains "vport_ops" capability. E.g. # virsh nodedev-dumpxml scsi_host3 <device> <name>scsi_host3</name> <parent>pci_0000_00_08_0</parent> <capability type='scsi_host'> <host>3</host> </capability> </device> That says "scsi_host3" doesn't support vHBA # virsh nodedev-dumpxml scsi_host5 <device> <name>scsi_host5</name> <parent>pci_0000_04_00_1</parent> <capability type='scsi_host'> <host>5</host> <capability type='fc_host'> <wwnn>2001001b32a9da4e</wwnn> <wwpn>2101001b32a9da4e</wwpn> <fabric_wwn>2001000dec9877c1</fabric_wwn> </capability> <capability type='vport_ops' /> </capability> </device> But "scsi_host5" supports it. One might be confused with the node device naming style (e.g. scsi_host5) in this document and RHEL6 Virtualization Guide [1] (pci_10df_fe00_scsi_host_0). It's because of libvirt has two backends for node device driver: udev and HAL. We prefer the udev backend more than HAL backend in internal implementation, I think there is good enough reason to do so (HAL is maintenance mode now). I believe udev backend is used more than HAL backend, but if your destribution packager build libvirt without udev backend, don't be surprised with the node device names like the ones in [1]. 2) How to create a vHBA Pick up one HBA which supports vHBA, use it's "node device name" as the "parent" of vHBA, and specify the "wwnn" and "wwpn" in the vHBA's XML. E.g. <device> <name>scsi_host6</name> <parent>scsi_host5</parent> <capability type='scsi_host'> <capability type='fc_host'> <wwnn>2001001b32a9da5e</wwnn> <wwpn>2101001b32a9da5e</wwpn> </capability> </capability> </device> Then create the vHBA with virsh command "nodedev-create" (assuming above XML file is named "vhba.xml"): # virsh nodedev-create vhba.xml Node device scsi_host6 created from vhba.xml Since "0.9.10", libvirt will generate "wwnn" and "wwpn" automatically if they are not specified. It means one can create the vHBA by a more simple XML like: <device> <parent>scsi_host5</parent> <capability type='scsi_host'> <capability type='fc_host'> </capability> </capability> </device> 3) How to destroy a vHBA As usual, destroying something is always simpler than creating it: # virsh nodedev-destroy scsi_host6 Destroyed node device 'scsi_host6' You might already realize that the vHBA is removed permanently, don't be surprised, it's the life, node device driver doesn't support persistent config. I won't say it's nightmare for users who screams when realizing the vHBA disappeared after a system rebooting, but it's relatively not good, (assuming that you got the wwnn:wwpn pair from the storage admin, but didn't record it). Fortunately, we support the persistent vHBA now, see next section for details. 4) How to create a persistent vHBA Let's go back to the history a bit firstly. Prior to libvirt "1.0.5", one can define a "scsi" type pool based on a (v)HBA by it's scsi host name (e.g. "host5" in XML below). E.g. <pool type='scsi'> <name>poolhba0</name> <uuid>e9392370-2917-565e-692b-d057f46512d6</uuid> <capacity unit='bytes'>0</capacity> <allocation unit='bytes'>0</allocation> <available unit='bytes'>0</available> <source> <adapter name='host0'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> Quite nice? yeah, at least it looks so, but the problem is the scsi host number is *unstable* (it can be changed after system rebooting, or kernel module reloading, or a vHBA recreating etc), and thus the "scsi" type pool based on a (v)HBA becomes unstable too. Obviously it doesn't help on the "persistent vHBA" problem. To solve the problems, since libvirt "1.0.5", we introduced new XML schema to indicate the (v)HBA. An example of the XML: <pool type='scsi'> <name>poolvhba0</name> <uuid>e9392370-2917-565e-692b-d057f46512d6</uuid> <source> <adapter type='fc_host' parent='scsi_host5' wwnn='20000000c9831b4b' wwpn='10000000c9831b4b'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> It allows to define a "scsi" type pool based on either a HBA or a vHBA. For HBA, "parent" attribute can be omitted. For vHBA, if "parent" is not specified, libvirt will pick up the first HBA which supports vHBA, and doesn't exceed the maximum vports it supports, automatically. For the pool based on a vHBA, When the pool is starting, libvirt will check if the specified vHBA (wwnn:wwpn) is existing on host or not, if it doesn't exist yet, libvirt will create it automatically. When the pool is being stopped, the vHBA is destroyed. But since storage driver supports the persistent config, one can easily gets the vHBA with same "wwnn:wwpn" in next starting (Don't scream if your pool is transient). It's not the end if you want to get the vHBA created automatically after system rebooting, you will need to set the pool as "autostart": # virsh pool-autostart poolvhba0 One might be curious about why not to support persistent config for node device driver, and support to create persistent vHBA there. One of the reason is that it will be duplicate with what storage pool does. And another reason (the important one) is we want to assiciate the libvirt storage pool/volume with domain (see section "Use LUN for guest" below). 5) How to find out the LUN's path If you have defined the "scsi" type pool based on the (v)HBA, it's simple to lookup what LUNs attached to the (v)HBA by virsh command "vol-list", e.g. # virsh vol-list poolvhba0 --details Name Path Type Capacity Allocation -------------------------------------------------------------------------------------------------------- unit:0:2:0 /dev/disk/by-path/pci-0000:04:00.1-fc-0x203500a0b85ad1d7-lun-0 block 20.01 GiB 20.01 GiB If you have not defined a "scsi" type pool based on the (v)HBA, you can find it out (v)HBA by either virsh command "nodedev-list --tree", or iterating sysfs manually. To find out the LUNs by virsh command "nodedev-list" (irrelevant ouputs are omitted): # virsh nodedev-list --tree +- pci_0000_00_0d_0 | | | +- pci_0000_04_00_0 | | | | | +- scsi_host4 | | | +- pci_0000_04_00_1 | | | +- scsi_host5 | | | +- scsi_host7 | +- scsi_target5_0_0 | | | | | +- scsi_5_0_0_0 | | | +- scsi_target5_0_1 | | | | | +- scsi_5_0_1_0 | | | +- scsi_target5_0_2 | | | | | +- scsi_5_0_2_0 | | | | | +- block_sdb_3600a0b80005adb0b0000ab2d4cae9254 | | | +- scsi_target5_0_3 | | | +- scsi_5_0_3_0 "scsi_host5" is an HBA on my host, it has a LUN named "block_sdb_3600a0b80005adb0b0000ab2d4cae9254", don't be confused with the naming, it's the naming style libvirt uses, meaningful only for libvirt. It indicates the LUN has a short device path "/dev/sdb", and a ID "3600a0b80005adb0b0000ab2d4cae9254": # ls /dev/disk/by-id/ | grep 3600a0b80005adb0b0000ab2d4cae9254 scsi-3600a0b80005adb0b0000ab2d4cae9254 To manually find the LUNs of a (v)HBA: First, you need to iterate over all the directores begins with the SCSI scsi host number of the v(HBA) under "/sys/bus/scsi/devices". E.g. I will look up the LUNs of the HBA with SCSI host number 5 on my host: # ls /sys/bus/scsi/devices/5:* -d /sys/bus/scsi/devices/5:0:0:0 /sys/bus/scsi/devices/5:0:1:0 /sys/bus/scsi/devices/5:0:2:0 /sys/bus/scsi/devices/5:0:3:0 # ls /sys/bus/scsi/devices/5\:0\:3\:0/block/sdc It means scsi_host5 has a LUN attached with device name "sdc" on address "5:0:3:0". # ls /sys/bus/scsi/devices/5\:0\:1\:0/ | grep block device_blocked scsi_host5 doesn't have a LUN attached on address "5:0:2:0" The device name like "sdc" is not stable, to find out the stable path, find out the symbol link which points to the device name. E.g. # ls -l /dev/disk/by-path/ lrwxrwxrwx. 1 root root 9 Sep 10 22:28 pci-0000:00:07.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx. 1 root root 10 Sep 10 22:28 pci-0000:00:07.0-scsi-0:0:0:0-part1 -> ../../sda1 lrwxrwxrwx. 1 root root 9 Sep 10 22:28 pci-0000:04:00.1-fc-0x203400a0b85ad1d7-lun-0 -> ../../sdc Then "/dev/disk/by-path/pci-0000:04:00.1-fc-0x203400a0b85ad1d7-lun-0" is the stable path of the LUN attached to address "5:0:3:0". Of course, you can use the similiar method to get the "by-id | by-uuid | by-label" stable path. 6) Use the LUN to guest Since libvirt "1.0.5", we supported to use the storage volume as disk source by two new attributes ("pool" and "volume") for disk "<source"> element. E.g. <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='poolvhba0' volume='unit:0:2:0 '/> <target dev='hda' bus='ide'/> </disk> There are lots of advantage to do so. Since the mainly purpose of the document is about "how to use", I will only mention two here to persuade you using the it. First, you don't need to look up the LUN's path youself. Second, assuming that you want to migrate a domain which uses a LUN attached to a vHBA, do you want to create the vHBA manually on target host? With the pool, you can simply define/start a pool with same config on target host. So, if your libvirt is newer than "1.0.5", we recommend you to define the "scsi" type pool based on the (v)HBA, and use "pool/volume" names to use the LUN as disk source. You can either use the LUN as qemu emulated disk, or passthrough it to guest. To use it as qemu emulated disk, specifying the "device" attribute as "device='disk|cdrom|floppy'". E.g. <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='blk-pool0' volume='blk-pool0-vol0'/> <target dev='hda' bus='ide'/> </disk> Or (using the LUN's path directly) <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-path/pci-0000\:04\:00.1-fc-0x203400a0b85ad1d7-lun-0'/> <target dev='sda' bus='scsi'/> </disk> To passthrough the LUN, specifying the "device" attribute as "device='lun'", e.g. <disk type='volume' device='lun'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-path/pci-0000\:04\:00.1-fc-0x203400a0b85ad1d7-lun-0'/> <target dev='sda' bus='scsi'/> </disk> 6) Future work * NPIV based SCSI host passthrough That's what the users ask: How to passthrough a (v)HBA to guest? * Expose vendor information, LUN's path, state of (v)HBA in its XML * May be a virsh command to simplify vHBA creation with options [1] http://www.linuxtopia.org/online_books/rhel6/rhel_6_virtualization/rhel_6_v… Regards, Osier

2 1

[libvirt] [v0.9.12-maint v2 00/12] Debian's 0.9.12 patches
by Guido Günther 12 Sep '13

12 Sep '13

These are the patches Debian is currently carrying on 0.9.12. Most are straight cherry-picks. Since we're maintaining 0.9.12 for our current stable release I'm happy to push these to v0.9.12-maint. Daniel P. Berrange (2): Don't ignore return value of qemuProcessKill Fix race condition when destroying guests Eric Blake (1): build: fix virnetlink on glibc 2.11 Jiri Denemark (3): daemon: Fix crash in virTypedParameterArrayClear Revert "rpc: Discard non-blocking calls only when necessary" qemu: Add support for -no-user-config Luca Tettamanti (1): Make sure regfree is called close to it's usage Martin Kletzander (1): security: Fix libvirtd crash possibility Peter Krempa (4): qemu: Fix off-by-one error while unescaping monitor strings rpc: Fix crash on error paths of message dispatching conf: Remove callback from stream when freeing entries in console hash conf: Remove console stream callback only when freeing console helper cfg.mk | 3 +- daemon/remote.c | 16 +- src/conf/virconsole.c | 13 ++ src/qemu/qemu_capabilities.c | 7 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 11 +- src/qemu/qemu_driver.c | 21 ++- src/qemu/qemu_monitor.c | 11 +- src/rpc/virnetclient.c | 21 +-- src/rpc/virnetserverclient.c | 3 + src/rpc/virnetserverprogram.c | 11 +- src/storage/storage_backend_logical.c | 5 +- src/util/virnetlink.h | 2 + tests/qemuhelpdata/qemu-1.1 | 268 ++++++++++++++++++++++++++++++++++ tests/qemuhelpdata/qemu-1.1-device | 160 ++++++++++++++++++++ tests/qemuhelptest.c | 75 ++++++++++ 16 files changed, 586 insertions(+), 42 deletions(-) create mode 100644 tests/qemuhelpdata/qemu-1.1 create mode 100644 tests/qemuhelpdata/qemu-1.1-device -- 1.8.4.rc3

3 14

[libvirt] [PATCH] LXC: don't try to mount selinux filesystem when user namespace enabled
by Gao feng 12 Sep '13

12 Sep '13

Right now we mount selinuxfs even user namespace is enabled and ignore the error. But we shouldn't ignore these errors when user namespace is not enabled. This patch skips mounting selinuxfs when user namespace enabled. Signed-off-by: Gao feng <gaofeng(a)cn.fujitsu.com> --- src/lxc/lxc_container.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 661ac52..84b1b57 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -797,7 +797,7 @@ static int lxcContainerMountBasicFS(bool userns_enabled) #if WITH_SELINUX if (STREQ(mnts[i].src, SELINUX_MOUNT) && - !is_selinux_enabled()) + (!is_selinux_enabled() || userns_enabled)) continue; #endif @@ -814,12 +814,6 @@ static int lxcContainerMountBasicFS(bool userns_enabled) VIR_DEBUG("Mount %s on %s type=%s flags=%x, opts=%s", srcpath, mnts[i].dst, mnts[i].type, mnts[i].mflags, mnts[i].opts); if (mount(srcpath, mnts[i].dst, mnts[i].type, mnts[i].mflags, mnts[i].opts) < 0) { -#if WITH_SELINUX - if (STREQ(mnts[i].src, SELINUX_MOUNT) && - (errno == EINVAL || errno == EPERM)) - continue; -#endif - virReportSystemError(errno, _("Failed to mount %s on %s type %s flags=%x opts=%s"), srcpath, mnts[i].dst, NULLSTR(mnts[i].type), -- 1.8.3.1

2 1

[libvirt] [PATCH] qemu: Fix checking of guest ABI compatibility when reverting snapshots
by Peter Krempa 12 Sep '13

12 Sep '13

When reverting a live internal snapshot with a live guest the ABI compatiblity check was comparing a "migratable" definition with a normal one. This resulted in the check failing with: revert requires force: Target device address type none does not match source pci This patch generates a "migratable" definition from the actual one to check against the definition from the snapshot to avoid this problem. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1006886 --- src/qemu/qemu_driver.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index bbf2d23..ae1948f 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13037,6 +13037,7 @@ static int qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, qemuDomainObjPrivatePtr priv; int rc; virDomainDefPtr config = NULL; + virDomainDefPtr migratableDef = NULL; virQEMUDriverConfigPtr cfg = NULL; virCapsPtr caps = NULL; @@ -13151,8 +13152,13 @@ static int qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, * to have finer control. */ if (virDomainObjIsActive(vm)) { /* Transitions 5, 6, 8, 9 */ - /* Check for ABI compatibility. */ - if (config && !virDomainDefCheckABIStability(vm->def, config)) { + /* Check for ABI compatibility. We need to do this check against + * the migratable XML or it will always fail otherwise */ + if (!(migratableDef = qemuDomainDefCopy(driver, vm->def, + VIR_DOMAIN_XML_MIGRATABLE))) + goto cleanup; + + if (config && !virDomainDefCheckABIStability(migratableDef, config)) { virErrorPtr err = virGetLastError(); if (!(flags & VIR_DOMAIN_SNAPSHOT_REVERT_FORCE)) { @@ -13357,6 +13363,7 @@ cleanup: } if (vm) virObjectUnlock(vm); + virDomainDefFree(migratableDef); virObjectUnref(caps); virObjectUnref(cfg); -- 1.8.3.2

2 2

[libvirt] USB: about the auto identify funciton for guest OS
by Gonglei (Arei) 12 Sep '13

12 Sep '13

Hi, all Qemu upstream had achieved USB Auto Connect function for the guest. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provide such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -Gonglei

1 0

[libvirt] [PATCHv6 0/5] Introduce API to query IP addresses for given domain
by Nehal J Wani 12 Sep '13

12 Sep '13

This feature has been requested for a very long time. Since qemu guest agent gives us reliable results, now the wait is over. The RFC was first proposed by Michal Privoznik: http://www.redhat.com/archives/libvir-list/2012-February/msg00437.html A patch was submitted, using structs: https://www.redhat.com/archives/libvir-list/2012-June/msg00220.html Another patch was submitted, using XML: https://www.redhat.com/archives/libvir-list/2012-June/msg00904.html Neither of the patches were accepted, probably due to lack of extensibility and usability. Hence, we thought of using virTypedParameters for reporting list of interfaces along with their MAC address and IP addresses. The RFC can be found here: https://www.redhat.com/archives/libvir-list/2013-July/msg00084.html The idea of extensibility was rejected and rendered out of scope of libvirt. Hence, we were back to structs. This API is called virDomainInterfaceAddresses which returns a dynamically allocated array of virDomainInterface struct. The great disadvantage is once this gets released, it's written in stone and we cannot change or add an item into it. The API supports two methods: * Return information (list of all associated interfaces with MAC address and IP addresses) of all of the domain interfaces by default (if no interface name is provided) * Return information for the specified interface (if an interface name is provided) v6: * Inclusion of flags, readonly check for guest agent connection * Correction of memory leaks, other small nits. v5: * s/virDomainInterfacesAddresses/virDomainInterfaceAddresses. * Case for IP aliasing handled using virHashTable. * New test cases added, involving multiple and 0 IP addresse(s) per interface. * IP prefix changed from int to unsigned int. * Changes to practice libvirt habits. * https://www.redhat.com/archives/libvir-list/2013-September/msg00003.html v4: * Various style nits, indentation errors, memory leaks fixed. * https://www.redhat.com/archives/libvir-list/2013-August/msg01265.html v3: * Upper bounds to number of interfaces and addresses per interface introduced. * Change from array of structs to array of pointers * ifaces_count moved from function argument to return value * Changes in variable names * Test cases added for qemuAgentGetInterfaces. * https://www.redhat.com/archives/libvir-list/2013-August/msg01215.html v2: * Logical errors, memory leaks and few other errors fixed. * https://www.redhat.com/archives/libvir-list/2013-August/msg00631.html v1: * http://www.redhat.com/archives/libvir-list/2013-July/msg01553.html Nehal J Wani (5): domifaddr: Implement the public APIs domifaddr: Implement the remote protocol domifaddr: Implement the API for qemu domifaddr: Add virsh support domifaddr: Expose python binding daemon/remote.c | 130 ++++++++++++++++++++++++++ examples/python/Makefile.am | 2 +- examples/python/README | 1 + examples/python/domipaddrs.py | 56 +++++++++++ include/libvirt/libvirt.h.in | 38 ++++++++ python/generator.py | 3 + python/libvirt-override-api.xml | 8 +- python/libvirt-override.c | 102 ++++++++++++++++++++ src/driver.h | 6 ++ src/libvirt.c | 135 +++++++++++++++++++++++++++ src/libvirt_public.syms | 6 ++ src/qemu/qemu_agent.c | 201 ++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_agent.h | 3 + src/qemu/qemu_driver.c | 76 +++++++++++++++ src/remote/remote_driver.c | 99 ++++++++++++++++++++ src/remote/remote_protocol.x | 40 +++++++- src/remote_protocol-structs | 24 +++++ tests/qemuagenttest.c | 188 +++++++++++++++++++++++++++++++++++++ tools/virsh-domain-monitor.c | 131 ++++++++++++++++++++++++++ tools/virsh.pod | 18 ++++ 20 files changed, 1264 insertions(+), 3 deletions(-) create mode 100755 examples/python/domipaddrs.py -- 1.7.11.7

3 11

[libvirt] [v0.9.12-maint 08/11] Make sure regree is called close to it's usage
by Luca Tettamanti 12 Sep '13

12 Sep '13

This is a backport of 71da3b66a8455faf8019effe3cf504a31f91f54a. --- src/storage/storage_backend_logical.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index 9a91dd9..7abb17b 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -204,13 +204,16 @@ virStorageBackendLogicalMakeVol(virStoragePoolObjPtr pool, if (err != 0) { char error[100]; regerror(err, reg, error, sizeof(error)); + regfree(reg); virStorageReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to compile regex %s"), error); goto cleanup; } - if (regexec(reg, groups[3], nvars, vars, 0) != 0) { + err = regexec(reg, groups[3], nvars, vars, 0); + regfree(reg); + if (err != 0) { virStorageReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("malformed volume extent devices value")); goto cleanup; -- 1.8.4.rc3

2 3