February 2016 - Devel - libvirt List Archives

[libvirt] [PATCH] Revert "storageVolCreateXMLFrom: Check if backend knows how to createVol"
by Ján Tomko 17 Feb '16

17 Feb '16

This reverts commit 611a278fa46d3136b7fe5c6ab05e660ca3c8fdf4. According to the original commit message, this is dead code: It is highly unlikely that a backend will know how to create a volume from a different volume (buildVolFrom) and not know how to create an empty volume (createVol). --- src/storage/storage_driver.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 81b1584..e0ded01 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2037,13 +2037,6 @@ storageVolCreateXMLFrom(virStoragePoolPtr obj, if (newvol->target.capacity < origvol->target.capacity) newvol->target.capacity = origvol->target.capacity; - if (!backend->createVol) { - virReportError(VIR_ERR_NO_SUPPORT, - "%s", _("storage pool does not support volume " - "creation")); - goto cleanup; - } - if (!backend->buildVolFrom) { virReportError(VIR_ERR_NO_SUPPORT, "%s", _("storage pool does not support" -- 2.4.10

2 1

[libvirt] [PATCH 00/12] Split up qemu_command.c
by John Ferlan 16 Feb '16

16 Feb '16

Before disappearing too far down the rabbit hole... My recent foray into qemu_command.c to split out qemu_parse_command.c got me thinking that the module could use quite a bit of a reorganization. It's about 11,400 lines of all sorts of various functions. This started out as an attempt to order functions as they are used, but started turning into extracting certain API's/Helpers into other qemu_*.c modules. There's still quite a bit to do, but rather than hold onto it too long I figured I'd send what I have so far now (and keep working through while waiting for reviews). This is essentially all code motion with some function renames along the way. John Ferlan (12): qemu-command: Move qemuBuildTPMBackendStr qemu-command: Move qemuVirCommandGetFDSet qemu-command: Move qemuBuildTPMDevStr qemu-command: Move qemuVirCommandGetDevSet qemu: Move qemuPhysIfaceConnect to qemu_interface.c and rename qemu: Move qemuNetworkIfaceConnect to qemu_interface.c and rename qemu-command: Move qemuDomainSupports* functions qemu-command: Move qemuDomain*Address* functions to qemu_domain.c qemu-command: Move remaining qemuDomain* functions qemu-command: Move and rename qemuOpenVhostNet qemu-command: Move qemuNetworkPrepareDevices qemu-command: Move qemuAssign*Alias* API's into their own module po/POTFILES.in | 2 + src/Makefile.am | 1 + src/qemu/qemu_assign_alias.c | 468 +++++++ src/qemu/qemu_assign_alias.h | 60 + src/qemu/qemu_command.c | 3073 +++++------------------------------------- src/qemu/qemu_command.h | 48 - src/qemu/qemu_domain.c | 1646 ++++++++++++++++++++++ src/qemu/qemu_domain.h | 25 + src/qemu/qemu_driver.c | 1 + src/qemu/qemu_hotplug.c | 19 +- src/qemu/qemu_interface.c | 378 ++++++ src/qemu/qemu_interface.h | 22 + src/qemu/qemu_process.c | 56 +- tests/qemuhotplugtest.c | 1 + tests/qemuxml2argvtest.c | 1 + 15 files changed, 2978 insertions(+), 2823 deletions(-) create mode 100644 src/qemu/qemu_assign_alias.c create mode 100644 src/qemu/qemu_assign_alias.h -- 2.5.0

3 32

[libvirt] [PATCH] conf: Use a temporary int variable to store GIC version
by Andrea Bolognani 16 Feb '16

16 Feb '16

Since no value in the virGICVersion enumeration is negative, a clever enough compiler can report an error such as src/conf/domain_conf.c:15337:75: error: comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare] if ((def->gic_version = virGICVersionTypeFromString(tmp)) < 0 || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~ virGICVersionTypeFromString() can, however, return a negative value if the input string is not part of the enumeration, so we definitely need that check. Work around the problem by storing the return value in a temporary int variable. --- Pushed under the build-breaker rule. src/conf/domain_conf.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 295bc1b..0d2957b 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -14728,7 +14728,7 @@ virDomainDefParseXML(xmlDocPtr xml, xmlNodePtr *nodes = NULL, node = NULL; char *tmp = NULL; size_t i, j; - int n, virtType; + int n, virtType, gic_version; long id = -1; virDomainDefPtr def; bool uuid_generated = false; @@ -15334,12 +15334,13 @@ virDomainDefParseXML(xmlDocPtr xml, node = ctxt->node; ctxt->node = nodes[i]; if ((tmp = virXPathString("string(./@version)", ctxt))) { - if ((def->gic_version = virGICVersionTypeFromString(tmp)) < 0 || - def->gic_version == VIR_GIC_VERSION_NONE) { + gic_version = virGICVersionTypeFromString(tmp); + if (gic_version < 0 || gic_version == VIR_GIC_VERSION_NONE) { virReportError(VIR_ERR_XML_ERROR, _("malformed gic version: %s"), tmp); goto error; } + def->gic_version = gic_version; VIR_FREE(tmp); } def->features[val] = VIR_TRISTATE_SWITCH_ON; -- 2.5.0

1 0

[libvirt] [PATCH 0/7] Improve GIC support
by Andrea Bolognani 16 Feb '16

16 Feb '16

This series was really just supposed to enable guests to use the special "host" GIC version, but I ended up changing a bunch of other stuff and adding a whole lot of new test cases. I've also made it so the GIC availability is always reflected in the domain XML, the same way other implicit devices and features work. The GIC-related definitions are in their own file: depending on whether we end up probing for host GIC support ourselves or relying on QEMU this might turn out to be a huge overkill :) Cheers. Andrea Bolognani (7): gic: Introduce virGICVersion enumeration schema: List allowed GIC versions conf: Use virGICVersion enumeration in virDomainDef qemu: Default to GIC v2 qemu: Always enable GIC on ARM virt machines tests: Reorganize and simplify GIC test cases tests: Add more GIC test cases docs/schemas/domaincommon.rng | 6 +++- src/Makefile.am | 1 + src/conf/domain_conf.c | 15 ++++---- src/conf/domain_conf.h | 3 +- src/libvirt_private.syms | 5 +++ src/qemu/qemu_command.c | 8 +++-- src/qemu/qemu_domain.c | 29 ++++++++++++++++ src/util/virgic.c | 33 ++++++++++++++++++ src/util/virgic.h | 38 ++++++++++++++++++++ .../qemuxml2argv-aarch64-aavmf-virtio-mmio.xml | 1 + .../qemuxml2argv-aarch64-gic-default.args | 1 + .../qemuxml2argv-aarch64-gic-default.xml | 22 ++++++++++++ ...gic.args => qemuxml2argv-aarch64-gic-host.args} | 13 +++---- .../qemuxml2argv-aarch64-gic-host.xml | 22 ++++++++++++ .../qemuxml2argv-aarch64-gic-invalid.xml | 22 ++++++++++++ .../qemuxml2argv-aarch64-gic-none.args | 1 + .../qemuxml2argv-aarch64-gic-none.xml | 19 ++++++++++ .../qemuxml2argv-aarch64-gic-not-arm.xml | 22 ++++++++++++ .../qemuxml2argv-aarch64-gic-not-virt.xml | 22 ++++++++++++ ...gicv3.args => qemuxml2argv-aarch64-gic-v2.args} | 12 +++---- ...h64-gic.xml => qemuxml2argv-aarch64-gic-v2.xml} | 14 ++------ .../qemuxml2argv-aarch64-gic-v3.args | 20 +++++++++++ ...4-gicv3.xml => qemuxml2argv-aarch64-gic-v3.xml} | 14 ++------ tests/qemuxml2argvtest.c | 40 ++++++++++++++++++---- .../qemuxml2xmlout-aarch64-gic-default.xml | 1 + .../qemuxml2xmlout-aarch64-gic-none.xml | 1 + tests/qemuxml2xmltest.c | 7 ++-- 27 files changed, 331 insertions(+), 61 deletions(-) create mode 100644 src/util/virgic.c create mode 100644 src/util/virgic.h create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-default.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-default.xml rename tests/qemuxml2argvdata/{qemuxml2argv-aarch64-gic.args => qemuxml2argv-aarch64-gic-host.args} (57%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-host.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-invalid.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-none.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-none.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-not-arm.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-not-virt.xml rename tests/qemuxml2argvdata/{qemuxml2argv-aarch64-gicv3.args => qemuxml2argv-aarch64-gic-v2.args} (55%) rename tests/qemuxml2argvdata/{qemuxml2argv-aarch64-gic.xml => qemuxml2argv-aarch64-gic-v2.xml} (61%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic-v3.args rename tests/qemuxml2argvdata/{qemuxml2argv-aarch64-gicv3.xml => qemuxml2argv-aarch64-gic-v3.xml} (61%) create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-gic-default.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-gic-none.xml -- 2.5.0

3 24

[libvirt] [PATCH] qemu: fix hot unplug of PCI devices with VFIO
by Ludovic Beliveau 16 Feb '16

16 Feb '16

Currently, on hot unplug of PCI devices with VFIO driver for QEMU, libvirt is trying to restore the host devices to it's previous value (basically a chown on the previous user/group). However for devices with VFIO driver, when the device is unbinded it is removed from the /dev/vfio file system causing the restore label to fail. The fix is to not restore the label for those PCI devices since they are going to be teared down anyway. Signed-off-by: Ludovic Beliveau <ludovic.beliveau(a)windriver.com> --- diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index f8db960..f5beabd 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -2996,6 +2996,8 @@ qemuDomainRemoveHostDevice(virQEMUDriverPtr driver, int ret = -1; qemuDomainObjPrivatePtr priv = vm->privateData; char *drivestr = NULL; + virDomainHostdevSubsysPCIPtr pcisrc = NULL; + bool is_vfio = false; VIR_DEBUG("Removing host device %s from domain %p %s", hostdev->info->alias, vm, vm->def->name); @@ -3039,6 +3041,8 @@ qemuDomainRemoveHostDevice(virQEMUDriverPtr driver, switch ((virDomainHostdevSubsysType) hostdev->source.subsys.type) { case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: + pcisrc = &hostdev->source.subsys.u.pci; + is_vfio = pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO; qemuDomainRemovePCIHostDevice(driver, vm, hostdev); /* QEMU might no longer need to lock as much memory, eg. we just * detached the last VFIO device, so adjust the limit here */ @@ -3058,7 +3062,8 @@ qemuDomainRemoveHostDevice(virQEMUDriverPtr driver, if (qemuTeardownHostdevCgroup(vm, hostdev) < 0) VIR_WARN("Failed to remove host device cgroup ACL"); - if (virSecurityManagerRestoreHostdevLabel(driver->securityManager, + if (!is_vfio && + virSecurityManagerRestoreHostdevLabel(driver->securityManager, vm->def, hostdev, NULL) < 0) { VIR_WARN("Failed to restore host device labelling"); }

3 2

[libvirt] [PATCH] Spell VMware with a lowercase w
by Ján Tomko 16 Feb '16

16 Feb '16

Replace all occurrences of VMWare outside the news. --- docs/formatdomain.html.in | 2 +- docs/migration.html.in | 2 +- docs/storage.html.in | 2 +- libvirt.spec.in | 2 +- src/util/virerror.c | 2 +- src/util/virstoragefile.c | 2 +- tools/virsh.c | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index b3187bb..e96798f 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1569,7 +1569,7 @@ <dt><code>vmport</code></dt> <dd>Depending on the <code>state</code> attribute (values <code>on</code>, <code>off</code>, default <code>on</code>) enable or disable - the emulation of VMWare IO port, for vmmouse etc. + the emulation of VMware IO port, for vmmouse etc. <span class="since">Since 1.2.16</span> </dd> <dt><code>gic</code></dt> diff --git a/docs/migration.html.in b/docs/migration.html.in index 6986cc0..8efdd7f 100644 --- a/docs/migration.html.in +++ b/docs/migration.html.in @@ -475,7 +475,7 @@ </pre> <p> - Supported by Xen, QEMU, VMWare and VirtualBox drivers + Supported by Xen, QEMU, VMware and VirtualBox drivers </p> <h3><a name="scenarionativepeer2peer">Native migration, client to and peer2peer between, two libvirtd servers</a></h3> diff --git a/docs/storage.html.in b/docs/storage.html.in index 1f01330..b0efe69 100644 --- a/docs/storage.html.in +++ b/docs/storage.html.in @@ -161,7 +161,7 @@ <li><code>qcow</code>: QEMU v1 disk image format</li> <li><code>qcow2</code>: QEMU v2 disk image format</li> <li><code>qed</code>: QEMU Enhanced Disk image format</li> - <li><code>vmdk</code>: VMWare disk image format</li> + <li><code>vmdk</code>: VMware disk image format</li> <li><code>vpc</code>: VirtualPC disk image format</li> </ul> <p> diff --git a/libvirt.spec.in b/libvirt.spec.in index dd54dfc..fc2e2cf 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -190,7 +190,7 @@ %endif # RHEL doesn't ship OpenVZ, VBox, UML, PowerHypervisor, -# VMWare, libxenserver (xenapi), libxenlight (Xen 4.1 and newer), +# VMware, libxenserver (xenapi), libxenlight (Xen 4.1 and newer), # or HyperV. %if 0%{?rhel} %define with_openvz 0 diff --git a/src/util/virerror.c b/src/util/virerror.c index 3a3ddef..e1bcf52 100644 --- a/src/util/virerror.c +++ b/src/util/virerror.c @@ -105,7 +105,7 @@ VIR_ENUM_IMPL(virErrorDomain, VIR_ERR_DOMAIN_LAST, "Audit Utils", "Sysinfo Utils", "I/O Stream Utils", - "VMWare Driver", + "VMware Driver", "Event Loop", /* 40 */ "Xen Light Driver", diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 3e79ae1..49b1745 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -490,7 +490,7 @@ vmdk4GetBackingStore(char **res, *res = NULL; /* * Technically this should have been VMDK, since - * VMDK spec / VMWare impl only support VMDK backed + * VMDK spec / VMware impl only support VMDK backed * by VMDK. QEMU isn't following this though and * does probing on VMDK backing files, hence we set * AUTO diff --git a/tools/virsh.c b/tools/virsh.c index b96dbda..eb84dd0 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -550,7 +550,7 @@ virshShowVersion(vshControl *ctl ATTRIBUTE_UNUSED) vshPrint(ctl, " OpenVZ"); #endif #ifdef WITH_VMWARE - vshPrint(ctl, " VMWare"); + vshPrint(ctl, " VMware"); #endif #ifdef WITH_PHYP vshPrint(ctl, " PHYP"); -- 2.4.10

3 3

[libvirt] PING: [RFC] vhost-user + shared memory + NUMA
by Pavel Fedin 15 Feb '16

15 Feb '16

Hello! Sorry, but i did not get any answer to the last question. Would it be OK to require <memoryBacking> and implicitly add only shared mode ? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of > Pavel Fedin > Sent: Thursday, February 11, 2016 5:36 PM > To: 'Daniel P. Berrange' > Cc: 'Libvirt' > Subject: Re: [libvirt] [RFC] vhost-user + shared memory + NUMA > > Hello! > > > > Ok, then would it be a good compromise if we require <memoryBacking>, and only > implicitly > > add "shared" if we have vhost-user > > > devices? This way we would not change the way the guest memory is allocated. > > > > Adding shared implicitly *will* change the way guest memory is allocated, > > as it will have to use tmpfs to make it shared. > > You perhaps didn't get my idea. I meant - we will still need to specify <memoryBacking> with > huge pages, just no <numa>. Therefore, the memory will be allocated via file backend from > hugetlbfs. Only mode will be changed implicitly (private -> shared). > > > > IMHO being able to manually specify "shared" both in <numa> and > > > in <memoryBacking> would be ambiguous. > > > > That's not really any different to what we have already with NUMA. > > The top level setting would apply as the default, and the NUMA level > > settings override it if needed. > > Well, the only little drawback would be necessity to add "shared" by itself. This would > require additional patching to clients (e. g. openstack). > > Kind regards, > Pavel Fedin > Senior Engineer > Samsung Electronics Research center Russia > > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list

2 1

[libvirt] [PATCH 0/2] virsh: fix usage of vshPrint
by Peter Krempa 15 Feb '16

15 Feb '16

Peter Krempa (2): vsh: Simplify bailing out on OOM conditions vsh: Replace vshPrint macro with function tools/virsh-domain.c | 16 +++++++++------- tools/vsh.c | 34 +++++++++++++++++++++++++++++----- tools/vsh.h | 5 ++--- 3 files changed, 40 insertions(+), 15 deletions(-) -- 2.6.2

2 3

[libvirt] [PATCH 0/4] Couple of storage related fixes
by Michal Privoznik 15 Feb '16

15 Feb '16

After an e-mail on libvirt-users [1] I've realized there are some things that we can do better. The first two patches introduce a new feature. The other two are just some fixes. Michal Privoznik (4): cmdVolCreateAs: Rework to follow usual func pattern virsh: Teach vol-create-as to --print-xml storageVolCreateXML: Swap order of two operations storageVolCreateXMLFrom: Check if backend knows how to createVol src/storage/storage_driver.c | 15 +++++++++++---- tools/virsh-volume.c | 33 +++++++++++++++++++++------------ tools/virsh.pod | 6 ++++-- 3 files changed, 36 insertions(+), 18 deletions(-) -- 2.4.10

3 11

[libvirt] ARM KVM GICv3 Support
by Christoffer Dall 15 Feb '16

15 Feb '16

Hi all, I'm trying to figure out what the correct solution for libvirt support for ARM KVM guests with GICv3 is. The challenge is that QEMU's virt machine model defaults to GICv2 unless you specify an additional "-machine gic-version=host" parameter to QEMU, in which case your VM gets the same GIC version as your host. Now, I'm told that this is inconvenient for libvirt, because it typically does not pass any -machine options, is that correct? Further, there are two additional complications: First, some guest images may not include GICv3 support. For Linux, this is relatively old kernels (prior to v3.17), but other guests may only support GICv2. Second, some hardware platforms only support GICv2 guests, some only support GICv3 guests, and some support both GICv2 and GICv3 guests (those hosts with a GICv3 with the backwards compatibility support). It is unclear to me how libvirt users will relate to these constraints. For example, in an OpenStack deployment, will it somehow be easy to tell which nodes support which GIC version such that administrators can choose compatible VM images, or how does that work? The end goal here is to determine if we need to add any functionality to QEMU to better support libvirt, and what kind of features/glue need to be added to libvirt for this to work. Much thanks for any feedback! -Christoffer

12 53