- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: Don't fail if physical size can't be updated in qemuDomainGetBlockInfo
by Peter Krempa 27 Apr '17

27 Apr '17

Since commit c5f6151390 qemuDomainBlockInfo tries to update the "physical" storage size for all network storage and not only block devices. Since the storage driver APIs to do this are not implemented for certain storage types (RBD, iSCSI, ...) the code would fail to retrieve any data since the failure of qemuDomainStorageUpdatePhysical is fatal. Since it's desired to return data even if the total size can't be updated we need to ignore errors from that fucntion and return plausible data. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442344 --- Notes: This function will require more fixing though. This is just a bandaid to remove the regression. I'll post other patches as follow up later. src/qemu/qemu_driver.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e39de625d..8ff242597 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -11553,10 +11553,12 @@ qemuDomainGetBlockInfo(virDomainPtr dom, if (info->allocation == 0) info->allocation = entry->physical; - if (qemuDomainStorageUpdatePhysical(driver, cfg, vm, disk->src) < 0) - goto endjob; - - info->physical = disk->src->physical; + if (qemuDomainStorageUpdatePhysical(driver, cfg, vm, disk->src) == 0) { + info->physical = disk->src->physical; + } else { + virResetLastError(); + info->physical = entry->physical; + } } else { info->physical = entry->physical; } -- 2.12.2

2 2

[libvirt] [PATCH 00/14] network schema refactor and addition of cookies for http disks
by Peter Krempa 27 Apr '17

27 Apr '17

Peter Krempa (14): docs: schemas: Remove <interleave> from file/block/dir/volume disks docs: schemas: Extract disk source host specification docs: schemas: Move the interleave definition into network disk source docs: schemas: Extract RBD-specific data docs: schemas: Extract HTTP disk source specification docs: schemas: Split out simple network protocols docs: schemas: Split up definitions for NBD and gluster conf: Extract formatting of network disk source into separate function tests: genericxml2xml: Add test case for HTTP based disk util: string: Introduce virStringHasChars conf: Add support for cookies for HTTP based disks qemu: command: Use switch to formatting additional network disk params qemu: capabilities: Add capability for the new curl driver options qemu: command: Add support for HTTP cookies docs/formatdomain.html.in | 9 + docs/schemas/domaincommon.rng | 316 +++++++++++++-------- src/conf/domain_conf.c | 205 ++++++++++--- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 48 +++- src/util/virstoragefile.c | 124 ++++++++ src/util/virstoragefile.h | 14 + src/util/virstring.c | 23 +- src/util/virstring.h | 2 + .../generic-disk-network-http.xml | 48 ++++ tests/genericxml2xmltest.c | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + .../qemuxml2argv-disk-drive-network-http.args | 32 +++ .../qemuxml2argv-disk-drive-network-http.xml | 48 ++++ tests/qemuxml2argvtest.c | 1 + 16 files changed, 701 insertions(+), 174 deletions(-) create mode 100644 tests/genericxml2xmlindata/generic-disk-network-http.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-http.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-http.xml -- 2.12.2

3 31

[libvirt] [PATCH 0/3] qemu: Allow turing of SSL verification for https/ftps drives
by Peter Krempa 27 Apr '17

27 Apr '17

This is a followup to the qemu cookie series and should be applied on top of it. Since I already fixed a few things in the original series this would not apply cleanly, thus you can fetch it at: git fetch git://pipo.sk/pipo/libvirt.git qemu-ssl-verify-off Peter Krempa (3): conf: Use only one temporary string in virDomainDiskSourceParse conf: Add support for modifying ssl validation for https/ftps disks qemu: command: Implement ssl verification configuration docs/formatdomain.html.in | 9 ++++ docs/schemas/domaincommon.rng | 50 +++++++++++++++++++++- src/conf/domain_conf.c | 34 ++++++++++++--- src/qemu/qemu_command.c | 27 +++++++++++- src/util/virstoragefile.h | 1 + .../generic-disk-network-http.xml | 2 + .../qemuxml2argv-disk-drive-network-http.args | 2 +- .../qemuxml2argv-disk-drive-network-http.xml | 1 + 8 files changed, 114 insertions(+), 12 deletions(-) -- 2.12.2

1 3

[libvirt] [PATCH 0/3] add support for qemu-xhci USB controller
by Pavel Hrdina 27 Apr '17

27 Apr '17

Pavel Hrdina (3): qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI qemu: add support for qemu-xhci USB controller qemu: use qemu-xhci USB controller by default for ppc64 and aarch64 docs/formatdomain.html.in | 2 +- docs/schemas/domaincommon.rng | 1 + src/conf/domain_addr.c | 1 + src/conf/domain_conf.c | 1 + src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 8 +++++-- src/qemu/qemu_domain.c | 25 ++++++++++++++------ src/qemu/qemu_domain_address.c | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + ...uxml2argv-aarch64-usb-controller-qemu-xhci.args | 20 ++++++++++++++++ ...muxml2argv-aarch64-usb-controller-qemu-xhci.xml | 27 ++++++++++++++++++++++ ...emuxml2argv-ppc64-usb-controller-qemu-xhci.args | 19 +++++++++++++++ ...qemuxml2argv-ppc64-usb-controller-qemu-xhci.xml | 1 + ...qemuxml2argv-usb-controller-qemu-xhci-limit.xml | 15 ++++++++++++ ...l2argv-usb-controller-qemu-xhci-unavailable.xml | 15 ++++++++++++ .../qemuxml2argv-usb-controller-qemu-xhci.args | 19 +++++++++++++++ .../qemuxml2argv-usb-controller-qemu-xhci.xml | 15 ++++++++++++ tests/qemuxml2argvtest.c | 12 ++++++++++ 20 files changed, 177 insertions(+), 10 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-usb-controller-qemu-xhci.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-usb-controller-qemu-xhci.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppc64-usb-controller-qemu-xhci.args create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-ppc64-usb-controller-qemu-xhci.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci-limit.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci-unavailable.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-qemu-xhci.xml -- 2.12.2

4 14

[libvirt] [PATCH 0/2] Report VIR_DOMAIN_JOB_OPERATION in job stats
by Jiri Denemark 27 Apr '17

27 Apr '17

As agreed in [1] we should enhance job statistics returned by virDomainGetJobStats API and VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event with a new typed parameter which would indicate what operation (migration, snapshot, ...) the reported statistics belong to. https://bugzilla.redhat.com/show_bug.cgi?id=1441563 [1] https://www.redhat.com/archives/libvir-list/2017-April/msg00540.html Jiri Denemark (2): Add VIR_DOMAIN_JOB_OPERATION typed parameter qemu: Report VIR_DOMAIN_JOB_OPERATION include/libvirt/libvirt-domain.h | 25 +++++++++++++++++++++++++ src/qemu/qemu_domain.c | 16 +++++++++++++--- src/qemu/qemu_domain.h | 4 +++- src/qemu/qemu_driver.c | 32 ++++++++++++++++++++++---------- src/qemu/qemu_migration.c | 19 ++++++++++++------- src/qemu/qemu_process.c | 6 ++++-- src/qemu/qemu_process.h | 3 ++- tools/virsh-domain.c | 29 +++++++++++++++++++++++++++++ 8 files changed, 110 insertions(+), 24 deletions(-) -- 2.12.2

2 4

[libvirt] [PATCH 0/2] don't kill qemu process on restart if networkNotify fails
by Laine Stump 27 Apr '17

27 Apr '17

The individual patches explain themselves. Laine Stump (2): qemu: don't kill qemu process on restart if networkNotify fails network: better log message when network is inactive during reconnect src/network/bridge_driver.c | 7 +++++++ src/qemu/qemu_process.c | 9 +++------ 2 files changed, 10 insertions(+), 6 deletions(-) -- 2.9.3

2 8

[libvirt] [PATCH 0/4] Couple of trivial c89 style fixes
by Michal Privoznik 27 Apr '17

27 Apr '17

*** BLURB HERE *** BLURB Michal Privoznik (4): examples: Properly include getopt.h vmwarevertest: drop VIR_FROM_THIS definition lib: Fix c99 style comments cpu: Avoid c99 style of assembler examples/admin/logging.c | 14 +++++++------- examples/openauth/openauth.c | 2 +- src/cpu/cpu_ppc64.c | 4 ++-- src/cpu/cpu_x86.c | 44 +++++++++++++++++++++---------------------- src/lxc/lxc_controller.c | 2 +- src/remote/remote_driver.c | 2 +- src/rpc/virnetservermdns.c | 2 +- src/security/security_stack.c | 8 ++++---- src/uml/uml_conf.c | 2 +- src/util/virhostcpu.c | 4 ++-- src/util/virhostmem.c | 4 ++-- src/vbox/vbox_snapshot_conf.c | 2 +- tests/eventtest.c | 2 +- tests/virhostcpumock.c | 2 +- tests/vmwarevertest.c | 2 -- 15 files changed, 47 insertions(+), 49 deletions(-) -- 2.10.2

3 14

[libvirt] [PATCH v2 0/3] Cleanup messages after hotplug of scsi hostdev
by Eric Farman 27 Apr '17

27 Apr '17

v1 was here: https://www.redhat.com/archives/libvir-list/2017-April/msg01066.html Per review, removed the "internal error" messages and split the resulting patch into patches 2 (virtio-scsi) and 3 (vhost-scsi). Patch 1 fixes a return code check that is a little off. Eric Farman (3): qemu: Check return code from qemuHostdevPrepareSCSIDevices qemu: Remove extra messages from virtio-scsi hotplug qemu: Remove extra messages for vhost-scsi hotplug src/qemu/qemu_hotplug.c | 24 ++---------------------- 1 file changed, 2 insertions(+), 22 deletions(-) -- 1.9.1

2 4

[libvirt] [PATCH 0/2] qemu: migration: bugfixes for cancelling drive mirror
by Nikolay Shirokovskiy 27 Apr '17

27 Apr '17

Nikolay Shirokovskiy (2): qemu: take current async job into account in qemuBlockNodeNamesDetect qemu: migration: fix race on cancelling drive mirror src/qemu/qemu_block.c | 6 ++++-- src/qemu/qemu_block.h | 4 +++- src/qemu/qemu_blockjob.c | 9 ++++++--- src/qemu/qemu_blockjob.h | 4 ++++ src/qemu/qemu_driver.c | 11 ++++++----- src/qemu/qemu_migration.c | 43 +++++++++++++++++++++++++++++++------------ src/qemu/qemu_process.c | 2 +- 7 files changed, 55 insertions(+), 24 deletions(-) -- 1.8.3.1

2 5

Re: [libvirt] [PATCH v3] Add support for Veritas HyperScale (VxHS) block device protocol
by ashish mittal 27 Apr '17

27 Apr '17

Hi, I'm trying to figure out what changes are needed in the libvirt vxhs patch to support passing TLS X509 arguments to qemu, similar to the following - Sample QEMU command line passing TLS credentials to the VxHS block device (run in secure mode): ./qemu-io --object tls-creds-x509,id=tls0,dir=/etc/pki/qemu/vxhs,endpoint=client -c 'read -v 66000 2.5k' 'json:{"server.host": "127.0.0.1", "server.port": "9999", "vdisk-id": "/test.raw", "driver": "vxhs", "tls-creds":"tls0"}' I was hoping to find some NBD code related to this, but not able to locate it. Any pointers will be appreciated. Thanks, Ashish On Wed, Feb 1, 2017 at 8:36 AM, John Ferlan <jferlan(a)redhat.com> wrote: > [...] > Pressed send too soon, sigh. > > >>>> >>>> #1. Based on Peter's v2 comments, we don't want to support the >>>> older/legacy syntax for VxHS, so it's something that should be removed - >>>> although we should check for it being present and fail if found. >>>> >>> >>> I am testing with changed code to return error if legacy syntax is >>> found for VxHS. Also added a test case to check for failure on legacy >>> syntax and it seems to pass (test #41 below). >>> >>> Then I added a pass test case to check conversion from new native >>> syntax to XML (test #40 below). That test fails with error >>> 'qemuParseCommandLineDisk:901 : internal error: missing file parameter >>> in drive 'file.driver=vxhs,file.vdisk-id=eb90327c-8302-4725-9e1b...' >> >> The qemu_parse_command.c changes while nice to have weren't even updated >> when multiple gluster servers were added (e.g. commit id '' or '7b7da9e28') >> Check the changes to add the new s >> >> IOW: This code knows how to parse something like: >> >> -drive >> 'file=gluster+unix:///Volume2/Image?socket=/path/to/sock,format=raw,if=none,id=drive-virtio-disk1' >> >> but it's clueless for: >> >> -drive file.driver=gluster,file.volume=Volume3,file.path=/Image.qcow2,\ >> file.server.0.type=tcp,file.server.0.host=example.org,file.server.0.port=6000,\ >> file.server.1.type=tcp,file.server.1.host=example.org,file.server.1.port=24007,\ >> file.server.2.type=unix,file.server.2.socket=/path/to/sock,format=qcow2,\ >> if=none,id=drive-virtio-disk2 \ >> -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk2,\ >> id=virtio-disk2 >> >> See >>> >>> Looks like none of the existing tests in qemuargv2xmltest test for the >>> parsing of new syntax, and qemuParseCommandLineDisk() expects to find >>> 'file=' for a drive or it errors out. If this is true, will it be able >>> to parse the new syntax? Some help here please! > > So I wouldn't expect the VxHS code to be able to do that unless you > wanted to be adventurous. The good news is that this code is primarily > for developers that need to take a qemu command line to generate the > libvirt syntax. It has not really been kept up to date with all the most > recent command line changes. I started to try over a year ago, but got > very side tracked. > >>> >>> Output from the newly added test cases (40 should pass and 41 checks >>> for error) : >>> >>> 40) QEMU ARGV-2-XML disk-drive-network-vxhs >>> ... Got unexpected warning from qemuParseCommandLineString: >>> 2017-01-28 00:57:30.814+0000: 10391: info : libvirt version: 3.0.0 >>> 2017-01-28 00:57:30.814+0000: 10391: info : hostname: localhost.localdomain >>> 2017-01-28 00:57:30.814+0000: 10391: error : >>> qemuParseCommandLineDisk:901 : internal error: missing file parameter >>> in drive 'file.driver=vxhs,file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,file.server.host=192.168.0.1,file.server.port=9999,format=raw,if=none,id=drive-virtio-disk0,cache=none' >>> libvirt: QEMU Driver error : internal error: missing file parameter in >>> drive 'file.driver=vxhs,file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,file.server.host=192.168.0.1,file.server.port=9999,format=raw,if=none,id=drive-virtio-disk0,cache=none' >>> FAILED >>> >>> 41) QEMU ARGV-2-XML disk-drive-network-vxhs-fail >>> ... Got expected error from qemuParseCommandLineString: >>> libvirt: QEMU Driver error : internal error: VxHS protocol does not >>> support URI syntax >>> 'vxhs://192.168.0.1:9999/eb90327c-8302-4725-9e1b-4e85ed4dc251' >>> OK >>> 42) QEMU ARGV-2-XML disk-usb ... OK >>> >>> >>> >>>> #2. Is the desire to ever support more than 1 host? If not, then is the >>>> "server" syntax you've borrowed from the Gluster code necessary? Could >>>> you just go with the single "host" like NBD and SSH. As it relates to >>>> the qemu command line - I'm not quite as clear. From the example I see >>>> in commit id '7b7da9e28', the gluster syntax would have: >>>> >>> >>> Present understanding is to have only one host. You are right, the >>> "server" part is not necessary. Will have to check with the qemu >>> community on this change. >>> >>>> +file.server.0.type=tcp,file.server.0.host=example.org,file.server.0.port=6000,\ >>>> +file.server.1.type=tcp,file.server.1.host=example.org,file.server.1.port=24007,\ >>>> +file.server.2.type=unix,file.server.2.socket=/path/to/sock,format=qcow2,\ >>>> >>>> whereas, the VxHS syntax is: >>>> +file.server.host=192.168.0.1,file.server.port=9999,format=raw,if=none,\ >>>> >>>> FWIW: I also note there is no ".type=tcp" in your output - so perhaps >>>> the "default" is tcp unless otherwise specified, but I'm sure of the >>>> qemu syntax requirements in this area. I assume that since there's only >>>> 1 server, the ".0, .1, .2" become unnecessary (something added by commit >>>> id 'f1bbc7df4' for multiple gluster hosts). >>>> >>> >>> That's correct. TCP is the default. >>> >>>> I haven't closedly followed the qemu syntax discussion, but it would it >>>> would be possible to use: >>>> >>>> +file.host=192.168.0.1,file.port=9999 >>>> >>> >>> That is correct. Above syntax would also work for us. I will pose this >>> suggestion to the qemu community and update with their response. >>> > > It's not that important... I was looking for a simplification and > generation of only what's required. You can continue using the server > syntax - perhaps just leave a note/comment in the code indicating the > decision point and move on. > > [...] > > John

2 11