- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] qemu: Add support for host-model pseries machine option
by Fabiano Rosas 10 Oct '19

10 Oct '19

This series adds support for the -machine,host-model= QEMU option for for pseries guests. Pseries guests used to have a node (/proc/device-tree/host-model) in device-tree that exposed the host's model string so that guest userspace tools could determine the host machine they were running on. QEMU used to provide the node by default, but this has been disabled due to security concerns. There is now a machine option (host-model) that allows the user to set an arbitrary string to be used as the host model. Userspace tools will then be broken unless the user explicitly edits the domain XML with the desired host model to be exposed to the guest. However, having an arbitrary string in the domain XML that needs to be the same for every guest in that machine but different across host machines would generate issues with XML portability and more importantly, migration. So this series implements a generic way for an administrator to enable the old behavior for a specific guest without allowing arbitrary strings. Implementation note: The 'host-serial' property, which reads /proc/device-tree/system-id in the host and was also addressed by the QEMU change could be implemented similarly in the future. However I see that we're currently populating smbios structures (virSysinfoDef) with info gathered from /proc/cpuinfo for architectures that do not use smbios and I think that should be addressed first. My idea is to perhaps create new sysinfo types like the existing 'smbios', such as 'cpuinfo' and 'device-tree'. So to keep the two discussions separated I took advantage of the fact that the host model happens to also be present at /proc/cpuinfo and used the smbios structures for now. Fabiano Rosas (2): qemu: Add capability for pseries machine 'host-model' parameter qemu: Add support for pseries 'host-model' machine parameter docs/formatdomain.html.in | 9 ++++++ docs/schemas/domaincommon.rng | 5 ++++ src/conf/domain_conf.c | 4 +++ src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 25 ++++++++++++++-- src/qemu/qemu_domain.c | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + tests/qemuxml2argvdata/pseries-features.args | 3 +- tests/qemuxml2argvdata/pseries-features.xml | 1 + tests/qemuxml2argvtest.c | 30 ++++++++++++++++++- tests/qemuxml2xmloutdata/pseries-features.xml | 1 + 13 files changed, 79 insertions(+), 5 deletions(-) -- 2.20.1

2 7

[libvirt] [PATCH 0/2] qemu: Fix @vm locking issue when connecting to the monitor
by Michal Privoznik 10 Oct '19

10 Oct '19

See 1/2 for explanation. Michal Prívozník (2): qemu: Fix @vm locking issue when connecting to the monitor Revert "qemu: Obtain reference on monConfig" src/qemu/qemu_monitor.c | 33 +++++++++++++++++++++++++-------- src/qemu/qemu_process.c | 17 +---------------- tests/qemumonitortestutils.c | 2 ++ 3 files changed, 28 insertions(+), 24 deletions(-) -- 2.21.0

3 6

[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 10 Oct '19

10 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 10 Oct '19

10 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