- Devel - libvirt List Archives

[PATCH 0/3] ci: massively cut down the build log sizes
by Daniel P. Berrangé 17 Jan '26

17 Jan '26

The build logs for the Fedora jobs in gitlab CI are all getting truncated with a message: [1278/1650] gcc -o te Job's log exceeded limit of 4194304 bytes. Job execution will continue but no more output will be collected. when we're only 3/4 of the way through the build process this is massively unhelpful if something fails at the end...like unit tests. Removing some -D flags and cutting down logs from the package install phase remove about 1 MB of log file output. Moving -W flags off the compiler command line, to a separate file, removes about another 2 MB of log file output. IOW, the overall log drops from 5.7 MB to 2.7 MB and are thus fully captured by gitlab. Patch 3 depends on: https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/563 Daniel P. Berrangé (3): src: remove some -D defines from compiler args meson: write all warning flags to 'c-warnings.txt' ci: regenerate with 'lcitool manifest' ci/buildenv/almalinux-10.sh | 142 +++++++++-------- ci/buildenv/almalinux-9.sh | 144 ++++++++--------- ci/buildenv/centos-stream-10.sh | 138 ++++++++-------- ci/buildenv/centos-stream-9.sh | 144 ++++++++--------- ci/buildenv/fedora-42.sh | 142 ++++++++--------- ci/buildenv/fedora-43-cross-mingw32.sh | 94 +++++------ ci/buildenv/fedora-43-cross-mingw64.sh | 94 +++++------ ci/buildenv/fedora-43.sh | 142 ++++++++--------- ci/buildenv/fedora-rawhide-cross-mingw32.sh | 96 +++++------ ci/buildenv/fedora-rawhide-cross-mingw64.sh | 96 +++++------ ci/buildenv/fedora-rawhide.sh | 144 ++++++++--------- ci/containers/almalinux-10.Dockerfile | 146 ++++++++--------- ci/containers/almalinux-9.Dockerfile | 148 ++++++++--------- ci/containers/centos-stream-10.Dockerfile | 142 ++++++++--------- ci/containers/centos-stream-9.Dockerfile | 148 ++++++++--------- ci/containers/fedora-42.Dockerfile | 148 ++++++++--------- .../fedora-43-cross-mingw32.Dockerfile | 102 ++++++------ .../fedora-43-cross-mingw64.Dockerfile | 102 ++++++------ ci/containers/fedora-43.Dockerfile | 148 ++++++++--------- .../fedora-rawhide-cross-mingw32.Dockerfile | 104 ++++++------ .../fedora-rawhide-cross-mingw64.Dockerfile | 104 ++++++------ ci/containers/fedora-rawhide.Dockerfile | 150 +++++++++--------- ci/gitlab/build-templates.yml | 6 +- meson.build | 114 ++++++------- scripts/meson-warnings.py | 9 ++ src/internal.h | 2 + src/meson.build | 6 +- src/remote/remote_protocol.x | 1 + 28 files changed, 1490 insertions(+), 1466 deletions(-) create mode 100644 scripts/meson-warnings.py -- 2.52.0

2 5

[PATCH] Align help text of virt-aa-helper with actual expectated input
by Erik Huelsmann 16 Jan '26

16 Jan '26

When virt-aa-helper is invoked with a -u parameter followed by an actual UUID as suggested by the help text, it throws an 'invalid UUID' error, even when the UUID is the UUID of an existing VM. With this adjustment of the help text, there's a better chance of users providing the correct input. Signed-off-by: Erik Huelsmann <ehuels(a)gmail.com> --- src/security/virt-aa-helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index de0a826063..3f8dec98cc 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -105,7 +105,7 @@ vah_usage(void) " -R | --remove unload profile\n" " Options:\n" " -d | --dryrun dry run\n" - " -u | --uuid <uuid> uuid (profile name)\n" + " -u | --uuid libvirt-<uuid> AppArmor profile name\n" " -h | --help this help\n" " Extra File:\n" " -f | --add-file <file> add file to a profile generated from XML\n" -- 2.43.0

2 2

[PATCH 00/29] qemu: Implement support for uefi-vars device and firmwares
by Andrea Bolognani 16 Jan '26

16 Jan '26

This series makes it possible to use Secure Boot with aarch64 VMs. https://issues.redhat.com/browse/RHEL-82645 It needs a prerequisite series[1] to be applied first. Note that, while I consider the entire series to be ready for review, there are two patches that are marked as DONOTMERGE: that's because they respectively implement support for a JSON firmware descriptor syntax extension that has not yet been approved, and import into the tree firmware descriptor that are not yet part of the Fedora edk2 package. The latter depends on the former, of course, for which patches have been posted[2] to the QEMU mailing list. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/N2ET… [2] https://mail.gnu.org/archive/html/qemu-devel/2025-12/msg03462.html Andrea Bolognani (29): schemas: Drop pflashFormat schemas: Introduce firmware(Loader|Nvram)Formats schemas: Allow JSON format for NVRAM conf: Introduce VIR_STORAGE_FILE_JSON conf: Allow JSON format for NVRAM in the parser qemu_firmware: Rename qemuFirmwareFlashFile to qemuFirmwareFile qemu_firmware: Use qemuFirmwareFile in qemuFirmwareMappingMemory DONOTMERGE: qemu_firmware: Support extended syntax for ROM firmware descriptors qemu_firmware: Report NVRAM template path for ROMs qemu_firmware: Fill in more information for ROMs qemu_firmware: Don't skip EnsureNVRAM() for ROMs qemu_firmware: Parse host-uefi-vars firmware feature qemu_firmware: Split sanity check qemu_firmware: Consider host-uefi-vars feature in sanity check tests: Add firmware-manual-efi-qemuvars-q35 tests: Add firmware-manual-efi-qemuvars-aarch64 tests: Add firmware-manual-efi-qemuvars-nvram-network-nbd tests: Add firmware-auto-efi-enrolled-keys-aarch64 tests: Add firmware-auto-efi-format-nvram-json qemu_capabilities: Introduce QEMU_CAPS_DEVICE_UEFI_VARS qemu: Validate presence of uefi-vars device qemu: Don't allow remote locations for JSON format NVRAM qemu_firmware: Generate correct name for JSON format NVRAM qemu_firmware: Update matching logic for ROMs qemu_firmware: Require host-uefi-vars feature for JSON NVRAM qemu_firmware: Allow JSON format for NVRAM DONOTMERGE: tests: Add firmware descriptors for uefi-vars builds qemu_command: Use uefi-vars device where appropriate news: Document support for uefi-vars device and firmwares NEWS.rst | 10 + src/conf/domain_conf.c | 6 +- src/conf/schemas/domaincommon.rng | 22 +- src/conf/storage_source_conf.c | 2 +- src/conf/storage_source_conf.h | 1 + src/qemu/qemu_block.c | 2 + src/qemu/qemu_capabilities.c | 3 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 36 ++ src/qemu/qemu_firmware.c | 353 +++++++++++++++--- src/qemu/qemu_validate.c | 13 + .../caps_10.0.0_aarch64.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../caps_10.1.0_s390x.xml | 1 + .../caps_10.1.0_x86_64+inteltdx.xml | 1 + .../caps_10.1.0_x86_64.xml | 1 + .../caps_10.2.0_x86_64+mshv.xml | 1 + .../caps_10.2.0_x86_64.xml | 1 + ...tdx.json => 50-edk2-ovmf-x64-microvm.json} | 12 +- .../firmware/60-edk2-ovmf-x64-inteltdx.json | 6 +- .../out/usr/share/qemu/firmware/91-bios.json | 33 ++ ...70-edk2-ovmf-qemuvars-x64-sb-enrolled.json | 35 ++ .../70-edk2-qemuvars-aarch64-sb-enrolled.json | 33 ++ tests/qemufirmwaretest.c | 10 +- ...ware-auto-bios-stateless.x86_64-latest.xml | 2 +- .../firmware-auto-bios.x86_64-latest.xml | 2 +- ...fi-enrolled-keys-aarch64.aarch64-8.2.0.err | 1 + ...-enrolled-keys-aarch64.aarch64-latest.args | 32 ++ ...i-enrolled-keys-aarch64.aarch64-latest.xml | 32 ++ ...irmware-auto-efi-enrolled-keys-aarch64.xml | 20 + ...uto-efi-format-nvram-json.x86_64-8.2.0.err | 1 + ...o-efi-format-nvram-json.x86_64-latest.args | 35 ++ ...o-efi-format-nvram-json.x86_64-latest.xml} | 11 +- .../firmware-auto-efi-format-nvram-json.xml | 18 + ...l-efi-qemuvars-aarch64.aarch64-latest.args | 33 ++ ...l-efi-qemuvars-aarch64.aarch64-latest.xml} | 24 +- .../firmware-manual-efi-qemuvars-aarch64.xml | 19 + ...muvars-nvram-network-nbd.x86_64-latest.err | 1 + ...-manual-efi-qemuvars-nvram-network-nbd.xml | 23 ++ ...manual-efi-qemuvars-q35.x86_64-latest.args | 35 ++ ...manual-efi-qemuvars-q35.x86_64-latest.xml} | 11 +- .../firmware-manual-efi-qemuvars-q35.xml | 19 + ...-manual-efi-tdx.x86_64-latest+inteltdx.xml | 2 +- tests/qemuxmlconftest.c | 8 + .../storagepoolcapsschemadata/poolcaps-fs.xml | 5 + .../poolcaps-full.xml | 5 + .../out/qcow2-qcow2_qcow2-qcow2_qcow2-auto | 2 +- .../out/qcow2-qcow2_qcow2-qcow2_raw-auto | 2 +- .../out/qcow2-qcow2_qcow2-qcow2_raw-raw | 2 +- tests/virstoragetestdata/out/qcow2-symlinks | 2 +- .../out/qcow2datafile-qcow2_qcow2-datafile | 2 +- 52 files changed, 824 insertions(+), 111 deletions(-) copy tests/qemufirmwaredata/out/usr/share/qemu/firmware/{60-edk2-ovmf-x64-inteltdx.json => 50-edk2-ovmf-x64-microvm.json} (56%) create mode 100644 tests/qemufirmwaredata/out/usr/share/qemu/firmware/91-bios.json create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/70-edk2-ovmf-qemuvars-x64-sb-enrolled.json create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/70-edk2-qemuvars-aarch64-sb-enrolled.json create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-enrolled-keys-aarch64.aarch64-8.2.0.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-enrolled-keys-aarch64.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-enrolled-keys-aarch64.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-enrolled-keys-aarch64.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-json.x86_64-8.2.0.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-json.x86_64-latest.args copy tests/qemuxmlconfdata/{firmware-auto-bios-stateless.x86_64-latest.xml => firmware-auto-efi-format-nvram-json.x86_64-latest.xml} (71%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-json.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-aarch64.aarch64-latest.args copy tests/qemuxmlconfdata/{firmware-auto-bios.x86_64-latest.xml => firmware-manual-efi-qemuvars-aarch64.aarch64-latest.xml} (52%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-aarch64.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-nvram-network-nbd.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-nvram-network-nbd.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.args copy tests/qemuxmlconfdata/{firmware-auto-bios-stateless.x86_64-latest.xml => firmware-manual-efi-qemuvars-q35.x86_64-latest.xml} (74%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml -- 2.52.0

4 41

[PATCH 0/2] libvirt-guests.sh: Declare and assign separately to avoid masking return values
by Michal Privoznik 16 Jan '26

16 Jan '26

*** BLURB HERE *** Michal Prívozník (2): libvirt-guests.sh: Declare and assign separately to avoid masking return values syntax-check: Introduce sc_prohibit_local_with_subshell rule build-aux/syntax-check.mk | 6 ++++++ tools/libvirt-guests.sh.in | 34 +++++++++++++++++++++++----------- 2 files changed, 29 insertions(+), 11 deletions(-) -- 2.52.0

2 4

Re: [PATCH RFC v1 3/3] qapi/iothread: introduce poll-weight parameter for aio-poll
by Markus Armbruster 16 Jan '26

16 Jan '26

Cc: devel(a)lists.libvirt.org for a possible query-iothreads change discussed below. JAEHOON KIM <jhkim(a)linux.ibm.com> writes: > On 1/14/2026 1:48 AM, Markus Armbruster wrote: >> Jaehoon Kim <jhkim(a)linux.ibm.com> writes: >> >>> Introduce a new poll-weight parameter for aio-poll. This parameter >>> controls how much the most recent event interval affects the next >>> polling duration. When set to 0, a default value of 2 is used, meaning >>> the current interval contributes roughly 25% to the calculation. Larger >>> values decrease the weight of the current interval, enabling more >>> gradual adjustments to polling duration. >>> >>> Signed-off-by: Jaehoon Kim <jhkim(a)linux.ibm.com> >> [...] >> >>> diff --git a/qapi/misc.json b/qapi/misc.json >>> index 28c641fe2f..b21cc48a03 100644 >>> --- a/qapi/misc.json >>> +++ b/qapi/misc.json >>> @@ -85,6 +85,11 @@ >>> # @poll-shrink: how many ns will be removed from polling time, 0 means >>> # that it's not configured (since 2.9) >>> # >>> +# @poll-weight: the weight factor for adaptive polling. >>> +# Determines how much the current event interval contributes to >>> +# the next polling time calculation. 0 means that the default >>> +# value is used. (since 10.1) >> >> When the default value is used, the actual value being used remains >> hidden. Why? > > Actually, I just followed the existing pattern of poll-grow, which also > defaults to a factor of 2 when set to 0. Yes, and consistency is always desirable. But let's have a look at the new interface in isolation, to see whether it's actually good. > It wasn't my intention to hide the value; I kept this because the > previous API has been working fine without issues. > If you think the actual value should be visible, I'll consider ways to > make it explicit in the next version. As is, query-iothreads tells us "the weight factor for adaptive polling is X, and it was set by the user", or "the weight factor for adaptive polling was not set by the user, but picked by the system." If we returned the actual value, it would tell us "the weight factor for adaptive polling is X". Only the former interface tells us whether the user or the system picked. Only the latter interface tells us what the system picked. Which one is useful in practice? I'd argue the latter. A management application knows whether it set a value without query-iothreads' help, but it doesn't know what the system picked. The people coding it may know if a contract specifies what the system picks (see below). If we conclude that returning the actual value is better for new @poll-weight, then it would surely be better for @poll-grow and @poll-shrink, too. Could we still improve them? Libvirt developers, any advice? >>> +# >>> # @aio-max-batch: maximum number of requests in a batch for the AIO >>> # engine, 0 means that the engine will use its default (since 6.1) >>> # >>> @@ -96,6 +101,7 @@ >>> 'poll-max-ns': 'int', >>> 'poll-grow': 'int', >>> 'poll-shrink': 'int', >>> + 'poll-weight': 'int', >>> 'aio-max-batch': 'int' } } >>> >>> ## >>> diff --git a/qapi/qom.json b/qapi/qom.json >>> index 6f5c9de0f0..d90823478d 100644 >>> --- a/qapi/qom.json >>> +++ b/qapi/qom.json >>> @@ -606,6 +606,11 @@ >>> # algorithm detects it is spending too long polling without >>> # encountering events. 0 selects a default behaviour (default: 0) >>> # >>> +# @poll-weight: the weight factor for adaptive polling. >>> +# Determines how much the current event interval contributes to >>> +# the next polling time calculation. 0 selects a default >>> +# behaviour (default: 0) since 10.1. >> >> This leaves the actual default behavior unspecified. Is this a good >> idea? > > I agree that the documentation should be more explicit. > I'll update it to clarify that the default factor is 2 and explain its > meaning. I understand that you're mirroring how @poll-grow and @poll-shrink work, but let's ignore that for a minute. Compare four possible interfaces: 1. Optional @poll-weight defaults to 2. Values <= 0 are rejected. 2. Optional @poll-weight defaults to 2. Value 0 is replaced by the default value 2. Values < 0 are rejected. 3. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value 0 makes the system pick a value, namely 2. 4. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value 0 makes the system pick a value. It currently picks 2. The difference between 3. and 4. is that 3. makes "system picks 2" part of the contract, while 4. doesn't. 1. is the simplest. Is 2.'s additional complexity worthwhile? 3.'s? 4.'s? >>> +# >>> # The @aio-max-batch option is available since 6.1. >>> # >>> # Since: 2.0 >>> @@ -614,7 +619,8 @@ >>> 'base': 'EventLoopBaseProperties', >>> 'data': { '*poll-max-ns': 'int', >>> '*poll-grow': 'int', >>> - '*poll-shrink': 'int' } } >>> + '*poll-shrink': 'int', >>> + '*poll-weight': 'int' } } >>> >>> ## >>> # @MainLoopProperties: >> >> [...]

3 3

[RFC PATCH 0/3] qemu: Add support for control of persistent reservation migration
by Peter Krempa 16 Jan '26

16 Jan '26

Add support for migration of persistent reservations. Depends on RFC qemu patches: https://mail.gnu.org/archive/html/qemu-block/2026-01/msg00159.html Applies on top of my patches for new capabilities. Caps dump in 1/3 is based on a local build and thus will be replaced once I'll be doing an official update. Peter Krempa (3): DO_NOT_PUSH: qemucapabilitiestest: Regenerate with 'migrate-pr' patches qemu: capabilities: Introduce QEMU_CAPS_DEVICE_SCSI_BLOCK_MIGRATE_PR qemu: Implement support for persistent reservation migration control docs/formatdomain.rst | 3 +++ src/conf/domain_conf.c | 21 +++++++++++++++++++ src/conf/schemas/storagecommon.rng | 5 +++++ src/conf/storage_source_conf.c | 10 +++++++++ src/conf/storage_source_conf.h | 2 ++ src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 4 ++++ src/qemu/qemu_validate.c | 16 ++++++++++++++ .../caps_11.0.0_x86_64.replies | 8 ++++++- .../caps_11.0.0_x86_64.xml | 3 ++- ...irtio-scsi-reservations.x86_64-latest.args | 2 +- .../disk-virtio-scsi-reservations.xml | 2 +- 13 files changed, 75 insertions(+), 4 deletions(-) -- 2.52.0

1 3

[PATCH v2] domain_logcontext: Don't assume remote driver is always available
by Michal Privoznik 16 Jan '26

16 Jan '26

From: Michal Privoznik <mprivozn(a)redhat.com> Some functions inside of domain_logcontext.c call virLogManager APIs. But that one is available only when remote driver is enabled. Therefore, make domain_logcontext.c conditional, just like log_manager.c is: if config.has('WITH_REMOTE'). Resolves: https://gitlab.com/libvirt/libvirt/-/issues/842 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/7HSM… diff to v1: - Instead of #ifdef-ing virLogManager APIs, just make the whole domain_logcontext.c compiled conditionally. src/hypervisor/meson.build | 7 ++++++- src/libvirt_logging.syms | 7 +++++++ src/libvirt_private.syms | 7 ------- 3 files changed, 13 insertions(+), 8 deletions(-) diff --git a/src/hypervisor/meson.build b/src/hypervisor/meson.build index c32703af88..91eaefbebc 100644 --- a/src/hypervisor/meson.build +++ b/src/hypervisor/meson.build @@ -2,11 +2,16 @@ hypervisor_sources = [ 'domain_cgroup.c', 'domain_driver.c', 'domain_interface.c', - 'domain_logcontext.c', 'virclosecallbacks.c', 'virhostdev.c', ] +if conf.has('WITH_REMOTE') + hypervisor_sources += [ + 'domain_logcontext.c' + ] +endif + stateful_driver_source_files += files(hypervisor_sources) hypervisor_lib = static_library( diff --git a/src/libvirt_logging.syms b/src/libvirt_logging.syms index e2a1a7109f..5e867703cb 100644 --- a/src/libvirt_logging.syms +++ b/src/libvirt_logging.syms @@ -3,6 +3,13 @@ # +# hypervisor/domain_logcontext.h +domainLogContextGetWriteFD; +domainLogContextMarkPosition; +domainLogContextNew; +domainLogContextReadFiltered; +domainLogContextWrite; + # logging/log_manager.h virLogManagerDomainAppendMessage; virLogManagerDomainGetLogFilePosition; diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 4e57e4a8f6..51f4d6db24 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1695,13 +1695,6 @@ virDomainInterfaceStopDevice; virDomainInterfaceStopDevices; virDomainInterfaceVportRemove; -# hypervisor/domain_logcontext.h -domainLogContextGetWriteFD; -domainLogContextMarkPosition; -domainLogContextNew; -domainLogContextReadFiltered; -domainLogContextWrite; - # hypervisor/virclosecallbacks.h virCloseCallbacksDomainAdd; virCloseCallbacksDomainAlloc; -- 2.52.0

2 1

[PATCH] domain_logcontext: Don't assume remote driver is always available
by Michal Privoznik 16 Jan '26

16 Jan '26

From: Michal Privoznik <mprivozn(a)redhat.com> Some functions inside of domain_logcontext call virLogManager APIs. But that one is available only when remote driver is enabled (from src/logging/meson.build): if conf.has('WITH_REMOTE') log_driver_lib = static_library( 'virt_log_driver', [ log_driver_sources, log_protocol_generated, ], ... Guard calls to virLogManager APIs with #ifdef WITH_REMOTE. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/842 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/hypervisor/domain_logcontext.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/src/hypervisor/domain_logcontext.c b/src/hypervisor/domain_logcontext.c index 41d1bbdf64..92f942eb81 100644 --- a/src/hypervisor/domain_logcontext.c +++ b/src/hypervisor/domain_logcontext.c @@ -71,7 +71,9 @@ domainLogContextFinalize(GObject *object) domainLogContext *ctxt = DOMAIN_LOG_CONTEXT(object); VIR_DEBUG("ctxt=%p", ctxt); +#ifdef WITH_REMOTE virLogManagerFree(ctxt->manager); +#endif VIR_FREE(ctxt->path); VIR_FORCE_CLOSE(ctxt->writefd); VIR_FORCE_CLOSE(ctxt->readfd); @@ -82,8 +84,8 @@ domainLogContextFinalize(GObject *object) domainLogContext * domainLogContextNew(bool stdioLogD, char *logDir, - const char *driver_name, - virDomainObj *vm, + const char *driver_name G_GNUC_UNUSED, + virDomainObj *vm G_GNUC_UNUSED, bool privileged, const char *basename) { @@ -96,6 +98,7 @@ domainLogContextNew(bool stdioLogD, ctxt->path = g_strdup_printf("%s/%s.log", logDir, basename); if (stdioLogD) { +#ifdef WITH_REMOTE ctxt->manager = virLogManagerNew(privileged); if (!ctxt->manager) goto error; @@ -110,6 +113,11 @@ domainLogContextNew(bool stdioLogD, &ctxt->pos); if (ctxt->writefd < 0) goto error; +#else /* !WITH_REMOTE */ + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("logd stdio handler is not supported")); + goto error; +#endif /* !WITH_REMOTE */ } else { if ((ctxt->writefd = open(ctxt->path, O_WRONLY | O_CREAT | O_APPEND, S_IRUSR | S_IWUSR)) < 0) { virReportSystemError(errno, _("failed to create logfile %1$s"), @@ -202,6 +210,7 @@ domainLogContextRead(domainLogContext *ctxt, (unsigned long long)ctxt->pos); if (ctxt->manager) { +#ifdef WITH_REMOTE buf = virLogManagerDomainReadLogFile(ctxt->manager, ctxt->path, ctxt->inode, @@ -211,6 +220,11 @@ domainLogContextRead(domainLogContext *ctxt, if (!buf) return -1; buflen = strlen(buf); +#else /* !WITH_REMOTE */ + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("logd stdio handler is not supported")); + return -1; +#endif /* !WITH_REMOTE */ } else { ssize_t got; @@ -315,14 +329,17 @@ domainLogContextGetWriteFD(domainLogContext *ctxt) void domainLogContextMarkPosition(domainLogContext *ctxt) { - if (ctxt->manager) + if (ctxt->manager) { +#ifdef WITH_REMOTE virLogManagerDomainGetLogFilePosition(ctxt->manager, ctxt->path, 0, &ctxt->inode, &ctxt->pos); - else +#endif /* WITH_REMOTE */ + } else { ctxt->pos = lseek(ctxt->writefd, 0, SEEK_END); + } } -- 2.52.0

3 2

Questions about device attach/detach semantics
by pascal.scholz＠cyberus-technology.de 15 Jan '26

15 Jan '26

Hi all, I'm part of Cyberus Technology and currently working on the Cloud Hypervisor driver backend of libvirt. We are currently implementing a feature to fix device bus addresses in the domain definitions for PCI devices, guaranteeing that devices remain available at the same address even after live migration and restarts, and across libvirt versions. In doing so, some questions came up about the intended semantics of the `--persistent` and `--live` flags in virsh commands and the synchronization between runtime and persistent configuration. So we wanted to ask you these questions. Our first question revolves around `virsh mirgate --persistent`. The documentation says `leaves the domain persistent on the destination host physical machine`, but what domain definition is used from the source side to migrate the VM? Is it that the live definition is sent, then migrated, and persisted on the receiver side? Or is the source's persistent XML sent to the receiver, and the receiver’s live definition created from the persistent definition received? The second question is about synchronization between live and persistent configuration. To achieve the goal of keeping the same device at the same PCI bus address across restarts and live migrations, to our understanding, we have to ensure that one device is written to both domain definitions with the same PCI bus address. Is this right, or do we miss something? The next questions are about attaching/detaching devices (live). With respect to our intention to implement fixed PCI bus addresses for devices, what would be the right semantics for the following cases? Are they even valid? The source code of the qemu driver leaves those questions open: 1) We attach a device `A` with `--persistent`and remove it with `--live`. If we now attach `B`, either via `--persistent` and `--live`, we expect that the PCI bus address formerly assigned to `A` is not reused for `B`. Is this correct? 2) If we attach a device `A` with `--live` and a second device `B` with `--persistent`, then `A` will not be present in the persistent domain XML. Still, we expect that `B` is added to both live and persistent definitions, using the same PCI bus address. By doing so, we would expect the attachment routines for the persistent definition not to assign the address handed out by the attachment routines of the live configuration for device `A`. In other words, even if `A` is not present in the persistent configuration, we would expect the address of `A` not be reused when attaching `B` to the persistent definition. Are those semantics correct? The last question is about target names for network devices (`ifname`). libvirt does generate names for such devices in certain situations. Whenever a device definition is parsed that contains an `ifname` that matches libvirt's generation rules, e.g. vnet*, it is blanked out (see `virDomainNetDefParseXML`, in domain_conf.c). When writing code that tries to identify network devices by their `ifname`s, we found that this would be impossible because devices with an autogenerated name will have a blank `ifname` in the definition. What is the expected semantics around fixed PCI bus addresses for such devices? Would it be right to assign a custom `ifname` to them in this case? Thanks in advance! Pascal

3 4

Resolving issue 135 (Qemu under AppArmor can't access volume-type disks)
by Erik Huelsmann 15 Jan '26

15 Jan '26

Hi, Several months ago, I ran into issue #135 which says that Qemu under AppArmor can't access LVM volume disks. I have been studying the code and the invocation of virt-aa-helper. I'm using 11.3.0 and 10.0.0 -- I'm working to compile and run a development version, but have my progress to share in the mean time. So far, I'm finding that if I create a volume-based disk XML entry in my domain definition: <disk type='volume' device='disk'> <driver name='qemu' type='qcow2'/> <source pool='default' volume='cirros.img'/> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> with this, there is *no* XML (at all) on standard input in the virt-aa-helper command, whereas when using effectively the same definition, resolving the file manually, like this: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/cirros.img'/> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> I get full XML on standard input for virt-aa-helper, with this being the snippet for the disk definition: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/cirros.img' index='1'/> <backingStore/> <target dev='sda' bus='scsi'/> <alias name='scsi0-0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> I'm not asking for a fix, but would like to know if anybody has any "Ah hah!" moments about this - and if not, if there are some hints on how to test this, hopefully without needing to restart a VM over-and-over. Thanks in advance for any hints you may be able to provide! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 7