[libvirt] [PATCH 0/9] support use of precreated tap devices from unprivileged libvirtd
by Laine Stump
This resolves https://bugzilla.redhat.com/1723367
It has become more popular to run libvirtd in an unprivileged
environment (e.g. inside a container), but until now the only possible
types of network connection for a qemu started by an unprivileged
libvirtd were:
1) a usermode slirp connection
2) a tap device connection to a bridge handled by running
qemu-bridge-helper (a suid-root utility distributed with qemu)
3) a host network card assigned to the guest using VFIO (this requires
special setup by a privileged process though)
This patch series remedies that by making it possible for libvirtd to
use a tap device that has been pre-created (*and* properly setup) by
some other process beforehand.
In order to use this, you must have a standard tap, or macvtap device
that has been set to be owned by the uid that will be running
libvirtd, has its MAC address already set, and has been set online
(IFF_UP). For example, here are the commands to create a standard tap
device named "mytap0", attach it to the host bridge device "br0" and
prepare it for use by a libvirtd that is running as user "laine":
ip tuntap add mode tap user laine group laine name mytap0
ip link set mytap0 up
ip link set mytap0 master br0
(You may want to set a specific MAC address for the tap device, but as
long as it *doesn't* match the MAC address used by the guest emulated
device, it really doesn't matter)
You can now add the following <interface> to a domain definition:
<interface type='ethernet'>
<model type='virtio'/>
<mac address='52:54:00:11:11:11'/>
<target dev='mytap0' managed='no'/>
</interface>
and start up the guest.
A similar set of commands to create a macvtap device named
"mymacvtap0" with MAC addres 52:54:00:11:11:11 connected to the host
device "en2" would be something like this:
ip link add link en2 name mymacvtap0 address 52:54:00:11:11:11 \
type macvtap mode bridge
ip link set mymacvtap0 up
The XML would be identical, except the name of the device
<interface type='ethernet'>
<model type='virtio'/>
<mac address='52:54:00:11:11:11'/>
<target dev='mymacvtap0' managed='no'/>
</interface>
(Note that in the case of macvtap, the precreated device must *match*
the MAC address of the emulated guest device).
If libvirtd is given a precreated device, that device will *not* be
explicitly deleted when qemu is finished with it - the caller must
take care of that.
Laine Stump (9):
util: new function virNetDevMacVLanIsMacvtap()
util: make a couple virNetDevMacVlan*() functions public
qemu: reorganize qemuInterfaceEthernetConnect()
conf: use virXMLFormatElement for interface <target>
conf: new "managed" attribute for target dev of <interface
type='ethernet'>
qemu: support unmanaged target tap dev for <interface type='ethernet'>
qemu: support unmanaged macvtap devices with <interface
type='ethernet'>
qemu: explicitly delete standard tap devices only on platforms that
require it
docs: update news file
docs/formatdomain.html.in | 48 +++++++---
docs/news.xml | 13 +++
docs/schemas/domaincommon.rng | 5 ++
src/conf/domain_conf.c | 55 +++++++++---
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 3 +
src/qemu/qemu_interface.c | 89 ++++++++++++-------
src/qemu/qemu_process.c | 6 +-
src/util/virnetdev.h | 2 +-
src/util/virnetdevmacvlan.c | 35 ++++++--
src/util/virnetdevmacvlan.h | 12 +++
.../net-eth-unmanaged-tap.args | 32 +++++++
.../net-eth-unmanaged-tap.xml | 35 ++++++++
tests/qemuxml2argvmock.c | 16 +++-
tests/qemuxml2argvtest.c | 1 +
.../net-eth-unmanaged-tap.xml | 40 +++++++++
tests/qemuxml2xmltest.c | 1 +
17 files changed, 329 insertions(+), 65 deletions(-)
create mode 100644 tests/qemuxml2argvdata/net-eth-unmanaged-tap.args
create mode 100644 tests/qemuxml2argvdata/net-eth-unmanaged-tap.xml
create mode 100644 tests/qemuxml2xmloutdata/net-eth-unmanaged-tap.xml
--
2.21.0
4 years, 6 months
[libvirt] Fwd: libvirtd failing on MacOS in setgroups
by Marcus Furlong
Resend to libvir-list in case that is more appropriate:
Hi,
I get the following error when running libvirtd on MacOS as root:
2019-07-11 00:12:33.673+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-x86_64 for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
As a result `virsh capabilities` as root returns nothing:
$ sudo virsh capabilities | grep qemu
<baselabel type='qemu'>+0:+0</baselabel>
whereas running as a regular user works fine:
$ virsh capabilites | grep qemu
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
<domain type='qemu'/>
and by extension, running VMs as regular user works fine via
qemu:///session , but qemu:///system does not work.
It seems like setgroups is failing:
https://github.com/libvirt/libvirt/blob/v5.5.0/src/util/virutil.c#L1045-L...
Is this the expected behaviour?
Full output below:
$ sudo libvirtd
2019-07-11 00:12:33.379+0000: 123145573953536: info : libvirt version: 5.5.0
2019-07-11 00:12:33.379+0000: 123145573953536: warning :
virProcessGetStartTime:1070 : Process start time of pid 49746 not
available on this platform
2019-07-11 00:12:33.379+0000: 123145573953536: error :
virSysinfoReadDMI:1172 : internal error: Failed to find path for
dmidecode binary
2019-07-11 00:12:33.380+0000: 123145573953536: error :
virFileFindHugeTLBFS:3734 : this function is not supported by the
connection driver: virFileFindHugeTLBFS
2019-07-11 00:12:33.382+0000: 123145573953536: warning :
virQEMUCapsInit:919 : Failed to get host CPU cache info
2019-07-11 00:12:33.401+0000: 123145573953536: error :
virHostCPUGetTscInfo:1405 : Probing TSC is not supported on this
platform: Function not implemented
2019-07-11 00:12:33.401+0000: 123145573953536: error : virExec:521 :
Cannot find 'pm-is-supported' in path: No such file or directory
2019-07-11 00:12:33.401+0000: 123145573953536: warning :
virQEMUCapsInit:926 : Failed to get host power management capabilities
2019-07-11 00:12:33.401+0000: 123145573953536: error :
virNumaGetPages:988 : Operation not supported: page info is not
supported on this platform
2019-07-11 00:12:33.401+0000: 123145573953536: warning :
virQEMUCapsInit:933 : Failed to get pages info
2019-07-11 00:12:33.407+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-alpha for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.407+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-alpha: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-alpha for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.413+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-arm for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.413+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-arm: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-arm for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.419+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-arm for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.419+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-arm: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-arm for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.424+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-aarch64 for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.424+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-aarch64: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-aarch64 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.431+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-cris for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.431+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-cris: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-cris for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.437+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-i386 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.437+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-i386: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-i386 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.443+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-lm32 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.443+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-lm32: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-lm32 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.449+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-m68k for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.449+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-m68k: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-m68k for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.497+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-microblaze for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.497+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-microblaze: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-microblaze for probing:
libvirt: error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.503+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-microblazeel for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.503+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-microblazeel: internal error: Failed to
start QEMU binary /usr/local/bin/qemu-system-microblazeel for probing:
libvirt: error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.509+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-mips for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.509+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-mips: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-mips for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.515+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-mipsel for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.515+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-mipsel: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-mipsel for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.521+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-mips64 for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.521+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-mips64: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-mips64 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.527+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-mips64el for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.527+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-mips64el: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-mips64el for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.533+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-ppc for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.533+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-ppc: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-ppc for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.571+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-ppc64 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.571+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-ppc64: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-ppc64 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.576+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-ppc64 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.576+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-ppc64: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-ppc64 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.582+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-riscv32 for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.582+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-riscv32: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-riscv32 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.588+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-riscv64 for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.588+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-riscv64: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-riscv64 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.594+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-s390x for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.594+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-s390x: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-s390x for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.600+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-sh4 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.600+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-sh4: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-sh4 for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.605+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-sh4eb for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.605+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-sh4eb: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-sh4eb for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.612+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-sparc for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.612+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-sparc: internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-sparc for probing: libvirt: error :
cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.619+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-sparc64 for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.619+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-sparc64: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-sparc64 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.667+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-unicore32 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.667+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-unicore32: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-unicore32 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.673+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-x86_64 for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.673+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-x86_64: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-x86_64 for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.679+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-xtensa for probing: libvirt: error
: cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.679+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-xtensa: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-xtensa for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.685+0000: 123145573953536: error :
qemuProcessQMPLaunch:8501 : internal error: Failed to start QEMU
binary /usr/local/bin/qemu-system-xtensaeb for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
2019-07-11 00:12:33.685+0000: 123145573953536: warning :
virQEMUCapsLogProbeFailure:4578 : Failed to probe capabilities for
/usr/local/bin/qemu-system-xtensaeb: internal error: Failed to start
QEMU binary /usr/local/bin/qemu-system-xtensaeb for probing: libvirt:
error : cannot set supplemental groups: Invalid argument
--
Marcus Furlong
4 years, 7 months
[libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci
by Li Feng
Hi Guys,
And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support
for libvirt.
The usage in qemu like this:
Vhost-SCSI
-chardev socket,id=char0,path=/var/tmp/vhost.0
-device vhost-user-scsi-pci,id=scsi0,chardev=char0
Vhost-BLK
-chardev socket,id=char1,path=/var/tmp/vhost.1
-device vhost-user-blk-pci,id=blk0,chardev=char1
What type should I add for libvirt.
Type1:
<hostdev mode='subsystem' type='vhost-user'>
<source protocol='vhost-user-scsi' path='/tmp/vhost-scsi.sock'></source>
<alias name="vhost-user-scsi-disk1"/>
</hostdev>
Type2:
<disk type='network' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source protocol='vhost-user' path='/tmp/vhost-scsi.sock'>
</source>
<target dev='sdb' bus='vhost-user-scsi'/>
<boot order='3'/>
<alias name='scsi0-0-0-1'/>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>
<disk type='network' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source protocol='vhost-user' path='/tmp/vhost-blk.sock'>
</source>
<target dev='vda' bus='vhost-user-blk'/>
<boot order='1'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07'
function='0x0'/>
</disk>
Could anyone give some suggestions?
Thanks,
Feng Li
--
The SmartX email address is only for business purpose. Any sent message
that is not related to the business is not authorized or permitted by
SmartX.
本邮箱为北京志凌海纳科技有限公司（SmartX）工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.
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
4 years, 7 months
[libvirt] QEMU bitmap backup usability FAQ
by John Snow
Hi, downstream here at Red Hat I've been fielding some questions about
the usability and feature readiness of Bitmaps (and related features) in
QEMU.
Here are some questions I answered internally that I am copying to the
list for two reasons:
(1) To make sure my answers are actually correct, and
(2) To share this pseudo-reference with the community at large.
This is long, and mostly for reference. There's a summary at the bottom
with some todo items and observations about the usability of the feature
as it exists in QEMU.
Before too long, I intend to send a more summarized "roadmap" mail which
details all of the current and remaining work to be done in and around
the bitmaps feature in QEMU.
Questions:
> "What format(s) is/are required for this functionality?"
>From the QEMU API, any format can be used to create and author
incremental backups. The only known format limitations are:
1. Persistent bitmaps cannot be created on any format except qcow2,
although there are hooks to add support to other formats at a later date
if desired.
DANGER CAVEAT #1: Adding bitmaps to QEMU by default creates transient
bitmaps instead of persistent ones.
Possible TODO: Allow users to 'upgrade' transient bitmaps to persistent
ones in case they made a mistake.
2. When using push backups (blockdev-backup, drive-backup), you may use
any format as a target format.
DANGER CAVEAT #2: without backing file and/or filesystem-less sparse
support, these images will be unusable.
EXAMPLE: Backing up to a raw file loses allocation information, so we
can no longer distinguish between zeroes and unallocated regions. The
cluster size is also lost. This file will not be usable without
additional metadata recorded elsewhere.*
(* This is complicated, but it is in theory possible to do a push backup
to e.g. an NBD target with custom server code that saves allocation
information to a metadata file, which would allow you to reconstruct
backups. For instance, recording in a .json file which extents were
written out would allow you to -- with a custom binary -- write this
information on top of a base file to reconstruct a backup.)
3. Any format can be used for either shared storage or live storage
migrations. There are TWO distinct mechanisms for migrating bitmaps:
A) The bitmap is flushed to storage and re-opened on the destination.
This is only supported for qcow2 and shared-storage migrations.
B) The bitmap is live-migrated to the destination. This is supported for
any format and can be used for either shared storage or live storage
migrations.
DANGER CAVEAT #3: The second bitmap migration technique there is an
optional migration capability that must be enabled explicitly.
Otherwise, some migration combinations may drop bitmaps.
Matrix:
> migrate = migrate_capability or (persistent and shared_storage)
Enumerated:
live storage + raw : transient + no-capability: Dropped
live-storage + raw : transient + bm-capability: Migrated
live-storage + qcow2 : transient + no-capability: Dropped
live-storage + qcow2 : transient + bm-capability: Migrated
live-storage + qcow2 : persistent + no-capability: Dropped (!)
live-storage + qcow2 : persistent + bm-capability: Migrated
shared-storage + raw : transient - no-capability: Dropped
shared-storage + raw : transient + bm-capability: Migrated
shared-storage + qcow2 : transient + no-capability: Migrated
shared-storage + qcow2 : transient + bm-capability: Migrated
shared-storage + qcow2 : persistent + no-capability: Migrated
shared-storage + qcow2 : persistent + bm-capability: Migrated
Enabling the bitmap migration capability will ALWAYS migrate the bitmap.
If it's disabled, we will only migrate the bitmaps for shared storage
migrations where the bitmap is persistent, which is a qcow2-only case.
There is no warning or error if you attempt to migrate in a manner that
loses your bitmaps.
(I might be persuaded to add a case for when you are doing a live
storage migration of qcow2 with persistent bitmaps, which is somewhat a
conflicting case: you've asked for the bitmap to be persistent, but it
seems likely that if this ever happens in practice, it's because you
have neglected to ask for it to be migrated to the new host.)
See iotest 169 for more details on this.
At present, these are the only format limitations I am consciously aware
of. From a management API/GUI perspective, it makes sense to restrict
the feature set to "qcow2 only" to minimize edge cases.
> "Is libvirt aware of these 'gotcha' cases?"
>From talks I've had with Eric Blake and Peter Krempa, they certainly are
now.
> "Is it possible to make persistent the default?"
Not quickly.
In QEMU, not without a deprecation period or some other incompatibility.
Default values are not (yet?) introspectable via the schema. We need
(possibly) up to two QAPI extensions:
I) The ability to return deprecation warnings when issuing a command
that will cease to work in the future.
This has been being discussed somewhat on-list recently. It seems like
there is not a big appetite for tackling something perceived as
low-value because it is likely to be ignored.
II) The ability to document default values in the QAPI schema for the
purposes of introspection.
With one or both of these extensions, we could remove the default value
for persistence and promote it to a required argument with a
transitionary period where it will work with a warning. Then, in the
future, users will be forced to specify if they want persistent=true or
persistent=false.
This is not on my personal roadmap to implement.
> "Is it possible to make bitmap migration the default?"
I don't know at present. Migration capabilities are either "on" or "off"
and the existing negotiation mechanisms for capabilities are extremely
rudimentary.
Changing this might require fiddling with machine compat properties,
adding features to the migration protocol, or more. I don't know what I
don't know, so I will estimate this change as likely invasive.
I've discussed this with David Gilbert and it seems like a complicated
project for the benefit of this sub-project alone, so this isn't on my
personal roadmap to resolve.
The general consensus appears to be that protecting the user is
libvirt's job.
> "Where do we stand with external snapshot support?"
Still broken. In the aftermath of 4.1, it's the most obvious outstanding
broken feature. Vladimir has patches to fix it, but they need some
attention.
> "What needs to happen to bitmaps when doing stream or commit?"
Uncertain in QEMU; creating an external snapshot implicitly ends the
timeslice represented by the old bitmap, but an explicit checkpoint is
better.
I think some little ascii charts will help people understand what we're
talking about here, so let's cover some examples.
SCENARIO 1)
Here's a timeline for a single node (one image, no backing files), with
some points in time highlighted:
Time T = 0.........................n
+rec: [--X------Y------Z--------]
-rec: [---------x------y--------]
region: [aabbbbbbbcccccccddddddddd]
X, Y, and Z are points in time where bitmaps 'x', 'y', and 'z' were
created and began recording. x and y are points in time where bitmaps
'x' and 'y' stopped recording.
This creates a few distinct regions / timeslices.
a: Data written before we began tracking writes.
b: Data written to bitmap 'x'
c: Data written to bitmap 'y'
d: data written to bitmap 'z'
region 'a' is of an unknown size and indeterminate length, because there
is no reference point (checkpoint) prior to it.
regions 'b' and 'c' are of finite size and determinate length, because
they have fixed reference points on either sides of their timeslice.
region 'd' is also of an unknown size and indeterminate length, because
it is actively recording and has no checkpoint to its right. It may be
fixed at any time by disabling bitmap 'z'.
In QEMU, generally what we want to do is to do several things at one
atomic moment to keep these regions adjacent, contiguous, and disjoint.
So from a high-level (using a fictional simplified syntax), we do:
Transaction(
create('y'),
disable('x'),
backup('x')
)
which together performs a backup+checkpoint.
We can do a backup without a checkpoint:
4.1:
Transaction(
create('tmp')
merge('tmp', 'x')
backup('tmp')
)
4.2:
> backup('x', bitmap_sync=never)
Or a checkpoint without a backup:
Transaction(
create('y'),
disable('x')
)
SCENARIO 2)
Now, what happens when we make an external snapshot and do nothing at
all to our bitmaps?
Time T = 0.......................................n
+rec: [--X------Y------Z--------] <-- [-------]
-rec: [---------x------y--------] <-- [-------]
region: [aabbbbbbbcccccccddddddddd] <-- [eeeeeee]
{ base } <-- { top }
We've created a new implicit timeslice, "e" without creating a new
bitmap. Because the bitmap 'z' was still active at the time of the
snapshot, it now has a temporarily-determinate endpoint to its region.
This is kind of like an "implied checkpoint", but it's a very poor one
because it's not really addressable.
DANGER CAVEAT #4: We have no way to create incremental backups anymore,
because the current moment in time has no addressable point.
That's not great; but it is likely a fixable scenario when commit is
fixed: committing the top layer back down into the base layer will add
all new writes to the end of the old region; restoring our backup chain:
Time T = 0.........................C.......n
+rec: [--X------Y------Z-------- -------]
-rec: [---------x------y-------- -------]
region: [aabbbbbbbcccccccddddddddd ddddddd]
Here, region 'e' just gets appended to region d, and we can make
incremental backups from any checkpoint X, Y, Z to the current moment again.
SCENARIO 3)
What happens if we make a firm checkpoint at the same time we make the
snapshot?
Transaction(
disable('z'),
snapshot('top'),
create('w')
)
Time T = 0......................... ......n
+rec: [--X------Y------Z-------- ] <-- [W------]
-rec: [---------x------y--------z] <-- [-------]
region: [aabbbbbbbcccccccddddddddd ] <-- [eeeeeee]
{ base } <-- { top }
Now instead of the new region 'e' being implied, it's explicit. We can
make backups between any point and the current moment *across* the gap.
It was my thought that this was the most preferable method that libvirt
should use, but there is some doubt from Peter Krempa. We'll see how it
shakes out.
There are questions about what QEMU should do by default, without
libvirt's help. At the moment, it's "nothing" but there have been
questions about "something".
Keeping in mind that we likely can't change our existing behavior
without some kind of flag, there are still some API/usability questions:
> If we create an external snapshot on top of an image with actively
> recording bitmaps, should we disable them?
We can leave them enabled, but they'll never see any writes. Or we can
explicitly disable them. Explicitly disabling them may make more sense
to prevent modifying bitmaps accidentally on commit.
My guess: No. we should leave them alone; allow checkpoint creation
mechanisms to do the disable+create dance for bitmaps as needed.
Potential problems: The backing image is read-only, and if we change our
mind later, we will need to find a way to re-open the backing image as
read-write for the purposes of toggling the recording bit prior to any
legitimate guest usage of that node. Then, re-open as RO again.
> Should we fork bitmaps (on snapshot)?
If a bitmap named 'z' is recording when we create an external snapshot,
should that bitmap be *copied* into the top layer?
My guess: No.
This would allow us to create external snapshots *without* creating a
checkpoint, but conceptually that's a nightmare: It would allow for
mutually independent creation of snapshots OR checkpoints. This would be
hard to corral when undoing a snapshot, for instance.
In my opinion, snapshots MUST be checkpoints, and therefore allowing a
snapshot without creating a checkpoint is a no-go.
> (Should we fork bitmaps) if we're not using checkpoints?
If we are using a checkpoint-less paradigm (i.e. the rolling incremental
backup using only one bitmap) we might want to copy the bitmap up to
make the next incremental backup as if nothing ever happened.
However, rolling incremental backups doesn't need any kind of auto-copy
feature. This is possible today:
> create('base', 'A')
> transact(snapshot('top'), create('top', 'B'))
> merge('B', [('base', 'A'), ('top', 'B')])
i.e., we create a new bitmap on the top layer, then merge in the old
data from the backing file, which remains addressable.
Whether the user wants to copy up or not, there are commands that will
do that already.
> Should we create new bitmaps by default when we can?
If a backing image has bitmaps, should QEMU automatically create a new
bitmap for the top layer? Should it be named something new, something
user-provided, or based on existing active bitmaps?
If a user creates a new external snapshot with no consideration paid to
bitmaps (like "SCENARIO 2" above), they temporarily lose the ability to
do incremental backups. They might be able to commit the image back to
"try again."
That's not great. Here are some options for resolving this:
- Automatic names: Might cause collisions out-of-band with management
tooling by accident, tooling has to query to discover what bitmaps were
automatically created.
- Same names: Can create namespace confusion when committing snapshots
later; although each layer of a backing chain can have bitmaps named the
same thing, it causes future problems when committing together that can
be hard to resolve.
- User-provided name: This is workable, and requires an amendment to the
snapshot command to automatically create a new bitmap on the snapshot.
My guess: No, we can't automatically create a new bitmap for the user.
We can amend the snapshot commands to accept bitmap names, but at that
point we've just duplicated transactions:
Transact(
snapshot('top'),
create('top', 'new-bitmap')
)
All that said (Mostly a lot "No, let's not do anything"), maybe there's
room for an "assistive" mode for users, a bitmap-aware snapshot creation
command. It could do the following well-defined magic:
bitmap-snapshot(base, top, bitmap_name):
1. disable any active bitmaps in the base node.
2. create a bitmap named "bitmap_name" in the top node, failing if
a bitmap by that name already exists on either node.
What this accomplishes:
- Disables any bitmaps in the base layer ahead of time, in preparation
for an eventual commit operation.
- Always creates a new, enabled bitmap on the snapshot mode which is
guaranteed not to conflict with a name on the base node. This bitmap can
be used to create additional copies post-hoc, if desired.
- Formalizes our "best practice" suggestion for mixing bitmaps and
snapshots into a single, documented command.
Is this strictly needed? No, if you have the foresight, you can do this
instead:
Transact(
disable('a'),
disable('b'),
disable('c'),
# plus however many more ...
snapshot('top', ...),
create('top', 'd')
)
but a convenience command might still have a role to play in helping
take the guesswork out for non-libvirt users.
That's the bulk of what was discussed.
Summary:
GOTCHAs:
#1: Bitmaps are created non-persistent by default, and can't be changed.
#2: Push backup destination formats will happily back up to a format
that isn't semantically useful.
#3: Migrating non-shared block storage can drop even persistent bitmaps
if you don't pass the bitmap migration capability flag to both QEMU
instances.
#4: Creating a snapshot without doing some bitmap manipulation
beforehand can temporarily render your bitmaps unusable. Failing to
disable bitmaps before creating a snapshot might make commits very
tricky later on.
Gotchas 1 and 4 can be at least partially alleviated. gotcha 2 remains a
pain point we cannot intercept at the QEMU layer. gotcha 3 has potential
remedies, but they are complicated.
QEMU todo items:
- Fix bitmap data corruption on commit (Ongoing, by Vladimir@Virtuozzo)
- add a set_persistence method for bitmaps that allows us to change the
storage class of a bitmap after creation. (Helps alleviate gotcha #1.)
- Add a command that allows us to merge allocation data into a bitmap.
This helps alleviate gotcha #4: If we create a new image but neglected
to do the proper transaction dance, we can simply copy the allocation
data into a new bitmap. (Note, we'd still need set_persistence to help
us disable the old bitmap before any commit happens.)
- Add convenience command for easy + safe combination of bitmaps +
snapshots. Helps prevent #4.
Research items:
- How hard is it to reopen a backing image as RW while it's in-use,
disable a bitmap, and then reopen as RO? This is to partially address
gotcha #4; if we forget to disable bitmaps before creating the snapshot.
- How hard is the reverse operation? Can we reopen a backing image RW,
enable a bitmap, and then reopen as RO? This gives us better control
over what happens on commit.
- After we fix the commit bug, what does/should commit actually do with
bitmaps? What about bitmaps that collide? The current behavior is that
any bitmaps don't transfer from top to base. Any bitmaps active in the
base record all the new writes from the top.
That's all!
--js
4 years, 7 months
[libvirt] [PATCH 0/6] test_driver: implement device attach/detach APIs
by Ilias Stamatis
Ilias Stamatis (6):
test_driver: implement virDomainAttachDeviceFlags
test_driver: implement virDomainAttachDevice
test_driver: implement virDomainDetachDeviceFlags
test_driver: implement virDomainDetachDevice
test_driver: implement virDomainDetachDeviceAlias
test_driver: implement virDomainUpdateDeviceFlags
src/test/test_driver.c | 570 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 570 insertions(+)
--
2.22.0
4 years, 8 months
[libvirt] [PATCH 0/5] qemu: Use FW descriptors to report FW image paths
by Michal Privoznik
It feels a bit odd to report a built in list of FW images when we have
FW descriptor files. Especially, when some weird architectures are
concerned. For instance, OVMF_CODE.fd is reported even for
non-x86_64/non-i386 arches, like ppc. But if FW descriptor files are
taken into the picture then no OVMF_CODE.fd is ever reported.
One can argue, that these patches are not necessary, because the whole
point of FW descriptor files is that users do not have to bother with
paths to FW images. And that is true. However, the whole ecosystem of
FW descriptor files allows sys admins and regular users to write their
own FW descriptor files and thus reporting what paths libvirt found
might come handy when writing those descriptors.
Michal Prívozník (5):
virfirmware: Expose and define autoptr for virFirmwareFree
qemu_firmware: Document qemuFirmwareGetSupported
qemu_firmware: Extend qemuFirmwareGetSupported to return FW paths
qemufirmwaretest: Test FW path getting through
qemuFirmwareGetSupported()
qemu: Use FW descriptors to report FW image paths
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 19 +++++++--
src/qemu/qemu_firmware.c | 81 +++++++++++++++++++++++++++++++++++-
src/qemu/qemu_firmware.h | 5 ++-
src/util/virfirmware.c | 2 +-
src/util/virfirmware.h | 5 +++
tests/qemufirmwaretest.c | 78 ++++++++++++++++++++++++++++++----
7 files changed, 177 insertions(+), 14 deletions(-)
--
2.21.0
4 years, 8 months
[libvirt] [PATCH 0/7] util: abort when out of memory
by Daniel P. Berrangé
See this previous thread:
https://www.redhat.com/archives/libvir-list/2019-May/msg00273.html
The executive summary is that catching & reporting ENOMEM is not worth
the maint cost because:
- this code will almost never run on Linux hosts
- if it does run it will likely have bad behaviour silently dropping
data or crashing the process
- apps using libvirt often do so via a non-C language that aborts/exits
the app on OOM regardless, or use other C libraries that abort
- we can build a system that is more reliable when OOM happens by
not catching OOM, instead simply letting apps exit, restart and
carry on where they left off
The first part of the series does the bare minimum to cull OOM handling.
With this done, the main reason why we never adopted glib is now
removed. Thus the second part of this series introduces use of glib into
libvirt and converts our our allocation APIs to use the glib allocation
APIs internally.
In future I'd especially like to use glib to replace virObject code,
which I knowingly wrote as a somewhat pathetic clone of GObject.
Eliminating all our DBus code is also another thing I'd like, since
Glib's DBus client code is better IMHO.
Note that none of the callers are updated at this point, so they are all
still attempting to handle errors from VIR_ALLOC, VIR_STRDUP, etc. If
we convert VIR_ALLOC calls to remove return value checks, and then later
convert to glib's g_new0 API, we go through two lots of churn which I
think is undesirable.
Thus I think it is highly desirable to introduce glib straight away and
do a single conversion step. It also means we can introduce other data
structures from glib to replace ours and avoid wasting time converting
those too.
Overall the code in this series is all quite simple and a nice cleanup.
50% of the lines culled come from the first patch removing OOM testing,
the other 50% come from viralloc.c impl simplification
The interesting question is the impact is has on downstreams who have
to backport patches to older versions.
If we start converting callers to g_new0, etc, then downstream have
to either
* Change g_new0 back into VIR_ALLOC and likely re-add many goto
calls we purged
Or
* Backport all the patches in this series that drop OOM handling
and introduce glib usage
If we start adopting other glib features beyond g_new0, then downstreams
are pretty much forced into option 2.
Given the benefit I think we'll see from this series in our codebase,
I'm inclined to say we should prioritize the future, over prioritizing
the past (backports), and thus freely adopt use of glib APIs rightaway.
IOW, I think we should expect vendors to backport this series as a
starting point, before any other patches. I've not tested but I'm
hopeful that such a backport of this series is fairly easy. The
viralloc.{c,h} file hasn't seen much change in recent times so
ought to be a clean cherry-pick. The glib additions might hit
some conflicts in makefiles, but not too terrible I hope. Probably
worth doing a test to see just how easy backports are over the past
1 year of releases.
Daniel P. Berrangé (7):
util: purge all code for testing OOM handling
util: make allocation functions abort on OOM
util: remove several unused _QUIET allocation macro variants
util: make string functions abort on OOM
build: probe for glib-2 library in configure
build: link to glib library
util: use glib allocation functions
configure.ac | 19 +-
docs/docs.html.in | 3 -
docs/internals/oomtesting.html.in | 213 --------------------
libvirt.spec.in | 1 +
m4/virt-glib.m4 | 30 +++
mingw-libvirt.spec.in | 2 +
src/Makefile.am | 2 +
src/internal.h | 1 +
src/libvirt_private.syms | 4 -
src/lxc/Makefile.inc.am | 2 +
src/remote/Makefile.inc.am | 1 +
src/util/Makefile.inc.am | 1 +
src/util/viralloc.c | 313 ++++--------------------------
src/util/viralloc.h | 204 ++++---------------
src/util/virstring.c | 93 +++------
src/util/virstring.h | 79 +++-----
tests/Makefile.am | 4 +-
tests/oomtrace.pl | 41 ----
tests/qemuxml2argvtest.c | 12 +-
tests/testutils.c | 189 +-----------------
tests/testutils.h | 2 -
tests/virfirewalltest.c | 12 --
tools/Makefile.am | 1 +
23 files changed, 179 insertions(+), 1050 deletions(-)
delete mode 100644 docs/internals/oomtesting.html.in
create mode 100644 m4/virt-glib.m4
delete mode 100755 tests/oomtrace.pl
--
2.21.0
4 years, 8 months
[libvirt] [PATCH v2 00/10] Adding resolution properties for video models
by jcfaracco＠gmail.com
From: Julio Faracco <jcfaracco(a)gmail.com>
This serie adds 'xres' and 'yres' QEMU display properties into a new
element called 'resolution'. This element is covered by model element:
<model type='foo'>
<resolution x='800' y='600'/>
</model>
Only types VGA, QXL, Virtio and Bochs support passing resolution to
driver. That's why some test cases were added too.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1485793
Julio Faracco (10):
docs: Adding 'xres' and 'yres' into qxl XML definition
qemu: Include {xres,yres} QEMU capabilities for video models
conf: Adding resolution property for model element
qemu: Include {xres,yres} for QEMU command line
tests: Include {xres,yres} QEMU capabilities into tests
tests: Include bochs-display as capability test too
tests: Introduce resolution test for QXL model
tests: Introduce resolution test for Virtio model
tests: Introduce resolution test for Bochs model
tests: Introduce resolution test for VGA model
docs/schemas/domaincommon.rng | 10 ++
src/conf/domain_conf.c | 75 +++++++-
src/conf/domain_conf.h | 5 +
src/conf/virconftypes.h | 3 +
src/qemu/qemu_capabilities.c | 16 ++
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_command.c | 20 +++
.../caps_2.10.0.aarch64.xml | 2 +
.../caps_2.10.0.ppc64.xml | 2 +
.../caps_2.10.0.s390x.xml | 2 +
.../caps_2.10.0.x86_64.xml | 2 +
.../caps_2.11.0.s390x.xml | 2 +
.../caps_2.11.0.x86_64.xml | 2 +
.../caps_2.12.0.aarch64.xml | 2 +
.../caps_2.12.0.ppc64.xml | 2 +
.../caps_2.12.0.s390x.xml | 2 +
.../caps_2.12.0.x86_64.xml | 2 +
.../caps_3.0.0.ppc64.replies | 139 +++++++++++----
.../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 2 +
.../caps_3.0.0.riscv32.xml | 2 +
.../caps_3.0.0.riscv64.xml | 2 +
.../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 2 +
.../caps_3.0.0.x86_64.replies | 167 +++++++++++++-----
.../caps_3.0.0.x86_64.xml | 2 +
.../caps_3.1.0.ppc64.replies | 139 +++++++++++----
.../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 2 +
.../caps_3.1.0.x86_64.replies | 167 +++++++++++++-----
.../caps_3.1.0.x86_64.xml | 2 +
.../caps_4.0.0.aarch64.replies | 139 +++++++++++----
.../caps_4.0.0.aarch64.xml | 2 +
.../caps_4.0.0.ppc64.replies | 139 +++++++++++----
.../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 2 +
.../caps_4.0.0.riscv32.replies | 131 +++++++++++---
.../caps_4.0.0.riscv32.xml | 2 +
.../caps_4.0.0.riscv64.replies | 131 +++++++++++---
.../caps_4.0.0.riscv64.xml | 2 +
.../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 +
.../caps_4.0.0.x86_64.replies | 167 +++++++++++++-----
.../caps_4.0.0.x86_64.xml | 2 +
.../caps_4.1.0.x86_64.replies | 159 ++++++++++++-----
.../caps_4.1.0.x86_64.xml | 2 +
...ochs-display-resolution.x86_64-latest.args | 35 ++++
.../video-bochs-display-resolution.xml | 33 ++++
.../video-qxl-resolution.x86_64-latest.args | 35 ++++
.../qemuxml2argvdata/video-qxl-resolution.xml | 33 ++++
...o-virtio-gpu-resolution.x86_64-latest.args | 35 ++++
.../video-virtio-gpu-resolution.xml | 33 ++++
tests/qemuxml2argvtest.c | 4 +
...bochs-display-resolution.x86_64-latest.xml | 33 ++++
.../video-qxl-resolution.x86_64-latest.xml | 33 ++++
...eo-virtio-gpu-resolution.x86_64-latest.xml | 33 ++++
tests/qemuxml2xmltest.c | 5 +
52 files changed, 1604 insertions(+), 365 deletions(-)
create mode 100644 tests/qemuxml2argvdata/video-bochs-display-resolution.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/video-bochs-display-resolution.xml
create mode 100644 tests/qemuxml2argvdata/video-qxl-resolution.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/video-qxl-resolution.xml
create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-resolution.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/video-virtio-gpu-resolution.xml
create mode 100644 tests/qemuxml2xmloutdata/video-bochs-display-resolution.x86_64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/video-qxl-resolution.x86_64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/video-virtio-gpu-resolution.x86_64-latest.xml
--
2.20.1
4 years, 8 months
[libvirt] [PATCH] libvirt.spec.in: Add the Secure Boot-variant OVMF binaries
by Kashyap Chamarthy
Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries
(an unintentional omission, checking with Cole on #virt, OFTC) for
'x86_64' and 'ia32'. Add them.
This way, getDomainCapabilities() will report all the OVMF binaries that
are present on the system. E.g. on Fedora 29, if you only have the
edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running
`virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead
of just the OVMF_CODE.fd):
$> virsh getdomcapabilities
...
<loader supported='yes'>
<value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value>
<value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value>
...
(
Learnt this from a discussion with Michal Privoznik in this bug,
comment#2:
https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report
firmware (FW) paths in domainCapabilities based on FW descriptor
files
)
Signed-off-by: Kashyap Chamarthy <kchamart(a)redhat.com>
---
I only did a cursory check on if I missed to add any other valid paths
for other architectures.
---
libvirt.spec.in | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index b13b863928..99950495a7 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1135,10 +1135,17 @@ exit 1
# Nightly edk2.git-arm
LOADERS="$LOADERS:/usr/share/edk2.git/arm/QEMU_EFI-pflash.raw:/usr/share/edk2.git/arm/vars-template-pflash.raw"
- # Fedora edk2-ovmf
+ # Fedora edk2-ovmf, x86_64
LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd"
+ # Fedora edk2-ovmf, x86_64, with Secure Boot
+ LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd"
# Fedora edk2-ovmf-ia32
LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd"
+ # Fedora edk2-ovmf-ia32, with Secure Boot. (NB: Unlike x86_64, for
+ # 'ia32', there is no secboot-variant "VARS" file (NVRAM template).
+ # So the NVRAM template for 'ovmf-ia32/OVMF_CODE.secboot.fd' is the
+ # same as the one for the non-secboot variant.)
+ LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd"
# Fedora edk2-aarch64
LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw"
# Fedora edk2-arm
--
2.20.1
4 years, 8 months
