[PATCH 0/2] qemu: monitor: Fix handling of 'detach' for 'migrate' and 'dump-guest-memory' QMP commands
by Peter Krempa
QEMU is deprecating 'detach' argument of 'migrate' as it was never
actually used. Drop it in libvirt as we always specify it.
The monitor handler of 'dump-guest-memory' allows controlling 'detach'
but always passes true. Libvirt doesn't want to block the monitor so
hardcode 'true' in the monitor code instead.
Peter Krempa (2):
qemuMonitorDumpToFd: Drop 'detach' argument
qemuMonitorJSONMigrate: Drop 'detach' QMP option
src/qemu/qemu_driver.c | 2 +-
src/qemu/qemu_monitor.c | 5 ++---
src/qemu/qemu_monitor.h | 3 +--
src/qemu/qemu_monitor_json.c | 6 ++----
src/qemu/qemu_monitor_json.h | 3 +--
tests/qemumonitorjsontest.c | 3 +--
6 files changed, 8 insertions(+), 14 deletions(-)
--
2.49.0
1 week, 4 days
[PATCH 0/1] [RFC] Live migration support for ch driver
by Stefan Kober
This change serves as a proof of concept that adds live migration support to
the Cloud Hypervisor driver. It is meant to show feasibility and to receive
early feedback.
I tested the live migration by invoking:
virsh -c ch:///session migrate --domain vmName --desturi ch+ssh://dstHost/session --live
Opens:
* What is required for a minimal viable live migration to be merged?
* Job state tracking? (virDomainObjBeginJob, ...)
* What should 'virsh domjobinfo' show?
* Testing?
* Anything else?
Stefan Kober (1):
Initial CH migrate API
src/ch/ch_conf.h | 4 +
src/ch/ch_domain.h | 2 +
src/ch/ch_driver.c | 362 +++++++++++++++++++++++++++++-
src/ch/ch_monitor.c | 156 +++++++++++++
src/ch/ch_monitor.h | 8 +
src/ch/ch_process.c | 136 ++++++++++-
src/ch/ch_process.h | 6 +
src/hypervisor/domain_interface.c | 1 +
src/libvirt-domain.c | 15 +-
9 files changed, 680 insertions(+), 10 deletions(-)
--
2.49.0
1 week, 4 days
[PATCH] build-aux: simplify grep detection on FreeBSD
by Roman Bogorodskiy
From: Alexey Dokuchaev <danfe(a)FreeBSD.org>
For quite some time now FreeBSD provides its own version of the grep(1)
tool, and the GNU grep from the ports collection is available as
ggrep(1). So remove the detection code and just request ggrep.
Signed-off-by: Alexey Dokuchaev <danfe(a)FreeBSD.org>
---
build-aux/meson.build | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/build-aux/meson.build b/build-aux/meson.build
index bcd10e89f2..56c91971cf 100644
--- a/build-aux/meson.build
+++ b/build-aux/meson.build
@@ -13,23 +13,10 @@ if git and tests_enabled[0]
if host_machine.system() == 'freebsd' or host_machine.system() == 'darwin'
make_prog = find_program('gmake')
sed_prog = find_program('gsed')
+ grep_prog = find_program('ggrep')
else
make_prog = find_program('make')
sed_prog = find_program('sed')
- endif
-
- if host_machine.system() == 'freebsd'
- grep_prog = find_program('grep')
- grep_cmd = run_command(grep_prog, '--version', check: true)
- if grep_cmd.stdout().startswith('grep (BSD grep')
- grep_prog = find_program('/usr/local/bin/grep', required: false)
- if not grep_prog.found()
- error('GNU grep not found')
- endif
- endif
- elif host_machine.system() == 'darwin'
- grep_prog = find_program('ggrep')
- else
grep_prog = find_program('grep')
endif
--
2.49.0
1 week, 4 days
[PATCH 1/2] NEWS: bhyve: document NVRAM support
by Roman Bogorodskiy
Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com>
---
NEWS.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index e924c08fbf..102e49373a 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -23,6 +23,14 @@ v11.4.0 (unreleased)
That option suppresses registration of pkttyagent with polkitd.
+ * bhyve: support NVRAM configuration for UEFI firmwares
+
+ The bhyve driver now supports specifying NVRAM store file, such as ::
+
+ <os firmware='efi'>
+ <nvram/>
+ </os>
+
* **Bug fixes**
* qemu: Fix failure when reverting to internal snapshots
--
2.49.0
1 week, 4 days
[PATCH 0/4] USB hostdev: allow addressing by port
by Maximilian Martin
This resubmission splits up the previous patch into multiple patches and
incorporates review comments from Michal Prívozník.
Currently, only vendor/product and bus/device matching are supported for USB host
devices. Neither of these provide a stable and persistent way of assigning a guest
a specific host device. Vendor/product can be ambiguous. Device numbers change on
every enumeration.
This patch adds a bus/port matching, which allows a specific port on the host to be
specified using the dotted notation found in Linux's "devpath" sysfs attribute.
This patch is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7...
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513
Signed-off-by: Maximilian Martin <maximilian_martin(a)gmx.de>
Maximilian Martin (4):
virusb test data: add devpath files for port addressing
domain_conf, virhostdev, virusb, virusb test: add bus/port matching
schema: add USB port attribute
docs: add description for USB port matching
docs/formatdomain.rst | 29 ++--
src/conf/domain_conf.c | 69 +++++++-
src/conf/domain_conf.h | 1 +
src/conf/schemas/domaincommon.rng | 11 +-
src/hypervisor/virhostdev.c | 131 +++++++++------
src/libvirt_private.syms | 2 -
src/util/virusb.c | 156 ++++++------------
src/util/virusb.h | 32 ++--
tests/virusbtest.c | 149 ++++++++++++-----
.../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.3/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.4/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.5/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.6/devpath | 1 +
.../sys_bus_usb/devices/1-1.5/devpath | 1 +
.../sys_bus_usb/devices/1-1.6/devpath | 1 +
.../sys_bus_usb/devices/1-1/devpath | 1 +
.../sys_bus_usb/devices/2-1.2/devpath | 1 +
.../sys_bus_usb/devices/2-1/devpath | 1 +
.../sys_bus_usb/devices/usb1/devpath | 1 +
.../sys_bus_usb/devices/usb2/devpath | 1 +
.../sys_bus_usb/devices/usb3/devpath | 1 +
.../sys_bus_usb/devices/usb4/devpath | 1 +
24 files changed, 351 insertions(+), 244 deletions(-)
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath
--
2.39.5
1 week, 4 days
[PATCH 0/5] bhyve: introduce NVRAM support
by Roman Bogorodskiy
Roman Bogorodskiy (5):
bhyve: conf: introduce nvramDir
bhyve: generate NVRAM bhyve arguments
bhyve: firmware: try to guess NVRAM settings
bhyve: introduce bhyveDomainDefValidate()
bhyve: support removing NVRAM on domain undefine
src/bhyve/bhyve_command.c | 8 +-
src/bhyve/bhyve_conf.c | 4 +
src/bhyve/bhyve_domain.c | 43 ++++++
src/bhyve/bhyve_driver.c | 32 ++++-
src/bhyve/bhyve_firmware.c | 119 ++++++++++++++--
src/bhyve/bhyve_process.c | 132 ++++++++++++++++++
src/bhyve/bhyve_process.h | 8 ++
src/bhyve/bhyve_utils.h | 2 +
src/bhyve/meson.build | 5 +
...gv-uefi-nvram-template-and-source-set.args | 12 ++
...-uefi-nvram-template-and-source-set.ldargs | 1 +
...rgv-uefi-nvram-template-and-source-set.xml | 24 ++++
...bhyvexml2argv-uefi-nvram-template-set.args | 12 ++
...yvexml2argv-uefi-nvram-template-set.ldargs | 1 +
.../bhyvexml2argv-uefi-nvram-template-set.xml | 24 ++++
.../bhyvexml2argv-uefi-nvram.args | 12 ++
.../bhyvexml2argv-uefi-nvram.ldargs | 1 +
.../bhyvexml2argv-uefi-nvram.xml | 24 ++++
tests/bhyvexml2argvtest.c | 5 +
19 files changed, 452 insertions(+), 17 deletions(-)
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.xml
--
2.49.0
1 week, 4 days
[PATCH 0/4] virsh completer cleanups
by Peter Krempa
Make the core completer code common in all virt shells and annotate few
arguments with the existing empty and local-file completers.
Peter Krempa (4):
virsh: completer: Extract common completer methods from virsh to vsh
vsh: Apply empty/local completers to global commands
virsh: Apply empty completer to arguments where completion doesn't
make sense
virsh: domain: Annotate rest of arguments taking local existing file
tools/meson.build | 2 +-
tools/virsh-backup.c | 6 +-
tools/virsh-checkpoint.c | 8 +-
tools/virsh-completer-domain.c | 70 ++++++------
tools/virsh-completer-host.c | 12 +-
tools/virsh-completer-nodedev.c | 10 +-
tools/virsh-completer-pool.c | 6 +-
tools/virsh-completer-volume.c | 4 +-
tools/virsh-completer.h | 19 +---
tools/virsh-domain.c | 112 ++++++++++---------
tools/virsh-host.c | 6 +-
tools/virsh-interface.c | 2 +-
tools/virsh-network.c | 9 +-
tools/virsh-nodedev.c | 2 +-
tools/virsh-nwfilter.c | 4 +-
tools/virsh-pool.c | 18 +--
tools/virsh-secret.c | 6 +-
tools/virsh-snapshot.c | 8 +-
tools/virsh-volume.c | 12 +-
tools/virsh.c | 2 +-
tools/virsh.h | 2 +-
tools/{virsh-completer.c => vsh-completer.c} | 34 +++---
tools/vsh-completer.h | 41 +++++++
tools/vsh.c | 6 +
24 files changed, 222 insertions(+), 179 deletions(-)
rename tools/{virsh-completer.c => vsh-completer.c} (85%)
create mode 100644 tools/vsh-completer.h
--
2.49.0
1 week, 5 days
[PATCH] cputest: Skip more tests requiring JSON_MODELS if QEMU is disabled
by Jaroslav Suchanek
From: Jaroslav Suchanek <jsuchane(a)redhat.com>
Marking more tests with JSON_MODELS_REQUIRED as these tests fail if QEMU is
disabled, typically when running tests on FreeBSD or macOS systems.
Signed-off-by: Jaroslav Suchanek <jsuchane(a)redhat.com>
---
tests/cputest.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/cputest.c b/tests/cputest.c
index de313f6102..bb471d2ae7 100644
--- a/tests/cputest.c
+++ b/tests/cputest.c
@@ -1183,14 +1183,14 @@ mymain(void)
DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-D510", JSON_NONE);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-N450", JSON_NONE);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362", JSON_MODELS_REQUIRED);
- DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362-2", JSON_MODELS);
+ DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362-2", JSON_MODELS_REQUIRED);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-650", JSON_MODELS_REQUIRED);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-2500", JSON_HOST);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-2540M", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-4670T", JSON_HOST);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-6600", JSON_HOST);
- DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1270P", JSON_MODELS);
- DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1365U", JSON_MODELS);
+ DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1270P", JSON_MODELS_REQUIRED);
+ DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1365U", JSON_MODELS_REQUIRED);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600", JSON_HOST);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600-xsaveopt", JSON_MODELS_REQUIRED);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3520M", JSON_NONE);
@@ -1225,7 +1225,7 @@ mymain(void)
DO_TEST_CPUID(VIR_ARCH_X86_64, "Ryzen-9-3900X-12-Core", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-5110", JSON_NONE);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-6731E", JSON_MODELS);
- DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Bronze-3408U", JSON_MODELS);
+ DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Bronze-3408U", JSON_MODELS_REQUIRED);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1225-v5", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1245-v5", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1270-v5", JSON_MODELS);
@@ -1244,12 +1244,12 @@ mymain(void)
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6130", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6148", JSON_HOST);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6152", JSON_MODELS);
- DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6530", JSON_MODELS);
+ DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6530", JSON_MODELS_REQUIRED);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Platinum-8268", JSON_HOST);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Platinum-9242", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Silver-4214R", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-W3520", JSON_HOST);
- DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-w7-3465X", JSON_MODELS);
+ DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-w7-3465X", JSON_MODELS_REQUIRED);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-X5460", JSON_NONE);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Ice-Lake-Server", JSON_MODELS);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Cooperlake", JSON_MODELS);
--
2.49.0
1 week, 5 days
[libvirt PATCH] qemu: forbid readonly attribute for externally launched virtiofsd
by Ján Tomko
From: Ján Tomko <jtomko(a)redhat.com>
In that case, libvirtd cannot set it on the command line because
virtiofsd is not launched by libvirt.
https://issues.redhat.com/browse/RHEL-87522
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
src/qemu/qemu_validate.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 87588024ce..013ff14d75 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -4684,6 +4684,11 @@ qemuValidateDomainDeviceDefFS(virDomainFSDef *fs,
_("virtiofs does not support wrpolicy"));
return -1;
}
+ if (fs->readonly) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("readonly mode cannot be set for extrenally started virtiofsd"));
+ return -1;
+ }
}
if (fs->model != VIR_DOMAIN_FS_MODEL_DEFAULT) {
--
2.49.0
1 week, 5 days
libvirt TLS certificates letsencrypt
by Jani Heikkinen
Hello! I am part of infrastructure team at BFH and we are building an
openstack installation.
A couple of months ago I was experimenting with setting up noVNC
consoles with encryption.
Connecting until the novncproxy service with TLS can be done with no
issues, but the connection between libvirt and the proxy turned out to
be problematic.
We would really love to use letsencrypt certificates which are generated
for each server/container, instead of relying on creating own CA and
generate certificates.
With libvirt, using letsencrypt is impossible, since the code does bunch
of checks for properties of the TLS certificates, see:
https://github.com/libvirt/libvirt/blob/bf79a021a6437b4f85469a53f650bff62...
Does anybody know, why these checks exist? They de facto prevent using
anything else than self-generated certificates for securing vnc console
traffic.
Is using my own self-created CA somehow more trustworthy than
LetsEncrypt root CA?
Best, Jani Heikkinen
--
Berner Fachhochschule / Bern University of Applied Sciences
IT-Services / Team Linux & Infrastructure Services
Jani Heikkinen
IT Linux Engineer
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 68 14
Telefon Servicedesk +41 31 848 48 48
jani.heikkinen(a)bfh.ch
1 week, 5 days
