[libvirt] KVM Forum 2018: Call For Participation
by Paolo Bonzini
================================================================
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-tra...
===============
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
7 years
[libvirt] [PATCHv3 0/7] Finish the conversion to virConfGetValue* functions
by Fabiano Fidêncio
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_virConf...
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
7 years
[libvirt] [PATCH 00/12] Various apparmor related changes (part )
by Christian Ehrhardt
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
7 years
[libvirt] [RFC PATCH 0/7] Enable vfio-pci 'property' for mediated devices
by Erik Skultety
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
7 years
[libvirt] [RFC PATCH 0/2] Introduce RDT memory bandwidth allocation support
by bing.niu＠intel.com
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
7 years
[libvirt] [PATCH v2 0/2] bhyve: add CPU topology support
by Roman Bogorodskiy
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
7 years
[libvirt] [dbus PATCH 0/8] NWFilter APIs
by Katerina Koukiou
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
7 years
[libvirt] [PATCH 00/13] PCI passthrough support on s390
by Xiao Feng Ren
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
7 years
[libvirt] [ v3 0/4] Introduce network-backed loader & NVRAM.
by Prerna Saxena
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
7 years
[libvirt] [PATCH] qemu: Honour <on_reboot/>
by Michal Privoznik
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
7 years
