[PATCH v3 0/4] Add qemu support setting qos via ovs on ovs interface
by zhangjl02
---
diff to v2:
- Remove passing "actualType" argument, get it inside funtion
- Format code.
diff to v1:
- Move qemuDomainDefIsOvsport from src/qemu/qemu_domain.c to
src/conf/domain_conf.c
- Call virCommandFree(cmd)free cmd before reusing it.
- Ddd g_autofree to variables.
- Reduce usage of virReportError(), and coupled it with return -1.
- Fix remove port qos error.
- Optimise code structure.
Thanks to Michal Privoznik for helping reviewing these patches and solving
problems. Really sorry to bring extra work to review them. I will continue
to learn and become familiar with submission process.
Now libvirt use tc rules to manage interface's qos. But when an interface
is created by ovs, there is no qos setting result in ovs database. Therefore,
qos of ovs port should be set via ovs management command.
We add a function to tell whether a port definition is an ovs managed virtual
port. Change default qdisc rules, which return 0 directly if the port is ovs
managed(When the ovs port is set noqueue, qos config on this port will not
work). Add ovs management function of setting and cleaning qos. Then check if
the port is an ovs managed port during its life cycle, and call the ovs
management function to set or clean qos settings.
zhangjl02 (4):
virDomain: interface: add virDomainNetDefIsOvsport
virDomain: interface: add virNetDevOpenvswitchInterfaceSetQos and
virNetDevOpenvswitchInterfaceClearQos
qemu: interface: remove setting noqueue for ovs port
qemu: interface: check and use ovs command to set qos of ovs managed
port
src/conf/domain_conf.c | 11 ++
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 3 +
src/qemu/qemu_command.c | 10 +-
src/qemu/qemu_domain.c | 3 +-
src/qemu/qemu_driver.c | 23 ++-
src/qemu/qemu_hotplug.c | 35 ++--
src/qemu/qemu_process.c | 7 +-
src/util/virnetdevopenvswitch.c | 274 ++++++++++++++++++++++++++++++++
src/util/virnetdevopenvswitch.h | 11 ++
10 files changed, 364 insertions(+), 15 deletions(-)
--
2.30.2.windows.1
3 years, 1 month
[RFC] Allowing SEV attestation
by Michal Prívozník
Dear list,
in the light of recent development of secure virtualization (for instance AMD
SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new
technologies and thus would like to discuss our options. So far, I've came
across AMD SEV-SNP [2]. While it's true that we do support SEV, we need to
adopt its newer version too.
Consider the following example: you loan a VM on a public cloud and you want
to process some private data there. Of course, the data has to be stored on an
encrypted disk/partition. But encrypting guest memory (confidentiality)
prevents you only from finding the key in a memory dump. It doesn't help if
the guest image, initial guest memory, hypervisor or firmware were tampered with.
This is where attestation comes to help - it enables the guest owner (which in
this example is different to the one running it) verify - with cryptographic
level of confidence - that data confidentiality and integrity can be ensured.
Depending on the technology, attestation will be done at different times in
the VM lifecycle. When it's done before starting guest vCPUs, it's called
pre-attestation and when it's done after the guest has launched, it's called
post-attestation. For example, AMD SEV and SEV-ES require pre-attestation.
SEV-SNP allows for post attestation. The crux of the issue here is that *when*
and *how* the guest owner will interact with the VM for attestation will be
different depending on which technology is being used.
It looks like QEMU will expose commands needed for attestation via QMP [3].
But question then is, how to expose those at Libvirt level? Should we allow
users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in
public APIs, or something completely different?
Will those APIs be generic enough to serve other technologies too? For
instance, given set of APIs in given order works for SEV but might not work
for Intel's TDX.
1: https://kvmforum2019.sched.com/event/Tmwl/improving-and-expanding-sev-sup...
2: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolat...
3: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03689.html
Michal
3 years, 1 month
[RFC PATCH 00/10] VirtioNet RSS support
by Andrew Melnychenko
This series of patches add RSS property support for virtio-net-pci.
Virtio RSS effectively works with TAP devices, it requires additional
vectors for VirtioNet, queues for TAP device, and vCPU cores.
Example of device configuration:
```
<interface type="network">
<mac address="52:54:00:c4:90:25"/>
<source network="default"/>
<model type="virtio"/>
<driver name="qemu" queues="9" rss="on" rss_hash_report="off"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
```
Capability "rss" enables RSS, "rss_hash_report" - enables hashes in vheader.
Qemu uses eBPF program as RSS driver.
For loading RSS eBPF program, the helper is used.
Path to the helper is provided by Qemu through "query-helper-paths" qmp command.
The helper "qemu-ebpf-rss-helper" is built with Qemu and may differ from build to build.
So it's required that the Qemu should provide a proper helper path.
Libvirt would call the helper and receive the program and map fd through unix socket.
Fds would be passed to Qemu in "ebpf_rss_fds" property by passing to child process or unix socket.
If libvirt would fail at helper call or Qemu didn't provide the path,
the Qemu would be launched without "ebpf_rss_fds" property.
Without "ebpf_rss_fds" property, Qemu would try to load eBPF program by
itself - usually, it would require additional system permissions.
Qemu may use "in-qemu" RSS as a fallback option, which will not require system
permissions, but doesn't work with vhost TAP.
Qemu patches: https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg03535.html
Andrew Melnychenko (10):
domain_conf: Added configs for RSS and Hash report.
qemu_capabilities: Added capabilites for qemu's "rss" and "hash".
qemu_command: Added "rss" and "hash" properties.
virsocket: Added receive for multiple fds.
qemu_capabilities: Added capability for qemu's "ebpf_rss_fds".
qemu_capabilities: Added capability for ebpf helper path.
qemu_interface: Added ebpf helper call.
qemu_command: Added ebpf RSS helper call for NIC creation.
qemu_hotplug: Added helper call for hotplug NIC.
docs: Added descriptions for "rss" and "rss_hash_report"
configurations.
docs/formatdomain.rst | 16 +++++++
src/conf/domain_conf.c | 31 +++++++++++++-
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 48 +++++++++++++++++++++
src/qemu/qemu_capabilities.h | 5 +++
src/qemu/qemu_command.c | 46 +++++++++++++++++++-
src/qemu/qemu_command.h | 2 +
src/qemu/qemu_hotplug.c | 30 ++++++++++++-
src/qemu/qemu_interface.c | 54 +++++++++++++++++++++++
src/qemu/qemu_interface.h | 2 +
src/qemu/qemu_monitor.c | 9 ++++
src/qemu/qemu_monitor.h | 3 ++
src/qemu/qemu_monitor_json.c | 50 ++++++++++++++++++++++
src/qemu/qemu_monitor_json.h | 3 ++
src/qemu/qemu_validate.c | 16 +++++++
src/util/virsocket.c | 83 ++++++++++++++++++++++++++++++++++++
src/util/virsocket.h | 2 +
18 files changed, 399 insertions(+), 4 deletions(-)
--
2.31.1
3 years, 2 months
[libvirt PATCH 0/7] Accumulated mdev fixes
by Jonathon Jongsma
These patches fix a couple of outstanding issues with mdev support. These include:
1. output proper xml for the mdev parent device when run under the test suite
2. mdevctl allows multiple devices with the same UUID (but different parents),
so we have to be prepared to handle this. This also requires a change in
nodedev name for mdev devices. From 'mdev_$UUID' to 'mdev_$UUID_$PARENTADDR'
3. validate input xml when defining or creating mdevs (e.g. ensure we have a
proper parent device)
This patch obsoletes the previous patch titled "nodedev: Handle inactive mdevs
with the same UUID"
Jonathon Jongsma (7):
nodedev: add internal virNodeDeviceObjListFind()
nodedev: fix xml output for mdev parents in test suite
nodedev: cache parent address in mdev caps
nodedev: Add parser validation for node devices
nodedev: add PostParse callback for nodedev parsing
nodedev: Handle inactive mdevs with the same UUID
nodedev: look up mdevs by UUID and parent
src/conf/node_device_conf.c | 37 +++-
src/conf/node_device_conf.h | 21 +-
src/conf/virnodedeviceobj.c | 71 +++++--
src/conf/virnodedeviceobj.h | 15 +-
src/hypervisor/domain_driver.c | 7 +-
src/libvirt_private.syms | 1 +
src/node_device/node_device_driver.c | 182 ++++++++++++++----
src/node_device/node_device_driver.h | 6 +
src/node_device/node_device_udev.c | 21 +-
src/test/test_driver.c | 6 +-
.../mdevctl-list-multiple.out.xml | 16 +-
tests/nodedevmdevctltest.c | 36 +++-
tests/nodedevxml2xmltest.c | 3 +-
13 files changed, 338 insertions(+), 84 deletions(-)
--
2.31.1
3 years, 2 months
set custom loglevel for external libraries
by Olaf Hering
In src/libxl/libxl_conf.c:libxlDriverConfigInit, virLogGetDefaultPriority is used to specify the (private) loglevel of an external library. This value could be controlled via "log_level=N" in libvirtd.conf. But doing it that way will affect libvirtd itself, instead of libxenlight.so as intended. There might be ways to suppress everything but libxl output via "log_filters=", but it is not clear what the syntax would be.
I wonder what the preferred way is to specify the desired loglevel for the external library. It seems a separate configuration setting is required so that each value of XTL_* from xentoollog.h can be specified.
Olaf
3 years, 2 months
[PATCH v3 0/3] remove sysconfig files
by Olaf Hering
rebased to 919f25d36ef0ea41c50bdb5afa0b83187ffb3c87
Olaf Hering (3):
libvirt.spec: relocate pre script of daemon-driver-qemu
remove sysconfig files
NEWS: mention removal of sysconfig
NEWS.rst | 10 +++
docs/daemons.rst | 20 +++++
docs/remote.html.in | 2 +-
libvirt.spec.in | 100 ++++++++++++++++--------
src/ch/meson.build | 5 --
src/ch/virtchd.service.in | 1 +
src/ch/virtchd.sysconf | 3 -
src/interface/meson.build | 5 --
src/interface/virtinterfaced.service.in | 1 +
src/interface/virtinterfaced.sysconf | 3 -
src/libxl/meson.build | 5 --
src/libxl/virtxend.service.in | 1 +
src/libxl/virtxend.sysconf | 3 -
src/locking/meson.build | 5 --
src/locking/virtlockd.service.in | 1 +
src/locking/virtlockd.sysconf | 3 -
src/logging/meson.build | 5 --
src/logging/virtlogd.sysconf | 3 -
src/lxc/meson.build | 5 --
src/lxc/virtlxcd.service.in | 1 +
src/lxc/virtlxcd.sysconf | 3 -
src/meson.build | 16 ----
src/network/meson.build | 5 --
src/network/virtnetworkd.service.in | 1 +
src/network/virtnetworkd.sysconf | 3 -
src/node_device/meson.build | 5 --
src/node_device/virtnodedevd.service.in | 1 +
src/node_device/virtnodedevd.sysconf | 3 -
src/nwfilter/meson.build | 5 --
src/nwfilter/virtnwfilterd.service.in | 1 +
src/nwfilter/virtnwfilterd.sysconf | 3 -
src/qemu/meson.build | 5 --
src/qemu/virtqemud.service.in | 7 ++
src/qemu/virtqemud.sysconf | 12 ---
src/remote/libvirtd.service.in | 7 ++
src/remote/libvirtd.sysconf | 21 -----
src/remote/meson.build | 10 ---
src/remote/virtproxyd.service.in | 1 +
src/remote/virtproxyd.sysconf | 3 -
src/secret/meson.build | 5 --
src/secret/virtsecretd.service.in | 1 +
src/secret/virtsecretd.sysconf | 3 -
src/storage/meson.build | 5 --
src/storage/virtstoraged.service.in | 1 +
src/storage/virtstoraged.sysconf | 3 -
src/vbox/meson.build | 5 --
src/vbox/virtvboxd.service.in | 1 +
src/vbox/virtvboxd.sysconf | 3 -
src/vz/meson.build | 5 --
src/vz/virtvzd.service.in | 1 +
src/vz/virtvzd.sysconf | 3 -
tools/libvirt-guests.sh.in | 40 ++++++++++
tools/libvirt-guests.sysconf | 50 ------------
tools/meson.build | 6 --
54 files changed, 166 insertions(+), 260 deletions(-)
delete mode 100644 src/ch/virtchd.sysconf
delete mode 100644 src/interface/virtinterfaced.sysconf
delete mode 100644 src/libxl/virtxend.sysconf
delete mode 100644 src/locking/virtlockd.sysconf
delete mode 100644 src/logging/virtlogd.sysconf
delete mode 100644 src/lxc/virtlxcd.sysconf
delete mode 100644 src/network/virtnetworkd.sysconf
delete mode 100644 src/node_device/virtnodedevd.sysconf
delete mode 100644 src/nwfilter/virtnwfilterd.sysconf
delete mode 100644 src/qemu/virtqemud.sysconf
delete mode 100644 src/remote/libvirtd.sysconf
delete mode 100644 src/remote/virtproxyd.sysconf
delete mode 100644 src/secret/virtsecretd.sysconf
delete mode 100644 src/storage/virtstoraged.sysconf
delete mode 100644 src/vbox/virtvboxd.sysconf
delete mode 100644 src/vz/virtvzd.sysconf
delete mode 100644 tools/libvirt-guests.sysconf
3 years, 2 months
[PATCH RFC 0/8] blockdev-replace
by Vladimir Sementsov-Ogievskiy
Hi all!
As a continuation of "Qemu block filter insertion/removal API"
discussion, here is my proposal of blockdev-replace.
The realization allows:
- replace children of different parents: BDS, block devices, block
exports
- automatically replace all parents of specific BDS, excluding creating
loops (like bdrv_replace_node())
- do several replacements in one transaction
It's an untested draft, so you may go to patch 8, to look at QAPI
addition.
Vladimir Sementsov-Ogievskiy (8):
block-backend: blk_root(): drop const specifier on return type
block: add BlockParentClass class
block: realize BlockParentClass for BlockDriverState
block/export: realize BlockParentClass functionality
qdev: improve find_device_state() to distinguish simple not found case
qdev: realize BlockParentClass
block: improve bdrv_replace_node_noperm()
qapi: add blockdev-replace command
qapi/block-core.json | 78 ++++++++++++++++
include/block/block-parent.h | 32 +++++++
include/sysemu/block-backend.h | 2 +-
block.c | 158 ++++++++++++++++++++++++++++++++-
block/block-backend.c | 2 +-
block/block-parent.c | 66 ++++++++++++++
block/export/export.c | 44 +++++++++
softmmu/qdev-monitor.c | 90 +++++++++++++++----
block/meson.build | 1 +
9 files changed, 453 insertions(+), 20 deletions(-)
create mode 100644 include/block/block-parent.h
create mode 100644 block/block-parent.c
--
2.29.2
3 years, 2 months
RFC: revert to external snapshot API
by Nikolay Shirokovskiy
Hi, all.
I want to implement reverting to external snapshot functionality.
I've checked the mailing list history and found some previous attempts
(not sure if this is a complete list of them).
[1] was done in 2012 by the Redhat team itself. [2] and [3] was done in
2018.
Looks like it was not clear how the API should look like.
For example we have disk.qcow2 <- disk.snap1 chain <- disk.snap2 chain
(after
having snap1 and snap2 snapshots). Now we want to revert to snap1 snapshot.
The
snapshot state is held by disk.qcow2 image. We can run reverted domain on
disk.qcow2 itself but then we lose snap1 (held by disk.qcow2) and snap2
(held by disk.snap1). So we definitely should run on some overlay over
disk.qcow2. But then what name should be given to overlay? We should have
an option for mgmt to specify this name like in case of snapshots itself.
The [1] has some discussion on adding extra options to reverting
functionality.
Like for example if we revert back to snap2 then having the ability to run
from
state in disk.snap2 rather than disk.snap1. My opinion is there is no need
to
as if one wants to revert to the state of disk2.snap2 it can take a
snapshot (some
snap3). At the same time one needs to be aware that revert operation loses
current state and later one can revert only to the states of snapshots.
This is the way internal snapshots work and the way one expects external
snapshots to work too.
The [2] takes an approach of reusing current top image as overlay on revert
so
that in the above example disk.snap2 will be overlay over disk.qcow2 on
reverting to snap1 snapshot. IMHO this is a confusing naming scheme.
The [3] suggests a different scheme for naming images. For example after
taking
snapshot snap1 the chain should be disk.snap1 <- disk.qcow2 which looks very
appealing to me. With this naming using the [2] approach is quite natural.
Implementing this does not look hard even for a running domain but this is
a big change to API and all mgmt need to be aware of (well it could be done
safely using a new flag).
Anyway we can go on with current image names. In order to specify overlay
image name let's introduce new API:
int virDomainRevertToSnapshotXML(virDomainSnapshotPtr snapshot,
char *xmlDesc,
unsigned int flags)
with XML like:
<domainsnapshotrevert>
<disks>
<disk name='vda'>
<source file='/path/to/revert/overlay'/>
</disk>
</disks>
</domainsnapshotrevert>
Having an XML looks like a bit overkill right now but I could not
find a better solution.
If overlay name is omitted the generated name will be like disk.snap1-1 in
the
above example to be in alignment with creating a snapshot case. So that
disk.snap1*
images hold states derived from snap1 state. We can also support reverting
to
external snapshot thru existing virDomainRevertToSnapshot for those who
rely on
generated names using this naming scheme.
[1] Re: [PATCHv4 4/4] snapshot: qemu: Implement reverting of external
snapshots
https://listman.redhat.com/archives/libvir-list/2012-November/msg00932.html
[2] Re: [PATCH 1/5] snapshot: Implement reverting for external disk
snapshots
https://listman.redhat.com/archives/libvir-list/2018-November/msg00338.html
[3] External disk snapshot paths and the revert operation
https://listman.redhat.com/archives/libvir-list/2018-October/msg01110.html
3 years, 3 months
[PATCH v2 0/3] qapi & doc: deprecate drive-backup
by Vladimir Sementsov-Ogievskiy
Hi all!
See 03 commit message for details. 01-02 are preparation docs update.
v2: add a lot of documentation changes
v1 was "[PATCH] qapi: deprecate drive-backup"
Supersedes: <20210423125900.3640-1-vsementsov(a)virtuozzo.com>
Vladimir Sementsov-Ogievskiy (3):
docs/block-replication: use blockdev-backup
docs/interop/bitmaps: use blockdev-backup
qapi: deprecate drive-backup
docs/block-replication.txt | 4 +-
docs/interop/bitmaps.rst | 285 +++++++++++++++++++------
docs/interop/live-block-operations.rst | 47 ++--
docs/system/deprecated.rst | 11 +
qapi/block-core.json | 5 +-
5 files changed, 263 insertions(+), 89 deletions(-)
--
2.29.2
3 years, 3 months
[PATCH 00/22] qemu: Fix mess with lifecycle actions and unbreak transient disks
by Peter Krempa
While investigating how to fix issue with transient disks breaking when
-no-shutdown is not used I've ended up figuring out that lifecycle
action handling in the qemu driver is very broken.
Unbreak the handling by rejecting some actions which were never
implemented, add support for 'set-action' qmp command and use it to
update the 'reset' action in qemu and always use '-no-shutdown'.
Peter Krempa (22):
qemuMonitorJSONSetWatchdogAction: Use automatic memory clearing
qemuDomainSetLifecycleAction: Add a note about argument range-check
qemu: driver: Use 'qemuDomainSaveStatus' for saving status XML
qemu: validate: Reformat header and purge unused includes
qemu: Reject 'rename-restart' action for
'on_reboot'/'on_poweroff'/'on_crash'
qemu: driver: Validate lifecycle actions in
'qemuDomainSetLifecycleAction'
qemu: Reject 'preserve' action for
'on_reboot'/'on_poweroff'/'on_crash'
qemu: Honor 'restart' action for 'on_poweroff'
qemu: capablities: Detect presence of 'set-action' as
QEMU_CAPS_SET_ACTION
qemu: monitor: Implement monitor code for 'set-action' command
qemuDomainAttachWatchdog: Use 'set-action' instead of
'watchdog-set-action' if supported
qemuxml2argvtest: Add 'LATEST' version of 'misc-no-reboot' test case
qemuDomainObjPrivate: Annotate 'allowReboot' field
qemu: migration: Don't transfer 'allowReboot' flag
qemu: domain: Remove qemuDomainIsUsingNoShutdown
qemuDomainSetLifecycleAction: Forbid live update of 'on_reboot'
qemuProcessHandleReset: Don't emulate lifecycle actions for RESET
event
qemuProcessLaunch: Setup handling of 'on_reboot' via QMP when starting
the process
qemu: command: Always use '-no-shutdown'
qemu: process: Don't set 'allowReboot' when qemu supports 'set-action'
qemuDomainSetLifecycleAction: Properly update 'onReboot' action in
qemu
qemu: process: Ignore 'RESET' event during startup
docs/formatdomain.rst | 8 +-
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 14 +-
src/qemu/qemu_domain.c | 16 --
src/qemu/qemu_domain.h | 11 +-
src/qemu/qemu_driver.c | 201 +++++++++++-------
src/qemu/qemu_hotplug.c | 54 ++++-
src/qemu/qemu_migration.c | 5 -
src/qemu/qemu_migration_cookie.c | 22 --
src/qemu/qemu_migration_cookie.h | 4 -
src/qemu/qemu_monitor.c | 16 ++
src/qemu/qemu_monitor.h | 49 +++++
src/qemu/qemu_monitor_json.c | 95 ++++++++-
src/qemu/qemu_monitor_json.h | 7 +
src/qemu/qemu_process.c | 85 +++++---
src/qemu/qemu_validate.c | 51 +++++
src/qemu/qemu_validate.h | 31 +--
.../caps_6.0.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 +
.../caps_6.0.0.x86_64.xml | 1 +
.../caps_6.1.0.x86_64.xml | 1 +
.../basic-xml2xml-out.xml | 1 -
.../full-xml2xml-out.xml | 1 -
.../modern-dom-out-dest.xml | 1 -
.../modern-dom-out-source.xml | 1 -
.../nbd-bitmaps-xml2xml-out.xml | 1 -
tests/qemumonitorjsontest.c | 6 +
.../misc-no-reboot.x86_64-latest.args | 35 +++
tests/qemuxml2argvtest.c | 1 +
30 files changed, 529 insertions(+), 194 deletions(-)
create mode 100644 tests/qemuxml2argvdata/misc-no-reboot.x86_64-latest.args
--
2.31.1
3 years, 3 months