August 2014 - Devel - libvirt List Archives

[libvirt] [PATCH v5 0/3] OVMF exposure
by Michal Privoznik 22 Aug '14

22 Aug '14

Diff to v4: -rebased onto current master -introduced nvram/@template as requested by Dan -yet another Laszlo's review worked in Michal Privoznik (3): conf: Extend <loader/> and introduce <nvram/> qemu: Implement extended loader and nvram qemu: Automatically create NVRAM store docs/formatdomain.html.in | 22 +++- docs/schemas/domaincommon.rng | 28 +++++ libvirt.spec.in | 2 + src/Makefile.am | 1 + src/conf/domain_conf.c | 96 ++++++++++++++- src/conf/domain_conf.h | 23 +++- src/libvirt_private.syms | 3 + src/qemu/libvirtd_qemu.aug | 3 + src/qemu/qemu.conf | 14 +++ src/qemu/qemu_command.c | 97 ++++++++++++++- src/qemu/qemu_conf.c | 94 ++++++++++++++ src/qemu/qemu_conf.h | 5 + src/qemu/qemu_process.c | 137 +++++++++++++++++++++ src/qemu/test_libvirtd_qemu.aug.in | 3 + src/security/security_dac.c | 8 ++ src/security/security_selinux.c | 8 ++ src/security/virt-aa-helper.c | 4 +- src/vbox/vbox_common.c | 7 +- src/xenapi/xenapi_driver.c | 3 +- src/xenconfig/xen_common.c | 7 +- src/xenconfig/xen_sxpr.c | 16 +-- tests/domainschemadata/domain-bios-nvram-empty.xml | 40 ++++++ .../qemuxml2argvdata/qemuxml2argv-bios-nvram.args | 10 ++ tests/qemuxml2argvdata/qemuxml2argv-bios-nvram.xml | 40 ++++++ tests/qemuxml2argvtest.c | 2 + .../qemuxml2xmlout-pci-bridge-many-disks.xml | 2 +- tests/qemuxml2xmltest.c | 2 + tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-legacy-vfb.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml | 2 +- .../sexpr2xml-fv-serial-dev-2-ports.xml | 2 +- .../sexpr2xml-fv-serial-dev-2nd-port.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml | 2 +- .../sexpr2xml-fv-serial-tcp-telnet.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-sound-all.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-sound.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-utc.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-v2.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-no-source-cdrom.xml | 2 +- tests/xmconfigdata/test-escape-paths.xml | 2 +- tests/xmconfigdata/test-fullvirt-force-hpet.xml | 2 +- tests/xmconfigdata/test-fullvirt-force-nohpet.xml | 2 +- tests/xmconfigdata/test-fullvirt-localtime.xml | 2 +- tests/xmconfigdata/test-fullvirt-net-ioemu.xml | 2 +- tests/xmconfigdata/test-fullvirt-net-netfront.xml | 2 +- tests/xmconfigdata/test-fullvirt-new-cdrom.xml | 2 +- tests/xmconfigdata/test-fullvirt-old-cdrom.xml | 2 +- tests/xmconfigdata/test-fullvirt-parallel-tcp.xml | 2 +- .../test-fullvirt-serial-dev-2-ports.xml | 2 +- .../test-fullvirt-serial-dev-2nd-port.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-file.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-null.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-pipe.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-pty.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-stdio.xml | 2 +- .../test-fullvirt-serial-tcp-telnet.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-tcp.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-udp.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-unix.xml | 2 +- tests/xmconfigdata/test-fullvirt-sound.xml | 2 +- tests/xmconfigdata/test-fullvirt-usbmouse.xml | 2 +- tests/xmconfigdata/test-fullvirt-usbtablet.xml | 2 +- tests/xmconfigdata/test-fullvirt-utc.xml | 2 +- tests/xmconfigdata/test-no-source-cdrom.xml | 2 +- tests/xmconfigdata/test-pci-devs.xml | 2 +- 82 files changed, 705 insertions(+), 82 deletions(-) create mode 100644 tests/domainschemadata/domain-bios-nvram-empty.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-bios-nvram.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-bios-nvram.xml -- 1.8.5.5

2 6

[libvirt] [PATCH] virsh: Fix help info for freepages
by Li Yang 22 Aug '14

22 Aug '14

Signed-off-by: Li Yang <liyang.fnst(a)cn.fujitsu.com> --- tools/virsh-host.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/virsh-host.c b/tools/virsh-host.c index ae14311..ad821b3 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -263,10 +263,10 @@ cmdFreecell(vshControl *ctl, const vshCmd *cmd) */ static const vshCmdInfo info_freepages[] = { {.name = "help", - .data = N_("NUMA free memory") + .data = N_("NUMA free pages") }, {.name = "desc", - .data = N_("display available free memory for the NUMA cell.") + .data = N_("display available free pages for the NUMA cell.") }, {.name = NULL} }; -- 1.7.1

2 1

[libvirt] [PATCH] util: compare floor attribute in virNetDevBandwidthEqual
by Martin Kletzander 22 Aug '14

22 Aug '14

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1064770 Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/util/virnetdevbandwidth.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/util/virnetdevbandwidth.c b/src/util/virnetdevbandwidth.c index 1e00116..5fa231a 100644 --- a/src/util/virnetdevbandwidth.c +++ b/src/util/virnetdevbandwidth.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2013 Red Hat, Inc. + * Copyright (C) 2009-2014 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 @@ -342,6 +342,7 @@ virNetDevBandwidthEqual(virNetDevBandwidthPtr a, if (a->in->average != b->in->average || a->in->peak != b->in->peak || + a->in->floor != b->in->floor || a->in->burst != b->in->burst) return false; } else if (b->in) { @@ -355,6 +356,7 @@ virNetDevBandwidthEqual(virNetDevBandwidthPtr a, if (a->out->average != b->out->average || a->out->peak != b->out->peak || + a->out->floor != b->out->floor || a->out->burst != b->out->burst) return false; } else if (b->out) { -- 2.0.4

2 1

[libvirt] [PATCH] build: fix mingw build with virCommandReorderFDs
by Martin Kletzander 22 Aug '14

22 Aug '14

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Notes: pushed as a build-breaker src/util/vircommand.c | 4 ++-- src/util/virutil.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/util/vircommand.c b/src/util/vircommand.c index 3b3e6f5..1d6dbd9 100644 --- a/src/util/vircommand.c +++ b/src/util/vircommand.c @@ -201,6 +201,8 @@ virCommandFDSet(virCommandPtr cmd, return 0; } +#ifndef WIN32 + static void virCommandReorderFDs(virCommandPtr cmd) { @@ -273,8 +275,6 @@ virCommandReorderFDs(virCommandPtr cmd) return; } -#ifndef WIN32 - /** * virFork: * diff --git a/src/util/virutil.c b/src/util/virutil.c index 1d897d9..2edbec5 100644 --- a/src/util/virutil.c +++ b/src/util/virutil.c @@ -2397,6 +2397,8 @@ void virUpdateSelfLastChanged(const char *path) } } +#ifndef WIN32 + /** * virGetListenFDs: * @@ -2458,3 +2460,13 @@ virGetListenFDs(void) return nfds; } + +#else /* WIN32 */ + +unsigned int +virGetListenFDs(void) +{ + return 0; +} + +#endif /* WIN32 */ -- 2.0.4

1 0

[libvirt] RFC: sVirt disk isolation with network based storage
by Daniel P. Berrange 22 Aug '14

22 Aug '14

As everyone knows sVirt is our nice solution to isolating guest resources from other (malicious) guests through SELinux labelling of the appropriate files / device nodes. This has been pretty effective since we introduced it to libvirt. In the last year or two, particularly in the cloud arena, there has been a big shift towards use of network based storage. Initially we were relying on kernel drivers / FUSE layers that exposed this network storage as devices or nodes in the host filesystem, so sVirt still stood a chance of being useful if the devices /FUSE layer supported labelling. Now though QEMU has native support for talking to gluster, ceph/rbd, iscsi and even nfs servers. This support is increasingly used in preference to using the kernel drivers / FUSE layers since it provides a simpler and thus (in theory) better performing I/O path for the network storage and does not require any privileged setup tasks on the host ahead of time. The problem is that I beleive this is blowing a decent sized hole in our sVirt isolation story. eg when we launch QEMU with an argument like this: -drive 'file=rbd:pool/image:auth_supported=none:\ mon_host=mon1.example.org\:6321\;mon2.example.org\:6322\;\ mon3.example.org\:6322,if=virtio,format=raw' We are trusting QEMU to only ever access the disk volume 'pool/image'. There are, in all likelihood, many 100's or 1000's of disk images on the server it is connecting to and nothing is stopping QEMU from accessing any of them AFAICT. There is no currrently implemented mechanism by which the sVirt label that QEMU runs under is made available to the remote RBD server to use for enforcement, nor any way in which libvirt could tell the RBD server which label was applied for which disk. The same seems to apply for Gluster, iSCSI, and NFS too when accessed directly from a network client inside the QEMU process. As it stands the only approach I see for isolating each virtual machines disk(s) from other virtual machines is to make use of user authentication with these services. eg each virtual machine would need to have its own dedicated user account on the RBD/Gluster/iSCSI/NFS server, and the disk volumes for the VM would have to be made accessible solely to that user account. Assuming such user account / disk mapping exists in the servers today that can be made to work but it is an incredibly awful solution to deal with when VMs are being dynamically created & deleted very frequently. Today apps like OpenStack just have a single RBD username and password for everything they do. Any virtual machines running with RBD storage on OpenStack thus have no sVirt protection for their disk images AFAICT. To protect images OpenStack would have to dynamically create & delete new user accounts on the RBD server & setup disk access for them. I don't see that kind of approach being viable. IIUC, there is some mechanism at the IP stack level where the kernel can take the SELinux label of the process that establishes the network connection and pass it across to the server. If there was a way in the RBD API for libvirt to label the volumes, then potentially we could have a system where the RBD server did sVirt enforcement, based on the instructions from libvirt & the label of the client process. Thoughts on what to do about this ? Network based storage, where the network client is inside each QEMU server, is here to stay so I don't think we can ignore the problem long term. 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 :|

3 4

Re: [libvirt] pvspinlock not accepted by libvirt
by bancfc＠openmailbox.org 21 Aug '14

21 Aug '14

I'm using libvirt version 1.1.3.5 at the moment. I am sure I followed the right syntax as I put it under the features section: <features> ... <pvspinlock/> </features> It says: error internal error: unexpected feature pvspinlock Failed. try again?

2 1

[libvirt] pvspinlock not accepted by libvirt
by bancfc＠openmailbox.org 21 Aug '14

21 Aug '14

Hello, I have been experimenting with the various options to squeeze out the last bit of performance gains so I added the <pvspinlock/> feature to my machines. However when saving the xml, libvirt complains and refuses to accept this tag. AFAIK this is a feature that can be used by KVM too. My guests are Linux of course. So what am I doing wrong here?

2 1

[libvirt] [PATCH] formatdomain: Reformat vCPU description
by John Ferlan 21 Aug '14

21 Aug '14

Reformat the vCPU description to use list elements rather than one long run-on paragraphc Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- While working on some changes I was trying to read this section and suffice to say my eyes hurt. I didn't push as trivial just in case someone had a desire to "change" the words to describe things more clearly. For the most part the changes are just a reformat, although there were a few extra "the"'s added and replacement of a couple of semi-colons with periods. docs/formatdomain.html.in | 75 +++++++++++++++++++++++++++-------------------- 1 file changed, 44 insertions(+), 31 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ed17389..6d0ef8e 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -419,37 +419,50 @@ <dt><code>vcpu</code></dt> <dd>The content of this element defines the maximum number of virtual CPUs allocated for the guest OS, which must be between 1 and - the maximum supported by the hypervisor. Since - 0.4.4, this element can contain an optional - <code>cpuset</code> attribute, which is a comma-separated - list of physical CPU numbers that domain process and virtual CPUs - can be pinned to by default. (NB: The pinning policy of domain - process and virtual CPUs can be specified separately by - <code>cputune</code>. If attribute <code>emulatorpin</code> - of <code>cputune</code> is specified, <code>cpuset</code> - specified by <code>vcpu</code> here will be ignored; Similarly, - For virtual CPUs which has <code>vcpupin</code> specified, - <code>cpuset</code> specified by <code>cpuset</code> here - will be ignored; For virtual CPUs which doesn't have - <code>vcpupin</code> specified, it will be pinned to the physical - CPUs specified by <code>cpuset</code> here). - Each element in that list is either a single CPU number, - a range of CPU numbers, or a caret followed by a CPU number to - be excluded from a previous range. Since - 0.8.5, the optional attribute <code>current</code> can - be used to specify whether fewer than the maximum number of - virtual CPUs should be enabled. Since - 0.9.11 (QEMU and KVM only), the optional attribute - <code>placement</code> can be used to indicate the CPU placement - mode for domain process, its value can be either "static" or - "auto", defaults to <code>placement</code> of <code>numatune</code>, - or "static" if <code>cpuset</code> is specified. "auto" indicates - the domain process will be pinned to the advisory nodeset from querying - numad, and the value of attribute <code>cpuset</code> will be ignored - if it's specified. If both <code>cpuset</code> and <code>placement</code> - are not specified, or if <code>placement</code> is "static", but no - <code>cpuset</code> is specified, the domain process will be pinned to - all the available physical CPUs. + the maximum supported by the hypervisor. + <dl> + <dt><code>cpuset</code></dt> + <dd> + The optional attribute <code>cpuset</code> is a comma-separated + list of physical CPU numbers that domain process and virtual CPUs + can be pinned to by default. (NB: The pinning policy of domain + process and virtual CPUs can be specified separately by + <code>cputune</code>. If the attribute <code>emulatorpin</code> + of <code>cputune</code> is specified, the <code>cpuset</code> + specified by <code>vcpu</code> here will be ignored. Similarly, + for virtual CPUs which have the <code>vcpupin</code> specified, + the <code>cpuset</code> specified by <code>cpuset</code> here + will be ignored. For virtual CPUs which don't have + <code>vcpupin</code> specified, each will be pinned to the physical + CPUs specified by <code>cpuset</code> here). + Each element in that list is either a single CPU number, + a range of CPU numbers, or a caret followed by a CPU number to + be excluded from a previous range. + Since 0.4.4 + </dd> + <dt><code>current</code></dt> + <dd> + The optional attribute <code>current</code> can + be used to specify whether fewer than the maximum number of + virtual CPUs should be enabled. + Since 0.8.5 + </dd> + <dt><code>placement</code></dt> + <dd> + The optional attribute <code>placement</code> can be used to + indicate the CPU placement mode for domain process. The value can + be either "static" or "auto", but defaults to <code>placement</code> + of <code>numatune</code> or "static" if <code>cpuset</code> is + specified. Using "auto" indicates the domain process will be pinned + to the advisory nodeset from querying numad and the value of + attribute <code>cpuset</code> will be ignored if it's specified. + If both <code>cpuset</code> and <code>placement</code> are not + specified or if <code>placement</code> is "static", but no + <code>cpuset</code> is specified, the domain process will be + pinned to all the available physical CPUs. + Since 0.9.11 (QEMU and KVM only) + </dd> + </dl> </dd> </dl> -- 1.9.3

2 1

[libvirt] [PATCH v4 0/9] Series on passing FDs to daemon
by Martin Kletzander 21 Aug '14

21 Aug '14

v3 is here: https://www.redhat.com/archives/libvir-list/2014-July/msg01185.html the bug I'm still trying to fix is here: https://bugzilla.redhat.com/show_bug.cgi?id=927369 Martin Kletzander (9): util: abstract parsing of passed FDs into virGetListenFDs() remote: create virNetServerServiceNewFDOrUNIX() wrapper rpc: set listen backlog on FDs as well as on other sockets daemon: support passing FDs from the calling process cfg.mk: allow integers to be assigned a value computed with i|j|k tests: support dynamic prefixes in commandtest util: add virCommandPassListenFDs() function rpc: pass listen FD to the daemon being started daemon: use socket activation with systemd .gitignore | 1 + cfg.mk | 2 +- daemon/Makefile.am | 14 +++++- daemon/libvirtd.c | 45 ++++++++++-------- daemon/libvirtd.conf | 5 ++ daemon/libvirtd.service.in | 5 -- daemon/libvirtd.socket.in | 11 +++++ libvirt.spec.in | 25 ++++++++-- src/libvirt_private.syms | 2 + src/libvirt_remote.syms | 1 + src/locking/lock_daemon.c | 47 ++----------------- src/rpc/virnetserverservice.c | 55 +++++++++++++++++++++- src/rpc/virnetserverservice.h | 15 +++++- src/rpc/virnetsocket.c | 85 ++++++++++++++++++++++++++-------- src/util/vircommand.c | 99 +++++++++++++++++++++++++++++++++++++++ src/util/vircommand.h | 4 +- src/util/virutil.c | 62 +++++++++++++++++++++++++ src/util/virutil.h | 2 + tests/commanddata/test24.log | 7 +++ tests/commandtest.c | 105 ++++++++++++++++++++++++++++++++++-------- 20 files changed, 478 insertions(+), 114 deletions(-) create mode 100644 daemon/libvirtd.socket.in create mode 100644 tests/commanddata/test24.log -- 2.0.4

2 19

[libvirt] [PATCHv2] numatune: setting --mode does not work well
by Erik Skultety 21 Aug '14

21 Aug '14

When trying to set numatune mode directly using virsh numatune command, correct error is raised, however numatune structure was not deallocated, thus resulting in creating an empty numatune element in the guest XML, if none was present before. Running the same command aftewards results in a successful change with broken XML structure. Patch fixes the deallocation problem as well as checking for invalid attribute combination VIR_DOMAIN_NUMATUNE_PLACEMENT_AUTO + a nonempty nodeset. Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1129998 --- src/conf/numatune_conf.c | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/src/conf/numatune_conf.c b/src/conf/numatune_conf.c index 48d1d04..3bfac56 100644 --- a/src/conf/numatune_conf.c +++ b/src/conf/numatune_conf.c @@ -439,7 +439,7 @@ virDomainNumatuneSet(virDomainNumatunePtr *numatunePtr, { bool create = !*numatunePtr; /* Whether we are creating new struct */ int ret = -1; - virDomainNumatunePtr numatune = NULL; + virDomainNumatunePtr numatune = *numatunePtr; /* No need to do anything in this case */ if (mode == -1 && placement == -1 && !nodeset) @@ -461,9 +461,15 @@ virDomainNumatuneSet(virDomainNumatunePtr *numatunePtr, goto cleanup; } - if (create && VIR_ALLOC(*numatunePtr) < 0) + if (placement_static && !nodeset) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("nodeset for NUMA memory tuning must be set " + "if 'placement' is 'static'")); + goto cleanup; + } + + if (create && VIR_ALLOC(numatune) < 0) goto cleanup; - numatune = *numatunePtr; if (create) { /* Defaults for new struct */ @@ -492,12 +498,11 @@ virDomainNumatuneSet(virDomainNumatunePtr *numatunePtr, placement = VIR_DOMAIN_NUMATUNE_PLACEMENT_AUTO; } - if (placement == VIR_DOMAIN_NUMATUNE_PLACEMENT_STATIC && - !numatune->memory.nodeset) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("nodeset for NUMA memory tuning must be set " - "if 'placement' is 'static'")); - goto cleanup; + /* setting nodeset when placement auto is invalid */ + if (placement == VIR_DOMAIN_NUMATUNE_PLACEMENT_AUTO && + numatune->memory.nodeset) { + virBitmapFree(numatune->memory.nodeset); + numatune->memory.nodeset = NULL; } if (placement != -1) @@ -505,8 +510,17 @@ virDomainNumatuneSet(virDomainNumatunePtr *numatunePtr, numatune->memory.specified = true; + if (create) { + *numatunePtr = numatune; + numatune = NULL; + } + ret = 0; + return ret; + cleanup: + if (create) + virDomainNumatuneFree(numatune); return ret; } -- 1.9.3

2 1