- Devel - libvirt List Archives

Re: [PATCH RFC v4 11/17] qemu: block: Support block disk along with throttle filters
by Peter Krempa 04 Nov '24

04 Nov '24

On Mon, Nov 04, 2024 at 12:39:24 +0000, Edward Arulanadam wrote: > Hello Team, > > Originator of this libvirt change, Daniel Wu, will not be able to continue contributing to this requested change in libvirt. Another member in our team, Harikumar (harirajkumar), will continue working on this change request and implement any review comment that may come in. We are awaiting feedback review to get this change incorporated in libvirt and adopted in our Cloud solution. > > Could you please help with the review I think at this point the best course of actions will be if Harikumar adopts the patches, rebases them to the current tree as they no longer apply cleanly and posts another version. That way a discussion will be more natural and also it's less likely that any replies will break threads (as e.g. your email does). [1] https://www.libvirt.org/hacking.html#preparing-patches

1 0

[PATCH] spec: Fix attributes for some qemu dirs in %{_rundir}
by Jiri Denemark 04 Nov '24

04 Nov '24

The recent attempt to fix the attributes used wrong mode for some directories used by the QEMU driver. Only dbus and swtpm directories use 770, all other directories are created with 755. Fixes: 961fb8944d0c2d7d5cc0783888a20317e725a248 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 69693f4851..901ed9c464 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -2275,10 +2275,10 @@ exit 0 %config(noreplace) %{_sysconfdir}/libvirt/qemu.conf %config(noreplace) %{_sysconfdir}/libvirt/qemu-lockd.conf %config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd.qemu -%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/ +%ghost %dir %attr(0755, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/ %ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/dbus/ -%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/passt/ -%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/slirp/ +%ghost %dir %attr(0755, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/passt/ +%ghost %dir %attr(0755, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/slirp/ %ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/swtpm/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/checkpoint/ -- 2.47.0

2 1

Re: [PATCH RFC v4 11/17] qemu: block: Support block disk along with throttle filters
by Edward Arulanadam 04 Nov '24

04 Nov '24

Hello Team, Originator of this libvirt change, Daniel Wu, will not be able to continue contributing to this requested change in libvirt. Another member in our team, Harikumar (harirajkumar), will continue working on this change request and implement any review comment that may come in. We are awaiting feedback review to get this change incorporated in libvirt and adopted in our Cloud solution. Could you please help with the review Thanks and Regards, Edward Arulanandam Senior Development Manager, IBM Cloud Storage

1 0

[libvirt PATCH] json: do not call json_tokener_free with NULL
by Ján Tomko 04 Nov '24

04 Nov '24

Add an error message for the rare case if json_tokener_new fails (allocation failure) and guard any use of json_tokener_free where tok might be NULL (this was possible in libvirt-nss when the json file could not be opened). https://gitlab.com/libvirt/libvirt/-/issues/581 Signed-off-by: Ján Tomko <jtomko(a)redhat.com> Reported-by: Simon Pilkington --- src/util/virjson.c | 8 +++++++- tools/nss/libvirt_nss_leases.c | 7 ++++++- tools/nss/libvirt_nss_macs.c | 7 ++++++- 3 files changed, 19 insertions(+), 3 deletions(-) diff --git a/src/util/virjson.c b/src/util/virjson.c index 4a95e84f5b..18a4585e7b 100644 --- a/src/util/virjson.c +++ b/src/util/virjson.c @@ -1462,6 +1462,11 @@ virJSONValueFromString(const char *jsonstring) VIR_DEBUG("string=%s", jsonstring); tok = json_tokener_new(); + if (!tok) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("failed to create JSON tokener")); + return NULL; + } json_tokener_set_flags(tok, jsonflags); jobj = json_tokener_parse_ex(tok, jsonstring, strlen(jsonstring)); jerr = json_tokener_get_error(tok); @@ -1475,7 +1480,8 @@ virJSONValueFromString(const char *jsonstring) cleanup: json_object_put(jobj); - json_tokener_free(tok); + if (tok) + json_tokener_free(tok); return ret; } diff --git a/tools/nss/libvirt_nss_leases.c b/tools/nss/libvirt_nss_leases.c index 01e965c4a1..aea81bb56e 100644 --- a/tools/nss/libvirt_nss_leases.c +++ b/tools/nss/libvirt_nss_leases.c @@ -272,6 +272,10 @@ findLeases(const char *file, } tok = json_tokener_new(); + if (!tok) { + ERROR("failed to create JSON tokener"); + goto cleanup; + } json_tokener_set_flags(tok, jsonflags); do { @@ -301,7 +305,8 @@ findLeases(const char *file, cleanup: json_object_put(jobj); - json_tokener_free(tok); + if (tok) + json_tokener_free(tok); if (ret != 0) { free(*addrs); *addrs = NULL; diff --git a/tools/nss/libvirt_nss_macs.c b/tools/nss/libvirt_nss_macs.c index 430023abec..23229a18f3 100644 --- a/tools/nss/libvirt_nss_macs.c +++ b/tools/nss/libvirt_nss_macs.c @@ -134,6 +134,10 @@ findMACs(const char *file, } tok = json_tokener_new(); + if (!tok) { + ERROR("failed to create JSON tokener"); + goto cleanup; + } json_tokener_set_flags(tok, jsonflags); do { @@ -162,7 +166,8 @@ findMACs(const char *file, cleanup: json_object_put(jobj); - json_tokener_free(tok); + if (tok) + json_tokener_free(tok); if (ret != 0) { for (i = 0; i < *nmacs; i++) { char *mac = (*macs)[i]; -- 2.47.0

3 2

Release of libvirt-10.9.0
by Jiri Denemark 01 Nov '24

01 Nov '24

The 10.9.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: zero block detection for non-shared-storage migration Users can now request that all-zero blocks are not transferred when migrating non-shared disk data without actually enabling zero detection on the disk itself. This allows sparsifying images during migration where the source has no access to the allocation state of blocks at the cost of CPU overhead. This feature is available via the ``--migrate-disks-detect-zeroes`` option for ``virsh migrate`` or ``VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES`` migration parameter. See the documentation for caveats. * Improvements * qemu: internal snapshot improvements The qemu internal snapshot handling code was updated to use modern commands which avoid the problems the old ones had, preventing use of internal snapshots on VMs with UEFI NVRAM. Internal snapshots of VMs using UEFI are now possible provided that the NVRAM is in ``qcow2`` format. The new code also allows better control when deleting snapshots. To prevent possible regressions no strict checking is done, but in case inconsistent state is encountered a log message is added:: warning : qemuSnapshotActiveInternalDeleteGetDevices:3841 : inconsistent internal snapshot state (deletion): VM='snap' snapshot='1727959843' missing='vda ' unexpected='' extra='' Users are encouraged to report any occurence of the above message along with steps they took to the upstream tracker. * qemu: improve documentation of image format settings The documentation of the various ``*_image_format`` settings in ``qemu.conf`` imply they can only be used to control compression of the image. The documentation has been improved to clarify the settings describe the representation of guest memory blocks on disk, which includes compression among other possible layouts. * Report CPU model blockers in domain capabilities When a CPU model is reported as usable='no' an additional ``<blockers model='...'>`` element is added for that CPU model listing features required by the CPU model, but not supported on the host. Enjoy. Jirka

1 0

[PATCH] qemu: Fix maximum physical address size in baseline CPU
by Jiri Denemark 31 Oct '24

31 Oct '24

We should include maximum physical address size in the CPU definition created by virConnectBaselineHypervisorCPU only if we know the value for all input CPUs. Otherwise we would create a CPU definition that is not usable on all hosts from which we gathered the CPU info. https://issues.redhat.com/browse/RHEL-24850 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_driver.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 72211da137..72a9542c0b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -11914,10 +11914,12 @@ qemuConnectBaselineHypervisorCPU(virConnectPtr conn, goto cleanup; for (i = 0; i < ncpus; i++) { - if (!cpus[i]->addr || cpus[i]->addr->limit == 0) + if (!cpus[i]->addr || cpus[i]->addr->limit == 0) { + physAddrSize = 0; continue; + } - if (physAddrSize == 0 || cpus[i]->addr->limit < physAddrSize) + if (i == 0 || cpus[i]->addr->limit < physAddrSize) physAddrSize = cpus[i]->addr->limit; } -- 2.47.0

2 1

[Call for Presentations] FOSDEM 2025: Virt & IaaS devroom
by Kashyap Chamarthy 31 Oct '24

31 Oct '24

(Cross-posted to KVM, Rust-VMM, QEMU, and libvirt lists.) Hi, The CFP for the 'Virt & IaaS' (Infrastructure as a Service) 2025 "devroom" is out[+]. - Where? — Brussels, Belgium - When? — 02 Feb (Sunday) 2025 - Talk submission deadline — 01 Dec 2024 (The CFP submission on the FOSDEM list[+] says 08 Dec 2024 is the submission deadline in its intro paragraph. But I clarified it with Piotr Kliczewski, the deddline is *01* Dec 2024 and _not_ 08th Dec; I updated it below.) ======================================================================== This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by December *1st* 2024. Important Dates --------------- Submission deadline: 1st December 2024 Acceptance notifications: 10th December 2024 Final schedule announcement: 15th December 2024 Devroom: 2nd February 2025 About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal -------------------- All submissions must be made via the Pretalx event planning site[1]. It is a new submission system so you will need to create an account. If you submitted proposals for FOSDEM in previous years, you won’t be able to use your existing account. During submission please make sure to select Virtualization and Cloud infrastructure from the Track list. Please provide a meaningful abstract and description of your proposed session. Submission Guidelines --------------------- We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct --------------- Following the release of the updated code of conduct for FOSDEM[3], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://fosdem.org/submit [2] virtualization-devroom-manager at fosdem.org [3] https://fosdem.org/2025/practical/conduct/ ======================================================================== [+] https://lists.fosdem.org/pipermail/fosdem/2024q4/003574.html -- /kashyap

1 0

[PATCH] spec: Fix attributes for ghosts directories in %{_rundir}
by Jiri Denemark 31 Oct '24

31 Oct '24

Directories which we dynamically create in %{_rundir} with non-default attributes (i.e., the owner differs from root:root and/or mode is not 755) fail RPM verification. We should properly declare the expected ownership and mode in the specfile. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index d54d2a1e3e..69693f4851 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -2038,7 +2038,7 @@ exit 0 %config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf %dir %{_datadir}/libvirt/ %ghost %dir %{_rundir}/libvirt/ -%ghost %dir %{_rundir}/libvirt/common/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/common/ %dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/filesystems/ @@ -2124,7 +2124,7 @@ exit 0 %{_unitdir}/virtinterfaced-ro.socket %{_unitdir}/virtinterfaced-admin.socket %attr(0755, root, root) %{_sbindir}/virtinterfaced -%ghost %dir %{_rundir}/libvirt/interface/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/interface/ %{_libdir}/libvirt/connection-driver/libvirt_driver_interface.so %{_mandir}/man8/virtinterfaced.8* @@ -2166,7 +2166,7 @@ exit 0 %{_unitdir}/virtnodedevd-ro.socket %{_unitdir}/virtnodedevd-admin.socket %attr(0755, root, root) %{_sbindir}/virtnodedevd -%ghost %dir %{_rundir}/libvirt/nodedev/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/nodedev/ %{_libdir}/libvirt/connection-driver/libvirt_driver_nodedev.so %{_mandir}/man8/virtnodedevd.8* @@ -2181,8 +2181,8 @@ exit 0 %attr(0755, root, root) %{_sbindir}/virtnwfilterd %dir %attr(0700, root, root) %{_sysconfdir}/libvirt/nwfilter/ %ghost %dir %{_rundir}/libvirt/network/ -%ghost %dir %{_rundir}/libvirt/nwfilter-binding/ -%ghost %dir %{_rundir}/libvirt/nwfilter/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/nwfilter-binding/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/nwfilter/ %{_libdir}/libvirt/connection-driver/libvirt_driver_nwfilter.so %{_mandir}/man8/virtnwfilterd.8* @@ -2196,7 +2196,7 @@ exit 0 %{_unitdir}/virtsecretd-admin.socket %attr(0755, root, root) %{_sbindir}/virtsecretd %dir %attr(0700, root, root) %{_sysconfdir}/libvirt/secrets/ -%ghost %dir %{_rundir}/libvirt/secrets/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/secrets/ %{_libdir}/libvirt/connection-driver/libvirt_driver_secret.so %{_mandir}/man8/virtsecretd.8* @@ -2275,11 +2275,11 @@ exit 0 %config(noreplace) %{_sysconfdir}/libvirt/qemu.conf %config(noreplace) %{_sysconfdir}/libvirt/qemu-lockd.conf %config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd.qemu -%ghost %dir %{_rundir}/libvirt/qemu/ -%ghost %dir %{_rundir}/libvirt/qemu/dbus/ -%ghost %dir %{_rundir}/libvirt/qemu/passt/ -%ghost %dir %{_rundir}/libvirt/qemu/slirp/ -%ghost %dir %{_rundir}/libvirt/qemu/swtpm/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/dbus/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/passt/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/slirp/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/swtpm/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/checkpoint/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/dump/ -- 2.47.0

2 1

Entering freeze for libvirt-10.9.0
by Jiri Denemark 30 Oct '24

30 Oct '24

I have just tagged v10.9.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

1 1

[PATCH] docs: domain: Be more upfront about 'sgio' not being actually supported
by Peter Krempa 30 Oct '24

30 Oct '24

The support for the 'sgio' attribute for SCSI-backed devices was dropped as there wasn't really ever any upstream support for it. The docs do state that support for this depends on the hypervisor itself, but we can be more clear that there is no hypervisor which does support it. There is also a suggestion to use 'sgio' instead of 'rawio' as being more "secure" but since it no longer works drop this suggestion. Resolves: https://issues.redhat.com/browse/RHEL-65268 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatdomain.rst | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 3253a28e5a..d16e00661a 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2767,14 +2767,13 @@ paravirtualized driver is specified via the ``disk`` element. per-process basis). This attribute is only valid when device is "lun". NB, ``rawio`` intends to confine the capability per-device, however, current QEMU implementation gives the domain process broader capability than that - (per-process basis, affects all the domain disks). To confine the - capability as much as possible for QEMU driver as this stage, ``sgio`` is - recommended, it's more secure than ``rawio``. :since:`Since 0.9.10` + (per-process basis, affects all the domain disks). :since:`Since 0.9.10` ``sgio`` If supported by the hypervisor and OS, indicates whether unprivileged SG_IO commands are filtered for the disk. Valid settings are "filtered" or "unfiltered" where the default is "filtered". Only available when the - ``device`` is 'lun'. :since:`Since 1.0.2` + ``device`` is 'lun'. The attribute exists :since:`Since 1.0.2`, although + currently it's no longer supported by any hypervisor. ``snapshot`` Indicates the default behavior of the disk during disk snapshots: ``internal`` requires a file format such as qcow2 that can store both @@ -4346,7 +4345,7 @@ or: ... <devices> - <hostdev mode='subsystem' type='scsi' sgio='filtered' rawio='yes'> + <hostdev mode='subsystem' type='scsi' rawio='yes'> <source> <adapter name='scsi_host0'/> <address bus='0' target='0' unit='0'/> @@ -4436,14 +4435,19 @@ or: ``display`` attribute to be set to ``on``. ``scsi`` For SCSI devices, user is responsible to make sure the device is not used - by host. If supported by the hypervisor and OS, the optional ``sgio`` ( - :since:`since 1.0.6` ) attribute indicates whether unprivileged SG_IO - commands are filtered for the disk. Valid settings are "filtered" or - "unfiltered", where the default is "filtered". The optional ``rawio`` ( - :since:`since 1.2.9` ) attribute indicates whether the lun needs the rawio - capability. Valid settings are "yes" or "no". See the rawio description - within the `Hard drives, floppy disks, CDROMs`_ section. If a disk lun in the domain - already has the rawio capability, then this setting not required. + by host. + + If supported by the hypervisor and OS, the optional ``sgio`` ( + :since:`since 1.0.6`, but currently no longer supported by any hypervisor + driver ) attribute indicates whether unprivileged SG_IO commands are + filtered for the disk. Valid settings are "filtered" or + "unfiltered", where the default is "filtered". + + The optional ``rawio`` (:since:`since 1.2.9` ) attribute indicates whether + the lun needs the rawio capability. Valid settings are "yes" or "no". + See the rawio description within the `Hard drives, floppy disks, CDROMs`_ + section. If a disk lun in the domain already has the rawio capability, + then this setting not required. ``scsi_host`` :since:`since 2.5.0` For SCSI devices, user is responsible to make sure the device is not used by host. This ``type`` passes all LUNs presented by -- 2.47.0

2 1