- Devel - libvirt List Archives

[libvirt] [PATCH V2 0/4]] qemu: report actual vcpu state in virVcpuInfo
by Viktor Mihajlovski 06 Oct '16

06 Oct '16

Currently, the virVcpuInfo returned by virDomainGetVcpus() will always report a state of VIR_VCPU_RUNNING for each defined domain vcpu even if the vcpu is currently in the halted state. As the monitor interface is in fact reporting the accurate state, it is rather easy to transport this information with the existing API. This is done by - adding a new state of VIR_VCPU_HALTED - extending the monitor to pass back the halted state for the vcpus - adding a new field to the private domain vcpu object reflecting the halted state for the vcpu - modifying the driver code to report the vcpu state based on the halted indicator - extending virsh vcpuinfo to also display the halted state The vcpu state is however not recorded in the internal XML format, since the state can change asynchronously (without notification). V2 is a rebase on top of Peter Krempa's CPU hotplug modernization. Viktor Mihajlovski (4): domain: Add new VCPU state "halted" qemu: Add monitor support for CPU halted state qemu: Add domain support for VCPU halted state qemu: Ensure reported VCPU state is current in driver API include/libvirt/libvirt-domain.h | 1 + src/qemu/qemu_domain.c | 69 ++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 5 +++ src/qemu/qemu_driver.c | 23 ++++++++++++-- src/qemu/qemu_monitor.c | 6 +++- src/qemu/qemu_monitor.h | 5 +++ src/qemu/qemu_monitor_json.c | 3 ++ src/qemu/qemu_monitor_text.c | 8 ++++- tests/qemumonitorjsontest.c | 8 ++--- tools/virsh-domain.c | 3 +- 10 files changed, 122 insertions(+), 9 deletions(-) -- 1.9.1

3 14

[libvirt] [PATCH 0/6] qemu: fix UDP chardev hotplug and make qemumonitorjsontest less useless
by Peter Krempa 06 Oct '16

06 Oct '16

Most of the time qemumonitorjson test isn't really testing much. Add support for actually testing chardev hotplug and fix it for the UDP case. Peter Krempa (6): conf: Sanitize formatting of UDP chardev source tests: qemu: Add support for testing aguments on monitor verbatim tests: qemumonitorjson: Don't do multiple tests in one virTestRun tests: qemumonitorjsontest: Do some actual testing in qemuMonitorJSONTestAttachChardev qemu: monitor: Simplify construction of chardev backends qemu: monitor: Properly configure backend for UDP chardevs src/conf/domain_conf.c | 42 ++++---- src/qemu/qemu_monitor_json.c | 51 +++++----- tests/qemumonitorjsontest.c | 222 ++++++++++++++++++++++++++++++++----------- tests/qemumonitortestutils.c | 112 ++++++++++++++++++++++ tests/qemumonitortestutils.h | 6 ++ 5 files changed, 326 insertions(+), 107 deletions(-) -- 2.10.0

2 15

[libvirt] [PATCH 00/12] Add length (duration) params for iotune throttling
by John Ferlan 06 Oct '16

06 Oct '16

https://bugzilla.redhat.com/show_bug.cgi?id=1349898 Do a little housekeeping and minor adjustments to existing code, then add the various "-length" options for the <iotune> code. John Ferlan (12): docs: Fix typo in libvirt-domain.h parameter description include: Update description for <iotune> max params tests: Add blkdeviotune-max xml2xmltest qemu: Convert from shorthand to longer throttling names qemu: Adjust how supportMaxOptions is used. include: Add new definitions for duration for bps/iops throttling caps: Add new capability for the bps/iops throttling length qemu: Add length for bps/iops throttling parameters to driver conf: Add a formatting macro for all the blkiotune values conf: Adjust the PARSE_IOTUNE macro conf: Add support for blkiotune "_length" options qemu: Add the length options to the iotune command line docs/formatdomain.html.in | 40 +++++- docs/schemas/domaincommon.rng | 38 ++++++ include/libvirt/libvirt-domain.h | 124 ++++++++++++++++-- src/conf/domain_conf.c | 142 +++++++++++---------- src/conf/domain_conf.h | 6 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 96 ++++++-------- src/qemu/qemu_driver.c | 106 ++++++++++++++- src/qemu/qemu_monitor.c | 7 +- src/qemu/qemu_monitor.h | 3 +- src/qemu/qemu_monitor_json.c | 72 ++++++----- src/qemu/qemu_monitor_json.h | 3 +- .../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 | 17 ++- .../qemuxml2argv-blkdeviotune-max-length.args | 34 +++++ .../qemuxml2argv-blkdeviotune-max-length.xml | 65 ++++++++++ .../qemuxml2argv-blkdeviotune-max.args | 10 +- .../qemuxml2argv-blkdeviotune-max.xml | 14 +- .../qemuxml2argv-blkdeviotune.args | 5 +- tests/qemuxml2argvtest.c | 4 + .../qemuxml2xmlout-blkdeviotune-max-length.xml | 1 + .../qemuxml2xmlout-blkdeviotune-max.xml | 1 + tests/qemuxml2xmltest.c | 2 + 28 files changed, 616 insertions(+), 182 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-max-length.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-max-length.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-blkdeviotune-max-length.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-blkdeviotune-max.xml -- 2.7.4

3 30

[libvirt] [PATCH] qemu: allow 32 slots on pcie-expander-bus, not just 1
by Laine Stump 05 Oct '16

05 Oct '16

When I added support for the pcie-expander-bus controller in commit bc07251f, I incorrectly thought that it only had a single slot available. Actually it has 32 slots, just like the root complex aka pcie-root (the part that I *did* get correct is that unlike pcie-root a pcie-expander-bus doesn't allow any integrated endpoint devices - only pcie-root-ports and dmi-to-pci-controllers are allowed). --- src/conf/domain_addr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c index 93026c2..0406b50 100644 --- a/src/conf/domain_addr.c +++ b/src/conf/domain_addr.c @@ -304,13 +304,13 @@ virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr bus, bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST; break; case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS: - /* single slot, no hotplug, only accepts pcie-root-port or + /* 32 slots, no hotplug, only accepts pcie-root-port or * dmi-to-pci-bridge */ bus->flags = (VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT | VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE); bus->minSlot = 0; - bus->maxSlot = 0; + bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST; break; default: -- 2.7.4

2 2

[libvirt] libvirt zsh completions
by Marko Myllynen 05 Oct '16

05 Oct '16

Hi, FWIW, FYI, I've contributed completions for the commands part of libvirt to zsh upstream, here's a quick screenshot: $ virsh <TAB> zsh: do you wish to see all 222 possibilities (111 lines)? n $ virsh allocpages <TAB> --add --all --cellno --pagecount --pagesize $ virsh start <TAB> f23-test fedora-24-beta rhel-7-server $ virsh stop <TAB> f24-test rhel-6-server ubuntu-16.04 $ There's also support for the -c/--connect flag and selective completion support for the following (domains seen as an example above): + domains + interfaces + networks + devices + nwfilters + pools + secrets + snapshots + volumes Supported commands are: virsh virt-admin virt-host-validate virt-pki-validate virt-xml-validate Since virt-admin requires root/sudo, there are some additional security checks in zsh upstream to enable sudo for completions only by request. This will require the next zsh release. I've uploaded a version of these completions which uses sudo unconditionally to my fedorapeople.org page and it can be used by the adventurous already today (by placing it under /usr/share/zsh/*/functions/): https://myllynen.fedorapeople.org/_libvirt Cheers, -- Marko Myllynen

3 2

[libvirt] [PATCH v3 0/4] Combine various query-block json call paths
by John Ferlan 05 Oct '16

05 Oct '16

I'm not unreasonable ;-) - making the suggested alterations from the review and NACK of v2/v1 which combined the for loops as well. v2: http://www.redhat.com/archives/libvir-list/2016-September/msg01483.html Changes - new patch 1, 3, 4 Alteration to patch 1 of previous series to use the new Steal API John Ferlan (4): util: Introduce virJSONValueObjectStealArray qemu: Create common code for JSON "query-block" call qemu: Create helper qemuMonitorJSONGetBlockDev qemu: Create helper qemuMonitorJSONGetBlockDevDevice src/libvirt_private.syms | 1 + src/qemu/qemu_monitor_json.c | 157 ++++++++++++++++++++++--------------------- src/util/virjson.c | 43 ++++++++++++ src/util/virjson.h | 2 + 4 files changed, 125 insertions(+), 78 deletions(-) -- 2.7.4

2 10

[libvirt] [PATCH RESEND v2 0/5] Implementation of QEMU vhost-scsi
by Eric Farman 05 Oct '16

05 Oct '16

[Resending after the release of 2.2.0; no changes other than a rebase to current master and the associated tweaking to the capabilities patch] This patch series provides a libvirt implementation of the vhost-scsi interface in QEMU. As near as I can see, this was discussed upstream in July 2014[1], and ended in a desire to replace a vhost-scsi controller in favor of a hostdev element instead[2]. There is no capability check in this series for vhost-scsi in the underlying QEMU. Using a recent QEMU built with --disable-vhost-scsi fails with "not a valid device model name." Host Filesystem Example: # ls /sys/kernel/config/target/vhost/ discovery_auth naa.5001405df3e54061 version # ls /sys/kernel/config/target/vhost/naa.5001405df3e54061/tpgt_1/lun/ lun_0 QEMU Example (snippet): -device vhost-scsi-ccw,wwpn=naa.5001405df3e54061,devno=fe.0.1000 Libvirt Example (snippet): <hostdev mode='subsystem' type='scsi_host'> <source protocol='vhost' wwpn='naa.5001405df3e54061'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x1000'/> </hostdev> Guest Viewpoint: # lsscsi [1:0:1:0] disk LIO-ORG disk0 4.0 /dev/sda # dmesg | grep 1: [ 6.065735] scsi host1: Virtio SCSI HBA [ 6.093892] scsi 1:0:1:0: Direct-Access LIO-ORG disk0 4.0 PQ: 0 ANSI: 5 [ 6.313615] sd 1:0:1:0: Attached scsi generic sg0 type 0 [ 6.314981] sd 1:0:1:0: [sda] 29360128 512-byte logical blocks: (15.0 GB/14.0 GiB) [ 6.317290] sd 1:0:1:0: [sda] Write Protect is off [ 6.317566] sd 1:0:1:0: [sda] Mode Sense: 43 00 10 08 [ 6.317853] sd 1:0:1:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 6.352722] sd 1:0:1:0: [sda] Attached SCSI disk Changelog: v2->v2.1: - Rebased to current master (6 September) v1->v2: https://www.redhat.com/archives/libvir-list/2016-August/msg01028.html - Rebase - Applies to current master (20 August) - Added a capability check for QEMU 2.7 - Fixed the qemuxml2argv tests as the -smp options had changed - Reworked ccwaddrs parameter in virDomainCCWAddressAssign call - Comments - Squashed documentation, XML schema, XML parsing, and infrastructure patches into a single patch - Switched from "hostdev type='scsi'" to "hostdev type='scsi_host'"; this removes the refactoring patches since we're not shoe-horning a new SCSI protocol into the existing code - Reworked the handling of the fd's such that we send them to qemu after any possible errors could occur and cause us to back out - s/qemuBuildSCSIVhostHostdevDevStr/qemuBuildHostHostdevDevStr/ - Added virBufferCheckError, and an error message for vhostfdSize > 1, in qemuBuildHostHostdevDevStr - Added qemuBuildDeviceAddressStr in qemuBuildHostHostdevDevStr, thus superceding the last patch in the v1 series - Other - Simplified the vhostfd logic to just be a single int, rather than an alloc'd array (left the vhostfdSize described above as an identifier for if QEMU ever supports multiple vhostfds) - Replaced "qemuMonitorAddDevice" with "qemuMonitorAddDeviceWithFd" in hotplug routine v1: https://www.redhat.com/archives/libvir-list/2016-July/msg01004.html [1] http://www.redhat.com/archives/libvir-list/2014-July/msg01235.html [2] http://www.redhat.com/archives/libvir-list/2014-July/msg01390.html Eric Farman (5): Introduce a "scsi_host" hostdev type qemu: Introduce vhost-scsi capability qemu: Add vhost-scsi string for -device parameter qemu: Allow hotplug of vhost-scsi device tests: Introduce basic vhost-scsi test docs/formatdomain.html.in | 24 ++++ docs/schemas/domaincommon.rng | 23 ++++ src/conf/domain_audit.c | 2 + src/conf/domain_conf.c | 62 ++++++++- src/conf/domain_conf.h | 17 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 3 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 80 +++++++++++ src/qemu/qemu_command.h | 6 + src/qemu/qemu_domain_address.c | 10 ++ src/qemu/qemu_hotplug.c | 149 +++++++++++++++++++++ src/security/security_dac.c | 2 + src/util/virscsi.c | 26 ++++ src/util/virscsi.h | 1 + tests/domaincapsschemadata/full.xml | 1 + tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 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 + .../qemuxml2argv-hostdev-scsi-vhost-scsi.args | 24 ++++ .../qemuxml2argv-hostdev-scsi-vhost-scsi.xml | 33 +++++ tests/qemuxml2argvmock.c | 12 ++ tests/qemuxml2argvtest.c | 3 + 31 files changed, 491 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi.xml -- 1.9.1

2 18

[libvirt] [PATCH 0/3] Cleanup/unify RBD backend context setup
by John Ferlan 05 Oct '16

05 Oct '16

While working on a way to create a luks volume on an RBD backend - I figured I'd clean up the initialization of the environment a bit. Rather than a lot of copy/paste code - use a common initializer. John Ferlan (3): rbd: Change virStorageBackendRBDCloseRADOSConn to be static void rbd: Change from static to alloc contexts rbd: Move the encryption check in build src/storage/storage_backend_rbd.c | 150 +++++++++++++++++++------------------- 1 file changed, 73 insertions(+), 77 deletions(-) -- 2.7.4

2 6

[libvirt] [PATCH 0/2] Add support for preallocated fd memory
by Jaroslav Safka 05 Oct '16

05 Oct '16

Hi the xml element to be extended with additional children is the memoryBacking element. We would like to introduce 3 new elements source,access and allocation <memoryBacking> <source type="file|anonymous" path='/path/to/qemu/'/> <access Mode="shared|private"/> <allocation mode="immediate|ondemand"/> </memoryBacking> If allocation is immediate then -mem-prealloc should be added to the qemu commanline. If source is file then -object memory-backend-file,id=mem,size=1024M,mem-path=/var/lib/libvirt/qemu -numa node,memdev=mem Should be added to the qemu commandline If access is shared then the share=on parameter should be added to the memory-backend-file e.g. -object memory-backend-file,id=mem,size=1024M,mem-path=/var/lib/libvirt/qemu,share=on Jaroslav Safka (2): Add support for preallocated fd memory Add support for preallocated fd memory docs/schemas/domaincommon.rng | 37 +++++ src/conf/domain_conf.c | 149 +++++++++++++++----- src/conf/domain_conf.h | 34 +++++ src/qemu/qemu_command.c | 156 ++++++++++++++++----- src/qemu/qemu_command.h | 4 + .../qemuxml2argv-fd-memory-no-numa-topology.args | 34 +++++ .../qemuxml2argv-fd-memory-no-numa-topology.xml | 96 +++++++++++++ .../qemuxml2argv-fd-memory-numa-topology.args | 34 +++++ .../qemuxml2argv-fd-memory-numa-topology.xml | 99 +++++++++++++ .../qemuxml2argv-memorybacking-set.xml | 32 +++++ .../qemuxml2argv-memorybacking-unset.xml | 32 +++++ tests/qemuxml2argvtest.c | 24 ++++ .../qemuxml2xmlout-memorybacking-set.xml | 40 ++++++ .../qemuxml2xmlout-memorybacking-unset.xml | 40 ++++++ tests/qemuxml2xmltest.c | 3 + 15 files changed, 748 insertions(+), 66 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-fd-memory-no-numa-topology.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-fd-memory-no-numa-topology.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-fd-memory-numa-topology.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-fd-memory-numa-topology.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memorybacking-set.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memorybacking-unset.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-memorybacking-set.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-memorybacking-unset.xml -- 2.5.5 -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

4 5

[libvirt] 2 major proposals to enhance libvirt and its attractivity among developers & users
by jean-christophe Manciot 05 Oct '16

05 Oct '16

Hello everyone. Going straight to the point: 1) *add connection type: Docker* This should not induce a lot of development since there is already an LXC connection type. 2) add the ability to *choose the bridge type of any virtual network*: - Linux bridge + VPP : Cisco has recently open-sourced the virtual switch/router <https://wiki.fd.io/view/VPP/What_is_VPP%3F> which it uses with DPDK as a core part of some of its commercial virtual products. Its performance should be unprecedented as compared to the current Linux bridge or even OvS. "VPP is also applicable to many architectures (x86, ARM, and PowerPC) and deployment environments (bare metal, VM, container)", according to Simon Dredge in FD.io Takes Over VPP and Unites with DPDK to Accelerate NFV Data Planes to Outright Nutty Speeds <http://www.metaswitch.com/the-switch/fd.io-takes-over-vpp>. + OvS: not a priority IMHO. Regards. -- *Jean-Christophe Manciot* *[image: Architecte réseaux et Sécurité] <https://learningnetwork.cisco.com/people/manciot.jeanchristophe/content> *[image: Network & Security Architect] <https://fr.linkedin.com/in/jeanchristophemanciot/en> <https://twitter.com/jc_manciot> <https://plus.google.com/u/0/+jeanchristopheManciot-IT/posts>

2 2