Re: [libvirt] [Qemu-devel] Qemu migration with vhost-user-blk on top of local storage
by Stefan Hajnoczi
On Wed, Jan 09, 2019 at 06:23:42PM +0800, wuzhouhui wrote:
> Hi everyone,
>
> I'm working qemu with vhost target (e.g. spdk), and I attempt to migrate VM with
> 2 local storages. One local storage is a regular file, e.g. /tmp/c74.qcow2, and
> the other is a malloc bdev that spdk created. This malloc bdev will exported to
> VM via vhost-user-blk. When I execute following command:
>
> virsh migrate --live --persistent --unsafe --undefinesource --copy-storage-all \
> --p2p --auto-converge --verbose --desturi qemu+tcp://<uri>/system vm0
>
> The libvirt reports:
>
> qemu-2.12.1: error: internal error: unable to execute QEMU command \
> 'nbd-server-add': Cannot find device=drive-virtio-disk1 nor \
> node_name=drive-virtio-disk1
Please post your libvirt domain XML.
> Does it means that qemu with spdk on top of local storage don't support migration?
>
> QEMU: 2.12.1
> SPDK: 18.10
vhost-user-blk bypasses the QEMU block layer, so NBD storage migration
at the QEMU level will not work for the vhost-user-blk disk.
Stefan
1 year
[libvirt] [PATCH v3] openvswitch: Add new port VLAN mode "dot1q-tunnel"
by luzhipeng＠uniudc.com
From: ZhiPeng Lu <luzhipeng(a)uniudc.com>
Signed-off-by: ZhiPeng Lu <luzhipeng(a)uniudc.com>
---
v1->v2:
1. Fix "make syntax-check" failure
v2->v3:
1. remove other_config when updating vlan
docs/formatnetwork.html.in | 17 +++++++++--------
docs/schemas/networkcommon.rng | 1 +
src/conf/netdev_vlan_conf.c | 2 +-
src/util/virnetdevopenvswitch.c | 7 +++++++
src/util/virnetdevvlan.h | 1 +
5 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index 363a72b..3c1ae62 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -688,16 +688,17 @@
</p>
<p>
For network connections using Open vSwitch it is also possible
- to configure 'native-tagged' and 'native-untagged' VLAN modes
+ to configure 'native-tagged' and 'native-untagged' and 'dot1q-tunnel'
+ VLAN modes.
<span class="since">Since 1.1.0.</span> This is done with the
- optional <code>nativeMode</code> attribute on
- the <code><tag></code> subelement: <code>nativeMode</code>
- may be set to 'tagged' or 'untagged'. The <code>id</code>
- attribute of the <code><tag></code> subelement
- containing <code>nativeMode</code> sets which VLAN is considered
- to be the "native" VLAN for this interface, and
+ optional <code>nativeMode</code> attribute on the
+ <code><tag></code> subelement: <code>nativeMode</code>
+ may be set to 'tagged' or 'untagged' or 'dot1q-tunnel'.
+ The <code>id</code> attribute of the <code><tag></code>
+ subelement containing <code>nativeMode</code> sets which VLAN is
+ considered to be the "native" VLAN for this interface, and
the <code>nativeMode</code> attribute determines whether or not
- traffic for that VLAN will be tagged.
+ traffic for that VLAN will be tagged or QinQ.
</p>
<p>
<code><vlan></code> elements can also be specified in
diff --git a/docs/schemas/networkcommon.rng b/docs/schemas/networkcommon.rng
index 2699555..11c48ff 100644
--- a/docs/schemas/networkcommon.rng
+++ b/docs/schemas/networkcommon.rng
@@ -223,6 +223,7 @@
<choice>
<value>tagged</value>
<value>untagged</value>
+ <value>dot1q-tunnel</value>
</choice>
</attribute>
</optional>
diff --git a/src/conf/netdev_vlan_conf.c b/src/conf/netdev_vlan_conf.c
index dff49c6..79710d9 100644
--- a/src/conf/netdev_vlan_conf.c
+++ b/src/conf/netdev_vlan_conf.c
@@ -29,7 +29,7 @@
#define VIR_FROM_THIS VIR_FROM_NONE
VIR_ENUM_IMPL(virNativeVlanMode, VIR_NATIVE_VLAN_MODE_LAST,
- "default", "tagged", "untagged")
+ "default", "tagged", "untagged", "dot1q-tunnel")
int
virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr ctxt, virNetDevVlanPtr def)
diff --git a/src/util/virnetdevopenvswitch.c b/src/util/virnetdevopenvswitch.c
index 8fe06fd..9fec30b 100644
--- a/src/util/virnetdevopenvswitch.c
+++ b/src/util/virnetdevopenvswitch.c
@@ -91,6 +91,11 @@ virNetDevOpenvswitchConstructVlans(virCommandPtr cmd, virNetDevVlanPtr virtVlan)
virCommandAddArg(cmd, "vlan_mode=native-untagged");
virCommandAddArgFormat(cmd, "tag=%d", virtVlan->nativeTag);
break;
+ case VIR_NATIVE_VLAN_MODE_DOT1Q_TUNNEL:
+ virCommandAddArg(cmd, "vlan_mode=dot1q-tunnel");
+ virCommandAddArg(cmd, "other_config:qinq-ethtype=802.1q");
+ virCommandAddArgFormat(cmd, "tag=%d", virtVlan->nativeTag);
+ break;
case VIR_NATIVE_VLAN_MODE_DEFAULT:
default:
break;
@@ -504,6 +509,8 @@ int virNetDevOpenvswitchUpdateVlan(const char *ifname,
"--", "--if-exists", "clear", "Port", ifname, "tag",
"--", "--if-exists", "clear", "Port", ifname, "trunk",
"--", "--if-exists", "clear", "Port", ifname, "vlan_mode",
+ "--", "--if-exists", "remove", "Port", ifname, "other_config",
+ "qinq-ethtype", NULL,
"--", "--if-exists", "set", "Port", ifname, NULL);
if (virNetDevOpenvswitchConstructVlans(cmd, virtVlan) < 0)
diff --git a/src/util/virnetdevvlan.h b/src/util/virnetdevvlan.h
index be85f59..0667f9d 100644
--- a/src/util/virnetdevvlan.h
+++ b/src/util/virnetdevvlan.h
@@ -29,6 +29,7 @@ typedef enum {
VIR_NATIVE_VLAN_MODE_DEFAULT = 0,
VIR_NATIVE_VLAN_MODE_TAGGED,
VIR_NATIVE_VLAN_MODE_UNTAGGED,
+ VIR_NATIVE_VLAN_MODE_DOT1Q_TUNNEL,
VIR_NATIVE_VLAN_MODE_LAST
} virNativeVlanMode;
--
1.8.3.1
1 year
[libvirt] [PATCH] Fix compile error for stable 1.2.9
by Yang hongyang
Seems a backport miss. An extra member is passed to struct
virLXCBasicMountInfo.
Signed-off-by: Yang hongyang <hongyang.yang(a)easystack.cn>
---
src/lxc/lxc_container.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 28dabec..1c65fa9 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -760,7 +760,7 @@ typedef struct {
static const virLXCBasicMountInfo lxcBasicMounts[] = {
{ "proc", "/proc", "proc", MS_NOSUID|MS_NOEXEC|MS_NODEV, false, false },
- { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false, false },
+ { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "sysfs", "/sys", "sysfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "securityfs", "/sys/kernel/security", "securityfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, true, true },
#if WITH_SELINUX
--
1.7.1
1 year
[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so it's a good time to start this discussion.
There are two modes worth supporting for vhost-net in libvirt. The
first mode is where vhost-net backs to a tun/tap device. This is
behaves in very much the same way that -net tap behaves in qemu today.
Basically, the difference is that the virtio backend is in the kernel
instead of in qemu so there should be some performance improvement.
Current, libvirt invokes qemu with -net tap,fd=X where X is an already
open fd to a tun/tap device. I suspect that after we merge vhost-net,
libvirt could support vhost-net in this mode by just doing -net
vhost,fd=X. I think the only real question for libvirt is whether to
provide a user visible switch to use vhost or to just always use vhost
when it's available and it makes sense. Personally, I think the later
makes sense.
The more interesting invocation of vhost-net though is one where the
vhost-net device backs directly to a physical network card. In this
mode, vhost should get considerably better performance than the current
implementation. I don't know the syntax yet, but I think it's
reasonable to assume that it will look something like -net
tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
On most modern systems, there is a small number of network devices so
this model is not all that useful except when dealing with SR-IOV
adapters. In that case, each physical device can be exposed as many
virtual devices (VFs). There are a few restrictions here though. The
biggest is that currently, you can only change the number of VFs by
reloading a kernel module so it's really a parameter that must be set at
startup time.
I think there are a few ways libvirt could support vhost-net in this
second mode. The simplest would be to introduce a new tag similar to
<source network='br0'>. In fact, if you probed the device type for the
network parameter, you could probably do something like <source
network='eth0'> and have it Just Work.
Another model would be to have libvirt see an SR-IOV adapter as a
network pool whereas it handled all of the VF management. Considering
how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Has anyone put any more thought into this problem or how this should be
modeled in libvirt? Michael, could you share your current thinking for
-net syntax?
--
Regards,
Anthony Liguori
1 year
[libvirt] [python] WIP-FYI: mypy annotations for libvirt-python
by Philipp Hahn
Hello,
Maybe you already have heads about mypy <http://mypy-lang.org/>, which
"is an experimental optional static type checker for Python that aims to
combine the benefits of dynamic (or "duck") typing and static typing".
I started to write a manual annotation file for the Python binding of
libvirt. I've attached my current version, so others can benefit from
it, too. It is far from complete, but it already helped my to find some
errors in my code.
(My latest version is also available at
<https://github.com/univention/typeshed/blob/libvirt/third_party/2and3/lib...>)
Long-term it probably would be better to teach the Python binding
"generator.py" to add the type information (PEP 484
<https://www.python.org/dev/peps/pep-0484/>) directly into the generated
"libvirt.py" file, but that's for another day.
If someone else is interested in helping with that, please feel free to
get in contact.
Philipp
--
Philipp Hahn
Open Source Software Engineer
Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
hahn(a)univention.de
http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
4 years, 7 months
[libvirt] [PATCH 0/3] Fix ppc64 CPU configuration for QEMU 2.11+
by Jiri Denemark
The original fix was both incomplete and too general. It only fixed
domain startup, but libvirt would still report empty list of supported
CPU models with recent QEMU for ppc64. On the other hand, while ppc64
QEMU ignores case when looking up CPU model names, x86_64 QEMU does
case sensitive lookup.
Jiri Denemark (3):
Revert "domcaps: Treat host models as case-insensitive strings"
util: Introduce virStringListSearch
qemu: Adapt to changed ppc64 CPU model names
src/conf/domain_capabilities.c | 2 +-
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 28 +++++++++++++++++--
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_process.c | 2 +-
src/util/virstring.c | 28 +++++++++++++++++++
src/util/virstring.h | 3 ++
.../qemu_2.12.0.ppc64.xml | 6 +++-
.../caps_2.12.0.ppc64.xml | 12 ++++----
9 files changed, 73 insertions(+), 12 deletions(-)
--
2.17.0
5 years, 1 month
[libvirt] [PATCH v6 00/33] BaselineHypervisorCPU using QEMU QMP exchanges
by Chris Venteicher
Some architectures (S390) depend on QEMU to compute baseline CPU model and
expand a models feature set.
Interacting with QEMU requires starting the QEMU process and completing one or
more query-cpu-model-baseline QMP exchanges with QEMU in addition to a
query-cpu-model-expansion QMP exchange to expand all features in the model.
See "s390x CPU models: exposing features" patch set on Qemu-devel for discussion
of QEMU aspects.
This is part of resolution of: https://bugzilla.redhat.com/show_bug.cgi?id=1511999
-----
v6 addresses these issues from v5:
qemu_process: Move process code from qemu_capabilities to qemu_process
[x] Remove exception statement from commit message
qemu_process: Use qemuProcessQmp prefix
[x] s/ProcessQmp/ProcessQMP/ in this and all subsequent patches
qemu_process: Refer to proc not cmd in process code
[x] Back port indentation fix in qemuProcessQMPRun
qemu_capabilities: Stop QEMU process before freeing
[x] Back port !proc check in qemuProcessQmpStop
qemu_process: Use qemuProcessQmp struct for a single process
[x] Remove extra empty lines
qemu_process: All ProcessQMP errors are fatal
[x] Split into multiple patches
qemu_process: Introduce qemuProcessQmpStart
[x] Log function parameters separately in the first function debug message
[x] Removed NULLSTR check on proc-binary (would fail previously on proc activate)
[x] Back port referring to stderr rather than qmperr in comment
[ ] Combine qemuProcessQmpStop and qemuProcessQmpFree (See reply to v5 email)
emu_process: Collect monitor code in single function
[x] Back port qemuMonitorOpen indent fix to earlier patch
qemu_process: Don't open monitor if process failed
[x] Drop patch
qemu_process: Cleanup qemuProcessQmp alloc function
[x] s/Qemu/QEMU/ in comments for qemuProcessQMPNew
[x] Remove unneeded use of NULLSTR and NULL check before calling qemuProcessQmpFree
qemu_process: Cleanup qemuProcessQmpStop function
[x] Remove lines from from commit message
[x] Remove capitalization from comment
[x] Fix func def to match coding style
[x] Back port !proc check to earlier patch
qemu_process: Catch process free before process stop
[x] Remove capitalization from comment
[x] Don't do proc NULL check in VIR_DEBUG
[ ] Combine qemuProcessQmpStop and qemuProcessQmpFree (See reply to v5 email)
qemu_monitor: Make monitor callbacks optional
[x] Drop patch
qemu_process: Enter QMP command mode when starting QEMU Process
[ ] Don't call qemuMonitorSetCapabilities in qemuProcessQMPConnectMonitor (See reply to v5 email)
qemu_process: Use unique directories for QMP processes
[x] s/qemu./qmp-/ for QMP process directory name prefix
[x] Catch mkdtemp returns NULL
qemu_process: Stop locking QMP process monitor immediately
[x] Drop patch
qemu_monitor: Introduce qemuMonitorCPUModelInfoNew
[x] Use qemuMonitorCPUModelInfoNew to set model name
[x] Drop variable initialization
[x] Use qemuMonitorCPUModelInfoNew in qemuMonitorJSONGetCPUModelExpansion (Pull forward)
[ ] Remove orig NULL check (Unit tests fail if I do this)
qemu_monitor: Introduce qemuMonitorCPUModelInfo / JSON conversion
[x] Make variable initialization easier to read in PropAdd
[x] Require at least one "prop" (don't allow zero in this commit)
qemu_capabilities: Introduce virQEMuCapsMigratablePropsDiff
[x] Remove template txt in commit message
[x] Change function name
[x] Distinguish nmProp from mProp
[x] Don't set cpuData->info to NULL
[ ] Don't use tmp (defer to next patch set... out of time)
qemu_monitor: qemuMonitorGetCPUModelExpansion inputs and outputs CPUModelInfo
[x] Remove extra line from commit message
[x] Change parameter order
[x] Don't use VIR_STEAL_PTR
qemu_capabilities: Introduce CPUModelInfo to virCPUDef function
[x] Change comment
[x] Change parameter order
[x] Separate lines
[x] Move debug message before alloc
[x] Back port function spacing fix from next patch
qemu_capabilities: Introduce virCPUDef to CPUModelInfo function
[x] Change comment
[x] Move debug message before alloc
[x] Remove NULL check on feature->name
[x] Document prop value semantics
Reviewed in v5 but no changes required:
qemu_process: Limit qemuProcessQmpNew to const input strings
qemu_process: Use consistent name for stop process function
qemu_process: Persist stderr in qemuProcessQmp struct
qemu_process: Store libDir in qemuProcessQmp struct
qemu_process: Setup paths within qemuProcessQmpInit
qemu_process: Stop retaining Monitor config in qemuProcessQmp
Not reviewed in v5:
qemu_monitor: Support query-cpu-model-baseline QMP command
qemu_driver: Consolidate code to baseline using libvirt
qemu_driver: Decouple code for baseline using libvirt
qemu_driver: Identify using libvirt as a distinct way to compute baseline
qemu_driver: Support baseline calculation using QEMU
qemu_driver: Support feature expansion via QEMU when baselining cpu
qemu_driver: Remove unsupported props in expanded hypervisor baseline output
qemu_monitor: Default props to migratable when expanding cpu model
-----
v5:
Fixes all process issues identified here:
https://www.redhat.com/archives/libvir-list/2018-November/msg00349.html
- Make the process code generic (not capabilities specific) for use by
BaselineHypervisorCPU
- Many of the process patches are simple code moves with implementation
changes in other distinct patches
- A thread safe library function creates a unique directory under libDir for each QEMU
process (for QMP messaging) to decouple processes in terms of sockets and
file system footprint.
The remaining (non-process) patches in v4 address all issues in v1-v4 of
'BaselineHypervisorCPU using QEMU QMP exchanges'
Thanks,
Chris
*** BLURB HERE ***
Chris Venteicher (33):
qEmu_process: Move process code from qemu_capabilities to qemu_process
qemu_process: Use qemuProcessQMP prefix
qemu_process: Limit qemuProcessQMPNew to const input strings
qemu_process: Refer to proc not cmd in process code
qemu_process: Use consistent name for stop process function
qemu_capabilities: Stop QEMU process before freeing
qemu_process: Use qemuProcessQMP struct for a single process
qemu_process: All ProcessQMP errors are fatal
qemu_process: Expose process exit status code
qemu_process: Persist stderr in qemuProcessQMP struct
qemu_process: Introduce qemuProcessQMPStart
qemu_process: Collect monitor code in single function
qemu_process: Store libDir in qemuProcessQMP struct
qemu_process: Setup paths within qemuProcessQMPInit
qemu_process: Stop retaining Monitor config in qemuProcessQMP
qemu_process: Cleanup qemuProcessQMP alloc function
qemu_process: Cleanup qemuProcessQMPStop function
qemu_process: Catch process free before process stop
qemu_process: Enter QMP command mode when starting QEMU Process
qemu_process: Use unique directories for QMP processes
qemu_monitor: Introduce qemuMonitorCPUModelInfoNew
qemu_monitor: Introduce qemuMonitorCPUModelInfo / JSON conversion
qemu_capabilities: Introduce virQEMuCapsMigratablePropsCalc
qemu_monitor: qemuMonitorGetCPUModelExpansion inputs and outputs
CPUModelInfo
qemu_capabilities: Introduce CPUModelInfo to virCPUDef function
qemu_capabilities: Introduce virCPUDef to CPUModelInfo function
qemu_monitor: Support query-cpu-model-baseline QMP command
qemu_driver: Consolidate code to baseline using libvirt
qemu_driver: Decouple code for baseline using libvirt
qemu_driver: Identify using libvirt as a distinct way to compute
baseline
qemu_driver: Support baseline calculation using QEMU
qemu_driver: Support feature expansion via QEMU when baselining cpu
qemu_monitor: Default props to migratable when expanding cpu model
src/qemu/qemu_capabilities.c | 631 ++++++++----------
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_driver.c | 216 +++++-
src/qemu/qemu_monitor.c | 165 ++++-
src/qemu/qemu_monitor.h | 29 +-
src/qemu/qemu_monitor_json.c | 223 +++++--
src/qemu/qemu_monitor_json.h | 10 +-
src/qemu/qemu_process.c | 345 ++++++++++
src/qemu/qemu_process.h | 32 +
tests/cputest.c | 11 +-
.../caps_2.10.0.s390x.xml | 60 +-
.../caps_2.11.0.s390x.xml | 58 +-
.../caps_2.12.0.s390x.xml | 56 +-
.../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 32 +-
.../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 34 +-
.../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 64 +-
tests/qemucapabilitiestest.c | 7 +
17 files changed, 1375 insertions(+), 602 deletions(-)
--
2.17.1
5 years, 7 months
[libvirt] [PATCH v2 00/25] qemu: virtio-{non-}transitional support
by Cole Robinson
v1 libvirt patches:
https://www.redhat.com/archives/libvir-list/2019-January/msg00593.html
Previous incomplete RFC here:
https://www.redhat.com/archives/libvir-list/2019-January/msg00346.html
qemu patches, queued for qemu 4.0.0:
https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg00923.html
Previous libvirt discussion around this:
https://www.redhat.com/archives/libvir-list/2018-August/msg01073.html
Long story short we need to expose these options so apps have a
usable way to support rhel6 + virtio + q35. This series exposes
the new devices as model= values. This required adding new
model= attributes for several devices. See v1 posting for a summary
of the XML changes introduced, mostly it's adding virtio-transitional
and virtio-non-transitional to existing model= enums, and adding
model= XML attributes for devices that don't have them (disk, fs,
input)
Changes from v1:
- <filesystem> models are now named virtio-9p, virtio-9p-transitional,
virtio-9p-non-transitional. This is to avoid ambiguity as in the near
future we will likely add virtio-fs <filesystem> support
- Cleanup and prep work is separated into separate patches and front
loaded into the series.
- qemu caps additions are separated from the qemu_command.c patches,
and squashed together upfront.
- virDomainDeviceSetData is added to make it easier to compose a
virDomainDeviceDef on the fly. This is used for the transitional cli
building but can be useful elsewhere too, but that's for another
series.
- Lots of small improvements and fixes suggested by Andrea.
Thanks,
Cole
Cole Robinson (25):
conf: Set net->model earlier
conf: Add virDomainNetIsVirtioModel
qemu: Move <memballoon> validation out of qemu_command.c
qemu: Move <rng> validation out of qemu_command.c
qemu: command: Make vhost-scsi device string depend on address
qemu: command: Convert vhost-{vsock,scsi} to qemuBuildVirtioDevStr
conf: Add virDomainDeviceSetData
qemu: command: Make BuildVirtioDevStr more generic
qemu: command: Add qemuCaps to BuildVirtioStr
qemu: capabilities: Add virtio/vhost {non-}transitional
conf: Add <disk model='virtio-{non-}transitional'/>
qemu: Support disk model=virtio-{non-}transitional
qemu: Support interface model=virtio-{non-}transitional
conf: Add <hostdev model='virtio-{non-}transitional'/>
qemu: Support hostdev model=virtio-{non-}transitional
qemu: Support rng model=virtio-{non-}transitional
conf: Add <filesystem model='virtio-9p-{non-}transitional'/>
qemu: Support filesystem model=virtio-9p-{non-}transitional
qemu: Support memballoon model=virtio-{non-}transitional
qemu: Support vsock model=virtio-{non-}transitional
conf: Add <input model='virtio-{non-}transitional'/>
qemu: Support input model=virtio-{non-}transitional
qemu: Support virtio-serial controller model=virtio-{non-}transitional
qemu: Support scsi controller model=virtio-{non-}transitional
qemu: domcaps: Report disk <enum name="model">
docs/formatdomain.html.in | 39 ++-
docs/schemas/domaincommon.rng | 61 +++-
src/conf/domain_capabilities.c | 1 +
src/conf/domain_capabilities.h | 1 +
src/conf/domain_conf.c | 328 ++++++++++++++++--
src/conf/domain_conf.h | 67 ++++
src/libvirt_private.syms | 6 +
src/libxl/libxl_conf.c | 2 +
src/qemu/qemu_capabilities.c | 61 ++++
src/qemu/qemu_capabilities.h | 28 ++
src/qemu/qemu_command.c | 252 +++++++++++---
src/qemu/qemu_domain.c | 79 ++++-
src/qemu/qemu_domain_address.c | 97 ++++--
src/qemu/qemu_driver.c | 17 +-
src/qemu/qemu_hotplug.c | 2 +-
src/qemu/qemu_interface.c | 8 +-
src/qemu/qemu_process.c | 3 +-
src/security/virt-aa-helper.c | 2 +-
src/vbox/vbox_common.c | 2 +
src/vmx/vmx.c | 5 +-
.../bhyve_basic.x86_64.xml | 1 +
.../bhyve_fbuf.x86_64.xml | 1 +
.../bhyve_uefi.x86_64.xml | 1 +
tests/domaincapsschemadata/full.xml | 6 +
.../domaincapsschemadata/libxl-xenfv-usb.xml | 1 +
.../domaincapsschemadata/libxl-xenpv-usb.xml | 1 +
.../qemu_1.7.0.x86_64.xml | 3 +
.../qemu_2.12.0-virt.aarch64.xml | 5 +
.../qemu_2.12.0.ppc64.xml | 5 +
.../qemu_2.12.0.s390x.xml | 5 +
.../qemu_2.12.0.x86_64.xml | 5 +
.../qemu_2.6.0-virt.aarch64.xml | 5 +
.../qemu_2.6.0.aarch64.xml | 5 +
.../domaincapsschemadata/qemu_2.6.0.ppc64.xml | 5 +
.../qemu_2.6.0.x86_64.xml | 5 +
.../domaincapsschemadata/qemu_2.7.0.s390x.xml | 5 +
.../qemu_2.8.0-tcg.x86_64.xml | 5 +
.../domaincapsschemadata/qemu_2.8.0.s390x.xml | 5 +
.../qemu_2.8.0.x86_64.xml | 5 +
.../qemu_2.9.0-q35.x86_64.xml | 5 +
.../qemu_2.9.0-tcg.x86_64.xml | 5 +
.../qemu_2.9.0.x86_64.xml | 5 +
.../domaincapsschemadata/qemu_3.0.0.s390x.xml | 5 +
.../qemu_4.0.0.x86_64.xml | 154 ++++++++
tests/domaincapstest.c | 4 +
.../caps_4.0.0.x86_64.xml | 20 ++
.../virtio-non-transitional.x86_64-3.1.0.args | 65 ++++
...virtio-non-transitional.x86_64-latest.args | 62 ++++
.../virtio-non-transitional.xml | 40 +++
.../virtio-transitional.x86_64-3.1.0.args | 50 +++
.../virtio-transitional.x86_64-latest.args | 52 +++
.../qemuxml2argvdata/virtio-transitional.xml | 40 +++
tests/qemuxml2argvmock.c | 2 +-
tests/qemuxml2argvtest.c | 6 +
.../virtio-non-transitional.xml | 121 +++++++
.../virtio-transitional.xml | 80 +++++
tests/qemuxml2xmltest.c | 26 +-
57 files changed, 1736 insertions(+), 141 deletions(-)
create mode 100644 tests/domaincapsschemadata/qemu_4.0.0.x86_64.xml
create mode 100644 tests/qemuxml2argvdata/virtio-non-transitional.x86_64-3.1.0.args
create mode 100644 tests/qemuxml2argvdata/virtio-non-transitional.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-non-transitional.xml
create mode 100644 tests/qemuxml2argvdata/virtio-transitional.x86_64-3.1.0.args
create mode 100644 tests/qemuxml2argvdata/virtio-transitional.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-transitional.xml
create mode 100644 tests/qemuxml2xmloutdata/virtio-non-transitional.xml
create mode 100644 tests/qemuxml2xmloutdata/virtio-transitional.xml
--
2.20.1
5 years, 8 months
[libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities
by Erik Skultety
Hi,
this is a summary of a private discussion I've had with guys CC'd on this email
about finding a solution to [1] - basically, the default permissions on
/dev/sev (below) make it impossible to query for SEV platform capabilities,
since by default we run QEMU as qemu:qemu when probing for capabilities. It's
worth noting is that this is only relevant to probing, since for a proper QEMU
VM we create a mount namespace for the process and chown all the nodes (needs a
SEV fix though).
# ll /dev/sev
crw-------. 1 root root
I suggested either force running QEMU as root for probing (despite the obvious
security implications) or using namespaces for probing too. Dan argued that
this would have a significant perf impact and suggested we ask systemd to add a
global udev rule.
I proceeded with cloning [1] to systemd and creating an udev rule that I planned
on submitting to systemd upstream - the initial idea was to mimic /dev/kvm and
make it world accessible to which Brijesh from AMD expressed a concern that
regular users might deplete the resources (limit on the number of guests
allowed by the platform). But since the limit is claimed to be around 4, Dan
discouraged me to continue with restricting the udev rule to only the 'kvm'
group which Laszlo suggested earlier as the limit is so small that a malicious
QEMU could easily deplete this during probing. This fact also ruled out any
kind of ACL we could create dynamically. Instead, he suggested that we filter
out the kvm-capable QEMU and put only that one in the namespace without a
significant perf impact.
- my take on this is that there could potentially be more than a single
kvm-enabled QEMU and therefore we'd need to create more than just a
single namespace.
- I also argued that I can image that the same kind of DOS attack might be
possible from within the namespace, even if we created the /dev/sev node
only in SEV-enabled guests (which we currently don't). All of us have
agreed that allowing /dev/sev in the namespace for only SEV-enabled
guests is worth doing nonetheless.
In the meantime, Christophe went through the kernel code to verify how the SEV
resources are managed and what protection is currently in place to mitigate the
chance of a process easily depleting the limit on SEV guests. He found that
ASID, which determines the encryption key, is allocated from a single ASID
bitmap and essentially guarded by a single 'sev->active' flag.
So, in conclusion, we absolutely need input from Brijesh (AMD) whether there
was something more than the low limit on number of guests behind the default
permissions. Also, we'd like to get some details on how the limit is managed,
helping to assess the approaches mentioned above.
Thanks and please do share your ideas,
Erik
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1665400
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1561113
5 years, 8 months
