- Devel - libvirt List Archives

[libvirt] [PATCH] util: make use of VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE in virLockSpaceAcquireResource
by Shanzhi Yu 12 Feb '15

12 Feb '15

When create external disk snapshot with virtlock enabled, libvirtd will hang if flag VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE is missed in virLockSpaceAcquireResource. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1191901 Signed-off-by: Shanzhi Yu <shyu(a)redhat.com> --- src/util/virlockspace.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/util/virlockspace.c b/src/util/virlockspace.c index 2366a74..25b4433 100644 --- a/src/util/virlockspace.c +++ b/src/util/virlockspace.c @@ -626,8 +626,10 @@ int virLockSpaceAcquireResource(virLockSpacePtr lockspace, virMutexLock(&lockspace->lock); if ((res = virHashLookup(lockspace->resources, resname))) { - if ((res->flags & VIR_LOCK_SPACE_ACQUIRE_SHARED) && - (flags & VIR_LOCK_SPACE_ACQUIRE_SHARED)) { + if (((res->flags & VIR_LOCK_SPACE_ACQUIRE_SHARED) && + (flags & VIR_LOCK_SPACE_ACQUIRE_SHARED)) || + ((res->flags & VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE) && + (flags & VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE))){ if (VIR_EXPAND_N(res->owners, res->nOwners, 1) < 0) goto cleanup; -- 1.8.3.1

2 2

[libvirt] [PATCH 0/4] Introduce display of IOThreads Information
by John Ferlan 12 Feb '15

12 Feb '15

These patches satisfy part of: https://bugzilla.redhat.com/show_bug.cgi?id=1135491 Patches 1 and 2 are fairly straightforward adding a new API type patches although they were implemented with the thought of how patch 3 works. Also rather than implement a get iothreads and a get iothreadspin API, I combined the two into one. I could separate if that's more desirable, but it just seemed more natural to have one API do both. Patch 3 adds the qemu related to code to fetch not only the IOThreads data, but also the cpumap/cpumaplen in order to display the CPU Affinity. For that I somewhat followed how the vcpuinfo code works, but also a bit on how the nodecpumap code does things. Unlike the vcpuinfo code, I had no way to count the IOThreads before calling, so rather than pass in a cpumap/cpumaplen - I allocated them in the qemu code and passed them back within the IOThreadsInfo structure. Of course it did get me to thinking why are we doing 1 for each IOThread, but to that degree I was following the vcpu model. Patch 4 is the new 'virsh iothreads' command with no arguments (for now). It will display the IOThreads of active domains only. "Future" patches will implement a SetIOThreads API to change the thread pinning and allow for add/delete of IOThreads. I'm hoping to use the same command with new options --pin && --cpuset for pinning the IOThreads or --add/--del to add/remove IOThreads, but I wanted to make sure I had buyin on the use of one API to accomplish both get of basic IOThread data and CPU Affinity data. John Ferlan (4): Implement public API for virDomainGetIOThreadsInfo remote: Implement the remote plumbing for virDomainGetIOThreads qemu: Implement the qemu driver fetch for IOThreads virsh: Add 'iothreads' command daemon/remote.c | 75 +++++++++++++++++++++++++- include/libvirt/libvirt-domain.h | 22 +++++++- src/driver-hypervisor.h | 8 ++- src/libvirt-domain.c | 63 +++++++++++++++++++++- src/libvirt_public.syms | 6 +++ src/qemu/qemu_driver.c | 114 +++++++++++++++++++++++++++++++++++++++ src/remote/remote_driver.c | 82 +++++++++++++++++++++++++++- src/remote/remote_protocol.x | 29 +++++++++- src/remote_protocol-structs | 20 +++++++ src/rpc/gendispatch.pl | 1 + tools/virsh-domain.c | 72 +++++++++++++++++++++++++ tools/virsh.pod | 7 +++ 12 files changed, 492 insertions(+), 7 deletions(-) -- 2.1.0

2 6

[libvirt] [PATCH v2 0/4] security: Add check for invalid security models and duplicates
by Erik Skultety 12 Feb '15

12 Feb '15

Erik Skultety (4): security: Refactor virSecurityManagerGenLabel security: introduce virSecurityManagerCheckAllLabel function conf: forbid seclabel duplicates for domain devices schema: allow multiple seclabel for devices in domaincommon.rng docs/schemas/domaincommon.rng | 16 +-- src/conf/domain_conf.c | 9 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 6 + src/security/security_manager.c | 146 ++++++++++++++++++--- src/security/security_manager.h | 2 + .../qemuxml2argv-seclabel-device-duplicates.xml | 33 +++++ .../qemuxml2argv-seclabel-device-multiple.xml | 32 +++++ tests/qemuxml2argvtest.c | 1 + tests/qemuxml2xmltest.c | 1 + 10 files changed, 220 insertions(+), 27 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-seclabel-device-duplicates.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-seclabel-device-multiple.xml -- 1.9.3

2 8

[libvirt] [PATCH v2 0/3] Add support for vCPU and I/O thread scheduler setting
by Martin Kletzander 12 Feb '15

12 Feb '15

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1178986 v2: - No dependency on sched.h unless really needed - Docs fixed according to John - RNG schema matches parsing - Possibility to specify one element for whole mask of vcpus/iothreads - leaks fixed (VIR_FREE(nodes);) O:-) - not accepting "other" as a scheduler when parsing - Rebased, of course Martin Kletzander (3): util: Add virProcessSetScheduler() function for scheduler settings docs, schema, conf: Add support for setting scheduler parameters of guest threads qemu: Add support for setting vCPU and I/O thread scheduler setting configure.ac | 4 +- docs/formatdomain.html.in | 16 ++ docs/schemas/domaincommon.rng | 44 +++++ src/conf/domain_conf.c | 183 ++++++++++++++++++++- src/conf/domain_conf.h | 24 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 5 + src/qemu/qemu_process.c | 57 ++++++- src/qemu/qemu_process.h | 5 +- src/util/virprocess.c | 104 +++++++++++- src/util/virprocess.h | 20 ++- .../qemuxml2argv-cputune-iothreadsched-toomuch.xml | 38 +++++ .../qemuxml2argv-cputune-iothreadsched.xml | 39 +++++ .../qemuxml2argv-cputune-vcpusched-overlap.xml | 38 +++++ tests/qemuxml2argvtest.c | 2 + .../qemuxml2xmlout-cputune-iothreadsched.xml | 39 +++++ tests/qemuxml2xmltest.c | 1 + 17 files changed, 612 insertions(+), 8 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cputune-iothreadsched-toomuch.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cputune-iothreadsched.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cputune-vcpusched-overlap.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cputune-iothreadsched.xml -- 2.3.0

4 13

[libvirt] Google Summer of Code application submitted
by Stefan Hajnoczi 12 Feb '15

12 Feb '15

Hi, I have submitted our Google Summer of Code application for QEMU, libvirt, and KVM. Accepted organizations will be announced on March 2nd at 19:00 UTC on http://google-melange.com/. You can still add project ideas if you wish to mentor: http://qemu-project.org/Google_Summer_of_Code_2015 Mentors must be active contributors and willing to commit 5 hours per week during the summer. Please let me know if you have any questions. Stefan

1 0

[libvirt] [PATCH v2 0/3] Propagate storage errors on migration
by Michal Privoznik 12 Feb '15

12 Feb '15

This is practically v2 to: https://www.redhat.com/archives/libvir-list/2015-January/msg00230.html The approach is merely the same - listening to BLOCK_JOB_* events instead of asking on the monitor repeatedly. But the code looks more polished. Michal Privoznik (3): qemuProcessHandleBlockJob: Set disk->mirrorState more often qemuProcessHandleBlockJob: Take status into account qemuMigrationDriveMirror: Listen to events src/qemu/qemu_migration.c | 37 +++++++++++++++++-------------------- src/qemu/qemu_process.c | 36 +++++++++++++++++++++--------------- 2 files changed, 38 insertions(+), 35 deletions(-) -- 2.0.5

3 8

[libvirt] vm live storage migration with snapshots
by Edward Young 11 Feb '15

11 Feb '15

Hi all, I'm investigating the ways to improve the live migration performance in libvirt. I have a question about the vm live storage migration. the platform is libvirt + qemu + kvm If we want to migrate a running vm with its virtual disk images to another node. we can use 'virsh migrate ....' commands. What if this vm has a number of disk-only external snapshots? In the current version, how can live migrate this vm? Is it possible to blockcommit the snapshots to the base image and later perform the migration, without shutting down the running vm? Or is it possible to iteratively transfer all the snapshots to the destination and later live migrate only the latest new data? Thanks in advance. Best, Ed

2 4

[libvirt] [PATCH] qemu: fix setting of VM CPU affinity with TCG
by Daniel P. Berrange 11 Feb '15

11 Feb '15

If a previous commit I fixed the incorrect handling of vcpu pids for TCG mode QEMU: commit b07f3d821dfb11a118ee75ea275fd6ab737d9500 Author: Daniel P. Berrange <berrange(a)redhat.com> Date: Thu Dec 18 16:34:39 2014 +0000 Don't setup fake CPU pids for old QEMU The code assumes that def->vcpus == nvcpupids, so when we setup fake CPU pids for old QEMU with nvcpupids == 1, we cause the later code to read off the end of the array. This has fun results like sche_setaffinity(0, ...) which changes libvirtd's own CPU affinity, or even better sched_setaffinity($RANDOM, ...) which changes the affinity of a random OS process. The intent was that this would merely disable the ability to set per-vCPU affinity. It should still have been possible to set VM level host CPU affinity. Unfortunately, when you set <vcpu cpuset='0-1'>4</vcpu>, the XML parser will internally take this & initialize an entry in the def->cputune.vcpupin array for every VCPU. IOW this is implicitly being treated as <cputune> <vcpupin cpuset='0-1' vcpu='0'/> <vcpupin cpuset='0-1' vcpu='1'/> <vcpupin cpuset='0-1' vcpu='2'/> <vcpupin cpuset='0-1' vcpu='3'/> </cputune> Even more fun, the faked cputune elements are hidden from view when querying the live XML, because their cpuset mask is the same as the VM default cpumask. The upshot was that it was impossible to set VM level CPU affinity. To fix this we must update qemuProcessSetVcpuAffinities so that it only reports a fatal error if the per-VCPU cpu mask is different from the VM level cpu mask. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/qemu/qemu_process.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index d5df60d..e8c532f 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2497,9 +2497,18 @@ qemuProcessSetVcpuAffinities(virDomainObjPtr vm) return 0; if (priv->vcpupids == NULL) { - virReportError(VIR_ERR_OPERATION_INVALID, - "%s", _("cpu affinity is not supported")); - return -1; + /* If any CPU has custom affinity that differs from the + * VM default affinity, we must reject it + */ + for (n = 0; n < def->vcpus; n++) { + if (!virBitmapEqual(def->cpumask, + def->cputune.vcpupin[n]->cpumask)) { + virReportError(VIR_ERR_OPERATION_INVALID, + "%s", _("cpu affinity is not supported")); + return -1; + } + } + return 0; } for (n = 0; n < def->vcpus; n++) { -- 2.1.0

3 4

[libvirt] [PATCH] bhyvexml2argvmock: change int to size_t for tapfdSize
by Pavel Hrdina 11 Feb '15

11 Feb '15

Commit c5b6a4a5 forget to update also this mock function. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- Pushed as build breaker fix (FreeBSD). tests/bhyvexml2argvmock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/bhyvexml2argvmock.c b/tests/bhyvexml2argvmock.c index 0cbea29..41058ca 100644 --- a/tests/bhyvexml2argvmock.c +++ b/tests/bhyvexml2argvmock.c @@ -24,7 +24,7 @@ int virNetDevTapCreateInBridgePort(const char *brname ATTRIBUTE_UNUSED, const unsigned char *vmuuid ATTRIBUTE_UNUSED, const char *tunpath ATTRIBUTE_UNUSED, int *tapfd ATTRIBUTE_UNUSED, - int tapfdSize ATTRIBUTE_UNUSED, + size_t tapfdSize ATTRIBUTE_UNUSED, virNetDevVPortProfilePtr virtPortProfile ATTRIBUTE_UNUSED, virNetDevVlanPtr virtVlan ATTRIBUTE_UNUSED, unsigned int fakeflags ATTRIBUTE_UNUSED) -- 2.0.5

1 0

[libvirt] [PATCH] domain: include portgroup in interface status xml
by Laine Stump 11 Feb '15

11 Feb '15

Prior to commit 7d5bf484747 (first appearing in libvirt 1.2.2), the status XML of a domain's interface was missing a lot of important information; mainly it just output the config of the interface, plus the name of the tap device and qemu device alias. Commit 7d5bf484747 changed the status XML to include many important bits of information that were required to make network "hook" scripts useful - bandwidth information, vlan tag, the name of the bridge (or physical device in the case of macvtap) that the tap/macvtap device was attached to - the commit log for 7d5bf484747 has a very detailed explanation of the change. For quick reference - in the example given there, prior to the change, status XML looked like figure [C]: <interface type='network'> <source network='testnet' portgroup='admin'/> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> and after the change, it looked like figure [E]: <interface type='direct'> <source dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> You'll notice that bandwidth info, physdev, and macvtap mode have been added, but the network and portgroup names are now missing - I didn't think that this information was of any use once the needed bandwidth/vlan/etc config had been pulled from the network/portgroup. I was wrong. A few months after that change a user on IRC asked what happened to portgroup in the status XML and described how he used it (more or less as a tag to decide what external information to use in a hook script that was run at startup/migration time - see http://wiki.libvirt.org/page/OVS_and_PVLANS ). At that time I planned to make a patch to re-add portgroup, but life intervened as that was just prior to a transatlantic move involving several weeks of "vacation". During this time I somehow forgot to make the patch, and also mistakenly remembered that I *had* made it. Subsequent to this, as a part of mprivozn's work to add support for network-specific hooks, I did re-add the output of the network name in status XML, but once again completely forgot about portgroup. This was in commit a3609121 (first appearing in libvirt 1.2.11). This made the status XML from the above example look like this: <interface type='direct'> <source network='testnet' dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> *This* patch just adds the portgroup back to the status XML, so the same example interface will look like this: <interface type='direct'> <source network='testnet' portgroup='admin' dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> The result is that the status XML now contains all information about how the interface is setup (bandwidth, physical device, tap device, etc), in addition to pointers to its origin (the network and portgroup). --- I had previously asked about this topic here: https://www.redhat.com/archives/libvir-list/2014-June/msg00416.html but then forgot to follow up on it... src/conf/domain_conf.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 8600eff..d870bb6 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -17591,14 +17591,18 @@ virDomainActualNetDefContentsFormat(virBufferPtr buf, if (def->type == VIR_DOMAIN_NET_TYPE_NETWORK && !inSubelement) { /* When we're putting our output into the <actual> * subelement rather than the main <interface>, the - * network name isn't included in the <source> because the - * main interface element's <source> has the same info - * already. If we've been called to output directly into - * the main element's <source> though (the case here - - * "!inSubElement"), we *do* need to output the network - * name, because the caller won't have done it). + * network name and portgroup don't need to be included in + * the <source> here because the main interface element's + * <source> has the same info already. If we've been + * called to output directly into the main element's + * <source> though (the case here - "!inSubElement"), we + * *do* need to output network/portgroup, because the + * caller won't have done it). */ - virBufferEscapeString(buf, " network='%s'", def->data.network.name); + virBufferEscapeString(buf, " network='%s'", + def->data.network.name); + virBufferEscapeString(buf, " portgroup='%s'", + def->data.network.portgroup); } if (actualType == VIR_DOMAIN_NET_TYPE_BRIDGE || actualType == VIR_DOMAIN_NET_TYPE_NETWORK) { -- 2.1.0

2 1