[PATCH v2] meson: Add back prefix path for runstatedir
by Zhenzhong Duan
Currently libvirt favors /run instead of /var/run, but for local build
run test, a prefix path is still needed to avoid interoperating with OS
vendor provided binaries.
When 'system' option is specified, fixed path /run is honored.
Fixes: e5299ddf86121d3c792ca271ffcb54900eb19dc3
Signed-off-by: Zhenzhong Duan <zhenzhong.duan(a)intel.com>
---
v2: Take option `system` into consideration (Pavel)
meson.build | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/meson.build b/meson.build
index bf4a245dd3..2762236f37 100644
--- a/meson.build
+++ b/meson.build
@@ -62,11 +62,16 @@ if get_option('system')
endif
localstatedir = '/var'
sysconfdir = '/etc'
+ runstatedir = '/run'
else
prefix = get_option('prefix')
libdir = prefix / get_option('libdir')
localstatedir = prefix / get_option('localstatedir')
sysconfdir = prefix / get_option('sysconfdir')
+ runstatedir = get_option('runstatedir')
+ if runstatedir == ''
+ runstatedir = prefix / 'run'
+ endif
endif
# if --prefix is /usr, don't use /usr/var for localstatedir or /usr/etc for
@@ -80,11 +85,6 @@ if prefix == '/usr'
endif
endif
-runstatedir = get_option('runstatedir')
-if runstatedir == ''
- runstatedir = '/run'
-endif
-
initconfdir = get_option('initconfdir')
if initconfdir == ''
if (os_release.contains('alpine') or
--
2.34.1
53 minutes
[PATCH] rpm: Enable KVM for riscv64 on RHEL 10+
by Andrea Bolognani
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
libvirt.spec.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index cb41ea1de1..9217820137 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -8,7 +8,9 @@
%define arches_qemu_kvm %{ix86} x86_64 %{power64} %{arm} aarch64 s390x riscv64
%if 0%{?rhel}
- %if 0%{?rhel} > 8
+ %if 0%{?rhel} >= 10
+ %define arches_qemu_kvm x86_64 aarch64 s390x riscv64
+ %elif 0%{?rhel} >= 9
%define arches_qemu_kvm x86_64 aarch64 s390x
%else
%define arches_qemu_kvm x86_64 %{power64} aarch64 s390x
--
2.48.1
9 hours, 2 minutes
[PATCH v1] tests: add capabilities for QEMU 10.0.0 on s390x
by Shalini Chellathurai Saroja
Let us introduce the xml and reply files for QEMU 10.0.0 on s390x.
Notable changes:
- new s390-ccw-virtio-10.0 machine type
- old machine types (2.4 - 2.8) dropped
- new CPU models
- New devices:
- virtio-mem-ccw
- chardev now supports qemu-vdagent
Signed-off-by: Shalini Chellathurai Saroja <shalini(a)linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
Suggested-by: Michal Privoznik <mprivozn(a)redhat.com>
The replies and xml files are removed from this patch and are available in
https://gitlab.com/shalinichellathurai/libvirt/-/commit/3e9df63925e2c86b8...
---
tests/domaincapsdata/qemu_10.0.0.s390x.xml | 359 +
.../caps_10.0.0_s390x.replies | 38002 ++++++++++++++++
.../caps_10.0.0_s390x.xml | 4216 ++
3 files changed, 42577 insertions(+)
create mode 100644 tests/domaincapsdata/qemu_10.0.0.s390x.xml
create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies
create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml
diff --git a/tests/domaincapsdata/qemu_10.0.0.s390x.xml b/tests/domaincapsdata/qemu_10.0.0.s390x.xml
new file mode 100644
index 0000000000..4af3c7ec53
--- /dev/null
+++ b/tests/domaincapsdata/qemu_10.0.0.s390x.xml
@@ -0,0 +1,359 @@
+<domainCapabilities>
+ <path>/usr/bin/qemu-system-s390x</path>
+ <domain>kvm</domain>
+ <machine>s390-ccw-virtio-10.0</machine>
+ <arch>s390x</arch>
+ <vcpu max='248'/>
+ <iothreads supported='yes'/>
+ <os supported='yes'>
+ <enum name='firmware'/>
+ <loader supported='yes'>
+ <value>/obviously/fake/firmware1.fd</value>
+ <value>/obviously/fake/firmware2.fd</value>
+ <enum name='type'>
+ <value>rom</value>
+ <value>pflash</value>
+ </enum>
+ <enum name='readonly'>
+ <value>yes</value>
+ <value>no</value>
+ </enum>
+ <enum name='secure'>
+ <value>no</value>
+ </enum>
+ </loader>
+ </os>
+ <cpu>
+ <mode name='host-passthrough' supported='yes'>
+ <enum name='hostPassthroughMigratable'>
+ <value>off</value>
+ </enum>
+ </mode>
+ <mode name='maximum' supported='yes'>
+ <enum name='maximumMigratable'>
+ <value>on</value>
+ <value>off</value>
+ </enum>
+ </mode>
+ <mode name='host-model' supported='yes'>
+ <model fallback='forbid'>gen16a-base</model>
+ <feature policy='require' name='nnpa'/>
+ <feature policy='require' name='aen'/>
+ <feature policy='require' name='cmmnt'/>
+ <feature policy='require' name='vxpdeh'/>
+ <feature policy='require' name='aefsi'/>
+ <feature policy='require' name='diag318'/>
+ <feature policy='require' name='csske'/>
+ <feature policy='require' name='mepoch'/>
+ <feature policy='require' name='msa9'/>
+ <feature policy='require' name='msa8'/>
+ <feature policy='require' name='msa7'/>
+ <feature policy='require' name='msa6'/>
+ <feature policy='require' name='msa5'/>
+ <feature policy='require' name='msa4'/>
+ <feature policy='require' name='msa3'/>
+ <feature policy='require' name='msa2'/>
+ <feature policy='require' name='msa1'/>
+ <feature policy='require' name='sthyi'/>
+ <feature policy='require' name='edat'/>
+ <feature policy='require' name='ri'/>
+ <feature policy='require' name='deflate'/>
+ <feature policy='require' name='edat2'/>
+ <feature policy='require' name='etoken'/>
+ <feature policy='require' name='vx'/>
+ <feature policy='require' name='ipter'/>
+ <feature policy='require' name='pai'/>
+ <feature policy='require' name='paie'/>
+ <feature policy='require' name='mepochptff'/>
+ <feature policy='require' name='ap'/>
+ <feature policy='require' name='vxeh'/>
+ <feature policy='require' name='vxpd'/>
+ <feature policy='require' name='esop'/>
+ <feature policy='require' name='msa9_pckmo'/>
+ <feature policy='require' name='vxeh2'/>
+ <feature policy='require' name='esort'/>
+ <feature policy='require' name='appv'/>
+ <feature policy='require' name='apqi'/>
+ <feature policy='require' name='apft'/>
+ <feature policy='require' name='els'/>
+ <feature policy='require' name='iep'/>
+ <feature policy='require' name='appvi'/>
+ <feature policy='require' name='apqci'/>
+ <feature policy='require' name='cte'/>
+ <feature policy='require' name='ais'/>
+ <feature policy='require' name='bpb'/>
+ <feature policy='require' name='ctop'/>
+ <feature policy='require' name='gs'/>
+ <feature policy='require' name='ppa15'/>
+ <feature policy='require' name='zpci'/>
+ <feature policy='require' name='rdp'/>
+ <feature policy='require' name='sea_esop2'/>
+ <feature policy='require' name='beareh'/>
+ <feature policy='require' name='te'/>
+ <feature policy='require' name='cmm'/>
+ <feature policy='require' name='vxpdeh2'/>
+ </mode>
+ <mode name='custom' supported='yes'>
+ <model usable='yes' vendor='IBM'>gen15a</model>
+ <model usable='yes' vendor='IBM'>gen15a-base</model>
+ <model usable='yes' vendor='IBM'>gen15b</model>
+ <model usable='yes' vendor='IBM'>gen15b-base</model>
+ <model usable='yes' vendor='IBM'>gen16a</model>
+ <model usable='yes' vendor='IBM'>gen16a-base</model>
+ <model usable='yes' vendor='IBM'>gen16b</model>
+ <model usable='yes' vendor='IBM'>gen16b-base</model>
+ <model usable='no' vendor='IBM'>gen17a</model>
+ <blockers model='gen17a'>
+ <feature name='minste4'/>
+ <feature name='msa10'/>
+ <feature name='msa10_pckmo'/>
+ <feature name='msa11'/>
+ <feature name='msa11_pckmo'/>
+ <feature name='msa12'/>
+ <feature name='msa13'/>
+ <feature name='msa13_pckmo'/>
+ <feature name='plo_ext'/>
+ <feature name='sif'/>
+ <feature name='type'/>
+ <feature name='vxeh3'/>
+ <feature name='vxpdeh3'/>
+ </blockers>
+ <model usable='no' vendor='IBM'>gen17a-base</model>
+ <blockers model='gen17a-base'>
+ <feature name='minste4'/>
+ <feature name='msa12'/>
+ <feature name='plo_ext'/>
+ <feature name='sif'/>
+ <feature name='type'/>
+ </blockers>
+ <model usable='no' vendor='IBM'>gen17b</model>
+ <blockers model='gen17b'>
+ <feature name='minste4'/>
+ <feature name='msa10'/>
+ <feature name='msa10_pckmo'/>
+ <feature name='msa11'/>
+ <feature name='msa11_pckmo'/>
+ <feature name='msa12'/>
+ <feature name='msa13'/>
+ <feature name='msa13_pckmo'/>
+ <feature name='plo_ext'/>
+ <feature name='sif'/>
+ <feature name='type'/>
+ <feature name='vxeh3'/>
+ <feature name='vxpdeh3'/>
+ </blockers>
+ <model usable='no' vendor='IBM'>gen17b-base</model>
+ <blockers model='gen17b-base'>
+ <feature name='minste4'/>
+ <feature name='msa12'/>
+ <feature name='plo_ext'/>
+ <feature name='sif'/>
+ <feature name='type'/>
+ </blockers>
+ <model usable='yes' vendor='unknown'>max</model>
+ <model usable='yes' vendor='unknown'>qemu</model>
+ <model usable='yes' vendor='IBM'>z10BC</model>
+ <model usable='yes' vendor='IBM'>z10BC-base</model>
+ <model usable='yes' vendor='IBM'>z10BC.2</model>
+ <model usable='yes' vendor='IBM'>z10BC.2-base</model>
+ <model usable='yes' vendor='IBM'>z10EC</model>
+ <model usable='yes' vendor='IBM'>z10EC-base</model>
+ <model usable='yes' vendor='IBM'>z10EC.2</model>
+ <model usable='yes' vendor='IBM'>z10EC.2-base</model>
+ <model usable='yes' vendor='IBM'>z10EC.3</model>
+ <model usable='yes' vendor='IBM'>z10EC.3-base</model>
+ <model usable='yes' vendor='IBM'>z114</model>
+ <model usable='yes' vendor='IBM'>z114-base</model>
+ <model usable='yes' vendor='IBM'>z13</model>
+ <model usable='yes' vendor='IBM'>z13-base</model>
+ <model usable='yes' vendor='IBM'>z13.2</model>
+ <model usable='yes' vendor='IBM'>z13.2-base</model>
+ <model usable='yes' vendor='IBM'>z13s</model>
+ <model usable='yes' vendor='IBM'>z13s-base</model>
+ <model usable='yes' vendor='IBM'>z14</model>
+ <model usable='yes' vendor='IBM'>z14-base</model>
+ <model usable='yes' vendor='IBM'>z14.2</model>
+ <model usable='yes' vendor='IBM'>z14.2-base</model>
+ <model usable='yes' vendor='IBM'>z14ZR1</model>
+ <model usable='yes' vendor='IBM'>z14ZR1-base</model>
+ <model usable='yes' vendor='IBM'>z196</model>
+ <model usable='yes' vendor='IBM'>z196-base</model>
+ <model usable='yes' vendor='IBM'>z196.2</model>
+ <model usable='yes' vendor='IBM'>z196.2-base</model>
+ <model usable='yes' vendor='IBM'>z800</model>
+ <model usable='yes' vendor='IBM'>z800-base</model>
+ <model usable='yes' vendor='IBM'>z890</model>
+ <model usable='yes' vendor='IBM'>z890-base</model>
+ <model usable='yes' vendor='IBM'>z890.2</model>
+ <model usable='yes' vendor='IBM'>z890.2-base</model>
+ <model usable='yes' vendor='IBM'>z890.3</model>
+ <model usable='yes' vendor='IBM'>z890.3-base</model>
+ <model usable='yes' vendor='IBM'>z900</model>
+ <model usable='yes' vendor='IBM'>z900-base</model>
+ <model usable='yes' vendor='IBM'>z900.2</model>
+ <model usable='yes' vendor='IBM'>z900.2-base</model>
+ <model usable='yes' vendor='IBM'>z900.3</model>
+ <model usable='yes' vendor='IBM'>z900.3-base</model>
+ <model usable='yes' vendor='IBM'>z990</model>
+ <model usable='yes' vendor='IBM'>z990-base</model>
+ <model usable='yes' vendor='IBM'>z990.2</model>
+ <model usable='yes' vendor='IBM'>z990.2-base</model>
+ <model usable='yes' vendor='IBM'>z990.3</model>
+ <model usable='yes' vendor='IBM'>z990.3-base</model>
+ <model usable='yes' vendor='IBM'>z990.4</model>
+ <model usable='yes' vendor='IBM'>z990.4-base</model>
+ <model usable='yes' vendor='IBM'>z990.5</model>
+ <model usable='yes' vendor='IBM'>z990.5-base</model>
+ <model usable='yes' vendor='IBM'>z9BC</model>
+ <model usable='yes' vendor='IBM'>z9BC-base</model>
+ <model usable='yes' vendor='IBM'>z9BC.2</model>
+ <model usable='yes' vendor='IBM'>z9BC.2-base</model>
+ <model usable='yes' vendor='IBM'>z9EC</model>
+ <model usable='yes' vendor='IBM'>z9EC-base</model>
+ <model usable='yes' vendor='IBM'>z9EC.2</model>
+ <model usable='yes' vendor='IBM'>z9EC.2-base</model>
+ <model usable='yes' vendor='IBM'>z9EC.3</model>
+ <model usable='yes' vendor='IBM'>z9EC.3-base</model>
+ <model usable='yes' vendor='IBM'>zBC12</model>
+ <model usable='yes' vendor='IBM'>zBC12-base</model>
+ <model usable='yes' vendor='IBM'>zEC12</model>
+ <model usable='yes' vendor='IBM'>zEC12-base</model>
+ <model usable='yes' vendor='IBM'>zEC12.2</model>
+ <model usable='yes' vendor='IBM'>zEC12.2-base</model>
+ </mode>
+ </cpu>
+ <memoryBacking supported='yes'>
+ <enum name='sourceType'>
+ <value>file</value>
+ <value>anonymous</value>
+ <value>memfd</value>
+ </enum>
+ </memoryBacking>
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ <enum name='bus'>
+ <value>fdc</value>
+ <value>scsi</value>
+ <value>virtio</value>
+ <value>usb</value>
+ </enum>
+ <enum name='model'>
+ <value>virtio</value>
+ <value>virtio-transitional</value>
+ <value>virtio-non-transitional</value>
+ </enum>
+ </disk>
+ <graphics supported='yes'>
+ <enum name='type'>
+ <value>sdl</value>
+ <value>vnc</value>
+ <value>egl-headless</value>
+ <value>dbus</value>
+ </enum>
+ </graphics>
+ <video supported='yes'>
+ <enum name='modelType'>
+ <value>virtio</value>
+ <value>none</value>
+ </enum>
+ </video>
+ <hostdev supported='yes'>
+ <enum name='mode'>
+ <value>subsystem</value>
+ </enum>
+ <enum name='startupPolicy'>
+ <value>default</value>
+ <value>mandatory</value>
+ <value>requisite</value>
+ <value>optional</value>
+ </enum>
+ <enum name='subsysType'>
+ <value>usb</value>
+ <value>pci</value>
+ <value>scsi</value>
+ </enum>
+ <enum name='capsType'/>
+ <enum name='pciBackend'>
+ <value>default</value>
+ <value>vfio</value>
+ </enum>
+ </hostdev>
+ <rng supported='yes'>
+ <enum name='model'>
+ <value>virtio</value>
+ <value>virtio-transitional</value>
+ <value>virtio-non-transitional</value>
+ </enum>
+ <enum name='backendModel'>
+ <value>random</value>
+ <value>egd</value>
+ <value>builtin</value>
+ </enum>
+ </rng>
+ <filesystem supported='yes'>
+ <enum name='driverType'>
+ <value>path</value>
+ <value>handle</value>
+ <value>virtiofs</value>
+ </enum>
+ </filesystem>
+ <tpm supported='no'/>
+ <redirdev supported='yes'>
+ <enum name='bus'>
+ <value>usb</value>
+ </enum>
+ </redirdev>
+ <channel supported='yes'>
+ <enum name='type'>
+ <value>pty</value>
+ <value>unix</value>
+ </enum>
+ </channel>
+ <crypto supported='yes'>
+ <enum name='model'>
+ <value>virtio</value>
+ </enum>
+ <enum name='type'>
+ <value>qemu</value>
+ </enum>
+ <enum name='backendModel'>
+ <value>builtin</value>
+ <value>lkcf</value>
+ </enum>
+ </crypto>
+ <interface supported='yes'>
+ <enum name='backendType'>
+ <value>default</value>
+ <value>passt</value>
+ </enum>
+ </interface>
+ <panic supported='yes'>
+ <enum name='model'>
+ <value>s390</value>
+ </enum>
+ </panic>
+ </devices>
+ <features>
+ <gic supported='no'/>
+ <vmcoreinfo supported='no'/>
+ <genid supported='no'/>
+ <backingStoreInput supported='yes'/>
+ <backup supported='yes'/>
+ <async-teardown supported='yes'/>
+ <s390-pv supported='yes'/>
+ <ps2 supported='no'/>
+ <sev supported='no'/>
+ <sgx supported='no'/>
+ <launchSecurity supported='yes'>
+ <enum name='sectype'>
+ <value>s390-pv</value>
+ </enum>
+ </launchSecurity>
+ </features>
+</domainCapabilities>
diff --git a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies
new file mode 100644
index 0000000000..5195489878
--- /dev/null
+++ b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.replies
@@ -0,0 +1,38002 @@
[...]
diff --git a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml
new file mode 100644
index 0000000000..242848d6ae
--- /dev/null
+++ b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml
@@ -0,0 +1,4216 @@
[...]
20 hours, 3 minutes
[PATCH 0/2] qemucapabilitiestest: Update of x86_64 test data for qemu-10.0 release
by Peter Krempa
Peter Krempa (2):
qemucapabilitiestest: Final update for qemu-10.0 release on x86_64
qemucapabilitiestest: Final update for qemu-10.0 release on x86_64 of
the 'amdsev' variant
.../caps_10.0.0_x86_64+amdsev.replies | 199 ++++++++++--------
.../caps_10.0.0_x86_64+amdsev.xml | 9 +-
.../caps_10.0.0_x86_64.replies | 16 +-
.../caps_10.0.0_x86_64.xml | 12 +-
4 files changed, 127 insertions(+), 109 deletions(-)
--
2.49.0
20 hours, 5 minutes
RFC: libvirt-tck bhyve/FreeBSD support
by Roman Bogorodskiy
Hi,
I'd like to test the bhyve driver using libvirt-tck, which seems to be
very useful both from the continuous integration perspective,
and making the bhyve driver closer to other drivers to improve
integration with other tooling.
As a small proof-of-concept I made just a single test
060-persistent-lifecycle.t work with bhyve, though it was enough to
highlight a bunch of issues.
I've created a pull request on Gitlab:
https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/58
but apparently it's not very active there, so I'll briefly repeat it
here as well.
Issues I encountered:
* Network Filters not supported
It could be solved by implementing the network filters (obviously),
but realistically it's probably not going to happen soon.
I guess there are at least 3 options to solve that:
- Add a test suite config knob to skip nwfilters
- Don't fail the test suite on non-implemented list_nwfilters
- In the bhyve driver, add a minimal implementation which
always returns 0 rules
* Hardcoded /dev/urandom RNG devices
As the bhyve driver now supports virtio-rnd with /dev/random
backend, should there be a configuration knob for libvirt-tck to
override the RNG device definition?
* Missing IDE device support
Bhyve does not (and likely never will) support IDE devices, but supports
SATA devices. Similar to the previous item, should there be a config knob?
Or maybe just change default to sata?
* Missing pty console support
Bhyve does not support pty consoles. The bhyve driver currently supports
the nmdm console, and bhyve also supports virtio-console and TCP socket
connection which are not yet supported by the driver.
* Firmware loader specification
This is probably one of the trickiest ones. When no loader specified,
the bhyve driver uses the bhyveload(8) loader which allows to boot
FreeBSD guests only. That means that any other guest OS requires
specifying the BHYVE_UEFI.fd firmware (or use grub-bhyve). I see
two options for that:
- A test suite/framework configuration knob (again)
- Change the bhyve driver to default to BHYVE_UEFI.fd. I like this option
for two reasons: it makes bhyve domain XMLs more compatible with other
drivers, and also looks like a more reasonable default, because
for example I don't run FreeBSD guests inside bhyve very often, so for
most of my domains I have to set loader. It's a bit inconvenient that
the firmware is not a part of bhyve and needs to be installed through
the port, but we can make it possible to set the default firmware
via the build option and allow to override that via the bhyve driver
configuration, which should provide enough flexibility to users, I guess.
Any thoughts and recommendations how to tackle this project appreciated.
Thanks,
Roman
1 day, 12 hours
Re: [PATCH] qemuSnapshotDeleteValidate: Fix crash when disk is
not found in VM definition
by jungleman759
Hi
Thanks for following up, and sorry for the delay in getting back to you.
You're right to suspect the issue might be related to device changes. Here’s how the crash can be triggered:
The VM initially uses a SATA controller, with a disk defined as:
xml
复制编辑
<controller type="scsi" index="0" model="lsilogic"></controller> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/Testguest.qcow2'/> <target dev='sda' bus='sata'/> </disk>
A snapshot is created at this point — which records the disk as sda.
Later, the VM is reconfigured to use a virtio controller, and the disk is now assigned as vda.
When the VM is running and try to delete the snapshot, the snapshot code still expects to find a disk named sda in the current VM definition.
Because of this mismatch, qemuDomainDiskByName() returns NULL, and the crash occurs when the result is used without a null check.
This can easily happen during controller or disk bus reconfiguration between snapshot and deletion. The patch adds sanity checks to ensure we don’t dereference a null pointer in this situation.
Let me know if you’d like me to adjust the wording in the error messages or add a reproducer for automated testing.
Best regards,
kaihuan
Martin Kletzander <mkletzan(a)redhat.com> 于2025年1月22日周三 21:05写道：
On Fri, Nov 29, 2024 at 10:56:45PM +0800, kaihuan wrote:
>qemuDomainDiskByName() can return a NULL pointer on failure.
>But this returned value in qemuSnapshotDeleteValidate is not checked.It will make libvirtd crash.
>
Hi, looking through old unreviewed patches I found this one. Sorry for
the wait. Can you explain whether you found out how to trigger that?
This looks like there is some other issue that causes a snapshot having
a disk that is not in the domain. Does that happen when you want to
delete a snapshot after unplugging a disk?
>Signed-off-by: kaihuan <jungleman759(a)gmail.com>
>---
> src/qemu/qemu_snapshot.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
>diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c
>index 18b2e478f6..bcbd913073 100644
>--- a/src/qemu/qemu_snapshot.c
>+++ b/src/qemu/qemu_snapshot.c
>@@ -4242,8 +4242,19 @@ qemuSnapshotDeleteValidate(virDomainObj *vm,
> virDomainDiskDef *vmdisk = NULL;
> virDomainDiskDef *disk = NULL;
>
>- vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name);
>- disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name);
The function calls already report an error when the disk is not found,
so there is not need to rewrite that error in my opinion.
>+ if (!(vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name))) {
>+ virReportError(VIR_ERR_OPERATION_FAILED,
>+ _("disk '%1$s' referenced by snapshot '%2$s' not found in the current definition"),
>+ snapDisk->name, snap->def->name);
>+ return -1;
>+ }
>+
>+ if (!(disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name))) {
>+ virReportError(VIR_ERR_OPERATION_FAILED,
>+ _("disk '%1$s' referenced by snapshot '%2$s' not found in the VM definition of the deleted snapshot"),
>+ snapDisk->name, snap->def->name);
>+ return -1;
>+ }
>
> if (!virStorageSourceIsSameLocation(vmdisk->src, disk->src)) {
> virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
>--
>2.33.1.windows.1
>
1 day, 16 hours
Re: [PATCH] qemuSnapshotDeleteValidate: Fix crash when disk is
not found in VM definition
by jungleman759
Hi
Thanks for following up, and sorry for the delay in getting back to you.
You're right to suspect the issue might be related to device changes. Here’s how the crash can be triggered:
The VM initially uses a SATA controller, with a disk defined as:
xml
复制编辑
<controller type="scsi" index="0" model="lsilogic"></controller> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/Testguest.qcow2'/> <target dev='sda' bus='sata'/> </disk>
A snapshot is created at this point — which records the disk as sda.
Later, the VM is reconfigured to use a virtio controller, and the disk is now assigned as vda.
When the VM is running and the snapshot is deleted, the snapshot code still expects to find a disk named sda in the current VM definition.
Because of this mismatch, qemuDomainDiskByName() returns NULL, and the crash occurs when the result is used without a null check.
This can easily happen during controller or disk bus reconfiguration between snapshot and deletion. The patch adds sanity checks to ensure we don’t dereference a null pointer in this situation.
Let me know if you’d like me to adjust the wording in the error messages or add a reproducer for automated testing.
Best regards,
kaihuan
Martin Kletzander <mkletzan(a)redhat.com> 于2025年1月22日周三 21:05写道：
On Fri, Nov 29, 2024 at 10:56:45PM +0800, kaihuan wrote:
>qemuDomainDiskByName() can return a NULL pointer on failure.
>But this returned value in qemuSnapshotDeleteValidate is not checked.It will make libvirtd crash.
>
Hi, looking through old unreviewed patches I found this one. Sorry for
the wait. Can you explain whether you found out how to trigger that?
This looks like there is some other issue that causes a snapshot having
a disk that is not in the domain. Does that happen when you want to
delete a snapshot after unplugging a disk?
>Signed-off-by: kaihuan <jungleman759(a)gmail.com>
>---
> src/qemu/qemu_snapshot.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
>diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c
>index 18b2e478f6..bcbd913073 100644
>--- a/src/qemu/qemu_snapshot.c
>+++ b/src/qemu/qemu_snapshot.c
>@@ -4242,8 +4242,19 @@ qemuSnapshotDeleteValidate(virDomainObj *vm,
> virDomainDiskDef *vmdisk = NULL;
> virDomainDiskDef *disk = NULL;
>
>- vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name);
>- disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name);
The function calls already report an error when the disk is not found,
so there is not need to rewrite that error in my opinion.
>+ if (!(vmdisk = qemuDomainDiskByName(vm->def, snapDisk->name))) {
>+ virReportError(VIR_ERR_OPERATION_FAILED,
>+ _("disk '%1$s' referenced by snapshot '%2$s' not found in the current definition"),
>+ snapDisk->name, snap->def->name);
>+ return -1;
>+ }
>+
>+ if (!(disk = qemuDomainDiskByName(snapdef->parent.dom, snapDisk->name))) {
>+ virReportError(VIR_ERR_OPERATION_FAILED,
>+ _("disk '%1$s' referenced by snapshot '%2$s' not found in the VM definition of the deleted snapshot"),
>+ snapDisk->name, snap->def->name);
>+ return -1;
>+ }
>
> if (!virStorageSourceIsSameLocation(vmdisk->src, disk->src)) {
> virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
>--
>2.33.1.windows.1
>
1 day, 16 hours
Invoke QMP commands using native libvirt API
by Blade Liu
Hi all,
I have a problem to execute qmp commands via qemu guest agent using libvirt-Python. In libivrt and qemu tutorial, qmp commands are invoked
by terminal. In my project, I want to invoke the commands natively using libvirt-Python API, not using Python subprocess module.
(my test shows using subprocess to invoke the commands have some issues)
I'm not sure if libvirt-Python provides such API. If the API is not avaiable, as libvirt natively use C interface to interact
with QEMU, do we have to implement it by hand?
Another way to invoke qmp commands is communicate the socket of qemu guest agent. I tried it which did not work. Invoking qmp commands with virsh works fine.
Sorry if this post should be posted in other libvirt mail lists. Thank you very much for feedbacks.
Environment
- OS: Centos 8.5(x86_64)
- libvirt 6.0.0
- QEMU 6.0.0
=== qemu guest socket
$ss | grep libvirt
/var/lib/libvirt/qemu/channel/target/domain-71-run-win7/org.qemu.guest_agent.0 8568953
/run/libvirt/libvirt-sock
$sudo socat unix-connect:/var/lib/libvirt/qemu/channel/target/domain-71-run-win7/org.qemu.guest_agent.0
${"execute":"guest-info"}
// nothing shows
=== invoke qmp commands using Python
import subprocess
cmd = '{"execute": "guest-info"}'
p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE)
result = p.communicate()[0]
1 day, 20 hours
[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
2 days, 8 hours
Question about SEV* guests and automatic firmware selection
by Jim Fehlig
Hi All,
While investigating an internal bug report, we noticed that a minimal firmware
auto-selection configuration along with SEV* fails to find a match. E.g. the
following config
<domain type="kvm">
<os firmware="efi">
<type arch="x86_64" machine="q35">hvm</type>
<boot dev="hd"/>
</os>
<launchSecurity type="sev">
<policy>0x07</policy>
</launchSecurity>
...
</domain>
Fails with "Unable to find 'efi' firmware that is compatible with the current
configuration". A firmware that should match has the following json description
{
"description": "UEFI firmware for x86_64, with AMD SEV",
"interface-types": [
"uefi"
],
"mapping": {
"device": "flash",
"mode": "stateless",
"executable": {
"filename": "/usr/share/qemu/ovmf-x86_64-sev.bin",
"format": "raw"
}
},
"targets": [
{
"architecture": "x86_64",
"machines": [
"pc-q35-*"
]
}
],
"features": [
"acpi-s4",
"amd-sev",
"amd-sev-es",
"amd-sev-snp",
"verbose-dynamic"
],
"tags": [
]
}
Auto-selection works fine if I specify a 'stateless' firmware, e.g. amend the
above config with
<os firmware="efi">
<type arch="x86_64" machine="q35">hvm</type>
<loader stateless="yes"/>
<boot dev="hd"/>
</os>
Being unfamiliar with the firmware auto-selection code, I tried the below naive
hack, which only led to test failures and the subsequent runtime error "unable
to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin".
Should auto-selection work with the minimal config, or is it expected that user
also specify a stateless firmware?
Regards,
Jim
diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c
index 2d0ec0b4fa..660b74141a 100644
--- a/src/qemu/qemu_firmware.c
+++ b/src/qemu/qemu_firmware.c
@@ -1293,15 +1293,17 @@ qemuFirmwareMatchDomain(const virDomainDef *def,
return false;
}
- if (loader && loader->stateless == VIR_TRISTATE_BOOL_YES) {
- if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) {
- VIR_DEBUG("Discarding loader without stateless flash");
- return false;
- }
- } else {
- if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) {
- VIR_DEBUG("Discarding loader without split flash");
- return false;
+ if (loader) {
+ if (loader->stateless == VIR_TRISTATE_BOOL_YES) {
+ if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) {
+ VIR_DEBUG("Discarding loader without stateless flash");
+ return false;
+ }
+ } else if (loader->stateless == VIR_TRISTATE_BOOL_NO) {
+ if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) {
+ VIR_DEBUG("Discarding loader without split flash");
+ return false;
+ }
}
}
2 days, 8 hours
