[PATCH v2 00/14] hw: define and enforce a standard lifecycle for versioned machines
by Daniel P. Berrangé
Thomas proposed a new deprecation and removal policy for versioned
machine types that would see them liable for deletion after 6 years:
https://lists.nongnu.org/archive/html/qemu-devel/2024-04/msg04683.html
This suggest was met with broad approval, however, I suggested that we
could take it further and actually mark them deprecated sooner, at the
3 year timeframe, and also fully automate the enablement of the runtime
deprecation warning without developer intervention on every release
cycle.
This series implements my suggestions.
The first patch introduces some helper macros and documents a standard
code pattern for defining versioned machine types across targets.
The next 6 patches convert existing targets with versioned machine
types (arm, s390x, ppc, m68k, i386) to use the new helper macros and
code patterns.
A further patch introduces some helper macros for automating the
handling of deprecation and deletion of versioned machine types.
Two more patches then enable the deprecation and deletion logic
across all versioned machines
Finally we do some cleanup and document the new policy.
........a tangent about VERSION file handling.......
One oddity here, is that during the development and release
candidate phases the automatic logic in this series has an off-by-1
error.
This is because when we, for example, add the "9.1" machine type
versions, the VERSION file is still reporting '9.0.50', and then
'9.0.9{1,2,3,4}'.
IOW, during development and in rc candidates, we fail to deprecate
and delete 1 machine type. We should already have deprecated the
6.1 machine types, but the most recently deprecated is 6.0.
This is pretty harmless since the final release does the right
thing.
I wonder, however, whether we would benefit from changing how we
update the VERSION file.
eg instead of re-using the micro digit to indicate a dev or rc
snapshot, represent those explicitly. eg "9.1.0-dev" and
"9.1.0-rc1", "9.1.0-rc2", etc in VERSION.
We don't use the full QEMU_VERSION in the code in all that many
places. It appears in some help messages for command line tools,
and in QMP query-version response, and in a few other misc places.
At a glance it appears all of those places would easily handle a
tagged version.
For release candidates in particular I think it would be saner
to show the user the actual version the release is about to become,
rather than the previous release's version. This would make the
reported version match the rc tarball naming too which would be
nice.
Anyway, this isn't a blocker for this machine type versioning
proposal, just a thought....
Changed in v2:
- Various docs improvements and minor fixes from original
review
- Rebased and resolved conflicts with Philippe's merged
series
Daniel P. Berrangé (14):
include/hw: add helpers for defining versioned machine types
hw/arm: convert 'virt' machine definitions to use new macros
hw/s390x: convert 'ccw' machine definitions to use new macros
hw/ppc: convert 'spapr' machine definitions to use new macros
hw/m68k: convert 'virt' machine definitions to use new macros
hw/i386: convert 'i440fx' machine definitions to use new macros
hw/i386: convert 'q35' machine definitions to use new macros
include/hw: add macros for deprecation & removal of versioned machines
include/hw: temporarily disable deletion of versioned machine types
hw: set deprecation info for all versioned machine types
hw: skip registration of outdated versioned machine types
hw/ppc: remove obsolete manual deprecation reason string of spapr
machines
hw/i386: remove obsolete manual deprecation reason string of i440fx
machines
docs: document special exception for machine type deprecation &
removal
docs/about/deprecated.rst | 13 ++
hw/arm/virt.c | 30 ++--
hw/i386/pc_piix.c | 220 ++++++++++++---------------
hw/i386/pc_q35.c | 215 +++++++++++---------------
hw/m68k/virt.c | 53 ++++---
hw/ppc/spapr.c | 96 ++++++------
hw/s390x/s390-virtio-ccw.c | 98 ++++++------
include/hw/boards.h | 298 +++++++++++++++++++++++++++++++++++++
include/hw/i386/pc.h | 28 ++++
9 files changed, 681 insertions(+), 370 deletions(-)
--
2.43.0
9 months, 1 week
[PATCH 0/8] ch: support restore with network devices
by Purna Pavan Chandra
Current ch driver supports restore only for domains without any network
configuration defined. This was because libvirt explicitly passes network fds
and CH did not had support to restore with new net FDS. This support has been
added recently, https://github.com/cloud-hypervisor/cloud-hypervisor/pull/6402
The changes in this patch series majorly include moving to socket communication
for restore api, create new net fds and pass them via SCM_RIGHTS to CH.
Purna Pavan Chandra (8):
ch: report response message instead of just code
ch: Pass net ids explicitly during vm creation
ch: refactor chProcessAddNetworkDevices
ch: poll with -1 in chSocketRecv
ch: use monitor socket fd to send restore request
ch: refactor virCHMonitorSaveVM
ch: support restore with net devices
ch: kill CH process if restore fails
src/ch/ch_driver.c | 9 +-
src/ch/ch_monitor.c | 62 +++++++-----
src/ch/ch_monitor.h | 6 +-
src/ch/ch_process.c | 225 ++++++++++++++++++++++++++++++++++----------
4 files changed, 223 insertions(+), 79 deletions(-)
--
2.34.1
9 months, 2 weeks
[PATCH 0/8] Report 'passt' support in domain capabilities
by Michal Privoznik
There are some distributions that consider switching from SLIRP to just
passt. While libvirt wires no defaults and leaves this kind of
decisions onto upper layers, it can help mgmt apps do the decision by
reporting passt support in domain capabilities.
Michal Prívozník (8):
libvirt_private.syms: Export virDomainNetBackendType enum handlers
qemu_capabilities: Introduce QEMU_CAPS_NETDEV_USER
qemu_validate: Validate net backends against QEMU caps
domain_capabilities: Introduce netdev capabilities
qemu_capabilities: Fill supported net backend types
conf: Accept 'default' backend type for <interface type='user'/>
qemu_validate: Use domaincaps to validate supported net backend type
qemu_domain: Set 'passt' net backend if 'default' is unsupported
docs/formatdomaincaps.rst | 25 +++++++++++++++++++
src/conf/domain_capabilities.c | 13 ++++++++++
src/conf/domain_capabilities.h | 8 ++++++
src/conf/domain_conf.c | 5 +++-
src/conf/schemas/domaincaps.rng | 10 ++++++++
src/conf/schemas/domaincommon.rng | 1 +
src/libvirt_private.syms | 2 ++
src/qemu/qemu_capabilities.c | 23 +++++++++++++++++
src/qemu/qemu_capabilities.h | 4 +++
src/qemu/qemu_domain.c | 19 +++++++++++---
src/qemu/qemu_validate.c | 14 ++++++++---
.../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 5 ++++
.../qemu_4.2.0-virt.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_4.2.0.ppc64.xml | 5 ++++
tests/domaincapsdata/qemu_4.2.0.s390x.xml | 5 ++++
tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 5 ++++
.../qemu_5.0.0-tcg-virt.riscv64.xml | 5 ++++
.../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 5 ++++
.../qemu_5.0.0-virt.aarch64.xml | 5 ++++
.../qemu_5.0.0-virt.riscv64.xml | 5 ++++
tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 5 ++++
tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 5 ++++
tests/domaincapsdata/qemu_5.1.0.sparc.xml | 5 ++++
tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 5 ++++
.../qemu_5.2.0-tcg-virt.riscv64.xml | 5 ++++
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 5 ++++
.../qemu_5.2.0-virt.aarch64.xml | 5 ++++
.../qemu_5.2.0-virt.riscv64.xml | 5 ++++
tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_5.2.0.ppc64.xml | 5 ++++
tests/domaincapsdata/qemu_5.2.0.s390x.xml | 5 ++++
tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 5 ++++
.../qemu_6.0.0-virt.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_6.0.0.s390x.xml | 5 ++++
tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 5 ++++
tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 5 ++++
.../qemu_6.2.0-virt.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 5 ++++
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 5 ++++
.../qemu_7.0.0-hvf.aarch64+hvf.xml | 5 ++++
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 5 ++++
.../qemu_7.0.0-virt.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_7.0.0.aarch64.xml | 5 ++++
tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 5 ++++
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 5 ++++
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 5 ++++
tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 5 ++++
tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 5 ++++
.../qemu_7.2.0-hvf.x86_64+hvf.xml | 6 +++++
.../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 6 +++++
.../qemu_7.2.0-tcg.x86_64+hvf.xml | 6 +++++
.../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 6 +++++
tests/domaincapsdata/qemu_7.2.0.ppc.xml | 6 +++++
tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 6 +++++
.../qemu_8.0.0-tcg-virt.riscv64.xml | 6 +++++
.../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 6 +++++
.../qemu_8.0.0-virt.riscv64.xml | 6 +++++
tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 6 +++++
tests/domaincapsdata/qemu_8.1.0.s390x.xml | 6 +++++
tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 6 +++++
.../qemu_8.2.0-tcg-virt.loongarch64.xml | 6 +++++
.../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 6 +++++
.../qemu_8.2.0-virt.aarch64.xml | 6 +++++
.../qemu_8.2.0-virt.loongarch64.xml | 6 +++++
tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 6 +++++
tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 6 +++++
tests/domaincapsdata/qemu_8.2.0.s390x.xml | 6 +++++
tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 6 +++++
tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 6 +++++
.../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 6 +++++
tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 6 +++++
.../caps_4.2.0_aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_4.2.0_ppc64.xml | 1 +
.../qemucapabilitiesdata/caps_4.2.0_s390x.xml | 1 +
.../caps_4.2.0_x86_64.xml | 1 +
.../caps_5.0.0_aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_5.0.0_ppc64.xml | 1 +
.../caps_5.0.0_riscv64.xml | 1 +
.../caps_5.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_5.1.0_sparc.xml | 1 +
.../caps_5.1.0_x86_64.xml | 1 +
.../caps_5.2.0_aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_5.2.0_ppc64.xml | 1 +
.../caps_5.2.0_riscv64.xml | 1 +
.../qemucapabilitiesdata/caps_5.2.0_s390x.xml | 1 +
.../caps_5.2.0_x86_64.xml | 1 +
.../caps_6.0.0_aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.0.0_s390x.xml | 1 +
.../caps_6.0.0_x86_64.xml | 1 +
.../caps_6.1.0_x86_64.xml | 1 +
.../caps_6.2.0_aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 +
.../caps_6.2.0_x86_64.xml | 1 +
.../caps_7.0.0_aarch64+hvf.xml | 1 +
.../caps_7.0.0_aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 +
.../caps_7.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 +
.../caps_7.1.0_x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 +
.../caps_7.2.0_x86_64+hvf.xml | 1 +
.../caps_7.2.0_x86_64.xml | 1 +
.../caps_8.0.0_riscv64.xml | 1 +
.../caps_8.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 +
.../caps_8.1.0_x86_64.xml | 1 +
.../caps_8.2.0_aarch64.xml | 1 +
.../caps_8.2.0_armv7l.xml | 1 +
.../caps_8.2.0_loongarch64.xml | 1 +
.../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 1 +
.../caps_8.2.0_x86_64.xml | 1 +
.../caps_9.0.0_x86_64.xml | 1 +
.../caps_9.1.0_x86_64.xml | 1 +
137 files changed, 608 insertions(+), 8 deletions(-)
--
2.44.2
9 months, 2 weeks
[PATCH] qemuDomainChangeNet: forbid changing portgroup
by Adam Julis
While changing the portgroup attribute causes incorrect
behavior, this option is disabled for hot-plug.
Resolves: https://issues.redhat.com/browse/RHEL-7299
Signed-off-by: Adam Julis <ajulis(a)redhat.com>
---
src/qemu/qemu_hotplug.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 4a3f4f657e..355f742535 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -3884,6 +3884,13 @@ qemuDomainChangeNet(virQEMUDriver *driver,
goto cleanup;
}
+ if (newdev->type == VIR_DOMAIN_NET_TYPE_NETWORK &&
+ STRNEQ_NULLABLE(olddev->data.network.portgroup, newdev->data.network.portgroup)) {
+ virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
+ _("cannot modify network device portgroup attribute"));
+ goto cleanup;
+ }
+
/* allocate new actual device to compare to old - we will need to
* free it if we fail for any reason
*/
--
2.45.2
9 months, 2 weeks
[PATCH] NEWS: Mention crash when VM shuts down during migration
by Peter Krempa
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
NEWS.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 1ea98599db..5557018f33 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -65,6 +65,11 @@ v10.5.0 (unreleased)
have failed as the destination would incorrectly expect those features to
be enabled after starting QEMU.
+ * qemu: Fix ``libvirtd``/``virtqemud`` crash when VM shuts down during migration
+
+ The libvirt daemon could crash when a VM was shut down while being migrated
+ to another host.
+
v10.4.0 (2024-06-03)
====================
--
2.45.2
9 months, 2 weeks
[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik
There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
NEWS.rst | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index bc8acc62d4..d675c869a4 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -16,6 +16,10 @@ v10.5.0 (unreleased)
* **Removed features**
* **New features**
+ * Introduce SEV-SNP support
+
+ SEV-SNP is introduced as another type of ``<launchSecurity/>``. Its support
+ is reported in both domain capabilities and ``virt-host-validate``.
* **Improvements**
@@ -26,8 +30,34 @@ v10.5.0 (unreleased)
the dependency on ``certtool`` and providing more comprehensive checks
of the certificate properties.
+ * qemu: implement iommu coldplug/unplug
+
+ The ``<iommu/>`` device can be now cold plugged and/or cold unplugged.
+
+ * Pass shutoff reason to release hook
+
+ Sometimes in release hook it is useful to know if the VM shutdown was
+ graceful or not. This is especially useful to do cleanup based on the VM
+ shutdown failure reason in release hook. String with this release the last
+ argument 'extra' is used to pass VM shutoff reason in the call to release
+ hook.
+
+ * nodedev: improve DASD detection
+
+ In newer DASD driver versions the ID_TYPE tag is supported. This tag is
+ missing after a system reboot but when the ccw device is set offline and
+ online the tag is included. To fix this version independently we need to
+ check if devices detected as type disk is actually a DASD to maintain
+ the node object consistency and not end up with multiple node objects
+ for DASDs.
+
* **Bug fixes**
+ * remote_daemon_dispatch: Unref sasl session when closing client connection
+
+ A memory leak was identified when a client started SASL but then suddenly
+ closed connection. This is now fixed.
+
v10.4.0 (2024-06-03)
====================
--
2.44.2
9 months, 2 weeks
[PATCH] NEWS: Mention migration fix with disabled vmx-* CPU features
by Jiri Denemark
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
NEWS.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index b0b893b484..1ea98599db 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -59,6 +59,12 @@ v10.5.0 (unreleased)
A memory leak was identified when a client started SASL but then suddenly
closed connection. This is now fixed.
+ * qemu: Fix migration with disabled vmx-* CPU features
+
+ Migrating a domain with some vmx-* CPU features marked as disabled could
+ have failed as the destination would incorrectly expect those features to
+ be enabled after starting QEMU.
+
v10.4.0 (2024-06-03)
====================
--
2.45.1
9 months, 2 weeks
[PATCH] qemu: fix switchover-ack regression for old qemu
by Jon Kohler
When enabling switchover-ack on qemu from libvirt, the .party value
was set to both source and target; however, qemuMigrationParamsCheck()
only takes that into account to validate that the remote side of the
migration supports the flag if it is marked optional or auto/always on.
In the case of switchover-ack, when enabled on only the dst and not
the src, the migration will fail if the src qemu does not support
switchover-ack, as the dst qemu will issue a switchover-ack msg:
qemu/migration/savevm.c ->
loadvm_process_command ->
migrate_send_rp_switchover_ack(mis) ->
migrate_send_rp_message(mis, MIG_RP_MSG_SWITCHOVER_ACK, 0, NULL)
Since the src qemu doesn't understand messages with header_type ==
MIG_RP_MSG_SWITCHOVER_ACK, qemu will kill the migration with error:
qemu-kvm: RP: Received invalid message 0x0007 length 0x0000
qemu-kvm: Unable to write to socket: Bad file descriptor
Looking at the original commit [1] for optional migration capabilities,
it seems that the spirit of optional handling was to enhance a given
existing capability where possible. Given that switchover-ack
exclusively depends on return-path, adding it as optional to that cap
feels right.
[1] 61e34b08568 ("qemu: Add support for optional migration capabilities")
Fixes: 1cc7737f69e ("qemu: add support for qemu switchover-ack")
Signed-off-by: Jon Kohler <jon(a)nutanix.com>
Cc: Alex Williamson <alex.williamson(a)redhat.com>
Cc: Avihai Horon <avihaih(a)nvidia.com>
Cc: Jiri Denemark <jdenemar(a)redhat.com>
Cc: Markus Armbruster <armbru(a)redhat.com>
Cc: Peter Xu <peterx(a)redhat.com>
Cc: YangHang Liu <yanghliu(a)redhat.com>
---
src/qemu/qemu_migration_params.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/qemu/qemu_migration_params.c b/src/qemu/qemu_migration_params.c
index 9593b6ba65..98822012cc 100644
--- a/src/qemu/qemu_migration_params.c
+++ b/src/qemu/qemu_migration_params.c
@@ -210,17 +210,13 @@ static const qemuMigrationParamsFlagMapItem qemuMigrationParamsFlagMap[] = {
{.match = QEMU_MIGRATION_FLAG_FORBIDDEN,
.flag = VIR_MIGRATE_TUNNELLED,
.cap = QEMU_MIGRATION_CAP_RETURN_PATH,
+ .optional = QEMU_MIGRATION_CAP_SWITCHOVER_ACK,
.party = QEMU_MIGRATION_SOURCE | QEMU_MIGRATION_DESTINATION},
{.match = QEMU_MIGRATION_FLAG_REQUIRED,
.flag = VIR_MIGRATE_ZEROCOPY,
.cap = QEMU_MIGRATION_CAP_ZERO_COPY_SEND,
.party = QEMU_MIGRATION_SOURCE},
-
- {.match = QEMU_MIGRATION_FLAG_FORBIDDEN,
- .flag = VIR_MIGRATE_TUNNELLED,
- .cap = QEMU_MIGRATION_CAP_SWITCHOVER_ACK,
- .party = QEMU_MIGRATION_SOURCE | QEMU_MIGRATION_DESTINATION},
};
/* Translation from VIR_MIGRATE_PARAM_* typed parameters to
--
2.43.0
9 months, 2 weeks
[libvirt PATCH] vircgroup: fix g_variant_new_parsed format string causing abort
by Pavel Hrdina
The original code was incorrect and never tested because at the time of
implementing it the cgroup file `io.weight` was not available.
Resolves: https://issues.redhat.com/browse/RHEL-45185
Introduced-by: 9c1693eff427661616ce1bd2795688f87288a412
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
src/util/vircgroupv1.c | 2 +-
src/util/vircgroupv2.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/util/vircgroupv1.c b/src/util/vircgroupv1.c
index 77c7e209ce..c1f0562249 100644
--- a/src/util/vircgroupv1.c
+++ b/src/util/vircgroupv1.c
@@ -1225,7 +1225,7 @@ virCgroupV1SetBlkioDeviceWeight(virCgroup *group,
if (group->unitName) {
GVariant *value = NULL;
- value = g_variant_new_parsed("[(%s, uint64 %u)]", path, weight);
+ value = g_variant_new_parsed("[(%s, %t)]", path, weight);
return virCgroupSetValueDBus(group->unitName, "BlockIODeviceWeight", value);
} else {
diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c
index db115e25f7..eaf5ae98f6 100644
--- a/src/util/vircgroupv2.c
+++ b/src/util/vircgroupv2.c
@@ -867,7 +867,7 @@ virCgroupV2SetBlkioDeviceWeight(virCgroup *group,
if (group->unitName) {
GVariant *value = NULL;
- value = g_variant_new_parsed("[(%s, uint64 %u)]", path, weight);
+ value = g_variant_new_parsed("[(%s, %t)]", path, weight);
return virCgroupSetValueDBus(group->unitName, "IODeviceWeight", value);
} else {
--
2.45.2
9 months, 2 weeks
Entering freeze for libvirt-10.5.0
by Jiri Denemark
I have just tagged v10.5.0-rc1 in the repository and pushed signed
tarballs to https://download.libvirt.org/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
9 months, 2 weeks
