May 2018 - Devel - libvirt List Archives

[libvirt] KVM Forum 2018: Call For Participation
by Paolo Bonzini 12 Jun '18

12 Jun '18

================================================================ KVM Forum 2018: Call For Participation October 24-26, 2018 - Edinburgh International Conference Centre - Edinburgh, UK (All submissions must be received before midnight June 14, 2018) ================================================================= KVM Forum is an annual event that presents a rare opportunity for developers and users to meet, discuss the state of Linux virtualization technology, and plan for the challenges ahead. We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2018. At this highly technical conference, developers driving innovation in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can meet users who depend on KVM as part of their offerings, or to power their data centers and clouds. KVM Forum will include sessions on the state of the KVM virtualization stack, planning for the future, and many opportunities for attendees to collaborate. After more than ten years of development in the Linux kernel, KVM continues to be a critical part of the FOSS cloud infrastructure. This year, KVM Forum is joining Open Source Summit in Edinburgh, UK. Selected talks from KVM Forum will be presented on Wednesday October 24 to the full audience of the Open Source Summit. Also, attendees of KVM Forum will have access to all of the talks from Open Source Summit on Wednesday. https://events.linuxfoundation.org/events/kvm-forum-2018/program/cfp/ Suggested topics: * Scaling, latency optimizations, performance tuning, real-time guests * Hardening and security * New features * Testing KVM and the Linux kernel: * Nested virtualization * Resource management (CPU, I/O, memory) and scheduling * VFIO: IOMMU, SR-IOV, virtual GPU, etc. * Networking: Open vSwitch, XDP, etc. * virtio and vhost * Architecture ports and new processor features QEMU: * Management interfaces: QOM and QMP * New devices, new boards, new architectures * Graphics, desktop virtualization and virtual GPU * New storage features * High availability, live migration and fault tolerance * Emulation and TCG * Firmware: ACPI, UEFI, coreboot, U-Boot, etc. Management and infrastructure * Managing KVM: Libvirt, OpenStack, oVirt, etc. * Storage: Ceph, Gluster, SPDK, etc.r * Network Function Virtualization: DPDK, OPNFV, OVN, etc. * Provisioning =============== SUBMITTING YOUR PROPOSAL =============== Abstracts due: June 14, 2018 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Also include the proposal type -- one of: - technical talk - end-user talk Submit your proposal here:http://events.linuxfoundation.org/cfp Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by August 10, 2018. Speakers will receive a complimentary pass for the event. In the instance that case your submission has multiple presenters, only the primary speaker for a proposal will receive a complimentary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, focus on work that needs to be done, difficulties that haven't yet been solved, and on decisions that other developers should be aware of. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2018_BOF Let people you think who might be interested know about your BOF, and encourage them to add their names to the wiki page as well. Please try to add your ideas to the list before KVM Forum starts. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your the abstract. We will request full biographies if a panel is acceped. =============== HOTEL / TRAVEL =============== This year's event will take place at the Edinburgh International Conference Centre. For information about discounted hotel room rate for conference attendees at the nearby Sheraton Grand Hotel & Spa, Edinburgh, please visit https://events.linuxfoundation.org/events/kvm-forum-2018/attend/venue-trave… =============== IMPORTANT DATES =============== Submission deadline: June 14, 2018 Notification: August 10, 2018 Schedule announced: August 16, 2018 Event dates: October 24-26, 2018 Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2018 in October! -your KVM Forum 2018 Program Committee Please contact us with any questions or comments at kvm-forum-2018-pc(a)redhat.com

2 1

[libvirt] [PATCHv3 0/7] Finish the conversion to virConfGetValue* functions
by Fabiano Fidêncio 11 Jun '18

11 Jun '18

This patchset finishes the conversion to virConfGetValue* functions, started by Daniel Berrange a few months ago. Please, mind that although we could make virConfGetValue* functions more generic in order to support numbers and booleans as strings, that doesn't seem the safest path to take. The side-effect of this is that we will have to live with some specific code doing that as part of vmx and xen_common. Once this patchset gets merged, https://wiki.libvirt.org/page/BiteSizedTasks#Finish_conversion_to_virConfGe… can be removed. - Changes since v1: All the "values" from virConfGetValueString() are freed - Changes since v2: All comments from Ján Tomko have been addressed; A few leaks were (possibly) found and they're addressed in the last patch of the series; Fabiano Fidêncio (7): xen_xm: Split the per-disk logic from xenParseXMDisk() xen_vm: convert to typesafe virConf accessors vmx: convert to typesafe virConf accessors xen_common: Split per-PCI logic from xenParsePCI() xen_common: Split per-Vfi logic from xenParseVif() xen_common: convert to typesafe virConf acessors xen_common: Fix a few memory leaks src/vmx/vmx.c | 194 +++++-------- src/xenconfig/xen_common.c | 701 +++++++++++++++++++++++---------------------- src/xenconfig/xen_xm.c | 306 ++++++++++---------- 3 files changed, 595 insertions(+), 606 deletions(-) -- 2.14.3

2 15

[libvirt] [PATCH 00/12] Various apparmor related changes (part )
by Christian Ehrhardt 11 Jun '18

11 Jun '18

Hi, this is a continuation of the ongoing effort to feed back Ubuntu apparmor Delta on libvirt to the community (or to sort out remaining todos or to keep them distro specific). In that it is a follow on to: - https://www.redhat.com/archives/libvir-list/2017-May/msg00630.html - https://www.redhat.com/archives/libvir-list/2017-May/msg00887.html I punted those we had discussions on and decided to rework in the last rounds out of the submission. But in exchange pulled in some more changes we had that are now ready for discussion. That way I prepared the next set of 12 changes which I hereby submit for your consideration into 3.11. Christian Ehrhardt (3): apparmor, libvirt-qemu: add default pki path of lbvirt-spice apparmor, libvirt-qemu: add generic base vfio device apparmor, libvirt-qemu: qemu won't call qemu-nbd Jamie Strandboge (5): apparmor, libvirt-qemu: Allow read access to sysfs system info apparmor, libvirt-qemu: Allow qemu-block-extra libraries apparmor, libvirtd: Allow ixr to /var/lib/libvirt/virtd* apparmor, virt-aa-helper: Allow access to ecryptfs files apparmor, virt-aa-helper: Allow access to /sys/bus/usb/devices Serge Hallyn (3): apparmor, libvirt-qemu: Allow use of sgabios apparmor, libvirt-qemu: Allow read access to max_mem_regions apparmor, libvirt-qemu: Allow access to hugepage mounts Stefan Bader (1): apparmor, libvirt-qemu: Silence lttng related deny messages examples/apparmor/libvirt-qemu | 26 +++++++++++++++++++++++- examples/apparmor/usr.lib.libvirt.virt-aa-helper | 6 ++++++ examples/apparmor/usr.sbin.libvirtd | 4 ++++ 3 files changed, 35 insertions(+), 1 deletion(-) -- 2.7.4

5 56

[libvirt] [RFC PATCH 0/7] Enable vfio-pci 'property' for mediated devices
by Erik Skultety 11 Jun '18

11 Jun '18

Since QEMU 2.12 there's a new vfio-pci device property 'display' with values on/off/auto. This special kind of display allows using a mediated device which is a VGA compatible device for a display output. There are 2 different implementations of how the device output is handled, referred to as dmabuf and vfio region mapping (currently NVIDIA uses the latter, while Intel relies on the former). From libvirt's perspective the important difference is that dmabuf requires OpenGL support whereas vfio regions don't (it will of course work even with OpenGL enabled). There's a catch though - because of several constraints in the vendor drivers (as discussed here [1]), there currently isn't a reasonable way for libvirt (other than spawning a dummy QEMU instance) to probe such mediated devices for the display mode they use. This the nr.1 reason why libvirt is not going to support the value 'auto' with QEMU and will default to 'off' instead in all cases to stay safe the least and therefore is going to rely on users being able to configure this properly otherwise they'll get an error. Once there's a way for libvirt to probe the nature of the display-capable mediated devices, we can consider adding support for 'auto' value meaning that libvirt is going to take care of adding an appropriate Spice/VNC graphics device depending on the system if these are missing in the config, otherwise the user's choice is always favoured. TL;DR: - we have a new attribute value for vfio-pci mediated devices called 'display' -> devices can now format this new 'display=on/off' property to the cmdline - if user enables the vfio display (display=on) but doesn't enable OpenGL for Spice, we automatically assume the usage of '-display egl-headless' (uses local drm nodes) which works both for Spice and VNC -> if OpenGL is enabled, then '-display egl-headless' is not necessary Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1475770 [1] https://www.redhat.com/archives/libvir-list/2018-May/msg00243.html Erik Skultety (7): conf: Remove a redundant model/address-type check in mdev post parse qemu: command: Move graphics iteration to its own function conf: Introduce virDomainDefHasSpiceGL helper conf: Introduce new <hostdev> attribute 'display' qemu: caps: Add vfio-pci.display capability qemu: domain: Set default vfio-pci display value depending on capability qemu: command: Enable formatting vfio-pci.display option onto cmdline docs/formatdomain.html.in | 16 ++++- docs/schemas/domaincommon.rng | 5 ++ src/conf/domain_conf.c | 56 +++++++++++---- src/conf/domain_conf.h | 4 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 84 +++++++++++++++------- src/qemu/qemu_domain.c | 75 +++++++++++++++++++ tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 + .../hostdev-mdev-display-missing-graphics.xml | 35 +++++++++ .../hostdev-mdev-display-spice-no-opengl.args | 32 +++++++++ .../hostdev-mdev-display-spice-no-opengl.xml | 41 +++++++++++ .../hostdev-mdev-display-spice-opengl.args | 31 ++++++++ .../hostdev-mdev-display-spice-opengl.xml | 41 +++++++++++ .../qemuxml2argvdata/hostdev-mdev-display-vnc.args | 32 +++++++++ .../qemuxml2argvdata/hostdev-mdev-display-vnc.xml | 39 ++++++++++ tests/qemuxml2argvtest.c | 23 ++++++ .../hostdev-mdev-display-spice-no-opengl.xml | 47 ++++++++++++ .../hostdev-mdev-display-spice-opengl.xml | 48 +++++++++++++ .../hostdev-mdev-display-vnc.xml | 47 ++++++++++++ tests/qemuxml2xmltest.c | 3 + 25 files changed, 626 insertions(+), 41 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-missing-graphics.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-no-opengl.args create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-no-opengl.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-opengl.args create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-opengl.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc.args create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-spice-no-opengl.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-spice-opengl.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-vnc.xml -- 2.14.3

3 24

[libvirt] [RFC PATCH 0/2] Introduce RDT memory bandwidth allocation support
by bing.niu＠intel.com 09 Jun '18

09 Jun '18

From: Bing Niu <bing.niu(a)intel.com> This series is to introduce RDT memory bandwidth allocation support by extending current virresctrl implementation. The Memory Bandwidth Allocation (MBA) feature provides indirect and approximate control over memory bandwidth available per-core. This feature provides a method to control applications which may be over-utilizing bandwidth relative to their priority in environments such as the data-center. The details can be found in Intel's SDM 17.19.7. Kernel supports MBA through resctrl file system same as CAT. Each resctrl group have a MB parameter to control how much memory bandwidth it can utilize in unit of percentage. In this series, MBA is enabled by enhancing existing virresctrl implementation. The policy employed for MBA is similar with CAT: The sum of each MBA group's bandwidth dose not exceed 100%. The enhancement of virresctrl include two parts: Patch 1: Add two new structure virResctrlInfoMB and virResctrlAllocMB for collecting host system MBA capability and domain memory bandwidth allocation. Patch 2: On frontend XML parsing, add new element "llc" in cachetune section for MBA allocation. Bing Niu (2): util: Add memory bandwidth support to resctrl conf: Extend cputune/cachetune to support memory bandwidth allocation src/conf/domain_conf.c | 86 +++++++++- src/util/virresctrl.c | 422 ++++++++++++++++++++++++++++++++++++++++++++++--- src/util/virresctrl.h | 5 + 3 files changed, 487 insertions(+), 26 deletions(-) -- 2.7.4

4 14

[libvirt] [PATCH v2 0/2] bhyve: add CPU topology support
by Roman Bogorodskiy 08 Jun '18

08 Jun '18

Changes since v1: - Added a check that nvcpus == sockets * cores * threads and a test for that. Roman Bogorodskiy (2): bhyve: add CPU topology support docs: bhyve: document guest CPU topology feature docs/drvbhyve.html.in | 16 ++++++++++++ docs/news.xml | 9 +++++++ src/bhyve/bhyve_capabilities.c | 7 +++-- src/bhyve/bhyve_capabilities.h | 1 + src/bhyve/bhyve_command.c | 26 ++++++++++++++++++- ...yvexml2argv-cputopology-nvcpu-mismatch.xml | 26 +++++++++++++++++++ .../bhyvexml2argv-cputopology.args | 9 +++++++ .../bhyvexml2argv-cputopology.ldargs | 3 +++ .../bhyvexml2argv-cputopology.xml | 26 +++++++++++++++++++ tests/bhyvexml2argvtest.c | 8 +++++- 10 files changed, 127 insertions(+), 4 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology-nvcpu-mismatch.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.xml -- 2.17.0

3 9

[libvirt] [dbus PATCH 0/8] NWFilter APIs
by Katerina Koukiou 08 Jun '18

08 Jun '18

Katerina Koukiou (8): Introduce NWFilter Interface Implement ListNWFilters method for Connect Interface Implement NWFilterDefineXML method for Connect Interface Implement Name property for NWFilter Interface Implement UUID property for NWFilter Interface Implement GetXMLDesc method for NWFilter Interface Implement NWFilterLookupByName method for Connect Interface Implement NWFilterLookupByUUID method for Connect Interface data/Makefile.am | 1 + data/org.libvirt.Connect.xml | 24 +++++++ data/org.libvirt.NWFilter.xml | 23 +++++++ src/Makefile.am | 1 + src/connect.c | 131 +++++++++++++++++++++++++++++++++++ src/connect.h | 1 + src/nwfilter.c | 157 ++++++++++++++++++++++++++++++++++++++++++ src/nwfilter.h | 9 +++ src/util.c | 32 +++++++++ src/util.h | 15 ++++ 10 files changed, 394 insertions(+) create mode 100644 data/org.libvirt.NWFilter.xml create mode 100644 src/nwfilter.c create mode 100644 src/nwfilter.h -- 2.15.0

2 17

[libvirt] [PATCH 00/13] PCI passthrough support on s390
by Xiao Feng Ren 08 Jun '18

08 Jun '18

The PCI representation in QEMU has recently been extended for S390 allowing configuration of zPCI attributes like uid (user-defined identifier) and fid (PCI function identifier). The details can be found here: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html To support the new zPCI feature of the S390 platform, two new XML attributes, @uid and @fid, are introduced for device addresses of type 'pci', i.e.: <hostdev mode='subsystem' type='pci'> <driver name='vfio'/> <source> <address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' uid='0x0003' fid='0x00000027'/> </hostdev> uid and fid are optional attributes. If they are defined by the user, unique values within the guest domain must be used. If they are not specified and the architecture requires them, they are automatically generated with non-conflicting values. Current implementation is the most seamless one for the user as it unites the address specific data of a PCI device on one XML element. It could accommodate both specifying our special parameters (uid and fid) and re-using standard statements (domain, bus, slot and function) for PCI devices. User can still specify bus/slot/function for the virtualized PCI devices in the XML. Thus uid/fid act as an extension to the PCI address and are stored in a new structure 'virZPCIDeviceAddress' which is a member of common PCI Address structure. Additionally, two hashtables are used for assignment and reservation of uid/fid. In support of extending the PCI address, a new PCI address extension flag is introduced. This extension flag allows is not only dedicated for the S390 platform but also other architectures needing certain extensions to PCI address space. Yi Min Zhao (13): conf: Add definitions for 'uid' and 'fid' PCI address attributes qemu: Introduce zPCI capability conf: Introduce a new PCI address extension flag qemu: Enable PCI multi bus for S390 guests qemu: Auto add pci-root for s390/s390x guests qemu: Generate and use zPCI device in QEMU command line qemu: Add hotpluging support for PCI devices on S390 guests conf: Introduce parser, formatter for uid and fid conf: Introduce address caching for PCI extensions conf: Allocate/release 'uid' and 'fid' in PCI address tests: Add new tests for zPCI docs: Add 'uid' and 'fid' information news: Update news for PCI address extension attributes docs/formatdomain.html.in | 9 +- docs/news.xml | 11 + docs/schemas/basictypes.rng | 28 ++ docs/schemas/domaincommon.rng | 1 + src/conf/device_conf.c | 74 +++++ src/conf/device_conf.h | 1 + src/conf/domain_addr.c | 346 +++++++++++++++++++++ src/conf/domain_addr.h | 29 ++ src/conf/domain_conf.c | 4 + src/libvirt_private.syms | 4 + src/qemu/qemu_capabilities.c | 5 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 104 +++++++ src/qemu/qemu_command.h | 4 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain_address.c | 183 ++++++++++- src/qemu/qemu_hotplug.c | 175 ++++++++++- src/util/virpci.h | 13 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemuxml2argvdata/disk-virtio-s390-zpci.args | 27 ++ tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml | 17 + .../hostdev-vfio-zpci-autogenerate.args | 24 ++ .../hostdev-vfio-zpci-autogenerate.xml | 18 ++ .../hostdev-vfio-zpci-boundaries.args | 27 ++ .../hostdev-vfio-zpci-boundaries.xml | 26 ++ .../hostdev-vfio-zpci-multidomain-many.args | 38 +++ .../hostdev-vfio-zpci-multidomain-many.xml | 67 ++++ tests/qemuxml2argvdata/hostdev-vfio-zpci.args | 24 ++ tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 19 ++ tests/qemuxml2argvtest.c | 21 ++ tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml | 29 ++ tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml | 30 ++ tests/qemuxml2xmltest.c | 3 + 38 files changed, 1347 insertions(+), 22 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml -- 2.16.3

8 47

[libvirt] [ v3 0/4] Introduce network-backed loader & NVRAM.
by Prerna Saxena 06 Jun '18

06 Jun '18

Libvirt domain XML allows only local filepaths to specify a loader element or its matching NVRAM. Given that VMs may themselves move across hypervisor hosts, it should be possible to allocate loaders/NVRAM disks on network storage for uninterrupted access. This series extends the loader & NVRAM disk elements to be described as virStorageSource* elements, as discussed in : https://www.redhat.com/archives/libvir-list/2018-March/msg01721.html Sample XML with new annotation: <loader readonly='yes' type='pflash' backing='file'> <source file='/usr/share/OVMF/OVMF_CODE.fd'/> </loader> <nvram backing='network'> <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/0'> <host name='example.com' port='6000'/> </source> </nvram> References: ---------- v0/ Proposal: https://www.redhat.com/archives/libvir-list/2018-March/msg01721.html.v1 v1: https://www.redhat.com/archives/libvir-list/2018-April/msg02024.html v2: https://www.redhat.com/archives/libvir-list/2018-May/msg00948.html Changelog: --------- Changes since v2: - Consolidated patches with related data structures to avoid build breakage. - Passes make check & make syntax-check. Prerna Saxena (4): Schema: Introduce XML schema for network-backed loader and nvram elements. Loader: Add a more elaborate definition. Test: Add a test snippet to evaluate command line generation for loader/nvram specified via virStorageSource Documentation: Add a blurb for the newly added XML snippets for loader and nvram. docs/formatdomain.html.in | 36 +++- docs/schemas/domaincommon.rng | 108 +++++++++-- src/bhyve/bhyve_command.c | 6 +- src/conf/domain_conf.c | 250 +++++++++++++++++++++++-- src/conf/domain_conf.h | 11 +- src/qemu/qemu_cgroup.c | 13 +- src/qemu/qemu_command.c | 21 ++- src/qemu/qemu_domain.c | 31 ++- src/qemu/qemu_driver.c | 7 +- src/qemu/qemu_parse_command.c | 30 ++- src/qemu/qemu_process.c | 54 ++++-- src/security/security_dac.c | 6 +- src/security/security_selinux.c | 6 +- src/security/virt-aa-helper.c | 14 +- src/vbox/vbox_common.c | 11 +- src/xenapi/xenapi_driver.c | 4 +- src/xenconfig/xen_sxpr.c | 19 +- src/xenconfig/xen_xm.c | 9 +- tests/qemuxml2argvdata/bios-nvram-network.args | 31 +++ tests/qemuxml2argvdata/bios-nvram-network.xml | 42 +++++ tests/qemuxml2argvtest.c | 1 + 21 files changed, 606 insertions(+), 104 deletions(-) create mode 100644 tests/qemuxml2argvdata/bios-nvram-network.args create mode 100644 tests/qemuxml2argvdata/bios-nvram-network.xml -- 1.8.1.2

3 8

[libvirt] [PATCH] qemu: Honour <on_reboot/>
by Michal Privoznik 06 Jun '18

06 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1476866 For some reason, we completely ignore <on_reboot/> setting for domains. The implementation is simply not there. It never was. However, things are slightly more complicated. QEMU sends us two RESET events on domain reboot. Fortunately, the event contains this 'guest' field telling us who initiated the reboot. And since we don't want to destroy the domain if the reset is initiated by a user, we have to ignore those events. Whatever, just look at the code. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_monitor.c | 4 ++-- src/qemu/qemu_monitor.h | 3 ++- src/qemu/qemu_monitor_json.c | 8 +++++++- src/qemu/qemu_process.c | 34 ++++++++++++++++++++++++++++++---- 5 files changed, 42 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 4c9050aff..d865e67c7 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -233,6 +233,7 @@ struct _qemuDomainObjPrivate { bool agentError; bool gotShutdown; + bool gotReset; bool beingDestroyed; char *pidfile; diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 19082d8bf..8f81a2b28 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -1344,12 +1344,12 @@ qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest) int -qemuMonitorEmitReset(qemuMonitorPtr mon) +qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest) { int ret = -1; VIR_DEBUG("mon=%p", mon); - QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm); + QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm, guest); return ret; } diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 31f7e97ba..8c33f6783 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -134,6 +134,7 @@ typedef int (*qemuMonitorDomainShutdownCallback)(qemuMonitorPtr mon, void *opaque); typedef int (*qemuMonitorDomainResetCallback)(qemuMonitorPtr mon, virDomainObjPtr vm, + virTristateBool guest, void *opaque); typedef int (*qemuMonitorDomainPowerdownCallback)(qemuMonitorPtr mon, virDomainObjPtr vm, @@ -346,7 +347,7 @@ int qemuMonitorEmitEvent(qemuMonitorPtr mon, const char *event, long long seconds, unsigned int micros, const char *details); int qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest); -int qemuMonitorEmitReset(qemuMonitorPtr mon); +int qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest); int qemuMonitorEmitPowerdown(qemuMonitorPtr mon); int qemuMonitorEmitStop(qemuMonitorPtr mon); int qemuMonitorEmitResume(qemuMonitorPtr mon); diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index b8a68154a..8a1501ced 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -536,7 +536,13 @@ static void qemuMonitorJSONHandleShutdown(qemuMonitorPtr mon, virJSONValuePtr da static void qemuMonitorJSONHandleReset(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED) { - qemuMonitorEmitReset(mon); + bool guest = false; + virTristateBool guest_initiated = VIR_TRISTATE_BOOL_ABSENT; + + if (data && virJSONValueObjectGetBoolean(data, "guest", &guest) == 0) + guest_initiated = guest ? VIR_TRISTATE_BOOL_YES : VIR_TRISTATE_BOOL_NO; + + qemuMonitorEmitReset(mon, guest_initiated); } static void qemuMonitorJSONHandlePowerdown(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 0aecce3b1..889efc7f0 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -478,27 +478,51 @@ qemuProcessFindVolumeQcowPassphrase(qemuMonitorPtr mon ATTRIBUTE_UNUSED, static int qemuProcessHandleReset(qemuMonitorPtr mon ATTRIBUTE_UNUSED, virDomainObjPtr vm, + virTristateBool guest_initiated, void *opaque) { virQEMUDriverPtr driver = opaque; - virObjectEventPtr event; + virObjectEventPtr event = NULL; qemuDomainObjPrivatePtr priv; virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); + bool callOnReboot = false; virObjectLock(vm); + priv = vm->privateData; + + /* This is a bit tricky. When a guest does 'reboot' we receive RESET event + * twice, both times it's guest initiated. However, if users call 'virsh + * reset' we still receive two events but the first one is guest_initiated + * = no, the second one is guest_initiated = yes. Therefore, to avoid + * executing onReboot action in the latter case we need this complicated + * construction. */ + if (guest_initiated == VIR_TRISTATE_BOOL_NO) { + VIR_DEBUG("Ignoring not guest initiated RESET event from domain %s", + vm->def->name); + priv->gotReset = true; + } else if (priv->gotReset && guest_initiated == VIR_TRISTATE_BOOL_YES) { + VIR_DEBUG("Ignoring second RESET event from domain %s", + vm->def->name); + priv->gotReset = false; + } else { + callOnReboot = true; + } + event = virDomainEventRebootNewFromObj(vm); - priv = vm->privateData; if (priv->agent) qemuAgentNotifyEvent(priv->agent, QEMU_AGENT_EVENT_RESET); if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, vm, driver->caps) < 0) VIR_WARN("Failed to save status on vm %s", vm->def->name); + if (callOnReboot && + guest_initiated == VIR_TRISTATE_BOOL_YES && + vm->def->onReboot == VIR_DOMAIN_LIFECYCLE_DESTROY) + qemuProcessShutdownOrReboot(driver, vm); + virObjectUnlock(vm); - qemuDomainEventQueue(driver, event); - virObjectUnref(cfg); return 0; } @@ -555,6 +579,7 @@ qemuProcessFakeReboot(void *opaque) goto endjob; } priv->gotShutdown = false; + priv->gotReset = false; event = virDomainEventLifecycleNewFromObj(vm, VIR_DOMAIN_EVENT_RESUMED, VIR_DOMAIN_EVENT_RESUMED_UNPAUSED); @@ -5320,6 +5345,7 @@ qemuProcessPrepareDomain(virConnectPtr conn, priv->monError = false; priv->monStart = 0; priv->gotShutdown = false; + priv->gotReset = false; VIR_DEBUG("Updating guest CPU definition"); if (qemuProcessUpdateGuestCPU(vm->def, priv->qemuCaps, caps, flags) < 0) -- 2.13.0

4 6