- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] List only online cpus for vcpupin/emulatorpin when vcpu placement static
by Nitesh Konkar 08 Nov '16

08 Nov '16

From: nitesh konkar <niteshkonkar.libvirt(a)gmail.com> Currently when the vcpu placement is static and cpuset is not specified, CPU Affinity shows 0.. CPUMAX. This patchset will result in display of only online CPU's under CPU Affinity. nitesh konkar (2): conf: List only online cpus under CPU Affinity for virsh vcpupin. conf: List only online cpus under CPU Affinity for virsh emulatorpin src/conf/domain_conf.c | 3 +++ src/qemu/qemu_driver.c | 2 ++ 2 files changed, 5 insertions(+) -- 2.1.0

2 4

[libvirt] [PATCH] Test driver should error when domain destroy twice
by Félix Bouliane 08 Nov '16

08 Nov '16

Fixes the behavior when destroying a domain more than once. VIR_ERR_OPERATION_INVALID should be raised when destroying an already destroyed domain. --- src/test/test_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 51fb7c8..42adbad 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -1735,6 +1735,12 @@ static int testDomainDestroy(virDomainPtr domain) if (!(privdom = testDomObjFromDomain(domain))) goto cleanup; + if (!virDomainObjIsActive(privdom)) { + virReportError(VIR_ERR_OPERATION_INVALID, + "%s", _("domain is not running")); + goto cleanup; + } + testDomainShutdownState(domain, privdom, VIR_DOMAIN_SHUTOFF_DESTROYED); event = virDomainEventLifecycleNewFromObj(privdom, VIR_DOMAIN_EVENT_STOPPED, -- 2.9.3

2 1

[libvirt] [PATCH v2 00/11] clean up after "slot sharing" patches
by Laine Stump 07 Nov '16

07 Nov '16

(this is just a rebase of the v1 patches to make review easier) Some of the patches that enabled sharing PCI slots by multiple pcie-root-ports made the idea of reserving an entire slot obsolete. To reduce confusion and misunderstandings, this patch series gets rid of the name "Slot" in all of the functions that reserve and release PCI addresses. None of these patches affect any functional change. This is a lot of patches, but each patch is trivial, I promise - most are simply renaming a single function, or changing one argument to some calls to a function. Laine Stump (11): conf: fix fromConfig argument to virDomainPCIAddressReserveAddr() conf: fix fromConfig argument to virDomainPCIAddressValidate() conf: rename virDomainPCIAddressGetNextSlot() to ...GetNextAddr() conf: eliminate virDomainPCIAddressReserveNextSlot() qemu: replace virDomainPCIAddressReserveAddr with virDomainPCIAddressReserveSlot conf: make virDomainPCIAddressReserveAddr() a static function conf: rename virDomainPCIAddressReserveAddr() to ...Internal() conf: rename virDomainPCIAddressReserveSlot() to ...Addr() qemu: remove qemuDomainPCIAddressReserveNextAddr() qemu: rename qemuDomainPCIAddressReserveNextSlot() to ...Addr() conf: eliminate virDomainPCIAddressReleaseSlot() in favor of ...Addr() src/bhyve/bhyve_device.c | 26 ++++++---- src/conf/domain_addr.c | 60 +++++------------------ src/conf/domain_addr.h | 15 ------ src/libvirt_private.syms | 4 +- src/qemu/qemu_domain_address.c | 105 ++++++++++++++++++++--------------------- 5 files changed, 80 insertions(+), 130 deletions(-) -- 2.7.4

1 11

[libvirt] [PATCH 0/6] Add group_name support for <iotune>
by John Ferlan 07 Nov '16

07 Nov '16

https://bugzilla.redhat.com/show_bug.cgi?id=1336564 Add support for "group" name in <iotune>. The odd thing about the <iotune> group name is that support was added in qemu after the _max parameters, but before the _max_length - so when building the command line - that needs to be followed. At least it's far less complicated than the _length parameters. John Ferlan (6): include: Add new "group_name" definition for iotune throttling caps: Add new capability for the iotune group name qemu: Add support for parsing iotune group setting conf: Add support for blkiotune group_name option qemu: Add the group name option to the iotune command line virsh: Add group name to blkdeviotune output docs/formatdomain.html.in | 11 ++++ docs/schemas/domaincommon.rng | 5 ++ include/libvirt/libvirt-domain.h | 15 +++++ src/conf/domain_conf.c | 10 +++ src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 ++++ src/qemu/qemu_driver.c | 50 +++++++++++++-- src/qemu/qemu_monitor.c | 2 + src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 21 +++++- src/qemu/qemu_monitor_json.h | 1 + tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemumonitorjsontest.c | 74 +++++++++++++++++----- .../qemuxml2argv-blkdeviotune-group-num.args | 32 ++++++++++ .../qemuxml2argv-blkdeviotune-group-num.xml | 61 ++++++++++++++++++ tests/qemuxml2argvtest.c | 4 ++ .../qemuxml2xmlout-blkdeviotune-group-num.xml | 1 + tests/qemuxml2xmltest.c | 1 + tools/virsh-domain.c | 17 +++++ tools/virsh.pod | 5 +- 28 files changed, 309 insertions(+), 26 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-group-num.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-group-num.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-blkdeviotune-group-num.xml -- 2.7.4

3 16

Re: [libvirt] [PATCH 1/2] vbox: add vbox 5.1 C API header file.
by Eric Blake 07 Nov '16

07 Nov '16

On 11/07/2016 03:03 PM, Dawid Zamirski wrote: > > extracted from VirutalBox SDK and reindented with cppi. > --- > src/vbox/vbox_CAPI_v5_1.h | 26117 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 26117 insertions(+) > create mode 100644 src/vbox/vbox_CAPI_v5_1.h 1.1 Meg of generated code is a lot to send to the mailing list. Can you compress the patch so that it isn't taxing the list server quite so hard? Or if someone with push rights agrees, send them the patch on the side and get it committed without going through the list (as there's very little that actually needs a review). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

2 1

[libvirt] [PATCH v2 0/8] aggregate multiple pcie-root-ports onto a single slot
by Laine Stump 07 Nov '16

07 Nov '16

This is just a rebase of v1 of the same series, reposted to make it easier for Andrea to review. Laine Stump (8): conf: use struct instead of int for each slot in virDomainPCIAddressBus conf: eliminate concept of "reserveEntireSlot" conf: eliminate repetitive code in virDomainPCIAddressGetNextSlot() conf: start search for next unused PCI address at same slot as previous find conf: new function virDomainPCIAddressIsMulti() qemu: use virDomainPCIAddressIsMulti() to determine multifunction setting conf: aggregate multiple devices on a slot when assigning PCI addresses conf: aggregate multiple pcie-root-ports onto a single slot src/conf/domain_addr.c | 290 ++++++++++++++------- src/conf/domain_addr.h | 48 +++- src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 16 +- src/qemu/qemu_domain_address.c | 35 ++- .../qemuxml2argv-pcie-root-port.args | 5 +- .../qemuxml2argv-pcie-switch-upstream-port.args | 5 +- .../qemuxml2argv-q35-default-devices-only.args | 7 +- .../qemuxml2argv-q35-multifunction.args | 43 +++ .../qemuxml2argv-q35-multifunction.xml | 51 ++++ .../qemuxml2argv-q35-pcie-autoadd.args | 30 ++- tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 28 +- .../qemuxml2argv-q35-virt-manager-basic.args | 13 +- .../qemuxml2argv-q35-virtio-pci.args | 28 +- tests/qemuxml2argvtest.c | 25 ++ .../qemuxml2xmlout-pcie-root-port.xml | 2 +- .../qemuxml2xmlout-pcie-switch-upstream-port.xml | 4 +- .../qemuxml2xmlout-q35-default-devices-only.xml | 8 +- .../qemuxml2xmlout-q35-multifunction.xml | 120 +++++++++ .../qemuxml2xmlout-q35-pcie-autoadd.xml | 52 ++-- .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 48 ++-- .../qemuxml2xmlout-q35-virt-manager-basic.xml | 20 +- .../qemuxml2xmlout-q35-virtio-pci.xml | 48 ++-- tests/qemuxml2xmltest.c | 25 ++ 24 files changed, 676 insertions(+), 276 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-multifunction.xml -- 2.7.4

1 8

[libvirt] [PATCH] Unbreak rebuilding docs with release tarballs
by Guido Günther 07 Nov '16

07 Nov '16

Release tarballs ship the include/libvirt/libvirt-common.h. when srcdir != builddir we end up including libvirt-common.h twice: from $top_srcdir/include/libvirt-common.h and from $builddir/include/libvirt-common.h leading to function virTypedParamsGetUInt from /tmp/buildd/libvirt-2.4.0/debian/build/docs/../include/libvirt/libvirt-common.h redeclared in /tmp/buildd/libvirt-2.4.0/docs/../include/libvirt/libvirt-common.h function virTypedParamsAddBoolean from /tmp/buildd/libvirt-2.4.0/debian/build/docs/../include/libvirt/libvirt-common.h redeclared in /tmp/buildd/libvirt-2.4.0/docs/../include/libvirt/libvirt-common.h … Only add the builddir to the search list if there is no pregenerated libvirt-common.h. Reuse the existing check that predates the libvirt.h → libvirt-common.h split and that probably was meant for exactly that. References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842452 --- docs/apibuild.py | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/apibuild.py b/docs/apibuild.py index 8728b27..47f340c 100755 --- a/docs/apibuild.py +++ b/docs/apibuild.py @@ -2607,10 +2607,9 @@ class app: dirs = [srcdir + "/../src", srcdir + "/../src/util", srcdir + "/../include/libvirt"] - if builddir: + if (builddir and + not os.path.exists(srcdir + "/../include/libvirt/libvirt-common.h")): dirs.append(builddir + "/../include/libvirt") - if glob.glob(srcdir + "/../include/libvirt/libvirt.h") == [] : - dirs.append("../include/libvirt") builder = docBuilder(name, srcdir, dirs, []) elif glob.glob("src/libvirt.c") != [] : if not quiet: -- 2.10.1

2 2

[libvirt] [PATCH] spec: Run all make jobs in parallel
by Andrea Bolognani 07 Nov '16

07 Nov '16

Commit e8861f69714f changed our spec file to compile and run tests in parallel. That's a very good step forward, but why stop there? Let's run *all* make jobs in parallel and really put those expensive cores to use! On my laptop, this shaves ~10s off 'make rpm'. --- libvirt.spec.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 5133936..a2c2f2f 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1210,9 +1210,9 @@ rm -fr %{buildroot} # Avoid using makeinstall macro as it changes prefixes rather than setting # DESTDIR. Newer make_install macro would be better but it's not available # on RHEL 5, thus we need to expand it here. -make install DESTDIR=%{?buildroot} SYSTEMD_UNIT_DIR=%{_unitdir} +make %{?_smp_mflags} install DESTDIR=%{?buildroot} SYSTEMD_UNIT_DIR=%{_unitdir} -make -C examples distclean +make %{?_smp_mflags} -C examples distclean rm -f $RPM_BUILD_ROOT%{_libdir}/*.la rm -f $RPM_BUILD_ROOT%{_libdir}/*.a -- 2.7.4

2 2

[libvirt] [PATCH] Allow saving QEMU libvirt state to a pipe
by Roy Keene 07 Nov '16

07 Nov '16

All, Currently the "virsh save" command opens a file to save a domain's XML and memory state, does the save, and then re-opens the file to simulate seeking to the beginning to update the header to indicate that the file is complete. For pipes this is not possible, attempting to re-open the pipe will not connect you to the same consumer. Seeking is also not possible on a pipe. Attached is a patch that detects if the file being written to is not seekable, and if so writes the completed header initially, then writes the normal data, and avoids re-opening the file. This is useful to me for saving a VM state directly to Ceph RBD images without having an intermediate file. I've tested this patch successfully (against v1.3.5) for both saving and restoring a domain: # *( fifo="$(mktemp -u)"; mkfifo "${fifo}" && virsh save one-0 "${fifo}" & cat "${fifo}" | rbd import - rbd/test1234 & wait; rm -f "${fifo}" )* Domain one-0 saved to /tmp/tmp.HK4hChiQqB # # *( fifo="$(mktemp -u)"; mkfifo "${fifo}" && rbd export rbd/test1234 - > "${fifo}" & virsh restore "${fifo}" & wait; rm -f "${fifo}" ) * Exporting image: 100% complete...done. Domain restored from /tmp/tmp.0YaUZ5Y2yT # *virsh list* Id Name State ---------------------------------------------------- 11 one-0 running # -- Roy Keene Knight Point Systems, LLC Service-Disabled Veteran-Owned Business 1775 Wiehle Avenue Suite 101 | Reston, VA 20190 c: 813-956-3808 f: 571-266-3106 www.knightpoint.com DHS EAGLE II Prime Contractor: FC1 SDVOSB Track GSA Schedule 70 SDVOSB: GS-35F-0646S GSA MOBIS Schedule: GS-10F-0404Y ISO 20000 / ISO 27001 Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copy, use, disclosure, or distribution is STRICTLY prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

3 3

[libvirt] qemu: domain notification for serial channel changes
by Matt Broadstone 07 Nov '16

07 Nov '16

Hi, I was in the process of implementing a custom qemu agent which communicates over virtio-serial channels, when I noticed that the only way to receive channel state change notifications was to poll the domstatus XML file. There does seem to be code in libvirt to monitor for serial change events (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=38…) however it's hardcoded/specific to the qemu-ga (explicitly checking for ports named "org.qemu.guest_agent.0"). It occurs to me that while there was a class of events added for guest lifecycle changes, it might be a more generic solution to provide events for character device changes. Am I missing some existing functionality here? I'm a first-time poster here so I was hoping to both signal my intent to implement something more generic, as well as ping the community to see if there would be interest in this work or reasons why I shouldn't be doing this. Regards, Matt

3 6