- Devel - libvirt List Archives

[libvirt PATCH] rpm: Drop rpcgen Build-Requires once again
by Andrea Bolognani 28 Nov '23

28 Nov '23

We no longer use it, so commit a62486b95fee correctly dropped the Build-Requires; shortly afterwards, however, I accidentally re-introduced it by mistake. Fixes: 3df8cc658ed0ac2f84089ad0db61ba20eb8b8aa7 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- libvirt.spec.in | 1 - 1 file changed, 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 361a34675b..f3fdedfde4 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -313,7 +313,6 @@ BuildRequires: libxml2 BuildRequires: libxslt BuildRequires: gettext BuildRequires: systemd-rpm-macros -BuildRequires: rpcgen # Fedora build root suckage BuildRequires: gawk %if %{with_native} -- 2.43.0

2 1

[PATCH 0/4] A bunch of trivial fixes
by Michal Privoznik 28 Nov '23

28 Nov '23

*** BLURB HERE *** Michal Prívozník (4): virpci: Decrease scope of VIR_PF_PHYS_PORT_NAME_REGEX macro qemu_command: Don't open code virPCIDeviceAddressAsString() vircpi: Decrease scope of VIR_PCI_DEVICE_ADDRESS_FMT macro ch: Don't leak ch_driver->chCaps src/ch/ch_driver.c | 5 +++-- src/qemu/qemu_command.c | 6 +----- src/util/virpci.c | 9 +++++++++ src/util/virpci.h | 7 ------- 4 files changed, 13 insertions(+), 14 deletions(-) -- 2.41.0

5 10

[Call for Presentations] FOSDEM 2024: Virt & IaaS Devroom
by Kashyap Chamarthy 28 Nov '23

28 Nov '23

[Cross-posted to KVM, Rust-VMM, QEMU, and libvirt lists) Hi, the CFP for the "Virt & IaaS" DevRoom is out[+]. Something new this year is a new talk-submission system: so you need to create a new account, even if you've had an account with the older talk-submission system. Details in the "Submit Your Proposal" section below. ======================================================================== We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2024, to be hosted on February 3rd 2024. 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 would like to invite all those who are involved in these fields to submit your proposals by December 8th, 2023. Important Dates --------------- Submission deadline: 8th December 2023 Acceptance notifications: 10th December 2023 Final schedule announcement: 15th December 2023 Devroom: 3rd February 2024 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 fill out all the required fields, and 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, 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[2]. 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://pretalx.fosdem.org/fosdem-2024/cfp [2] virtualization-devroom-manager at fosdem.org ======================================================================= [+] This email is a slightly formatted version of the official announce: https://lists.fosdem.org/pipermail/fosdem/2023q4/003481.html -- /kashyap

1 0

Re: [libvirt RFCv11 00/33] multifd save restore prototype
by Claudio Fontana 27 Nov '23

27 Nov '23

On 11/27/23 11:18, Daniel P. Berrangé wrote: > On Mon, Nov 27, 2023 at 10:43:58AM +0100, Claudio Fontana wrote: >> Hi all, >> >> I understand there has been some movement in this topic as the fixed-offset ram and multifd code evolves. >> >> I think I understood that now the idea is to pass from libvirt to QEMU two file descriptors, >> one for writing metadata, >> and a separate one for the actual memory pages, which is the one that can potentially be O_DIRECT. > > We determined that O_DIRECT changes propagate across dup'd file > descriptors, so we have only two choices > > * 1 FD, and QEMU has to take care to toggle O_DIRECT on/off > repeatedly depending on what phase it is in > * 2 FDs, one with and one without O_DIRECT > > Either is viable for libvirt. I have a mild preference for having > 1 FD, but not enough to call it a design blocker. So at the > discretion of whomever implements the QEMU part. > >> 1) I would assume that libvirt would then need to check if the user requested --parallel / --parallel-connections to enable QEMU multifd. > > Yes > >> 2) I would also assume that libvirt would check the presence of --bypass-cache as the condition to set O_DIRECT on the second (memory pages fd), and to enable QEMU "io-direct" feature. > > Yes > >> 3) I would tentatively suggest that when it comes to fixed-ram-offset, the condition to enable that one is a check like the one currently in libvirt: >> >> src/util/virfile.c::virFileDiskCopy() >> >> ie checking that we are writing to a seekable file that is not S_ISBLK . >> >> Does this match your understanding/reasoning? > > Both the io-direct and fixed-ram-offset features are dependent on > new QEMU impls, so there is a mild backwards compatibility concern. > > ie, lets say if we are running QEMU 9.0.0, but with old machine > type pc-i440fx-8.0.0, and we save the state, but want to then > restore with QEMU 8.2.0. > > Essentially we must NOT use io-direct/fixed-ram-offset if we > want the ability to migrate to older QEMU. At the same time I > would like us to be able to take advantage of this new QEMU > support to the greatest extent possible, even if not doing the > --parallel stuff which was the original motivator. > > Thus, we need some way to decide whether to use the new or the > old on disk format. > > I wonder if having a setting in '/etc/libvirt/qemu.conf' is > sufficient, or whether we must expose a flag via the API. > > With regards, > Daniel Thanks Daniel, that's an interesting point. The new fixed-ram-offset format is a QEMU format, and as such I presume that in theory there is a qemu_saveimage.h:#define QEMU_SAVE_VERSION 2 that could be bumped to 3 if this new format is used? But then again, libvirt would need to decide whether to save in "old QEMU compatibility mode" or in the new QEMU_SAVE_VERSION 3 mode that allows for fixed-ram-offset. Maybe a new libvirt option for controlling which QEMU_SAVE_VERSION format to use for the save, with the default being v2 for backward compatibility reasons? Thanks, Claudio

2 2

Re: [kubevirt-dev] ANNOUNCE: Virtualization linting library
by Michal Prívozník 27 Nov '23

27 Nov '23

[Following move of libvir-list to new location] On 11/15/23 09:26, Dan Kenigsberg wrote: > Thanks, Michal, for this overture. I think libvirt and its people have a > lot of knowledge about working-yet-not-recommended configurations that > can be beneficial to higher-level management systems such as KubeVirt. Indeed. But writing checks for such configurations should be trivial enough, now that they can be written in Lua. But individual checks are technicality, those can and will be extended once we know current (API) design works for KubeVirt. > > How do you envisage it to be used by KubeVirt? > > Do you think virt-launcher can call it before it is calling > virCreateXML()? If so, would it make sense to bubble up its warnings as > VM.status conditions? Yes, that's my idea. Once KubeVirt constructed domain XML, it can feed it to virt-lint tool. From that it'll receive bunch of warnings (or none if domain XML is okay) which could be then forwarded to the UI for users to resolve. Or ignore and continue starting up the guest (for instance, one of currently implemented checks is for enough of free PCIe root ports for future hotplug - it's up to user to tell if they will ever want hotplug). > > BTW, I think it may be valuable to add a machine-accessible code for > each warning, on top of the English language text. Good point. That way we can save user's preference on ignoring some warnings. Or have KubeVirt fix some of the warnings automagically. Anyway, my knowledge of KubeVirt internals is not intimate enough to even attempt to integrate this. If anybody from KubeVirt developers is willing to offer a helping hand, I'd appreciate it. Michal

1 0

[PATCH v2 0/3] Introduce pipewire audio backend
by Michal Privoznik 24 Nov '23

24 Nov '23

v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4M7O… diff to v1: - Introduced 'runtimeDir' attribute to <audio/> so that users do not have use <qemu:env/> hack to set PIPEWIRE_RUNTIME_DIR. - Worked in the rest of Peter's review suggestions. Michal Prívozník (3): conf: Introduce pipewire audio backend qemu: Generate cmd line for pipewire audio backend NEWS: Document pipewire audio backend NEWS.rst | 5 ++ docs/formatdomain.rst | 46 +++++++++++- src/conf/domain_conf.c | 73 +++++++++++++++++++ src/conf/domain_conf.h | 13 ++++ src/conf/schemas/domaincommon.rng | 42 +++++++++++ src/qemu/qemu_command.c | 71 ++++++++++++++++++ src/qemu/qemu_validate.c | 1 + .../audio-many-backends.x86_64-latest.args | 2 + .../qemuxml2argvdata/audio-many-backends.xml | 1 + .../audio-pipewire-best.x86_64-latest.args | 36 +++++++++ .../qemuxml2argvdata/audio-pipewire-best.xml | 43 +++++++++++ .../audio-pipewire-full.x86_64-latest.args | 36 +++++++++ .../qemuxml2argvdata/audio-pipewire-full.xml | 43 +++++++++++ .../audio-pipewire-minimal.x86_64-latest.args | 36 +++++++++ .../audio-pipewire-minimal.xml | 36 +++++++++ tests/qemuxml2argvtest.c | 10 +++ .../audio-many-backends.x86_64-latest.xml | 1 + .../audio-pipewire-best.x86_64-latest.xml | 46 ++++++++++++ .../audio-pipewire-full.x86_64-latest.xml | 46 ++++++++++++ .../audio-pipewire-minimal.x86_64-latest.xml | 39 ++++++++++ tests/qemuxml2xmltest.c | 3 + 21 files changed, 627 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/audio-pipewire-best.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/audio-pipewire-best.xml create mode 100644 tests/qemuxml2argvdata/audio-pipewire-full.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/audio-pipewire-full.xml create mode 100644 tests/qemuxml2argvdata/audio-pipewire-minimal.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/audio-pipewire-minimal.xml create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-best.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-full.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-minimal.x86_64-latest.xml -- 2.41.0

2 5

[PATCH 00/17] qemu: Prepare block device setup for removing the 'raw' driver ('raw' driver removal part 3)
by Peter Krempa 24 Nov '23

24 Nov '23

This series prepares the setup of the block device backend for removal of the raw driver from the block graph, and actually removes it from the migration NBD connection. Unfortunately for normal usage it's not yet possible as qemu then records the protocol driver name in the backing file format field which would break with older versions of libvirt (see my other series). Peter Krempa (17): qemu: block: Introduce qemuBlockStorageSourceGetSliceNodename qemu: block: Use qemuBlockStorageSourceNeedsStorageSliceLayer only for setup qemu: block: Introduce helper for deciding when a 'format' layer is needed qemuBlockStorageSourceGetBlockdevStorageSliceProps: Allow turning the slice layer into effective blockdev layer qemuBlockStorageSourceAttachPrepareBlockdev: Prepare for optionally missing format layer qemuBlockStorageSourceDetachPrepare: Prepare for possibly missing 'format' layer qemuDomainPrepareStorageSourceBlockdevNodename: Restructure code to allow missing 'format' layer qemuBlockStorageSourceGetEffectiveNodename: Prepare for missing 'format' driver qemu: block: Extract logic from qemuBlockReopenReadWrite/ReadOnly qemu: block: Absorb logic from qemuBlockReopenFormat to qemuBlockReopenAccess qemu: monitor: Sanitize arguments of qemuMonitorBlockdevReopen testQemuMonitorJSONBlockdevReopen: Don't use qemuBlockReopenFormatMon qemu: block: Absorb qemuBlockReopenFormatMon into qemuBlockReopenAccess qemuBlockReopenAccess: prepare for removal of 'raw' format layer qemuMigrationSrcNBDCopyCancel: Use qemuBlockStorageSourceAttachRollback to detach migration NBD blockdevs qemu: block: Remove unused qemuBlockStorageSourceDetachOneBlockdev qemuMigrationSrcNBDStorageCopyBlockdevPrepareSource: Don't setup 'raw' layer for migration NBD connection src/qemu/qemu_block.c | 257 ++++++++++++++++++----------------- src/qemu/qemu_block.h | 16 +-- src/qemu/qemu_domain.c | 17 ++- src/qemu/qemu_migration.c | 19 ++- src/qemu/qemu_monitor.c | 7 +- src/qemu/qemu_monitor.h | 2 +- src/qemu/qemu_monitor_json.c | 6 +- src/qemu/qemu_monitor_json.h | 2 +- tests/qemumonitorjsontest.c | 10 +- 9 files changed, 185 insertions(+), 151 deletions(-) -- 2.42.0

2 21

[PATCH 0/7] storage_file_probe: Handle qcow2 images with 'protocol' driver name in 'backing file format' field (part 1 - the fix)
by Peter Krempa 24 Nov '23

24 Nov '23

See 6/7 and 7/7 for the rationale. Further patches will be posted to refactor the rest of the parsers which are bitrotten. Peter Krempa (7): storage_file_probe: Remove unused state 'BACKING_STORE_ERROR' virStorageFileProbeGetMetadata: Do not partially skip probing of the image storage_file_probe: Remove BACKING_STORE_OK,BACKING_STORE_INVALID states virstoragetest: Use strings for storage type and format in output data virstoragetest: Format detected/unprocessed backing store format into output files virstoragetest: Add test cases for QCOW2 files with a protocol name as backing file format storage_file_probe: Treat qcow2 images with protocol drivers in backing store field as raw src/storage_file/storage_file_probe.c | 71 ++++++++---------- tests/virstoragetest.c | 19 ++++- .../images/qcow2-protocol-backing-file.qcow2 | Bin 0 -> 196616 bytes .../images/qcow2-protocol-backing-nbd.qcow2 | Bin 0 -> 196616 bytes tests/virstoragetestdata/out/directory-dir | 5 +- tests/virstoragetestdata/out/directory-none | 5 +- tests/virstoragetestdata/out/directory-raw | 5 +- .../out/qcow2-auto_qcow2-qcow2_raw-raw | 5 +- .../out/qcow2-auto_raw-raw-relative | 5 +- .../out/qcow2-protocol-backing-file | 21 ++++++ .../out/qcow2-protocol-backing-nbd | 21 ++++++ .../out/qcow2-qcow2_nbd-raw | 10 ++- .../out/qcow2-qcow2_qcow2-auto | 10 ++- .../out/qcow2-qcow2_qcow2-qcow2_qcow2-auto | 15 ++-- .../out/qcow2-qcow2_qcow2-qcow2_raw-auto | 15 ++-- .../out/qcow2-qcow2_qcow2-qcow2_raw-raw | 15 ++-- .../out/qcow2-qcow2_raw-raw-relative | 10 ++- tests/virstoragetestdata/out/qcow2-symlinks | 15 ++-- tests/virstoragetestdata/out/qed-auto_raw | 5 +- tests/virstoragetestdata/out/qed-qed_raw | 10 ++- tests/virstoragetestdata/out/raw-auto | 5 +- tests/virstoragetestdata/out/raw-raw | 5 +- 22 files changed, 173 insertions(+), 99 deletions(-) create mode 100644 tests/virstoragetestdata/images/qcow2-protocol-backing-file.qcow2 create mode 100644 tests/virstoragetestdata/images/qcow2-protocol-backing-nbd.qcow2 create mode 100644 tests/virstoragetestdata/out/qcow2-protocol-backing-file create mode 100644 tests/virstoragetestdata/out/qcow2-protocol-backing-nbd -- 2.42.0

2 9

[PATCH 0/2] qemu: block fixes
by Peter Krempa 24 Nov '23

24 Nov '23

Few issues I've found while testing the block layer for an upcoming patchset. Peter Krempa (2): qemu: hotplug: Detect disk backing images before setting up security access qemu: block: Don't try to merge bitmaps into 'raw' images src/qemu/qemu_block.c | 10 ++++++++++ src/qemu/qemu_hotplug.c | 10 +++++----- 2 files changed, 15 insertions(+), 5 deletions(-) -- 2.42.0

2 4

[PATCH] virnuma: Avoid integer overflow in virNumaGetPages()
by Michal Privoznik 24 Nov '23

24 Nov '23

On systems with humongous pages (16GiB) and 32bit int it's easy to hit integer overflow in virNumaGetPages(). What happens is, inside of virNumaGetPages() as we process hugepages for given NUMA node (e.g. in order to produce capabilities XML), we keep a sum of sizes of pools in an ULL variable (huge_page_sum). In each iteration, the variable is incremented by 1024 * page_size * page_avail. Now, page_size is just an uint, so we have: ULL += U * U * ULL; and because of associativity, U * U is computed first and since we have two operands of the same type, no type expansion happens. But this means, for humongous pages (like 16GiB) the multiplication overflows. Therefore, move the multiplication out of the loop. This helps in two ways: 1) now we have ULL += U * ULL; which expands the uint in multiplication, 2) it saves couple of CPU cycles. Resolves: https://issues.redhat.com/browse/RHEL-16749 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virnuma.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/util/virnuma.c b/src/util/virnuma.c index 5053a70c61..9393c20875 100644 --- a/src/util/virnuma.c +++ b/src/util/virnuma.c @@ -787,9 +787,7 @@ virNumaGetPages(int node, tmp_free[ntmp] = page_free; ntmp++; - /* page_size is in kibibytes while we want huge_page_sum - * in just bytes. */ - huge_page_sum += 1024 * page_size * page_avail; + huge_page_sum += page_size * page_avail; } if (direrr < 0) @@ -800,6 +798,9 @@ virNumaGetPages(int node, VIR_REALLOC_N(tmp_avail, ntmp + 1); VIR_REALLOC_N(tmp_free, ntmp + 1); + /* page_size is in kibibytes while we want huge_page_sum in just bytes. */ + huge_page_sum *= 1024; + if (virNumaGetPageInfo(node, system_page_size, huge_page_sum, &tmp_avail[ntmp], &tmp_free[ntmp]) < 0) return -1; -- 2.41.0

2 1