Hello,
I am trying to find a solution to an issue related to vhost-vdpa devices
and random mac addresses being assigned to them, if not set by the user.
vDPA devices are assigned a MAC address the time they are created. That
happens before creating the VM with qemu or libvirt. If the mac address
From: Peter Krempa
Further split up the code originally in 'qemuMigrationSrcIsSafe' to
separate checks concerning a single storage source.
The code will then be reused to check the safe migration state also for
the data file (qcow2 feature that allows store of data separated from
the qcow2 metad
On 9/10/25 07:57, Andrea Bolognani via Devel wrote:
One of the new test cases demonstrates how firmware
autoselection doesn't currently work correctly for domains
using SEV-SNP: the descriptor for a suitable firmware exists,
and yet it doesn't get picked up.
Another test cases shows that, while
While reviewing Stefan patches [1] I've changed some of them before
merging and oopsie, I've introduced a bug (patch 1/4) but fortunately
forgot to remove the code I intended to move so it actually works :-D.
1:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HAZRW5NYFJFBG
In the commit summary:
*properties
On a Wednesday in 2025, Peter Krempa via Devel wrote:
From: Peter Krempa
If the qcow2 data file feature (which separates the data into a separate
file from the metadata) is in use the migration safety check ought co
ought to
Jano
consider both the metad
On Wed, Sep 10, 2025 at 08:21:17AM -0500, Andrea Bolognani wrote:
> On Mon, Sep 08, 2025 at 04:00:06PM -0600, Jim Fehlig wrote:
> > Were you planning to spin another version which includes
> > patch 8?
>
> Not necessarily, but I have just opened
>
> https://src.fedoraproject.org/rpms/edk2/pull-re
Based on proposed changes in the Fedora edk2 package:
https://src.fedoraproject.org/rpms/edk2/pull-request/14
A new firmware descriptor exists for the stateful SEV
use case, and the regular edk2 descriptor no longer
advertises support for SEV/SEV-ES.
Additionally, all stateless SEV use cases a
Signed-off-by: Andrea Bolognani
---
NEWS.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 1b8e188f5e..847dcb390b 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -36,6 +36,11 @@ v11.8.0 (unreleased)
* **Bug fixes**
+ * qemu: Fix selection of stateless/combined f
The current code assumes that a stateless firmware has to be
explicitly requested by the user, and should never be picked
otherwise. This means that, for example, domains configured to
use SEV-SNP are forced to explicitly request for the firmware
to be stateless.
Additionally, we assume that only
One of the new test cases demonstrates how firmware
autoselection doesn't currently work correctly for domains
using SEV-SNP: the descriptor for a suitable firmware exists,
and yet it doesn't get picked up.
Another test cases shows that, while firmware autoselection
succeeds for non-SNP SEV domain
From: Jim Fehlig
SEV and SEV-ES guests should use q35 machine type and uefi. Adjust
existing tests accordingly.
Signed-off-by: Jim Fehlig
Reviewed-by: Andrea Bolognani
---
...curity-sev-direct.x86_64-latest+amdsev.args | 4 +++-
...ecurity-sev-direct.x86_64-latest+amdsev.xml | 8 ++--
.
Removing all unnecessary devices and elements makes it easier
to focus on the actual purpose of these tests (configuring
the SEV-specific bits).
Signed-off-by: Andrea Bolognani
Reviewed-by: Jim Fehlig
---
...urity-sev-direct.x86_64-latest+amdsev.args | 3 --
...curity-sev-direct.x86_64-latest+
This kind of firmware build is not shipped in Fedora, where
most descriptors in our test suite come from, so we had to
make it up. It was based off the Secure Boot-enabled edk2
build, and the filename it points to is the same.
That has been fine so far since it's not actually being picked
up by an
From: Peter Krempa
The 'data_file_raw' flag of qcow2 notifies that all data inside the
'data_file' is a raw image so can be used standalone without the
metadata without any problem (except for not updating the dirty
bitmaps).
Our migration safety checks will allow skipping the migration safety
c
From: Peter Krempa
The feature exists for a long time, no need to add extra notice about
it.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_migration.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index a8f4dd4
Patches 1-3 are refactors that simplify the code and prepare it.
Patch 4 fixed bug where 'data_file' is not checked
Patches 5 and 6 add a workaround for Kubevirt's corner case migration
approach.
Peter Krempa (6):
qemuMigrationSrcIsSafe: Drop 'DEBUG' message about qemu supporting
cache dropp
On Mon, Sep 08, 2025 at 04:00:06PM -0600, Jim Fehlig wrote:
> Hi Andrea,
>
> Is there anything I can do to help move this series forward? I think 8/10
> can now be considered for merging, correct?
Well, yes, but I'm not particularly keen on updating libvirt's test
suite when the status in the Fedo
On 9/10/25 14:04, Jiri Denemark via Devel wrote:
> The version of setuptools shipped by Fedora 42 is PEP 625 compliant,
> which requires distribution files to contain a normalized package name.
> Thus the generated tarball is called libvirt_python-$VER.tar.gz rather
> than libvirt-python-$VER.tar.g
From: Ján Tomko
There are no functions reimplemented here anymore.
Signed-off-by: Ján Tomko
---
src/util/glibcompat.c | 64 ---
src/util/meson.build | 1 -
2 files changed, 65 deletions(-)
delete mode 100644 src/util/glibcompat.c
diff --git a/src/uti
From: Ján Tomko
We removed support for Debian 11 which only had 2.66.8.
Next stop: 2.72 after we drop Ubuntu 22.04
For libvirt, the update to the 2.68 GLib release:
* introduces g_string_replace
* deprecates g_memdup in favor of g_memdup2
* removes the need for some warning workarounds
* depreca
Ján Tomko (2):
build: bump minimum glib version to 2.68
util: remove glibcompat.c
meson.build | 2 +-
src/conf/virdomainjob.c | 6 +-
src/esx/esx_vi_types.c | 9 +-
src/internal.h | 24
src/libvirt_private.syms | 4 -
src/qemu/qemu_c
From: Michal Privoznik
The aim of chDomainRemoveDevice() is to remove device from
virDomainDef. Well, in case of disks this is done by calling
virDomainDiskRemove() which merely just removes it from the array
of virDomainDiskDef-s but leaves it up to the caller to actually
free the disk def.
1,2
From: Michal Privoznik
The 'disk' variable inside of chDomainFindDisk() is not used
really. Drop it.
Signed-off-by: Michal Privoznik
---
src/ch/ch_hotplug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/ch/ch_hotplug.c b/src/ch/ch_hotplug.c
index aa723dd123..cfa11cc
From: Michal Privoznik
Inside of chDomainDetachDeviceLive() there are two variables that
are important in this case: 'match' and 'detach'. The first one
contains device definition as parsed from user provided XML, the
other contains pointer to the device definition inside
virDomainDef (as returne
From: Michal Privoznik
When virCHDriverConfig struct is initialized in
virCHDriverConfigNew() the 'configDir' member is allocated but
corresponding free is missing in virCHDriverConfigDispose().
While at it, reorder the free calls to match the order in which
they are declared in the struct so it'
25 matches
Mail list logo
