- Devel - libvirt List Archives

[libvirt] [RFC] externall (pull) backup API
by Nikolay Shirokovskiy 22 Nov '17

22 Nov '17

Table of contents. I Preface 1. Fleece API 2. Export API 3. Incremental backups 4. Other hypervisors II Links I Preface This is a RFC for external (or pull) backup API in libvirt. There was a series [1] with more limited API scope and functionality for this kind of backup API. Besides other issues the series was abandoned as qemu blockdev-del command has experimental status at that time. There is also a long pending RFC series for internal (or push) backup API [2] which however has not much in comman with this RFC. Also there is RFC with overall agreement to having a backup API in libvirt [3]. The aim of external backup API is to provide means for 3d party application to read/write domain disks as block devices for the purpuse of backup. Disk is read on backup operation and in case of active domain is presented at some point in time (preferable in some guest consistent state). Disk is written on restore operation. As to providing disk state at some point in time one can use existing disks snapshots for this purpose. However this RFC introduces API to leverage image fleecing (blockdev-backup command) instead. Image fleecing is somewhat inverse to snapshots. In case of snapshots writes go to top image thus backing image stays constant, in case of fleecing writes go to same image as before but old data is previously popped out to fleece image which have original image as backing. As a result fleece image became disk snapshot. Another task of this API is to provide disks for read/write operations. One could try to leverage libvirt stream API for this purpose but AFAIK clients want random access to disks data which is not what stream API suitable for. I'm not sure what is costs of adding block API to libvirt, particularly what it costs to make it effective implementation at RPC level thus this RFC add means to export disks data thru existing block interfaces. For qemu it is NBD. 1. Fleece API So the below API is to provide means to start/stop/query disk image fleecing. I use BlockSnaphost name for this operation. Other options are Fleecing, BlockFleecing, TempBlockSnapshot etc. /* Start fleecing */ virDomainBlockSnapshotPtr virDomainBlockSnapshotCreateXML(virDomainPtr domain, const char *xmlDesc, unsigned int flags); /* Stop fleecing */ int virDomainBlockSnapshotDelete(virDomainBlockSnapshotPtr snapshot, unsigned int flags); /* List active fleecings */ virDomainBlockSnapshotList(virDomainPtr domain, virDomainBlockSnapshotPtr **snaps, unsigned int flags); /* Get fleecing description */ char* virDomainBlockSnapshotGetXMLDesc(virDomainBlockSnapshotPtr snapshot, unsigned int flags); /* Get fleecing by name */ virDomainBlockSnapshotPtr virDomainBlockSnapshotLookupByName(virDomainPtr domain, const char *name); Here is a minimal block snapshot xml description to feed creating function: <domainblocksnapshot> <snapshot disk='sda'> <fleece file="/path/to/fleece-image-sda"/> </snapshot> <snapshot disk='sdb'> <fleece file="/path/to/fleece-image-sdb"/> </snapshot> </domainblocksnapshot> Below is an example of what getting description function should provide upon successful block snaphost creation. The difference with the above xml is that name element (it can be specified on creation as well) and aliases are generated. Aliases will be useful later to identify block devices on exporting thru nbd. <domainblocksnapshot> <name>5768a388-c1c4-414c-ac4e-eab216ba7c0c</name> <snapshot disk='sda'> <fleece file="/path/to/fleece-image-sda"/> <alias name="scsi0-0-0-0-backup"/> </snapshot> <snapshot disk='sdb'> <fleece file="/path/to/fleece-image-sdb"/> <alias name="scsi0-0-0-1-backup"/> </snapshot> </domainblocksnapshot> 2. Export API During backup operation we need to provide read access to fleecing image. This is done thru qemu process nbd server. We just need to specify the disks to export. /* start block export */ int virDomainBlockExportStart(virDomainPtr domain, const char *xmlDesc, unsigned int flags); /* stop block export */ int virDomainBlockExportStop(virDomainPtr domain, const char *diskName, unsigned int flags); Here is an example of xml for starting function: <blockexport type="nbd" port="8001"> <listen type="address" address="10.0.2.10"/> <disk name="scsi0-0-0-1-backup"/> </blockexport> qemu nbd server is started upon first disk export start and shutted down upon last disk export stop. Another option is to control ndb server explicitly. One way to do it is to consider ndb server a new device so to start/stop/update ndb server we can use attach/detach/update device functions. Then in block export start we need to refer to this device somehow. This can be a generated name/uuid or type/address pair. Actually this approach to expose ndb server looks more natural to me even it includes more management from client side. I am not suggesting it in the first place mostly due to hesitations on how to refer to ndb server on block export. In any case I'd like to provide export info in active domain config: <devices> <blockexport type="nbd" port="8001"> <listen type="address" address="10.0.2.10"/> <disk name="scsi0-0-0-1-backup"/> <disk name="scsi0-0-0-2-backup"/> </blockexport> </devices> This API is used in restore operation too. Domain is started in paused state, the disks to be restored are exported and backup client fills it with the backup data. 3. Incremental backups Qemu can track what disk parts are changed from from fleecing start. This is what typically called CBT (dirty bitmap in qemu community I guess). There are also experimental ndb support [4] and a bunch of merged/agreed/proposed bitmap operation that help to organize incremental backups. Different hypervisors has different bitmap implementations with different costs thus it is up to hyperivsor whether to start CBT or not upon block snapshot create by default. Qemu implementations has memory and disk costs for every bitmap thus I suggest by default start fleecing without bitmap and add flag VIR_DOMAIN_BLOCK_SNAPSHOT_CREATE_CHECKPOINT to ask to start a bitmap. Disks bitmaps are visible in active domain definition with the name of block snapshot for which bitmap was started. <disk type='file' device='disk'> .. <target dev='sda' bus='scsi'/> <alias name='scsi0-0-0-0'/> <checkpoint name="93a5c045-6457-2c09-e56c-927cdf34e178"> <checkpoint name="5768a388-c1c4-414c-ac4e-eab216ba7c0c"> .. </disk> The bitmap can be specified upon disk export like below (I guess there is no need to provide more then one bitmap per disk). Active domain config section for block export is expanded similarly. <blockexport type="nbd" port="8001"> <listen type="address" address="10.0.2.10"/> <disk name="scsi0-0-0-1-backup" checkpoint="5768a388-c1c4-414c-ac4e-eab216ba7c0c"/> </blockexport> If bitmap was created on backup start but client failed to make a backup for some reason then it makes no sense to keep this checkpoint anymore. As having bitmap takes resources it is convinient to drop bitmap in this case. Also one may want to drop bitmap for pure resource managment issues. So we need API to remove bitmap: virDomainBlockCheckpointRemove(virDomainPtr domain, const char *name, unsigned int flags); 4. Other hypervisors I took a somewhat considerable look only at vmware backup interface at [5] etc. Looks like they don't have fleecing like qemu has so for vmware snapshots one can use usual disks snapshots API. Also there is no nbd interface for snapshots expectedly thus to deal with vmware snapshot disks one eventually will have to add block API to libvirt. So the only point this RFC has to vmware backups is exporting checkpoints in disk xml. The vmware documentation does not say much about bitmap limitations but I guess they still can provide only a number of them which can be exposed as suggested for active domain disks. II Links: [1] https://www.redhat.com/archives/libvir-list/2016-September/msg00192.html [2] https://www.redhat.com/archives/libvir-list/2017-May/msg00379.html [3] https://www.redhat.com/archives/libvir-list/2016-March/msg00937.html [4] https://github.com/NetworkBlockDevice/nbd/commit/cfa8ebfc354b2adbdf73b6e6c2… [5] https://code.vmware.com/doc/preview?id=4076#/doc/vddkBkupVadp.9.3.html#1014…

1 1

[libvirt] [PATCH 0/6] implement support to configure sound output
by Pavel Hrdina 21 Nov '17

21 Nov '17

Pavel Hrdina (6): tests: add test cases for default sound output qemu: move QEMU_AUDIO_DRIVER out of graphic into sound qemu: explicitly disable audio if there is no sound device conf: introduce <output> element for <sound> devices qemu: implement <output> element for <sound> devices tests: add test cases for specific sound output docs/formatdomain.html.in | 11 ++++ docs/schemas/domaincommon.rng | 14 ++++ src/conf/domain_conf.c | 61 ++++++++++++++++++ src/conf/domain_conf.h | 14 ++++ src/libvirt_private.syms | 2 + src/qemu/qemu_command.c | 75 ++++++++++++++-------- src/qemu/qemu_domain.c | 54 ++++++++++++++++ src/qemu/qemu_process.c | 41 ++++++++++++ .../qemuxml2argv-channel-spicevmc-old.args | 2 +- .../qemuxml2argv-channel-spicevmc.args | 2 +- .../qemuxml2argv-clock-france.args | 2 +- .../qemuxml2argv-graphics-sdl-fullscreen.args | 1 + .../qemuxml2argv-graphics-sdl.args | 1 + ...emuxml2argv-graphics-spice-agent-file-xfer.args | 2 +- .../qemuxml2argv-graphics-spice-agentmouse.args | 2 +- ...emuxml2argv-graphics-spice-auto-socket-cfg.args | 2 +- .../qemuxml2argv-graphics-spice-auto-socket.args | 2 +- .../qemuxml2argv-graphics-spice-compression.args | 2 +- .../qemuxml2argv-graphics-spice-no-args.args | 2 +- .../qemuxml2argv-graphics-spice-qxl-vga.args | 2 +- .../qemuxml2argv-graphics-spice-sasl.args | 2 +- .../qemuxml2argv-graphics-spice-socket.args | 2 +- .../qemuxml2argv-graphics-spice-usb-redir.args | 2 +- .../qemuxml2argv-graphics-spice.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-name-escape.args | 2 +- .../qemuxml2argv-serial-spiceport.args | 2 +- .../qemuxml2argv-sound-default-output-sdl.args | 23 +++++++ .../qemuxml2argv-sound-default-output-sdl.xml | 24 +++++++ ...emuxml2argv-sound-default-output-spice-vnc.args | 25 ++++++++ ...qemuxml2argv-sound-default-output-spice-vnc.xml | 25 ++++++++ .../qemuxml2argv-sound-default-output-spice.args | 24 +++++++ .../qemuxml2argv-sound-default-output-spice.xml | 24 +++++++ ...emuxml2argv-sound-default-output-vnc-spice.args | 25 ++++++++ ...qemuxml2argv-sound-default-output-vnc-spice.xml | 25 ++++++++ .../qemuxml2argv-sound-default-output-vnc.args | 24 +++++++ .../qemuxml2argv-sound-default-output-vnc.xml | 24 +++++++ ...xml2argv-sound-multi-different-output-spice.xml | 29 +++++++++ .../qemuxml2argv-sound-multi-pa-output-spice.args | 26 ++++++++ .../qemuxml2argv-sound-multi-pa-output-spice.xml | 27 ++++++++ .../qemuxml2argv-sound-pa-output-spice.args | 24 +++++++ .../qemuxml2argv-sound-pa-output-spice.xml | 26 ++++++++ .../qemuxml2argv-video-virtio-gpu-spice-gl.args | 2 +- tests/qemuxml2argvtest.c | 34 ++++++++++ 43 files changed, 675 insertions(+), 42 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-sdl.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-sdl.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-spice-vnc.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-spice-vnc.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-spice.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-spice.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-vnc-spice.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-vnc-spice.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-vnc.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-default-output-vnc.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-multi-different-output-spice.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-multi-pa-output-spice.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-multi-pa-output-spice.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-pa-output-spice.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-sound-pa-output-spice.xml -- 2.13.6

4 36

[libvirt] [PATCH 00/12] qemu: command: Move frontend disk attributes to -device (blockdev-add saga)
by Peter Krempa 21 Nov '17

21 Nov '17

For legacy reasons we've formatted some attributes of the disk frontend in -drive which now mostly holds backend arguments. (-drive was used by itself some time ago and still is for sdcards) Since we will no longer use -drive with -blockdev, some of them need to be moved (and the rest interpreted with -blockdev). Peter Krempa (12): qemu: command: Split out geometry frontend attribute formatting from -drive qemu: command: Format frontend props with -device rather than -drive tests: qemuxml2xml: Run the 'disk-serial' test tests: qemuxml2argv: Test SD card with serial number qemu: command: Move disk 'serial' into frontend parameter formatter qemu: command: Move around order of generating -drive arguments qemu: command: Refactor logic when formatting -drive qemu: command: Move disk trhottling argument building into a separate function qemu: command: Move formatting of disk io error policy from -drive qemu: command: Move around logic for formatting bootindex qemu: command: Move formatting of 'boot' attribute to -device qemu: command: Explain formatting of 'media=cdrom' in -drive src/qemu/qemu_command.c | 252 ++++++++++++--------- src/qemu/qemu_command.h | 2 +- src/qemu/qemu_hotplug.c | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-cdrom.args | 2 +- .../qemuxml2argv-boot-complex-bootindex.args | 2 +- .../qemuxml2argv-boot-complex.args | 6 +- ...xml2argv-boot-menu-disable-drive-bootindex.args | 2 +- .../qemuxml2argv-boot-menu-disable-drive.args | 2 +- .../qemuxml2argv-boot-menu-disable.args | 2 +- .../qemuxml2argv-boot-menu-enable-bootindex.args | 2 +- ...qemuxml2argv-boot-menu-enable-with-timeout.args | 2 +- .../qemuxml2argv-boot-menu-enable.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-multi.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-order.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-strict.args | 2 +- .../qemuxml2argv-controller-order.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-disk-aio.args | 4 +- .../qemuxml2argv-disk-cdrom-empty.args | 2 +- .../qemuxml2argv-disk-cdrom-network-ftp.args | 2 +- .../qemuxml2argv-disk-cdrom-network-ftps.args | 2 +- .../qemuxml2argv-disk-cdrom-network-http.args | 2 +- .../qemuxml2argv-disk-cdrom-network-https.args | 2 +- .../qemuxml2argv-disk-cdrom-network-tftp.args | 2 +- ...qemuxml2argv-disk-cdrom-tray-no-device-cap.args | 2 +- .../qemuxml2argv-disk-cdrom-tray.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-disk-cdrom.args | 2 +- .../qemuxml2argv-disk-copy_on_read.args | 2 +- .../qemuxml2argv-disk-drive-boot-cdrom.args | 4 +- .../qemuxml2argv-disk-drive-boot-disk.args | 4 +- .../qemuxml2argv-disk-drive-cache-directsync.args | 4 +- .../qemuxml2argv-disk-drive-cache-unsafe.args | 4 +- .../qemuxml2argv-disk-drive-cache-v2-none.args | 4 +- .../qemuxml2argv-disk-drive-cache-v2-wb.args | 4 +- .../qemuxml2argv-disk-drive-cache-v2-wt.args | 4 +- .../qemuxml2argv-disk-drive-detect-zeroes.args | 2 +- .../qemuxml2argv-disk-drive-discard.args | 2 +- ...uxml2argv-disk-drive-error-policy-enospace.args | 9 +- .../qemuxml2argv-disk-drive-error-policy-stop.args | 9 +- ...gv-disk-drive-error-policy-wreport-rignore.args | 9 +- .../qemuxml2argv-disk-drive-fmt-qcow.args | 4 +- .../qemuxml2argv-disk-drive-no-boot.args | 4 +- .../qemuxml2argv-disk-drive-readonly-disk.args | 2 +- ...qemuxml2argv-disk-drive-readonly-no-device.args | 2 +- .../qemuxml2argv-disk-drive-shared.args | 9 +- .../qemuxml2argv-disk-geometry.args | 6 +- .../qemuxml2argv-disk-ide-wwn.args | 5 +- .../qemuxml2argv-disk-ioeventfd.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-disk-order.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-disk-serial.args | 9 +- .../qemuxml2argvdata/qemuxml2argv-disk-serial.xml | 5 + .../qemuxml2argv-disk-snapshot.args | 4 +- .../qemuxml2argv-disk-source-pool-mode.args | 12 +- .../qemuxml2argv-disk-source-pool.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-disk-virtio.args | 4 +- tests/qemuxml2argvdata/qemuxml2argv-event_idx.args | 2 +- .../qemuxml2argv-graphics-spice-timeout.args | 2 +- .../qemuxml2argv-hugepages-numa.args | 2 +- .../qemuxml2argv-pci-autoadd-addr.args | 4 +- .../qemuxml2argv-pci-autoadd-idx.args | 4 +- .../qemuxml2argv-pci-autofill-addr.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-pci-bridge.args | 4 +- tests/qemuxml2argvdata/qemuxml2argv-pci-many.args | 4 +- .../qemuxml2argv-user-aliases.args | 2 +- .../qemuxml2xmlout-disk-serial.xml | 47 ++++ tests/qemuxml2xmltest.c | 2 + 65 files changed, 305 insertions(+), 219 deletions(-) create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-serial.xml -- 2.14.3

1 13

[libvirt] [PATCH 00/21] Initial support for resctrl (CAT)
by Martin Kletzander 21 Nov '17

21 Nov '17

This is an initial support for resctrl, so that domains can make use of Cache Allocation Technology (🐈). After bunch of initial discussions I followed most of those things except one detail. In order to distinguish different allocations while minimizing the number of them at the same time, I changed the XML design, but only slightly. See docs in patch 17 for detail. There is still much missing, but all is designed in a way that should not collied with the future additions. Missing features include: - After allocation is created the file should be re-read and parsed into the al the allocation so that the masks reflect what kernel actually uses (just in case there was a change) - When formatting live XML, used masks for allocations should be formatted as well - Each <cache/> should support shared allocations, for now every single allocation is exclusive only - Suuport for different backing, particularly if allocation has type='both' (code as well as data) and the host supports CDP (Code Data Partitioning), meaning it can allocate code and data portions separately the code currently fails even though it is possible to convert such allocation. - APIs for manipulation with various resctrl groups. What's needed is reading and setting values of the default group as well as any cachetune of a domain. Martin Kletzander (21): Only output initialized capabilities with VIR_TEST_DEBUG > 1 util: Introduce virPrettySize util: Make prefix optional in virBitampString util: Rename virBitmapString to virBitmapToString util: Rename virBitmapDataToString to virBitmapDataFormat util: Don't output too many zeros from virBitmapToString util: Introduce virBitmapNewString util: Reintroduce virBitmapSubtract util: Introduce virBitmapShrink conf: Sort cache banks in capabilities XML conf: Format cache banks in capabilities with virPrettySize resctrl: Instantiate all resctrl information at once tests: Remove executable bits on plain data files tests: Change some schemata for the default group caps2xml resctrl-skx-twocaches resctrl: Add functions to work with resctrl allocations conf: cachetune tests: Minor adjustments for test data tests: Add virresctrltest qemu: Add support for resctrl docs: Add CAT (resctrl) support into news.xml docs/formatdomain.html.in | 24 + docs/news.xml | 11 + docs/schemas/domaincommon.rng | 32 + po/POTFILES.in | 1 + src/Makefile.am | 2 +- src/conf/capabilities.c | 113 +- src/conf/capabilities.h | 4 +- src/conf/domain_conf.c | 249 ++++ src/conf/domain_conf.h | 21 + src/libvirt_private.syms | 24 +- src/qemu/qemu_capabilities.c | 4 +- src/qemu/qemu_process.c | 61 +- src/util/virbitmap.c | 118 +- src/util/virbitmap.h | 15 +- src/util/virresctrl.c | 1317 ++++++++++++++++++-- src/util/virresctrl.h | 81 +- src/util/virresctrlpriv.h | 32 + src/util/virutil.c | 50 + src/util/virutil.h | 3 + tests/Makefile.am | 8 +- .../genericxml2xmlindata/generic-cachetune-cdp.xml | 36 + .../generic-cachetune-colliding-allocs.xml | 30 + .../generic-cachetune-colliding-tunes.xml | 32 + .../generic-cachetune-colliding-types.xml | 30 + .../generic-cachetune-small.xml | 29 + tests/genericxml2xmlindata/generic-cachetune.xml | 33 + tests/genericxml2xmltest.c | 10 + tests/testutils.c | 2 +- tests/virbitmaptest.c | 84 +- tests/vircaps2xmldata/linux-caches/system | 1 + .../linux-resctrl-cdp/resctrl/info/L3CODE/cbm_mask | 0 .../resctrl/info/L3CODE/min_cbm_bits | 0 .../resctrl/info/L3CODE/num_closids | 0 .../linux-resctrl-cdp/resctrl/info/L3DATA/cbm_mask | 0 .../resctrl/info/L3DATA/min_cbm_bits | 0 .../resctrl/info/L3DATA/num_closids | 0 .../linux-resctrl-cdp/resctrl/schemata | 4 +- .../resctrl/info/L3/cbm_mask | 1 + .../resctrl/info/L3}/min_cbm_bits | 0 .../resctrl/info/L3/num_closids | 1 + .../linux-resctrl-skx-twocaches/resctrl/schemata | 1 + .../resctrl/some_reservation/schemata | 1 + .../system/cpu/cpu0/cache/index0/id | 1 + .../system/cpu/cpu0/cache/index0/level | 1 + .../system/cpu/cpu0/cache/index0/shared_cpu_list | 1 + .../system/cpu/cpu0/cache/index0/shared_cpu_map | 1 + .../system/cpu/cpu0/cache/index0/size | 1 + .../system/cpu/cpu0/cache/index0/type | 1 + .../system/cpu/cpu0/cache/index1/id} | 0 .../system/cpu/cpu0/cache/index1/level | 1 + .../system/cpu/cpu0/cache/index1/shared_cpu_list | 1 + .../system/cpu/cpu0/cache/index1/shared_cpu_map | 1 + .../system/cpu/cpu0/cache/index1/size | 1 + .../system/cpu/cpu0/cache/index1/type | 1 + .../system/cpu/cpu0/online} | 0 .../system/cpu/cpu0/topology/core_id | 1 + .../system/cpu/cpu0/topology/core_siblings | 1 + .../system/cpu/cpu0/topology/core_siblings_list | 1 + .../system/cpu/cpu0/topology/physical_package_id | 1 + .../system/cpu/cpu0/topology/thread_siblings | 1 + .../system/cpu/cpu0/topology/thread_siblings_list | 1 + .../linux-resctrl-skx-twocaches/system/cpu/online | 1 + .../linux-resctrl-skx-twocaches/system/cpu/present | 1 + .../system/node/node0/cpu0 | 1 + .../system/node/node0/cpulist | 1 + .../system/node/node0/cpumap | 1 + .../system/node/node0/distance | 1 + .../linux-resctrl-skx-twocaches/system/node/online | 1 + .../linux-resctrl-skx/resctrl/empty/schemata | 0 .../linux-resctrl-skx/resctrl/schemata | 2 +- .../vircaps2xmldata/linux-resctrl/resctrl/schemata | 2 +- tests/vircaps2xmldata/vircaps-x86_64-caches.xml | 2 +- .../vircaps2xmldata/vircaps-x86_64-resctrl-cdp.xml | 4 +- ...ml => vircaps-x86_64-resctrl-skx-twocaches.xml} | 7 +- .../vircaps2xmldata/vircaps-x86_64-resctrl-skx.xml | 4 +- tests/vircaps2xmldata/vircaps-x86_64-resctrl.xml | 4 +- tests/vircaps2xmltest.c | 1 + .../resctrl--cachetune/vcpus-0-1.alloc | 1 + .../resctrl--cachetune/vcpus-3.alloc | 1 + .../resctrl-cdp--cachetune-cdp/vcpus-0-1.alloc | 2 + .../resctrl-cdp--cachetune-cdp/vcpus-2.alloc | 1 + .../resctrl-cdp--cachetune-cdp/vcpus-3.alloc | 1 + tests/virresctrldata/resctrl-cdp.schemata | 2 + .../virresctrldata/resctrl-skx-twocaches.schemata | 1 + tests/virresctrldata/resctrl-skx.schemata | 1 + tests/virresctrldata/resctrl.schemata | 1 + tests/virresctrltest.c | 277 ++++ tools/virsh-domain.c | 4 +- tools/virsh-host.c | 2 +- 89 files changed, 2626 insertions(+), 183 deletions(-) create mode 100644 src/util/virresctrlpriv.h create mode 100644 tests/genericxml2xmlindata/generic-cachetune-cdp.xml create mode 100644 tests/genericxml2xmlindata/generic-cachetune-colliding-allocs.xml create mode 100644 tests/genericxml2xmlindata/generic-cachetune-colliding-tunes.xml create mode 100644 tests/genericxml2xmlindata/generic-cachetune-colliding-types.xml create mode 100644 tests/genericxml2xmlindata/generic-cachetune-small.xml create mode 100644 tests/genericxml2xmlindata/generic-cachetune.xml create mode 120000 tests/vircaps2xmldata/linux-caches/system mode change 100755 => 100644 tests/vircaps2xmldata/linux-resctrl-cdp/resctrl/info/L3CODE/cbm_mask mode change 100755 => 100644 tests/vircaps2xmldata/linux-resctrl-cdp/resctrl/info/L3CODE/min_cbm_bits mode change 100755 => 100644 tests/vircaps2xmldata/linux-resctrl-cdp/resctrl/info/L3CODE/num_closids mode change 100755 => 100644 tests/vircaps2xmldata/linux-resctrl-cdp/resctrl/info/L3DATA/cbm_mask mode change 100755 => 100644 tests/vircaps2xmldata/linux-resctrl-cdp/resctrl/info/L3DATA/min_cbm_bits mode change 100755 => 100644 tests/vircaps2xmldata/linux-resctrl-cdp/resctrl/info/L3DATA/num_closids create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/resctrl/info/L3/cbm_mask copy tests/vircaps2xmldata/{linux-resctrl-cdp/resctrl/info/L3CODE => linux-resctrl-skx-twocaches/resctrl/info/L3}/min_cbm_bits (100%) mode change 100755 => 100644 create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/resctrl/info/L3/num_closids create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/resctrl/schemata create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/resctrl/some_reservation/schemata create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index0/id create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index0/level create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index0/shared_cpu_list create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index0/shared_cpu_map create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index0/size create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index0/type copy tests/vircaps2xmldata/{linux-resctrl-cdp/resctrl/info/L3CODE/min_cbm_bits => linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index1/id} (100%) mode change 100755 => 100644 create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index1/level create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index1/shared_cpu_list create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index1/shared_cpu_map create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index1/size create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/cache/index1/type copy tests/vircaps2xmldata/{linux-resctrl-cdp/resctrl/info/L3CODE/min_cbm_bits => linux-resctrl-skx-twocaches/system/cpu/cpu0/online} (100%) mode change 100755 => 100644 create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/topology/core_id create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/topology/core_siblings create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/topology/core_siblings_list create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/topology/physical_package_id create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/topology/thread_siblings create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/cpu0/topology/thread_siblings_list create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/online create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/cpu/present create mode 120000 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/node/node0/cpu0 create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/node/node0/cpulist create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/node/node0/cpumap create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/node/node0/distance create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx-twocaches/system/node/online create mode 100644 tests/vircaps2xmldata/linux-resctrl-skx/resctrl/empty/schemata copy tests/vircaps2xmldata/{vircaps-x86_64-resctrl-skx.xml => vircaps-x86_64-resctrl-skx-twocaches.xml} (68%) create mode 100644 tests/virresctrldata/resctrl--cachetune/vcpus-0-1.alloc create mode 100644 tests/virresctrldata/resctrl--cachetune/vcpus-3.alloc create mode 100644 tests/virresctrldata/resctrl-cdp--cachetune-cdp/vcpus-0-1.alloc create mode 100644 tests/virresctrldata/resctrl-cdp--cachetune-cdp/vcpus-2.alloc create mode 100644 tests/virresctrldata/resctrl-cdp--cachetune-cdp/vcpus-3.alloc create mode 100644 tests/virresctrldata/resctrl-cdp.schemata create mode 100644 tests/virresctrldata/resctrl-skx-twocaches.schemata create mode 100644 tests/virresctrldata/resctrl-skx.schemata create mode 100644 tests/virresctrldata/resctrl.schemata create mode 100644 tests/virresctrltest.c -- 2.15.0

3 57

[libvirt] [PATCH v4 1/2] remote: Extract common clearing of event callbacks of client private data
by xinhua.Cao 20 Nov '17

20 Nov '17

Extract common clearing of event callbacks as remoteClientFreePrivateCallbacks. the common function also separation including the sysident handling. --- daemon/remote.c | 73 ++++++++++++++++++++++++++++++--------------------------- 1 file changed, 39 insertions(+), 34 deletions(-) diff --git a/daemon/remote.c b/daemon/remote.c index cbcb6e8..2dcec1e 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -1689,6 +1689,44 @@ void remoteRelayConnectionClosedEvent(virConnectPtr conn ATTRIBUTE_UNUSED, int r neventCallbacks = 0; \ } while (0); + +static void +remoteClientFreePrivateCallbacks(struct daemonClientPrivate *priv) +{ + virIdentityPtr sysident = virIdentityGetSystem(); + virIdentitySetCurrent(sysident); + + DEREG_CB(priv->conn, priv->domainEventCallbacks, + priv->ndomainEventCallbacks, + virConnectDomainEventDeregisterAny, "domain"); + DEREG_CB(priv->conn, priv->networkEventCallbacks, + priv->nnetworkEventCallbacks, + virConnectNetworkEventDeregisterAny, "network"); + DEREG_CB(priv->conn, priv->storageEventCallbacks, + priv->nstorageEventCallbacks, + virConnectStoragePoolEventDeregisterAny, "storage"); + DEREG_CB(priv->conn, priv->nodeDeviceEventCallbacks, + priv->nnodeDeviceEventCallbacks, + virConnectNodeDeviceEventDeregisterAny, "node device"); + DEREG_CB(priv->conn, priv->secretEventCallbacks, + priv->nsecretEventCallbacks, + virConnectSecretEventDeregisterAny, "secret"); + DEREG_CB(priv->conn, priv->qemuEventCallbacks, + priv->nqemuEventCallbacks, + virConnectDomainQemuMonitorEventDeregister, "qemu monitor"); + + if (priv->closeRegistered) { + if (virConnectUnregisterCloseCallback(priv->conn, + remoteRelayConnectionClosedEvent) < 0) + VIR_WARN("unexpected close callback event deregister failure"); + } + + virIdentitySetCurrent(NULL); + virObjectUnref(sysident); +} +#undef DEREG_CB + + /* * You must hold lock for at least the client * We don't free stuff here, merely disconnect the client's @@ -1702,44 +1740,11 @@ void remoteClientFreeFunc(void *data) /* Deregister event delivery callback */ if (priv->conn) { - virIdentityPtr sysident = virIdentityGetSystem(); - - virIdentitySetCurrent(sysident); - - DEREG_CB(priv->conn, priv->domainEventCallbacks, - priv->ndomainEventCallbacks, - virConnectDomainEventDeregisterAny, "domain"); - DEREG_CB(priv->conn, priv->networkEventCallbacks, - priv->nnetworkEventCallbacks, - virConnectNetworkEventDeregisterAny, "network"); - DEREG_CB(priv->conn, priv->storageEventCallbacks, - priv->nstorageEventCallbacks, - virConnectStoragePoolEventDeregisterAny, "storage"); - DEREG_CB(priv->conn, priv->nodeDeviceEventCallbacks, - priv->nnodeDeviceEventCallbacks, - virConnectNodeDeviceEventDeregisterAny, "node device"); - DEREG_CB(priv->conn, priv->secretEventCallbacks, - priv->nsecretEventCallbacks, - virConnectSecretEventDeregisterAny, "secret"); - DEREG_CB(priv->conn, priv->qemuEventCallbacks, - priv->nqemuEventCallbacks, - virConnectDomainQemuMonitorEventDeregister, "qemu monitor"); - - if (priv->closeRegistered) { - if (virConnectUnregisterCloseCallback(priv->conn, - remoteRelayConnectionClosedEvent) < 0) - VIR_WARN("unexpected close callback event deregister failure"); - } - + remoteClientFreePrivateCallbacks(priv); virConnectClose(priv->conn); - - virIdentitySetCurrent(NULL); - virObjectUnref(sysident); } - VIR_FREE(priv); } -#undef DEREG_CB static void remoteClientCloseFunc(virNetServerClientPtr client) -- 2.8.3

3 5

[libvirt] [PATCH v2 00/10] Implement query-dump command
by John Ferlan 20 Nov '17

20 Nov '17

v1: https://www.redhat.com/archives/libvir-list/2017-November/msg00731.html Differences from v1 (besides more patches) Rather than use a timing loop in order to fetch the dump stats and the presence of the 'query-dump' command, let's use the DUMP_COMPLETED event and wire that up in order to determine when the dump has been completed. In the mean time, the previous timing loop is converted into a qemuDomainGetJobInfoDumpStats to be called if the "right conditions" exist. Also found/fixed a couple of minor issues from v1 regarding usage "dumpformat" instead of just "format" from my patch 2 adjustment and a type for qemuMonitorDumpStatus (was qemuMontiorDumpStatus in v1). NB: (from v1 cover): Details in the patches. Essentially though QEMU 2.6 added the ability to perform the 'dump-guest-memory' via a thread by adding a 'detach' boolean to the command. In order to watch the progress of the thread the 'query-dump' command was added. The query-dump will return just the current status, the total size to be dumped, and the current progress. So using the migrate stats data in the DomainJobInfo we can then save our current progress allowing tools such as virsh to watch that progress. As an added benefit, the dump-guest-memory is now truly asynchronous. John Ferlan (10): qemu: Clean up style for the qemuDumpToFd definition qemu: Alter dump-guest-memory command generation qemu: Add support for DUMP_COMPLETED event qemu: Introduce qemuProcessHandleDumpCompleted qemu: Introduce qemuMonitor[JSON]QueryDump qemu: Add new parameter to qemuMonitorDumpToFd qemu: Introduce qemuDomainGetJobInfoMigrationStats qemu: Introduce qemuDomainGetJobInfoDumpStats qemu: Add dump completed event to the capabilities qemu: Allow showing the dump progress for memory only dump src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 2 + src/qemu/qemu_domain.h | 2 + src/qemu/qemu_driver.c | 157 ++++++++++++++++++--- src/qemu/qemu_monitor.c | 39 ++++- src/qemu/qemu_monitor.h | 33 ++++- src/qemu/qemu_monitor_json.c | 122 ++++++++++++++-- src/qemu/qemu_monitor_json.h | 7 +- src/qemu/qemu_process.c | 23 +++ .../caps_2.10.0-gicv2.aarch64.xml | 1 + .../caps_2.10.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.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.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + tests/qemumonitorjsontest.c | 3 +- 27 files changed, 365 insertions(+), 42 deletions(-) -- 2.13.6

1 10

[libvirt] [jenkins-ci PATCH 0/5] Fix environment handling
by Andrea Bolognani 20 Nov '17

20 Nov '17

My own attempt at fixing libosinfo-master-rpm's failing status, and then some. This is an extension of Pavel's attempt[1] in a way; except of course I think my approach is superior, otherwise I wouldn't have bothered ;) It also sets the groundwork for finally moving $VIRT_PREFIX and friends out of the Jenkins server configuration, where they are invisible to anyone but the CI admins, and into the git repository so that they can be tracked alongside the jobs using them. [1] https://www.redhat.com/archives/libvir-list/2017-November/msg00045.html Andrea Bolognani (5): jobs: Rename {make_env} to {global_env} jobs: Include {global_env} everywhere jobs: Rename {check_env} to {env} jobs: Include {env} everywhere jobs: Include $PATH definition in {global_env} jobs/autotools.yaml | 17 ++++++++++++----- jobs/defaults.yaml | 5 +++-- jobs/generic.yaml | 20 ++++++++++++++++---- jobs/go.yaml | 4 ++++ jobs/perl-makemaker.yaml | 9 ++++++--- jobs/perl-modulebuild.yaml | 6 ++++++ jobs/python-distutils.yaml | 6 ++++++ projects/libosinfo.yaml | 2 +- projects/libvirt.yaml | 2 +- projects/osinfo-db.yaml | 4 ---- 10 files changed, 55 insertions(+), 20 deletions(-) -- 2.14.3

2 8

[libvirt] [PATCH 00/14] Fix serial console behavior on non-x86 architectures
by Andrea Bolognani 20 Nov '17

20 Nov '17

See the last commit for a short explanation of what this series is all about. Andrea Bolognani (10): qemu: Add QEMU_CAPS_DEVICE_SPAPR_VTY conf,qemu: Use type-aware switches where possible qemu: Introduce qemuDomainChrDefPostParse() conf: Run devicePostParse() again for the first serial device conf: Introduce VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_NONE conf: Drop virDomainChrDeviceType.targetTypeAttr conf: Add VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SPAPR qemu: Support usb-serial and pci-serial on pSeries conf: Add VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_PL011 news: Update for serial console fixes Pino Toscano (4): conf: add VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SCLP/SCLPLM conf: pass parseFlags down to virDomainDefAddConsoleCompat conf: convert sclp/sclplm <console> as <serial> qemu: switch s390/s390x default console back to serial docs/formatdomain.html.in | 13 +- docs/news.xml | 12 ++ docs/schemas/domaincommon.rng | 4 + src/conf/domain_conf.c | 132 +++++++++++++++----- src/conf/domain_conf.h | 11 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 136 +++++++++++++-------- src/qemu/qemu_domain.c | 95 ++++++++++++-- src/qemu/qemu_domain_address.c | 8 +- src/vz/vz_sdk.c | 5 +- .../qemuargv2xml-console-compat.xml | 2 +- tests/qemuargv2xmldata/qemuargv2xml-serial-dev.xml | 2 +- .../qemuargv2xmldata/qemuargv2xml-serial-file.xml | 2 +- .../qemuargv2xmldata/qemuargv2xml-serial-many.xml | 4 +- tests/qemuargv2xmldata/qemuargv2xml-serial-pty.xml | 2 +- .../qemuargv2xml-serial-tcp-telnet.xml | 2 +- tests/qemuargv2xmldata/qemuargv2xml-serial-tcp.xml | 2 +- tests/qemuargv2xmldata/qemuargv2xml-serial-udp.xml | 4 +- .../qemuargv2xmldata/qemuargv2xml-serial-unix.xml | 2 +- tests/qemuargv2xmldata/qemuargv2xml-serial-vc.xml | 2 +- tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + ...otplug-console-compat-2-live+console-virtio.xml | 4 +- .../qemuhotplug-console-compat-2-live.xml | 4 +- .../qemuxml2argv-mach-virt-console-native.args | 1 + .../qemuxml2argv-mach-virt-console-native.xml | 17 +++ ... => qemuxml2argv-mach-virt-console-virtio.args} | 15 +-- .../qemuxml2argv-mach-virt-console-virtio.xml | 19 +++ ...muxml2argv-mach-virt-serial+console-native.args | 1 + ...emuxml2argv-mach-virt-serial+console-native.xml | 18 +++ .../qemuxml2argv-mach-virt-serial-compat.args | 1 + .../qemuxml2argv-mach-virt-serial-compat.xml | 19 +++ ...muxml2argv-mach-virt-serial-invalid-machine.xml | 19 +++ ...s => qemuxml2argv-mach-virt-serial-native.args} | 12 +- .../qemuxml2argv-mach-virt-serial-native.xml | 16 +++ .../qemuxml2argv-mach-virt-serial-pci.args | 26 ++++ .../qemuxml2argv-mach-virt-serial-pci.xml | 18 +++ .../qemuxml2argv-mach-virt-serial-usb.args | 27 ++++ .../qemuxml2argv-mach-virt-serial-usb.xml | 21 ++++ .../qemuxml2argv-pseries-basic.args | 2 +- .../qemuxml2argv-pseries-console-native.args | 1 + .../qemuxml2argv-pseries-console-native.xml | 17 +++ ...gs => qemuxml2argv-pseries-console-virtio.args} | 10 +- .../qemuxml2argv-pseries-console-virtio.xml | 19 +++ .../qemuxml2argv-pseries-cpu-compat-power9.args | 2 +- .../qemuxml2argv-pseries-cpu-compat.args | 2 +- .../qemuxml2argv-pseries-cpu-exact.args | 2 +- .../qemuxml2argv-pseries-cpu-le.args | 2 +- .../qemuxml2argv-pseries-panic-missing.args | 2 +- .../qemuxml2argv-pseries-panic-no-address.args | 2 +- ...qemuxml2argv-pseries-serial+console-native.args | 1 + .../qemuxml2argv-pseries-serial+console-native.xml | 18 +++ .../qemuxml2argv-pseries-serial-compat.args | 1 + .../qemuxml2argv-pseries-serial-compat.xml | 19 +++ ...qemuxml2argv-pseries-serial-invalid-machine.xml | 19 +++ ...rgs => qemuxml2argv-pseries-serial-native.args} | 7 +- .../qemuxml2argv-pseries-serial-native.xml | 16 +++ ...c.args => qemuxml2argv-pseries-serial-pci.args} | 7 +- .../qemuxml2argv-pseries-serial-pci.xml | 18 +++ ...c.args => qemuxml2argv-pseries-serial-usb.args} | 8 +- .../qemuxml2argv-pseries-serial-usb.xml | 21 ++++ .../qemuxml2argv-pseries-usb-default.args | 2 +- .../qemuxml2argv-pseries-usb-kbd.args | 2 +- .../qemuxml2argv-pseries-usb-multi.args | 2 +- .../qemuxml2argv-pseries-vio-user-assigned.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-pseries-vio.args | 4 +- ....args => qemuxml2argv-s390-console2serial.args} | 11 +- .../qemuxml2argv-s390-console2serial.xml | 19 +++ ...power9.args => qemuxml2argv-s390-serial-2.args} | 14 +-- .../qemuxml2argv-s390-serial-2.xml | 17 +++ ....args => qemuxml2argv-s390-serial-console.args} | 11 +- .../qemuxml2argv-s390-serial-console.xml | 15 +++ ...es-basic.args => qemuxml2argv-s390-serial.args} | 11 +- .../qemuxml2argvdata/qemuxml2argv-s390-serial.xml | 14 +++ ...muxml2argv-serial-tcp-tlsx509-chardev-notls.xml | 4 +- .../qemuxml2argvdata/qemuxml2argv-user-aliases.xml | 4 +- tests/qemuxml2argvtest.c | 83 +++++++++++++ .../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 2 +- .../qemuxml2xmlout-bios-nvram-os-interleave.xml | 2 +- .../qemuxml2xmlout-chardev-label.xml | 4 +- .../qemuxml2xmlout-console-compat-auto.xml | 2 +- .../qemuxml2xmlout-console-compat.xml | 2 +- .../qemuxml2xmlout-console-compat2.xml | 2 +- .../qemuxml2xmlout-console-virtio-many.xml | 2 +- .../qemuxml2xmlout-interface-driver.xml | 2 +- .../qemuxml2xmlout-interface-server.xml | 4 +- .../qemuxml2xmlout-mach-virt-console-native.xml | 1 + ...=> qemuxml2xmlout-mach-virt-console-virtio.xml} | 19 +-- ...uxml2xmlout-mach-virt-serial+console-native.xml | 1 + .../qemuxml2xmlout-mach-virt-serial-compat.xml | 29 +++++ .../qemuxml2xmlout-mach-virt-serial-native.xml | 1 + .../qemuxml2xmlout-mach-virt-serial-pci.xml | 42 +++++++ .../qemuxml2xmlout-mach-virt-serial-usb.xml | 39 ++++++ .../qemuxml2xmlout-net-bandwidth.xml | 2 +- .../qemuxml2xmlout-net-bandwidth2.xml | 2 +- .../qemuxml2xmlout-net-coalesce.xml | 2 +- .../qemuxml2xmloutdata/qemuxml2xmlout-net-mtu.xml | 2 +- .../qemuxml2xmlout-panic-pseries.xml | 2 +- .../qemuxml2xmlout-pseries-console-native.xml | 1 + ...l => qemuxml2xmlout-pseries-console-virtio.xml} | 16 +-- .../qemuxml2xmlout-pseries-cpu-compat-power9.xml | 2 +- .../qemuxml2xmlout-pseries-cpu-compat.xml | 2 +- .../qemuxml2xmlout-pseries-cpu-exact.xml | 2 +- .../qemuxml2xmlout-pseries-panic-missing.xml | 2 +- .../qemuxml2xmlout-pseries-panic-no-address.xml | 2 +- ...emuxml2xmlout-pseries-serial+console-native.xml | 1 + .../qemuxml2xmlout-pseries-serial-compat.xml | 1 + ...ml => qemuxml2xmlout-pseries-serial-native.xml} | 8 +- ...g.xml => qemuxml2xmlout-pseries-serial-pci.xml} | 14 +-- ...g.xml => qemuxml2xmlout-pseries-serial-usb.xml} | 11 +- .../qemuxml2xmlout-q35-virt-manager-basic.xml | 2 +- .../qemuxml2xmlout-s390-defaultconsole.xml | 6 +- .../qemuxml2xmlout-s390-serial-2.xml | 29 +++++ ....xml => qemuxml2xmlout-s390-serial-console.xml} | 18 +-- ...tconsole.xml => qemuxml2xmlout-s390-serial.xml} | 18 +-- .../qemuxml2xmlout-serial-spiceport-nospice.xml | 2 +- .../qemuxml2xmlout-serial-spiceport.xml | 2 +- .../qemuxml2xmlout-serial-target-port-auto.xml | 6 +- .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml | 4 +- .../qemuxml2xmlout-tap-vhost-incorrect.xml | 2 +- .../qemuxml2xmlout-tap-vhost.xml | 2 +- .../qemuxml2xmlout-vhost_queues.xml | 2 +- tests/qemuxml2xmltest.c | 54 ++++++++ 125 files changed, 1186 insertions(+), 284 deletions(-) create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-console-native.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-console-native.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-mach-virt-console-virtio.args} (53%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-console-virtio.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial+console-native.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial+console-native.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-compat.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-compat.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-invalid-machine.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-mach-virt-serial-native.args} (62%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-native.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-pci.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-pci.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-usb.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-usb.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-pseries-console-native.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-console-native.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-console-virtio.args} (59%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-console-virtio.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial+console-native.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial+console-native.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-compat.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-compat.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-invalid-machine.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-serial-native.args} (70%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-native.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-serial-pci.args} (70%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-pci.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-serial-usb.args} (65%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-usb.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-s390-console2serial.args} (71%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-console2serial.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-cpu-compat-power9.args => qemuxml2argv-s390-serial-2.args} (62%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-serial-2.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-s390-serial-console.args} (71%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-serial-console.xml copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-s390-serial.args} (71%) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-serial.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-console-native.xml copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-s390-defaultconsole.xml => qemuxml2xmlout-mach-virt-console-virtio.xml} (50%) create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial+console-native.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-compat.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-native.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-pci.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-usb.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-console-native.xml copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-panic-pseries.xml => qemuxml2xmlout-pseries-console-virtio.xml} (75%) create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-serial+console-native.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-serial-compat.xml copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-panic-missing.xml => qemuxml2xmlout-pseries-serial-native.xml} (82%) copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-panic-missing.xml => qemuxml2xmlout-pseries-serial-pci.xml} (74%) copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-panic-missing.xml => qemuxml2xmlout-pseries-serial-usb.xml} (75%) create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-serial-2.xml copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-s390-defaultconsole.xml => qemuxml2xmlout-s390-serial-console.xml} (50%) copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-s390-defaultconsole.xml => qemuxml2xmlout-s390-serial.xml} (50%) -- 2.13.6

5 46

[libvirt] [jenkins-ci PATCH 0/3] Add Fedora 27, remove Fedora 25
by Andrea Bolognani 20 Nov '17

20 Nov '17

'tis the season. Andrea Bolognani (3): Add Fedora 27 builder Remove Fedora 25 builder guests: Adjust Fedora 26 install URL guests/host_vars/libvirt-fedora-26/install.yml | 2 +- .../install.yml | 2 +- .../main.yml | 0 guests/inventory | 2 +- guests/vars/vault.yml | 90 +++++++++++----------- projects/libosinfo.yaml | 4 +- projects/libvirt-cim.yaml | 2 +- projects/libvirt-glib.yaml | 4 +- projects/libvirt-go-xml.yaml | 2 +- projects/libvirt-go.yaml | 2 +- projects/libvirt-perl.yaml | 4 +- projects/libvirt-python.yaml | 4 +- projects/libvirt-sandbox.yaml | 4 +- projects/libvirt-tck.yaml | 4 +- projects/libvirt.yaml | 6 +- projects/osinfo-db-tools.yaml | 4 +- projects/osinfo-db.yaml | 4 +- projects/virt-manager.yaml | 4 +- projects/virt-viewer.yaml | 4 +- 19 files changed, 74 insertions(+), 74 deletions(-) rename guests/host_vars/{libvirt-fedora-25 => libvirt-fedora-27}/install.yml (74%) rename guests/host_vars/{libvirt-fedora-25 => libvirt-fedora-27}/main.yml (100%) -- 2.14.3

2 6

[libvirt] [PATCH 0/2] tests: commandtest: handle tcmalloc hacking environment
by Nikolay Shirokovskiy 20 Nov '17

20 Nov '17

3 11

[libvirt] [PATCH 0/6] Implement query-dump command
by John Ferlan 20 Nov '17

20 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=916061 Details in the patches. Essentially though QEMU 2.6 added the ability to perform the 'dump-guest-memory' via a thread by adding a 'detach' boolean to the command. In order to watch the progress of the thread the 'query-dump' command was added. The query-dump will return just the current status, the total size to be dumped, and the current progress. So using the migrate stats data in the DomainJobInfo we can then save our current progress allowing tools such as virsh to watch that progress. As an added benefit, the dump-guest-memory is now truly asynchronous. John Ferlan (6): qemu: Fix the qemuDumpToFd definition qemu: Alter dump-guest-memory command generation qemu: Add query-dump to the capabilities qemu: Introduce qemuMonitor[JSON]QueryDump qemu: Add new @detach parameter to dump-guest-memory qemu: Allow showing the dump progress for memory only dump src/qemu/qemu_capabilities.c | 4 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_driver.c | 95 ++++++++++++++++++++-- src/qemu/qemu_monitor.c | 25 +++++- src/qemu/qemu_monitor.h | 25 +++++- src/qemu/qemu_monitor_json.c | 91 +++++++++++++++++---- src/qemu/qemu_monitor_json.h | 7 +- .../caps_2.10.0-gicv2.aarch64.xml | 1 + .../caps_2.10.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.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.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + tests/qemumonitorjsontest.c | 3 +- 24 files changed, 240 insertions(+), 27 deletions(-) -- 2.13.6

2 8

[libvirt] [PATCH] docs: don't use https in XML namespace URIs
by Daniel P. Berrange 20 Nov '17

20 Nov '17

The XML namespace URI for the QEMU/LXC drivers must use http as the protocol otherwise it won't match the parser's expectations. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/drvlxc.html.in | 2 +- docs/drvqemu.html.in | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index 94c6b82cfd..58a336ed30 100644 --- a/docs/drvlxc.html.in +++ b/docs/drvlxc.html.in @@ -601,7 +601,7 @@ rather than creating new network namespace for the container. In this case privn ignored. </p> <pre> -<domain type='lxc' xmlns:lxc='https://libvirt.org/schemas/domain/lxc/1.0'> +<domain type='lxc' xmlns:lxc='http://libvirt.org/schemas/domain/lxc/1.0'> ... <lxc:namespace> <lxc:sharenet type='netns' value='red'/> diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in index e2a0797cfb..cb41b505d7 100644 --- a/docs/drvqemu.html.in +++ b/docs/drvqemu.html.in @@ -546,7 +546,7 @@ $ virsh domxml-to-native qemu-argv demo.xml (<span class="since">Since 0.8.3</span>). In order to use the XML additions, it is necessary to issue an XML namespace request (the special <code>xmlns:<i>name</i></code> attribute) that - pulls in <code>https://libvirt.org/schemas/domain/qemu/1.0</code>; + pulls in <code>http://libvirt.org/schemas/domain/qemu/1.0</code>; typically, the namespace is given the name of <code>qemu</code>. With the namespace in place, it is then possible to add an element <code><qemu:commandline></code> @@ -566,7 +566,7 @@ $ virsh domxml-to-native qemu-argv demo.xml and optional <code>value</code>.</dd> </dl> <p>Example:</p><pre> -<domain type='qemu' xmlns:qemu='https://libvirt.org/schemas/domain/qemu/1.0'> +<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>QEmu-fedora-i686</name> <memory>219200</memory> <os> -- 2.14.3

2 1

[libvirt] [PATCH] AppArmor: add rules needed with additional mediation features brought by Linux 4.14.
by intrigeri 19 Nov '17

19 Nov '17

--- examples/apparmor/libvirt-qemu | 2 ++ examples/apparmor/usr.sbin.libvirtd | 9 +++++++++ 2 files changed, 11 insertions(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index b341e31f42..5994a35042 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -16,6 +16,8 @@ network inet stream, network inet6 stream, + signal (receive) set=("term") peer=/usr/sbin/libvirtd, + /dev/net/tun rw, /dev/kvm rw, /dev/ptmx rw, diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 819068ffc3..17b5ee38ff 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -30,6 +30,8 @@ # Needed for vfio capability sys_resource, + mount, + network inet stream, network inet dgram, network inet6 stream, @@ -37,11 +39,18 @@ network packet dgram, network packet raw, + network netlink raw, + network unix dgram, + network unix stream, + ptrace (trace) peer=unconfined, ptrace (trace) peer=/usr/sbin/libvirtd, ptrace (trace) peer=/usr/sbin/dnsmasq, ptrace (trace) peer=libvirt-*, + signal (send) set=("hup") peer=/usr/sbin/dnsmasq, + signal (send) set=("term") peer=libvirt-*, + # Very lenient profile for libvirtd since we want to first focus on confining # the guests. Guests will have a very restricted profile. / r, -- 2.15.0.rc2

5 16

[libvirt] [PATCH 0/2] vmcoreinfo feature
by marcandre.lureau＠redhat.com 18 Nov '17

18 Nov '17

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, Starting with QEMU 2.11, the guest can save kernel debug details when this feature is enabled and the kernel supports it. It is useful to process kernel dump with KASLR enabled, and also provides various kernel details to crash tools. rfc->v1: - rebased - update commit message to give some internal fw_cfg details - add news patch Marc-André Lureau (2): qemu: add vmcoreinfo support news: add vmcoreinfo feature details docs/formatdomain.html.in | 4 +++ docs/news.xml | 11 +++++++ docs/schemas/domaincommon.rng | 9 +++++ src/conf/domain_conf.c | 3 ++ src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 26 +++++++++++++++ .../qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args | 25 ++++++++++++++ tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml | 28 ++++++++++++++++ tests/qemuxml2argvtest.c | 1 + .../qemuxml2xmlout-vmcoreinfo.xml | 38 ++++++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 13 files changed, 150 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml -- 2.15.0.125.g8f49766d64

2 3

[libvirt] [PATCH] xenconfig: fix compilation error
by Jim Fehlig 17 Nov '17

17 Nov '17

Commit 03d0959a introduced a compilation error in src/xenconfig/xen_xl.c on ARM. Found by Xen's osstest http://logs.test-lab.xenproject.org/osstest/logs/116216/build-armhf-libvirt… Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- Pushing under the build-breaker rule. src/xenconfig/xen_xl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c index 05146d7db..984024bba 100644 --- a/src/xenconfig/xen_xl.c +++ b/src/xenconfig/xen_xl.c @@ -1261,11 +1261,11 @@ xenFormatXLVnuma(virConfValuePtr list, numaVnode->list = NULL; /* pnode */ - virBufferAsprintf(&buf, "pnode=%ld", node); + virBufferAsprintf(&buf, "pnode=%zu", node); xenFormatXLVnode(numaVnode, &buf); /* size */ - virBufferAsprintf(&buf, "size=%ld", nodeSize); + virBufferAsprintf(&buf, "size=%zu", nodeSize); xenFormatXLVnode(numaVnode, &buf); /* vcpus */ -- 2.15.0

1 0

[libvirt] [PATCH v2] docs: add a page describing support guarantees for libvirt features
by Daniel P. Berrange 17 Nov '17

17 Nov '17

While we have collective knowledge about the support status of various parts of libvirt, this has never been formally documented, leaving our users to guess. Note, this document makes one change to our previous policy. It explicitly declares the RPC protocol of libvirtd as being a supported interface. THis accepts the reality that we can a) never change it without breaking compat with old libvirt.so, b) there are both rust + go impls that are written against the RPC protocol alrady. Reviewed-by: Jim Fehlig <jfehlig(a)suse.com> Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Changed in v2: - Spelling fixes (Jim) - Call out new RPC policy in commit msg docs/docs.html.in | 3 + docs/support.html.in | 257 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 260 insertions(+) create mode 100644 docs/support.html.in diff --git a/docs/docs.html.in b/docs/docs.html.in index 931da85424..a8d544f83f 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -110,6 +110,9 @@ <dt><a href="drivers.html">Drivers</a></dt> <dd>Hypervisor specific driver information</dd> + <dt><a href="support.html">Support guarantees</a></dt> + <dd>Details of support status for various interfaces</dd> + <dt><a href="hvsupport.html">Driver support</a></dt> <dd>matrix of API support per hypervisor per release</dd> diff --git a/docs/support.html.in b/docs/support.html.in new file mode 100644 index 0000000000..7a377e6152 --- /dev/null +++ b/docs/support.html.in @@ -0,0 +1,257 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Support guarantees</h1> + + <ul id="toc"></ul> + + <p> + This document will outline the support status / guarantees around the + very interfaces that libvirt exposes to applications and/or system + administrators. The intent is to help users understand what features they + can rely upon in particular scenarios, and whether they are likely to + suffer disruption during upgrades + </p> + + <h2><a id="publicAPI">Primary public API</a></h2> + + <p> + The main public API provided by <code>libvirt.so</code> and described + in <code>libvirt/libvirt.h</code> exposes the primary hypervisor + agnostic management interface of libvirt. This API has the strongest + guarantee of any part of libvirt with a promise to keep backwards + compatibility forever. Specific details are as follows: + </p> + + <dl> + <dt>Functions</dt> + <dd>Functions will never be removed from the public API, and will + never have parameters added, removed or changed in their signature. + IOW they will be ABI compatible forever. The semantics implied by + a specific set of parameters passed to the function will remain + unchanged. Where a parameter accepts a bitset of feature flags, or + an enumerated value, further flags / enum values may be supported + in the future. Where a parameter accepts one of a set of related + constants, further constants may be supported in the future. + </dd> + <dt>Struct types</dt> + <dd>Once defined in a release, struct definitions will never have any + fields add, removed or changed in any way. Their size and layout is + fixed forever. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Union types</dt> + <dd>Once defined in a release, union definitions will never have any + existing fields removed or changed. New union choices may be added, + provided that they don't change the size of the existing union + definition. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Type definitions</dt> + <dd>Most custom data types used in the APIs have corresponding typedefs + provided for their stable names. The typedefs should always be used + in preference to the underlying data type name, as the latter are not + guaranteed to be stable. + </dd> + <dt>Enumerations</dt> + <dd>Once defined in a release, existing enumeration values will never + be removed or renamed. New enumeration values may be introduced at + any time. Every enumeration will have a '_LAST' value which indicates + the current highest enumeration value, which may increase with new + releases. If an enumeration name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the enum name. + </dd> + <dt>Constants</dt> + <dd>Once defined in a release, existing constants will never be removed + or have their value changed. Most constants are grouped into related + sets, and within each set, new constants may be introduced. APIs which + use the constants may thus accept or return new constant values over + time. + </dd> + <dt>Symbol versions</dt> + <dd>Where the platform library format permits, APIs defined in libvirt.so + library will have version information associated. Each API will be + tagged with the version in which it was introduced, and this won't + be changed thereafter. + </dd> + </dl> + + <h2><a id="hvAPI">Hypervisor specific APIs</a></h2> + + <p> + A number of hypervisor drivers provide additional libraries with hypervisor + specific APIs, extending the core libvirt API. These add-on libraries follow + the same general principles described above, however, they are <strong>not</strong> + guaranteed to be preserved forever. The project reserves the right to remove + hypervisor specific APIs in any new release, or to change their semantics. + That said the project will endeavour to maintain API compatibility for as long + as is practical. + </p> + + <p> + Use of some hypervisor specific APIs may result in the running guest being + marked as "tainted" if the API is at risk of having unexpected interactions + with normal libvirt operations. An application which chooses to make use of + hypervisor specific APIs should validate their operation with each new release + of libvirt and each new release of the underlying hypervisor. The semantics + may change in unexpected ways, or have unforeseen interactions with libvirt's + operation. + </p> + + <h2><a id="apierrors">Error reporting</a></h2> + + <p> + Most API calls are subject to failure and so will report error codes and + messages. Libvirt defines error codes for a wide variety of scenarios, some + represent very specific problems, while others are general purpose for + broad classes of problem. Over time the error codes reported are liable + to change, usually changing from a generic error to a more specific error. + Thus applications should be careful about checking for & taking action + upon specific error codes, as their behaviour may change across releases. + </p> + + <h2><a id="xmlschema">XML schemas</a></h2> + + <p> + The main objects exposed via the primary libvirt public API are usually + configured via XML documents following specific schemas. The XML schemas + are considered to be stable formats, whose compatibility will be maintained + forever. Specific details are as follows: + </p> + + <dl> + <dt>Attributes</dt> + <dd>Attributes defined on an XML element will never be removed or + renamed. New attributes may be defined. If the set of valid values + for an attribute are determined by an enumeration, the permitted + values will never be removed or renamed, only new values defined. + None the less, specific hypervisors may reject usage of certain + values according to their feature set.</dd> + <dt>Elements</dt> + <dd>Elements defined will never be removed or renamed. New child + elements may be defined at any time. In places where only a + single instance of a named XML element is used, future versions + may be extended to permit multiple instances of the named XML + element to be used. An element which currently has no content + may later gain child elements. + </dd> + </dl> + + <p> + Some hypervisor drivers may choose to allow use of hypervisor specific + extensions to the XML documents. These extensions will always be + contained within a hypervisor specific XML namespace. There is generally + no guarantee of long term support for the hypervisor specific extensions + across releases, though the project will endeavour to preserve them as + long as is possible. Applications choosing to use hypervisor specific + extensions should validate their operation against new libvirt or + hypervisor releases. + </p> + + <h2><a id="configfiles">Configuration files</a></h2> + + <p> + A number of programs / daemons provided libvirt rely on host filesystem + configuration files. These configuration files are accompanied by augeas + lens for easy manipulation by applications. There is in general no + guarantee that parameters available in the configuration file will be + preserved across releases, though the project will endeavour to preserve + them as long as is possible. If a configuration option is dropped from + the file, the augeas lens will retain the ability to read that configuration + parameter, so that it is able to read & update historically modified + files. + + The default configuration files ship with all parameters commented out + such that a deployment relies on the built-in defaults of the application + in question. There is no guarantee that the defaults will remain the same + across releases. A deployment that expects a particular value for a + configuration parameter should consider defining it explicitly, instead + of relying on the defaults. + </p> + + <h2><a id="hvdrivers">Hypervisor drivers</a></h2> + + <p> + The libvirt project provides support for a wide variety of hypervisor + drivers. These drivers target certain versions of the hypervisor's + underlying management APIs. In general libvirt aims to work with any + hypervisor version that is still broadly supported by its vendor. + When a vendor discontinues support for a particular hypervisor + version it will be dropped by libvirt. Libvirt may choose to drop + support for a particular hypervisor version prior to the vendor + ending support, if it deems that the likely usage is too small to + justify the ongoing maintenance cost. + </p> + <p> + Each hypervisor release will implement a distinct subset of features + that can be expressed in the libvirt APIs and XML formats. While the + XML schema syntax will be stable across releases, libvirt is unable + to promise that it will always be able to support usage of the same + features across hypervisor releases. Where a hypervisor changes the + way a feature is implemented, the project will endeavour to adapt + to the new implementation to provide the same semantics. In cases + where the feature is discontinued by the hypervisor, libvirt will + return an error indicating it is not supported. Likewise libvirt will + make reasonable efforts to keep API calls working across hypervisor + releases even if the underlying implementation changes. In cases where + this is impossible, an suitable error will be reported. The list of + APIs which have implementations <a href="hvsupport.html">is detailed separately</a>. + </p> + + <h2><a id="rpcproto">RPC protocol</a></h2> + + <p> + For some hypervisor drivers, the libvirt.so library communicates with + separate libvirt daemons to perform work. This communication takes + place over a binary RPC protocol defined by libvirt. The protocol uses + the XDR format for data encoding, and the message packet format is + defined in libvirt source code. + </p> + <p> + Applications are encouraged to use the primary libvirt.so library which + transparently talks to the daemons, so that they are not exposed to the + hypervisor driver specific details. None the less, the RPC protocol + associated with the libvirtd is considered to be a long term stable ABI. + It will only ever have new messages added to it, existing messages will + not be removed, nor have their contents changed. Thus if an application + does wish to provide its own client side implementation of the RPC + protocol this is supported, with the caveat that the application will + loose the ability to work with certain hypervisors libvirt supports. + The project reserves the right to define new authentication and encryption + options for the protocol, and the defaults used in this area may change + over time. This is particularly true of the TLS ciphers permitted. Thus + applications choosing to implement the RPC protocol must be prepared to + track support for new security options. If defaults are changed, however, + it will generally be possible to reconfigure the daemon to use the old + defaults, albeit with possible implications for system security. + </p> + + <p> + Other daemons besides, libvirtd, also use the same RPC protocol, but + with different message types defined. These RPC protocols are all + considered to be private implementations that are liable to change + at any time. Applications must not attempt to talk to these other + daemons directly. + </p> + + <h2><a id="virsh">virsh client</a></h2> + + <p> + The virsh program provides a simple client to interact with an arbitrary libvirt + hypevisor connection. Since it uses the primary public API of libvirt, it should + generally inherit the guarantees associated with that API, and with the hypervisor + driver. The commands that virsh exposes, and the arguments they accept are all + considered to be long term stable. Existing commands and arguments will not be + removed or renamed. New commands and arguments may be added in new releases. + The text output format produced by virsh commands is not generally guaranteed to + be stable if it contains compound data (eg formatted tables or lists). Commands + which output single data items (ie an object name, or an XML document), can be + treated as having stable format. + </p> + + </body> +</html> -- 2.14.3

2 2

[libvirt] [PATCH] docs: add a page describing support guarantees for libvirt features
by Daniel P. Berrange 16 Nov '17

16 Nov '17

While we have collective knowledge about the support status of various parts of libvirt, this has never been formally documented, leaving our users to guess. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/docs.html.in | 3 + docs/support.html.in | 257 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 260 insertions(+) create mode 100644 docs/support.html.in diff --git a/docs/docs.html.in b/docs/docs.html.in index 931da85424..a8d544f83f 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -110,6 +110,9 @@ <dt><a href="drivers.html">Drivers</a></dt> <dd>Hypervisor specific driver information</dd> + <dt><a href="support.html">Support guarantees</a></dt> + <dd>Details of support status for various interfaces</dd> + <dt><a href="hvsupport.html">Driver support</a></dt> <dd>matrix of API support per hypervisor per release</dd> diff --git a/docs/support.html.in b/docs/support.html.in new file mode 100644 index 0000000000..6f34a35eb7 --- /dev/null +++ b/docs/support.html.in @@ -0,0 +1,257 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Support guarantees</h1> + + <ul id="toc"></ul> + + <p> + This document will outline the support status / guarantees around the + very interfaces that libvirt exposes to applications and/or system + adminstrators. The intent is to help users understand what features they + can rely upon in particular scenarios, and whether they are likely to + suffer disruption during upgrades + </p> + + <h2><a id="publicAPI">Primary public API</a></h2> + + <p> + The main public API provided by <code>libvirt.so</code> and described + in <code>libvirt/libvirt.h</code> exposes the primary hypervisor + agnostic management interface of libvirt. This API has the strongest + guarantee of any part of libvirt with a promise to keep backwards + compatibility forever. Specific details are as follows: + </p> + + <dl> + <dt>Functions</dt> + <dd>Functions will never be removed from the public API, and will + never have parameters added, removed or changed in their signature. + IOW they will be ABI compatible forever. The semantics implied by + a specific set of parameters passed to the function will remain + unchanged. Where a parameter accepts a bitset of feature flags, or + an enumerated value, further flags / enum values may be supported + in the future. Where a parameter accepts one of a set of related + constants, further constants may be supported in the future. + </dd> + <dt>Struct types</dt> + <dd>Once defined in a release, struct definitions will never have any + fields add, removed or changed in any way. Their size and layout is + fixed forever. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Union types</dt> + <dd>Once defined in a release, union definitions will never have any + existing fields removed or changed. New union choices may be added, + provided that they don't change the size of the existing union + definition. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Type definitions</dt> + <dd>Most custom data types used in the APIs have corresponding typedefs + provided for their stable names. The typedefs should always be used + in preference to the underlying data type name, as the latter are not + guaranteed to be stable. + </dd> + <dt>Enumerations</dt> + <dd>Once defined in a release, existing enumeration values will never + be removed or renamed. New enumeration values may be introduced at + any time. Every enumeration will have a '_LAST' value which indicates + the current highest enumeration value, which may increase with new + releases. If an enumeration name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the enum name. + </dd> + <dt>Constants</dt> + <dd>Once defined in a release, existing constants will never be removed + or have their value changed. Most constants are grouped into related + sets, and within each set, new constants may be introduced. APIs which + use the constants may thus accept or return new constant values over + time. + </dd> + <dt>Symbol versions</dt> + <dd>Where the platform library format permits, APIs defined in libvirt.so + library will have version information associated. Each API will be + tagged with the version in which it was introduced, and this won't + be changed thereafter. + </dd> + </dl> + + <h2><a id="hvAPI">Hypervisor specific APIs</a></h2> + + <p> + A number of hypervisor drivers provide additional libraries with hypervisor + specific APIs, extending the core libvirt API. These add-on libraries follow + the same general principles described above, however, they are <strong>not</strong> + not guranteed to be preserved forever. The project reserves the right to remove + hypervisor specific APIs in any new release, or to change their semantics. + That said the project will endeavour to maintain API compatibility for as long + as is practical. + </p> + + <p> + Use of some hypervisor specific APIs may result in the running guest being + marked as "tainted" if the API is at risk of having unexpected interactions + with normal libvirt operations. An application which chooses to make use of + hypervisor specific APIs should validate their operation with each new release + of libvirt and each new release of the underlying hypervisor. The semantics + may change in unexpected ways, or have unforseen interactions with libvirt's + operation. + </p> + + <h2><a id="apierrors">Error reporting</a></h2> + + <p> + Almost API calls are subject to failure and so will report error codes and + messages. Libvirt defines error codes for a wide variety of scenarios, some + are very targetted to specific problems, while others are general purpose + for broad classes of problem. Over time the error codes reported are liable + to, usually changing from a generic error to a more specific error. Thus + applications should be careful about checking for & taking action upon + specific error codes, as the behaviour is liable to change across releases. + </p> + + <h2><a id="xmlschema">XML schemas</a></h2> + + <p> + The main objects exposed via the primary libvirt public API are usually + configured via XML documents following specific schemas. The XML schemas + are considered to be stable formats, whose compatibility will be maintained + forever. Specific details are as follows: + </p> + + <dl> + <dt>Attributes</dt> + <dd>Attributes defined on an XML element will never be removed or + renamed. New attributes may be defined. If the set of valid values + for an attribute are determined by an enumeration, the permitted + values will never be removed or renamed, only new values defined. + None the less, specific hypervisors may reject usage of certain + values according to their feature set.</dd> + <dt>Elements</dt> + <dd>Elements defined will never be removed or renamed. New child + elements may be defined at any time. In places where only a + single instance of a named XML element is used, future versions + may be extended to permit multiple instances of the named XML + element to be used. An element which currently has no content + may later gain child elements. + </dd> + </dl> + + <p> + Some hypervisor drivers may choose to allow use of hypervisor specific + extensions to the XML documents. These extensions will always be + contained within a hypervisor specific XML namespace. There is generally + no guarantee of long term support for the hypervisor specific extensions + across releases, though the project will endeavour to preserve them as + long as is possible. Applications choosing to use hypervisor specific + extensions should validate their operation against new libvirt or + hypervisor releases. + </p> + + <h2><a id="configfiles">Configuration files</a></h2> + + <p> + A number of programs / daemons provided libvirt rely on host filesystem + configuration files. These configuration files are accompanied by augeas + lens for easy manipulation by applications. There is in general no + guarantee that parameters available in the configuration file will be + preserved across releases, though the project will endeavour to preserve + them as long as is possible. If a configuration option is dropped from + the file, the augeas lens will retain the ability to read that configuration + parameter, so that it is able to read & update historically modified + files. + + The default configuration files ship with all parameters commented out + such that a deployment relies on the built-in defaults of the application + in question. There is no guarantee that the defaults will remain the same + across releases. An deployments that expects a particular value for a + configuration parameter should consider defining it explicitly, instead + of relying on the defaults. + </p> + + <h2><a id="hvdrivers">Hypervisor drivers</a></h2> + + <p> + The libvirt project provides support for a wide variety of hypervisor + drivers. These drivers target certain versions of the hypervisor's + underlying management APIs. In general libvirt aims to work with any + hypervisor version that is still broadly supported by its vendor. + When a vendor discontinues support for a particular hypervisor + version it will be dropped by libvirt. Libvirt may choose to drop + support for a particular hypervisor version prior to the vendor + ending support, if it deems that the likely usage is too small to + justify the ongoing maintenance cost. + </p> + <p> + Each hypervisor release will implement a distinct subset of features + that can be expressed in the libvirt APIs and XML formats. While the + XML schema syntax will be stable across releases, libvirt is unable + to promise that it will always be able to support usage of the same + features across hypervisor releases. Where a hypervisor changes the + way a feature is implemented, the project will endeavour to adapt + to the new implementation to provide the same semantics. In cases + where the feature is discontinued by the hypervisor, libvirt will + return an error indicating it is no supported. Likewise libvirt will + make reasonable efforts to keep API calls working across hypervisor + releases even if the underlying implementation changes. In cases where + this is impossible, an suitable error will be reported. The list of + APIs which have implementations <a href="hvsupport.html">is detailed separately</a>. + </p> + + <h2><a id="rpcproto">RPC protocol</a></h2> + + <p> + For some hypervisor drivers, the libvirt.so library communicates with + separate libvirt daemons to perform work. This communication takes + place over a binary RPC protocol defined by libvirt. The protocol uses + the XDR format for data encoding, and the message packet format is + defined in libvirt source code. + </p> + <p> + Applications are encouraged to use the primary libvirt.so library which + transparently talks to the daemons, so that they are not exposed to the + hypervisor driver specific details. None the less, the RPC protocol + associated with the libvirtd is considered to be a long term stable ABI. + It will only ever have new messages added to it, existing messages will + not be removed, nor have their contents changed. Thus if an application + does wish to provide its own client side implementation of the RPC + protocol this is supported, with the caveat that the application will + loose the ability to work with certain hypervisors libvirt supports. + The project reserves the right to define new authentication and encryption + options for the protocol, and the defaults used in this area may change + over time. This is particularly true of the TLS ciphers permitted. Thus + applications choosing to implement the RPC protocol must be prepared to + track support for new security options. If defaults are changed, however, + it will generally be possible to reconfigure the daemon to use the old + defaults, albeit with possible implications for system security. + </p> + + <p> + Other daemons besides, libvirtd, also use the same RPC protocol, but + with different message types defined. These RPC protocols are all + considered to be private implementation that are liable to change + at any time. Applications must not attempt to talk to these other + daemons directly. + </p> + + <h2><a id="virsh">virsh client</a></h2> + + <p> + The virsh program provides a simple client to interact with an arbitrary libvirt + hypevisor connection. Since it uses the primary public API of libvirt, it should + generally inherit the guarantees associated with that API, and with the hypervisor + driver. The commands that virsh exposes, and the arguments they accept are all + considered to be long term stable. Existing commands and arguments will not be + removed or renamed. New commands and arguments may be added in new releases. + The text output format produced by virsh commands is not generally guaranteed to + be stable if it contains compound data (eg formatted tables or lists). Commands + which output single data items (ie an object name, or an XML document), can be + treated as having stable format. + </p> + + </body> +</html> -- 2.14.3

2 1

[libvirt] [PATCH] virt-viewer.spec.in: fix build after spice-xpi-client removal
by marcandre.lureau＠redhat.com 16 Nov '17

16 Nov '17

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> This fixes commit 140cb84c2538bf0eab7dea2035dfecc4db74c784, where we removed the spice-xpi-client-remote-viewer. Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- virt-viewer.spec.in | 8 -------- 1 file changed, 8 deletions(-) diff --git a/virt-viewer.spec.in b/virt-viewer.spec.in index 44ef92e..54e2121 100644 --- a/virt-viewer.spec.in +++ b/virt-viewer.spec.in @@ -89,9 +89,6 @@ autoreconf -if %install rm -rf $RPM_BUILD_ROOT %__make install DESTDIR=$RPM_BUILD_ROOT -mkdir -p %{buildroot}%{_libexecdir} -touch %{buildroot}%{_libexecdir}/spice-xpi-client -install -m 0755 data/spice-xpi-client-remote-viewer %{buildroot}%{_libexecdir}/ %find_lang %{name} %clean @@ -100,8 +97,6 @@ rm -rf $RPM_BUILD_ROOT %post /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null || : /bin/touch --no-create %{_datadir}/mime/packages &> /dev/null || : -%{_sbindir}/update-alternatives --install %{_libexecdir}/spice-xpi-client \ - spice-xpi-client %{_libexecdir}/spice-xpi-client-remote-viewer 25 /usr/bin/update-desktop-database -q %{_datadir}/applications %postun @@ -109,7 +104,6 @@ if [ $1 -eq 0 ] ; then /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : /usr/bin/update-mime-database %{_datadir}/mime &> /dev/null || : - %{_sbindir}/update-alternatives --remove spice-xpi-client %{_libexecdir}/spice-xpi-client-remote-viewer fi /usr/bin/update-desktop-database -q %{_datadir}/applications @@ -127,8 +121,6 @@ fi %{_datadir}/applications/remote-viewer.desktop %{_datadir}/appdata/remote-viewer.appdata.xml %{_datadir}/mime/packages/virt-viewer-mime.xml -%ghost %{_libexecdir}/spice-xpi-client -%{_libexecdir}/spice-xpi-client-remote-viewer %{_mandir}/man1/virt-viewer.1* %{_mandir}/man1/remote-viewer.1* -- 2.15.0.125.g8f49766d64

2 1

[libvirt] [jenkins-ci PATCH 0/2] Small fixes
by Andrea Bolognani 16 Nov '17

16 Nov '17

Andrea Bolognani (2): jobs: Use $MAKE in autotools-mingw-job projects: Use {smp} in osinfo-db-master-build jobs/autotools.yaml | 8 ++++---- projects/osinfo-db.yaml | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.14.3

2 4

[libvirt] [jenkins-ci PATCH] projects: Port libvirt-cim to autotools-*-job
by Andrea Bolognani 16 Nov '17

16 Nov '17

Now that libvirt-cim's autogen.sh script has been changed to be compatible with the ones used by other libvirt-related project, we can drop the ad-hoc rules used to build it and adopt the standard autotools-*-job rules instead. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Not to be pushed until https://www.redhat.com/archives/libvir-list/2017-November/msg00675.html has been merged into libvirt-cim. projects/libvirt-cim.yaml | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml index b5405f3..d09db86 100644 --- a/projects/libvirt-cim.yaml +++ b/projects/libvirt-cim.yaml @@ -9,17 +9,7 @@ - libvirt-fedora-rawhide title: libvirt CIM jobs: - - generic-build-job: + - autotools-build-job: parent_jobs: 'libvirt-master-build' - command: | - {make_env} - ./autogen.sh - ./configure --prefix=$VIRT_PREFIX - $MAKE -j{smp} - $MAKE -j{smp} install - - generic-rpm-job: + - autotools-rpm-job: parent_jobs: 'libvirt-cim-master-build' - command: | - {make_env} - sed -i -e "s/.*libvirt-devel.*//" libvirt-cim.spec.in - $MAKE -j{smp} rpm -- 2.14.3

2 1

[libvirt] [cim PATCH 0/3] autogen.sh improvements
by Andrea Bolognani 16 Nov '17

16 Nov '17

These changes are a requirement for porting the libvirt-cim CI jobs to autotools-*-job. Andrea Bolognani (3): autogen: Better error handling autogen: Run configure automatically autogen: Support running out-of-tree autogen.sh | 48 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 37 insertions(+), 11 deletions(-) -- 2.14.3

2 4

[libvirt] [PATCH v2 0/3] Fix user provided aliases for some devices
by Michal Privoznik 16 Nov '17

16 Nov '17

In case user provides an alias for a device that is implicit (e.g. IDE controller for 440fx, SATA for Q35, etc.) we don't put the device onto qemu command line. Therefore we can't set its alias. diff to v1: - more controllers covered Michal Privoznik (3): virQEMUCapsHasPCIMultiBus: Fix @def type qemuBuildDriveDevStr: Prefer default alias for SATA bus qemuBuildDeviceAddressStr: Prefer default alias for PCI bus src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_capabilities.h | 2 +- src/qemu/qemu_command.c | 45 ++++++++++++++++------ .../qemuxml2argvdata/qemuxml2argv-user-aliases.xml | 4 +- .../qemuxml2argv-user-aliases2.args | 1 + .../qemuxml2argv-user-aliases2.xml | 34 ++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 7 files changed, 75 insertions(+), 14 deletions(-) create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-user-aliases2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-user-aliases2.xml -- 2.13.6

2 5

[libvirt] [PATCH] RFC: qemu: add vmcoreinfo support
by marcandre.lureau＠redhat.com 16 Nov '17

16 Nov '17

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg entry for a guest to store dump details, necessary to process kernel dump with KASLR enabled and providing additional kernel details. Since the device is a singleton and shouldn't use additional hardware resources, I decided to map this to a <feature> element in the libvirt domain XML. Feel free to argue and decide if it is better to have it under <devices> instead. The device is arm/x86 only for now (targets that support fw_cfg+dma). Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1395248 Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- docs/formatdomain.html.in | 4 +++ docs/schemas/domaincommon.rng | 5 +++ src/conf/domain_conf.c | 5 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 26 +++++++++++++++ .../qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args | 25 ++++++++++++++ tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml | 28 ++++++++++++++++ tests/qemuxml2argvtest.c | 1 + .../qemuxml2xmlout-vmcoreinfo.xml | 38 ++++++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 12 files changed, 136 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 92e14a919..d87a32a89 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1878,6 +1878,10 @@ which is also known as a split I/O APIC mode. <span class="since">Since 3.4.0</span> (QEMU/KVM only) </dd> + <dt><code>vmcoreinfo</code></dt> + <dd>Enable QEMU vmcoreinfo device to let the guest kernel save debug + details. <span class="since">Since 3.10.0</span> (QEMU only) + </dd> </dl> <h3><a id="elementsTime">Time keeping</a></h3> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 9cec1a063..86cbe2c8c 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4736,6 +4736,11 @@ <optional> <ref name="ioapic"/> </optional> + <optional> + <element name="vmcoreinfo"> + <empty/> + </element> + </optional> </interleave> </element> </optional> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 400e90032..3a9b56cd2 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -148,7 +148,8 @@ VIR_ENUM_IMPL(virDomainFeature, VIR_DOMAIN_FEATURE_LAST, "vmport", "gic", "smm", - "ioapic") + "ioapic", + "vmcoreinfo") VIR_ENUM_IMPL(virDomainCapabilitiesPolicy, VIR_DOMAIN_CAPABILITIES_POLICY_LAST, "default", @@ -18710,6 +18711,7 @@ virDomainDefParseXML(xmlDocPtr xml, case VIR_DOMAIN_FEATURE_VIRIDIAN: case VIR_DOMAIN_FEATURE_PRIVNET: case VIR_DOMAIN_FEATURE_HYPERV: + case VIR_DOMAIN_FEATURE_VMCOREINFO: case VIR_DOMAIN_FEATURE_KVM: def->features[val] = VIR_TRISTATE_SWITCH_ON; break; @@ -26052,6 +26054,7 @@ virDomainDefFormatInternal(virDomainDefPtr def, case VIR_DOMAIN_FEATURE_ACPI: case VIR_DOMAIN_FEATURE_PAE: case VIR_DOMAIN_FEATURE_VIRIDIAN: + case VIR_DOMAIN_FEATURE_VMCOREINFO: case VIR_DOMAIN_FEATURE_PRIVNET: switch ((virTristateSwitch) def->features[i]) { case VIR_TRISTATE_SWITCH_ABSENT: diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index be38792c6..add668025 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1723,6 +1723,7 @@ typedef enum { VIR_DOMAIN_FEATURE_GIC, VIR_DOMAIN_FEATURE_SMM, VIR_DOMAIN_FEATURE_IOAPIC, + VIR_DOMAIN_FEATURE_VMCOREINFO, VIR_DOMAIN_FEATURE_LAST } virDomainFeature; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 7cb091056..44a2833a7 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -443,6 +443,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, /* 270 */ "vxhs", "virtio-blk.num-queues", + "vmcoreinfo", ); @@ -1670,6 +1671,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = { { "pcie-root-port", QEMU_CAPS_DEVICE_PCIE_ROOT_PORT }, { "qemu-xhci", QEMU_CAPS_DEVICE_QEMU_XHCI }, { "spapr-pci-host-bridge", QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE }, + { "vmcoreinfo", QEMU_CAPS_DEVICE_VMCOREINFO }, }; static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtioBalloon[] = { diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index cacc2b77e..0cd9755a8 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -429,6 +429,7 @@ typedef enum { /* 270 */ QEMU_CAPS_VXHS, /* -drive file.driver=vxhs via query-qmp-schema */ QEMU_CAPS_VIRTIO_BLK_NUM_QUEUES, /* virtio-blk-*.num-queues */ + QEMU_CAPS_DEVICE_VMCOREINFO, /* -device vmcoreinfo */ QEMU_CAPS_LAST /* this must always be the last item */ } virQEMUCapsFlags; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 8708b79ed..b903b27b9 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -9727,6 +9727,29 @@ qemuBuildTPMCommandLine(virCommandPtr cmd, } +static int +qemuBuildVMCoreInfoCommandLine(virCommandPtr cmd, + const virDomainDef *def, + virQEMUCapsPtr qemuCaps) +{ + virTristateSwitch vmci = def->features[VIR_DOMAIN_FEATURE_VMCOREINFO]; + + if (vmci != VIR_TRISTATE_SWITCH_ON) { + return 0; + } + + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VMCOREINFO)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("vmcoreinfo is not available " + "with this QEMU binary")); + return -1; + } + + virCommandAddArgList(cmd, "-device", "vmcoreinfo", NULL); + return 0; +} + + static int qemuBuildPanicCommandLine(virCommandPtr cmd, const virDomainDef *def, @@ -10146,6 +10169,9 @@ qemuBuildCommandLine(virQEMUDriverPtr driver, if (qemuBuildNVRAMCommandLine(cmd, def, qemuCaps) < 0) goto error; + if (qemuBuildVMCoreInfoCommandLine(cmd, def, qemuCaps) < 0) + goto error; + if (snapshot) virCommandAddArgList(cmd, "-loadvm", snapshot->def->name, NULL); diff --git a/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args new file mode 100644 index 000000000..772e5a071 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args @@ -0,0 +1,25 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/home/test \ +USER=test \ +LOGNAME=test \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-i686 \ +-name QEMUGuest1 \ +-S \ +-M pc \ +-m 214 \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-nographic \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\ +server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=readline \ +-no-acpi \ +-boot c \ +-usb \ +-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-ide0-0-0 \ +-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \ +-device vmcoreinfo diff --git a/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml new file mode 100644 index 000000000..f8e586531 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml @@ -0,0 +1,28 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <vmcoreinfo/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-i686</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 2e07b85aa..7b9b846ef 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -2810,6 +2810,7 @@ mymain(void) DO_TEST_PARSE_ERROR("cpu-cache-emulate-l2", QEMU_CAPS_KVM); DO_TEST_PARSE_ERROR("cpu-cache-passthrough3", QEMU_CAPS_KVM); DO_TEST_PARSE_ERROR("cpu-cache-passthrough-l3", QEMU_CAPS_KVM); + DO_TEST("vmcoreinfo", QEMU_CAPS_DEVICE_VMCOREINFO); DO_TEST("user-aliases", QEMU_CAPS_KVM, QEMU_CAPS_DEVICE_CIRRUS_VGA, QEMU_CAPS_OBJECT_MEMORY_FILE, QEMU_CAPS_PIIX_DISABLE_S3, diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml new file mode 100644 index 000000000..a3922d630 --- /dev/null +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml @@ -0,0 +1,38 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <vmcoreinfo/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-i686</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </memballoon> + </devices> +</domain> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index 5a282e5ff..9a7d460e5 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -1260,6 +1260,7 @@ mymain(void) DO_TEST("cpu-check-default-none2", NONE); DO_TEST("cpu-check-default-partial", NONE); DO_TEST("cpu-check-default-partial2", NONE); + DO_TEST("vmcoreinfo", NONE); DO_TEST("smartcard-host", NONE); DO_TEST("smartcard-host-certificates", NONE); -- 2.15.0.rc0.40.gaefcc5f6f

4 4

[libvirt] [PATCH 0/3] qemu: handle connect hangs in virDomainOpenChannel
by Nikolay Shirokovskiy 16 Nov '17

16 Nov '17

The problem is described in [1] in more details. From libvirt perspective we have whole driver became unresponsive if connect to channel unix socket hangs during virDomainOpenChannel. This series address this by first using job for the API call and second by introducing connect timeout so that domain itself don't became unresponsive indefinetily. [1] http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg03013.html Nikolay Shirokovskiy (3): util: virFDStreamConnectUNIX: add missing error report util: add 30s connection timeout to virFDStreamConnectUNIX qemu: use job to keep driver responsive on qemuDomainOpenChannel src/qemu/qemu_driver.c | 11 ++++++++++ src/util/virfdstream.c | 18 +++++++++++++++ src/util/virutil.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++ src/util/virutil.h | 2 ++ 4 files changed, 90 insertions(+) -- 1.8.3.1

1 3

[libvirt] [PATCH v2] storage: Resolve storage driver crash
by John Ferlan 16 Nov '17

16 Nov '17

Resolve a storage driver crash as a result of a long running storageVolCreateXML when the virStorageVolPoolRefreshThread is run as a result of when a storageVolUpload completed and ran the virStoragePoolObjClearVols without checking if the creation code was currently processing a buildVol after incrementing the driver->asyncjob count. The refreshThread will now check the pool asyncjob count before attempting to pursue the pool refresh. Adjust the documentation to describe the condition. Crash from valgrind is as follows (with a bit of editing): ==21309== Invalid read of size 8 ==21309== at 0x153E47AF: storageBackendUpdateVolTargetInfo ==21309== by 0x153E4C30: virStorageBackendUpdateVolInfo ==21309== by 0x153E52DE: virStorageBackendVolRefreshLocal ==21309== by 0x153DE29E: storageVolCreateXML ==21309== by 0x562035B: virStorageVolCreateXML ==21309== by 0x147366: remoteDispatchStorageVolCreateXML ... ==21309== Address 0x2590a720 is 64 bytes inside a block of size 336 free'd ==21309== at 0x4C2F2BB: free ==21309== by 0x54CB9FA: virFree ==21309== by 0x55BC800: virStorageVolDefFree ==21309== by 0x55BF1D8: virStoragePoolObjClearVols ==21309== by 0x153D967E: virStorageVolPoolRefreshThread ... ==21309== Block was alloc'd at ==21309== at 0x4C300A5: calloc ==21309== by 0x54CB483: virAlloc ==21309== by 0x55BDC1F: virStorageVolDefParseXML ==21309== by 0x55BDC1F: virStorageVolDefParseNode ==21309== by 0x55BE5A4: virStorageVolDefParse ==21309== by 0x153DDFF1: storageVolCreateXML ==21309== by 0x562035B: virStorageVolCreateXML ==21309== by 0x147366: remoteDispatchStorageVolCreateXML ... Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: https://www.redhat.com/archives/libvir-list/2017-November/msg00198.html Changes since v1: - From review, remove the retry if Asyncjobs > 0 logic and replace with a VIR_DEBUG indicating not doing refresh due to Asyncjob running and just goto cleanup. - Adjust the virStorageVolUpload docs to note that an attempt will be made to refresh the pool. - Drop patch 2 which added the Asyncjobs > 0 check to the SCSI pool refresh thread. Since a SCSI pool doesn't support buildVol, the asyncjob count cannot be anything other than zero, so it's pointless. src/libvirt-storage.c | 3 ++- src/storage/storage_driver.c | 7 +++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 9ab0fe28ea..e4646cb80f 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1632,7 +1632,8 @@ virStorageVolDownload(virStorageVolPtr vol, * another active stream is writing to the storage volume. * * When the data stream is closed whether the upload is successful - * or not the target storage pool will be refreshed to reflect pool + * or not an attempt will be made to refresh the target storage pool + * if an asynchronous build is not running in order to reflect pool * and volume changes as a result of the upload. Depending on * the target volume storage backend and the source stream type * for a successful upload, the target volume may take on the diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 2b7a299706..d209f5afb8 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2267,6 +2267,13 @@ virStorageVolPoolRefreshThread(void *opaque) goto cleanup; def = virStoragePoolObjGetDef(obj); + /* If some thread is building a new volume in the pool, then we cannot + * clear out all vols and refresh the pool. So we'll just pass. */ + if (virStoragePoolObjGetAsyncjobs(obj) > 0) { + VIR_DEBUG("Asyncjob in process, cannot refresh storage pool"); + goto cleanup; + } + if (!(backend = virStorageBackendForType(def->type))) goto cleanup; -- 2.13.6

2 1