October 2019 - Devel - libvirt List Archives

[libvirt] [PATCH] qemu_process: Initialize domain definition for QMP query
by Michal Privoznik 10 Oct '19

10 Oct '19

When constructing QMP capabilities we allocate a dummy domain object to pass to qemuMonitorOpen(). However, after 75dd595861 the function also expects domain definition to be allocated for the domain object. The referenced commit already fixed qemumonitortestutils.c but forgot to fix the other caller: qemuProcessQMPConnectMonitor(). Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under trivial rule. src/qemu/qemu_process.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index ca2a5cab5b..c14c09da11 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8654,7 +8654,8 @@ qemuProcessQMPConnectMonitor(qemuProcessQMPPtr proc) monConfig.data.nix.listen = false; if (!(xmlopt = virDomainXMLOptionNew(NULL, NULL, NULL, NULL, NULL)) || - !(proc->vm = virDomainObjNew(xmlopt))) + !(proc->vm = virDomainObjNew(xmlopt)) || + !(proc->vm->def = virDomainDefNew())) goto cleanup; proc->vm->pid = proc->pid; -- 2.21.0

1 0

[libvirt] [PATCH v2 0/1] IDE: Deprecate ide-drive
by John Snow 10 Oct '19

10 Oct '19

V2: Change phrasings and spellings as Markus suggested. John Snow (1): IDE: deprecate ide-drive qemu-deprecated.texi | 5 +++++ hw/ide/qdev.c | 3 +++ tests/qemu-iotests/051.pc.out | 6 ++++-- 3 files changed, 12 insertions(+), 2 deletions(-) -- 2.21.0

3 3

[libvirt] Limiting old version back compat for language bindings ?
by Daniel P. Berrangé 10 Oct '19

10 Oct '19

In at least the Python and Go bindings for libvirt we use conditional compilation to allow the bindings to be build against old versions of libvirt. For Python this goes back to 0.9.11, from Apr 2012 For Go this goes back to 1.2.0, from Dec 2013 I'm wondering whether it would be worthwhile to define some rule to set a historical maximum, beyond which we will drop conditional compilation, or whether we're ok letting it grow without bound. The conditional compilation of code has some maint cost, but the cost is not huge, so I don't think this is something we need to be too aggressive on. At the same time I'm sceptical anyone is using latest Python bindings with libvirt 0.9.11, or latest Go bindings with libvirt 1.2.0 The challenge with language bindings is that users will often not use the language binding provided by the host OS vendor, instead preferring to download & build themselves. IOW, the host OS can have libvirt 3.0.0, but the app will be blindly pulling latest python binding (4.8.0) from PyPI and expect it to work. Of course if they're on an old distro, they could just pull an older version of the binding. Having to write code to download different version of the binding code on each OS is costly though, and indeed not even supported by common build tools. eg in python requirements.txt you can allow it to pick the latest version, or you can set an explicit version. The problem comes if you want to build on an OS with version 3.0.0, but also want to be able to use APIs from 4.0.0 if its available. AFAIK, you can't express this with distutils/setuptools. The same issue arises with the way you express deps in Go modules. You can ask for a specific version, but can't say to use a different version on certain OS. The key question is thus how far back applications should reasonably expect us to support language bindings. LTS distros live for quite a long time & its not unreasonable for apps to target them. In RHEL we've tended to rebase libvirt frequently while that RHEL version was the latest. That means we have RHEL-6 - 0.10.2 RHEL-7 - 4.5.0 RHEL-8 - 4.5.0 Considering Ubuntu LTS which doesn't rebase we have Trusty 14.04 - 1.2.2 Xenial 16.04 - 1.3.1 Bionic 18.04 - 4.0.0 Given this is only low/moderate maint cost, I'm tempted to be quite generous to applications and say that in January each year, we purge support for versions older than 5 years. This would imply... - Jan 2020 - purge older than 1.2.12 (Jan 2015) (Drops Trusty) - Jan 2021 - purge older than 1.3.1 (Jan 2016) - Jan 2022 - purge older than 3.0.0 (Jan 2017) (Drops Xenial) - Jan 2023 - purge older than 4.0.0 (Jan 2018) - Jan 2024 - purge older than 5.0.0 (Jan 2019) (drops RHEL-7, Bionic) - Jan 2025 - purge older than 6.0.0 (Jan 2020) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

2 5

[libvirt] [PATCH v3 00/12] hostdev: handle usb detach/attach on node
by Nikolay Shirokovskiy 10 Oct '19

10 Oct '19

Diff to v2[1] version: - add 'replug' attribute for hostdev element to allow replug semantics - avoid accuiring domain lock in event loop thread on udev events as suggested by Peter - nit picks after review by Daniel Henrique Barboza * is used to mark patches that were 'Reviewed-by' by Daniel (sometimes with very minor changes to take into account new replug flag). [1] https://www.redhat.com/archives/libvir-list/2019-September/msg00321.html Nikolay Shirokovskiy (12): conf: add replug option for usb hostdev qemu: track hostdev delete intention qemu: support host usb device unplug * qemu: support usb hostdev plugging back * qemu: handle host usb device add/del udev events qemu: handle libvirtd restart after host usb device unplug * qemu: handle race on device deletion and usb host device plugging * qemu: hotplug: update device list on device deleted event qemu: handle host usb device plug/unplug when libvirtd is down * qemu: don't mess with non mandatory hostdevs on reattaching * qemu: handle detaching of unplugged hostdev conf: parse hostdev missing flag * docs/formatdomain.html.in | 10 +- docs/schemas/domaincommon.rng | 5 + src/conf/domain_conf.c | 62 +++ src/conf/domain_conf.h | 17 + src/qemu/Makefile.inc.am | 2 + src/qemu/qemu_conf.h | 3 + src/qemu/qemu_domain.c | 2 + src/qemu/qemu_domain.h | 2 + src/qemu/qemu_driver.c | 404 +++++++++++++++++- src/qemu/qemu_hotplug.c | 104 ++++- src/qemu/qemu_hotplug.h | 3 +- src/qemu/qemu_process.c | 60 +++ src/util/virhostdev.c | 2 + tests/qemuhotplugtest.c | 2 +- tests/qemuxml2argvdata/hostdev-usb-replug.xml | 36 ++ .../qemuxml2xmloutdata/hostdev-usb-replug.xml | 40 ++ tests/qemuxml2xmltest.c | 1 + 17 files changed, 733 insertions(+), 22 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-usb-replug.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-usb-replug.xml -- 2.23.0

2 15

[libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci
by Li Feng 09 Oct '19

09 Oct '19

Hi Guys, And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support for libvirt. The usage in qemu like this: Vhost-SCSI -chardev socket,id=char0,path=/var/tmp/vhost.0 -device vhost-user-scsi-pci,id=scsi0,chardev=char0 Vhost-BLK -chardev socket,id=char1,path=/var/tmp/vhost.1 -device vhost-user-blk-pci,id=blk0,chardev=char1 What type should I add for libvirt. Type1: <hostdev mode='subsystem' type='vhost-user'> <source protocol='vhost-user-scsi' path='/tmp/vhost-scsi.sock'></source> <alias name="vhost-user-scsi-disk1"/> </hostdev> Type2: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source protocol='vhost-user' path='/tmp/vhost-scsi.sock'> </source> <target dev='sdb' bus='vhost-user-scsi'/> <boot order='3'/> <alias name='scsi0-0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source protocol='vhost-user' path='/tmp/vhost-blk.sock'> </source> <target dev='vda' bus='vhost-user-blk'/> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> Could anyone give some suggestions? Thanks, Feng Li -- The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. 本邮箱为北京志凌海纳科技有限公司（SmartX）工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.

2 1

[libvirt] [PATCH 0/1] IDE: Deprecate ide-drive
by John Snow 09 Oct '19

09 Oct '19

John Snow (1): IDE: deprecate ide-drive qemu-deprecated.texi | 5 +++++ hw/ide/qdev.c | 3 +++ tests/qemu-iotests/051.pc.out | 6 ++++-- 3 files changed, 12 insertions(+), 2 deletions(-) -- 2.21.0

3 6

[libvirt] [PATCH v3] dirty-bitmaps: remove deprecated autoload parameter
by John Snow 09 Oct '19

09 Oct '19

This parameter has been deprecated since 2.12.0 and is eligible for removal. Remove this parameter as it is actually completely ignored; let's not give false hope. Signed-off-by: John Snow <jsnow(a)redhat.com> Reviewed-by: Eric Blake <eblake(a)redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)virtuozzo.com> --- V2: Change 2.12.0 -> 4.2.0 in removed section. Adjust phrasing to match. qemu-deprecated.texi | 20 +++++++++++++++----- qapi/block-core.json | 6 +----- blockdev.c | 6 ------ 3 files changed, 16 insertions(+), 16 deletions(-) diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 01245e0b1c..7239e0959d 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -149,11 +149,6 @@ QEMU 4.1 has three options, please migrate to one of these three: @section QEMU Machine Protocol (QMP) commands -@subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) - -"autoload" parameter is now ignored. All bitmaps are automatically loaded -from qcow2 images. - @subsection query-block result field dirty-bitmaps[i].status (since 4.0) The ``status'' field of the ``BlockDirtyInfo'' structure, returned by @@ -356,3 +351,18 @@ existing CPU models. Management software that needs runnability guarantees must resolve the CPU model aliases using te ``alias-of'' field returned by the ``query-cpu-definitions'' QMP command. + + +@node Recently removed features +@appendix Recently removed features + +What follows is a record of recently removed, formerly deprecated +features that serves as a record for users who have encountered +trouble after a recent upgrade. + +@section QEMU Machine Protocol (QMP) commands + +@subsection block-dirty-bitmap-add "autoload" parameter (since 4.2.0) + +The "autoload" parameter has been ignored since 2.12.0. All bitmaps +are automatically loaded from qcow2 images. diff --git a/qapi/block-core.json b/qapi/block-core.json index e6edd641f1..e4975ece4a 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -1987,10 +1987,6 @@ # Qcow2 disks support persistent bitmaps. Default is false for # block-dirty-bitmap-add. (Since: 2.10) # -# @autoload: ignored and deprecated since 2.12. -# Currently, all dirty tracking bitmaps are loaded from Qcow2 on -# open. -# # @disabled: the bitmap is created in the disabled state, which means that # it will not track drive changes. The bitmap may be enabled with # block-dirty-bitmap-enable. Default is false. (Since: 4.0) @@ -1999,7 +1995,7 @@ ## { 'struct': 'BlockDirtyBitmapAdd', 'data': { 'node': 'str', 'name': 'str', '*granularity': 'uint32', - '*persistent': 'bool', '*autoload': 'bool', '*disabled': 'bool' } } + '*persistent': 'bool', '*disabled': 'bool' } } ## # @BlockDirtyBitmapMergeSource: diff --git a/blockdev.c b/blockdev.c index fbef6845c8..93804da840 100644 --- a/blockdev.c +++ b/blockdev.c @@ -1966,7 +1966,6 @@ static void block_dirty_bitmap_add_prepare(BlkActionState *common, qmp_block_dirty_bitmap_add(action->node, action->name, action->has_granularity, action->granularity, action->has_persistent, action->persistent, - action->has_autoload, action->autoload, action->has_disabled, action->disabled, &local_err); @@ -2858,7 +2857,6 @@ out: void qmp_block_dirty_bitmap_add(const char *node, const char *name, bool has_granularity, uint32_t granularity, bool has_persistent, bool persistent, - bool has_autoload, bool autoload, bool has_disabled, bool disabled, Error **errp) { @@ -2890,10 +2888,6 @@ void qmp_block_dirty_bitmap_add(const char *node, const char *name, persistent = false; } - if (has_autoload) { - warn_report("Autoload option is deprecated and its value is ignored"); - } - if (!has_disabled) { disabled = false; } -- 2.21.0

1 1

[libvirt] [PATCH 0/1] qemu: fix type of default video device
by Pavel Mores 09 Oct '19

09 Oct '19

This patch does seem to fix the original bug as it was reported, however it also raises the broader question of how exactly to decide under various circumstances what the type of the video device we're silently adding should be. This patch is meant to be an initial suggestion to kick off discussion. If you don't like anything about it please comment. :-) Pavel Mores (1): qemu: fix type of default video device src/qemu/qemu_domain.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) -- 2.21.0

2 2

[libvirt] [PATCH] libvirt_python:fix bug of sanitytest.py script
by ossdev＠puresoftware.com 09 Oct '19

09 Oct '19

From: ossdev <ossdev(a)puresoftware.com> libvirt-python:fix bug of sanitytest.py script Signed-off-by: ossdev <ossdev(a)puresoftware.com> --- sanitytest.py | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/sanitytest.py b/sanitytest.py index e87b57d..c5d1f42 100644 --- a/sanitytest.py +++ b/sanitytest.py @@ -22,6 +22,21 @@ def get_libvirt_api_xml_path(): sys.exit(proc.returncode) return stdout.splitlines()[0] +def sanitize_enum_val(value): + if value == 'VIR_TYPED_PARAM_INT': + value = 1 + elif value == 'VIR_TYPED_PARAM_UINT': + value = 2 + elif value == 'VIR_TYPED_PARAM_LLONG': + value = 3 + elif value == 'VIR_TYPED_PARAM_ULLONG': + value = 4 + elif value == 'VIR_TYPED_PARAM_DOUBLE': + value = 5 + elif value == 'VIR_TYPED_PARAM_BOOLEAN': + value = 6 + return value + # Path to the libvirt API XML file if len(sys.argv) >= 3: xml = sys.argv[2] @@ -48,8 +63,8 @@ set = tree.xpath('/api/symbols/enum') for n in set: typ = n.attrib['type'] name = n.attrib['name'] - val = n.attrib['value'] - + #val = n.attrib['value'] + val = sanitize_enum_val(n.attrib['value']) if typ not in enumvals: enumvals[typ] = {} -- 2.17.1 -- *Disclaimer* -The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. In such instances you are further prohibited from reproducing, disclosing, distributing or taking any action in reliance on it.As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email.

2 1

[libvirt] [PATCH 1/4] qemu: validate bochs-display capability
by Jonathon Jongsma 09 Oct '19

09 Oct '19

When the bochs display type was added, the capability was never checked. Add that check in the same place as the other video device capability checks. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/qemu/qemu_process.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 955ba4de4c..b93af966e2 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5278,7 +5278,9 @@ qemuProcessStartValidateVideo(virDomainObjPtr vm, !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_GPU)) || (video->type == VIR_DOMAIN_VIDEO_TYPE_VIRTIO && video->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW && - !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW))) { + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW)) || + (video->type == VIR_DOMAIN_VIDEO_TYPE_BOCHS && + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_BOCHS_DISPLAY))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("this QEMU does not support '%s' video device"), virDomainVideoTypeToString(video->type)); -- 2.21.0

2 5