Release of libvirt-10.3.0
by Jiri Denemark
Somehow I forgot to make rc2 on Tuesday, but the only commits after rc1
at that time were translations so I guess it's not a big deal.
The 10.3.0 release of both libvirt and libvirt-python is tagged and
signed tarballs are available at
https://download.libvirt.org/
https://download.libvirt.org/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing feedback. Your work is greatly
appreciated.
* New features
* qemu: Proper support for USB network device
USB address is now automatically assigned to USB network devices thus they
can be used without manual configuration.
* conf: Introduce memReserve attribute to <controller/>
Some PCI devices have large non-prefetchable memory. This can be a problem
in case when such device needs to be hotplugged as the firmware can't
foresee such situation. The user thus can override the value calculated at
start to accomodate for such devices.
* Improvements
* Improve validation of USB devices
Certain USB device types ('sound', 'fs', 'chr', 'ccid' and 'net') were not
properly handled in the check whether the VM config supports USB and thus
would result in poor error messages.
* virsh: Fix behaviour of ``--name`` and ``--parent`` used together when listing checkpoint and snapshots
The ``checkpoint-list`` and ``snapshot-list`` commands would ignore the
``--name`` option to print only the name when used with ``--parent``.
* Extend libvirt-guests to shutdown only persistent VMs
Users can now choose to shutdown only persistent VMs when the host is being
shut down.
* Bug fixes
* qemu: Fix migration with custom XML
Libvirt 10.2.0 would sometimes complain about incompatible CPU definition
when trying to migrate or save a domain and passing a custom XML even
though such XML was properly generated as migratable. Hitting this bug
depends on the guest CPU definition and the host on which a particular
domain was running.
* qemu: Fix TLS hostname verification failure in certain non-shared storage migration scenarios
In certain scenarios (parallel migration, newly also post-copy migration)
libvirt would wrongly pass an empty hostname to QEMU to be used for TLS
certificate hostname validation, which would result into failure of the
non-shared storage migration step::
error: internal error: unable to execute QEMU command 'blockdev-add': Certificate does not match the hostname
* Create OVS ports as transient
Libvirt now creates OVS ports as transient which prevents them from
reappearing or going stale on sudden reboots.
* Clear OVS QoS settings when domain shuts down
Libvirt now clears QoS settings on domain shutdown, so they no longer pile
up in OVS database.
Enjoy.
Jirka
1 year
- 1
- 0
[PATCH RESEND] NEWS: Document my contributions for upcoming release
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Rebased version of the patch sent earlier, because the file was changed
meanwhile.
NEWS.rst | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 7ced82e3da..554ca559a2 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -22,6 +22,13 @@ v10.3.0 (unreleased)
USB address is now automatically assigned to USB network devices thus they
can be used without manual configuration.
+ * conf: Introduce memReserve to <controller/>
+
+ Some PCI devices have large non-prefetchable memory. This is not a problem
+ for coldplug because firmware sets up such devices properly. But it may be
+ a problem for hotplug devices. To resolve this, new ``memReserve``
+ attribute is introduced which allows overriding value computed by firmware.
+
* **Improvements**
* Improve validation of USB devices
@@ -35,6 +42,11 @@ v10.3.0 (unreleased)
The ``checkpoint-list`` and ``snapshot-list`` commands would ignore the
``--name`` option to print only the name when used with ``--parent``.
+ * Extend libvirt-guests to shutdown only persistent VMs
+
+ Users can now chose to shutdown only persistent VMs when the host is being
+ shut down.
+
* **Bug fixes**
* qemu: Fix migration with custom XML
@@ -54,6 +66,16 @@ v10.3.0 (unreleased)
error: internal error: unable to execute QEMU command 'blockdev-add': Certificate does not match the hostname
+ * Create OVS ports as transient
+
+ Libvirt now creates OVS ports as transient which prevents them from
+ reappearing or going stale on sudden reboots.
+
+ * Clear OVS QoS settings when domain shuts down
+
+ Libvirt now clears QoS settings on domain shutdown, so they no longer pile
+ up in OVS database.
+
v10.2.0 (2024-04-02)
====================
--
2.43.2
1 year
- 4
- 4
Revisiting parallel save/restore
by Jim Fehlig
Hi All,
While Fabiano has been working on improving save/restore performance in qemu,
I've been tinkering with the same in libvirt. The end goal is to introduce a new
VIR_DOMAIN_SAVE_PARALLEL flag for save/restore, along with a
VIR_DOMAIN_SAVE_PARAM_PARALLEL_CONNECTIONS parameter to specify the number of
concurrent channels used for the save/restore. Recall Claudio previously posted
a patch series implementing parallel save/restore completely in libvirt, using
qemu's multifd functionality [1].
A good starting point on this journey is supporting the new mapped-ram
capability in qemu 9.0 [2]. Since mapped-ram is a new on-disk format, I assume
we'll need a new QEMU_SAVE_VERSION 3 when using it? Otherwise I'm not sure how
to detect if a saved image is in mapped-ram format vs the existing, sequential
stream format.
IIUC, mapped-ram cannot be used with the exiting 'fd:' migration URI and instead
must use 'file:'. Does qemu advertise support for that? I couldn't find it. If
not, 'file:' (available in qemu 8.2) predates mapped-ram, so in theory we could
live without the advertisement.
It's also not clear when we want to enable the mapped-ram capability. Should it
always be enabled if supported by the underlying qemu? One motivation for
creating the mapped-ram was to support direct-io of the migration stream in
qemu, in which case it could be tied to VIR_DOMAIN_SAVE_BYPASS_CACHE. E.g. the
mapped-ram capability is enabled when user specifies
VIR_DOMAIN_SAVE_BYPASS_CACHE && user-provided path results in a seekable fd &&
qemu supports mapped-ram?
Looking ahead, should the mapped-ram capability be required for supporting the
VIR_DOMAIN_SAVE_PARALLEL flag? As I understand, parallel save/restore was
another motivation for creating the mapped-ram feature. It allows multifd
threads to write exclusively to the offsets provided by mapped-ram. Can multiple
multifd threads concurrently write to an fd without mapped-ram?
Regards,
Jim
[1]
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3Y...
[2]
https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/m...
1 year
- 4
- 11