- Devel - libvirt List Archives

[PATCH v3 0/4] hyperv: Add snapshot create/delete support
by Jonathon Jongsma 14 Apr '26

14 Apr '26

Add ability to create and delete basic snapshots in thed hyperv driver. Changes in v3: - Rebase to latest master - update comments about release version 12.2.0 -> 12.3.0 - mention snapshot-create limitations in commit message Changes in v2: - re-word error message about configuring disks / memory for snapshots - split out the utility function for extracting async method output params Jonathon Jongsma (4): hyperv: Add snapshot related WMI class definitions hyperv: Implement domainSnapshotDelete() hyperv: Add a utility function for getting method output params hyperv: Implement domainSnapshotCreateXML() src/hyperv/hyperv_driver.c | 129 ++++++++++++++++++++++++ src/hyperv/hyperv_wmi.c | 139 ++++++++++++++++++++++++++ src/hyperv/hyperv_wmi.h | 17 ++++ src/hyperv/hyperv_wmi_generator.input | 42 ++++++++ 4 files changed, 327 insertions(+) -- 2.53.0

2 9

Save the date: KVM Forum 2026, Vancouver, Canada, November 12-13
by Peter Maydell 14 Apr '26

14 Apr '26

#################### KVM Forum 2026 November 12-13, 2026 Vancouver, Canada #################### On behalf of the program committee for the KVM Forum, I am pleased to announce KVM Forum 2026, November 12-13 2026 in Vancouver, Canada. The call for papers will follow, but we want to give you the opportunity to pre-plan. https://kvm-forum.qemu.org/ and https://kvm-forum.qemu.org/location/ already provide some initial information, more will come soon. -- Peter Maydell

1 0

[PATCH v4 0/3] apparmor: Preserve macvtap path in domain profile
by Wesley Hershberger 14 Apr '26

14 Apr '26

I will open a separate issue for tracking the blockcommit r/w permissions side of this (as I should have done all along). I've opened a MR to libvirt-tck with a test case that demonstrates the bug [1]. apparmor/110-macvtap.t passes with these patches applied. Thanks for the reviews and continued consideration. [1] https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/73 Resolves: https://gitlab.com/libvirt/libvirt/-/issues/692 Signed-off-by: Wesley Hershberger <wesley.hershberger(a)canonical.com> --- Changes in v4: - Split apparmor changes to separate patches - virBufferEscapeString for formatting in XML - Fix dangling pointer in virNetDevMacVLanTapOpen - Added tapfd path to qemustatusxml2xmldata Changes in v3: - Fix buglink in commit message - Link to v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/IPEB… Changes in v2: - Drop `virt-aa-helper: Ask for no deny rule...` as it was applied - Drop `qemu: Store blockcommit permissions...` due to unresolved concerns - Pass tapfd path through netdef instead of resolving from fd - Link to v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/UNNB… --- Wesley Hershberger (3): qemu: Store tapfd path in domstatus XML apparmor: Pass status XML to virt-aa-helper virt-aa-helper: Include macvtap tapfd path src/conf/domain_conf.c | 8 ++++++++ src/conf/domain_conf.h | 1 + src/hypervisor/domain_interface.c | 2 +- src/lxc/lxc_process.c | 1 + src/qemu/qemu_interface.c | 1 + src/security/security_apparmor.c | 1 + src/security/virt-aa-helper.c | 5 +++++ src/util/virnetdevmacvlan.c | 18 +++++++++++------- src/util/virnetdevmacvlan.h | 4 +++- tests/qemustatusxml2xmldata/modern-in.xml | 7 +++++++ 10 files changed, 39 insertions(+), 9 deletions(-) --- base-commit: 792cb6bf60e774ee8ecf9e7d3cd2b6f21011ab43 change-id: 20260105-apparmor-races-d03238ee4d93 Best regards, -- Wesley Hershberger <wesley.hershberger(a)canonical.com>

2 5

[PATCH] conf: Reject blockio settings for "<disk device='lun'>"
by Peter Krempa 14 Apr '26

14 Apr '26

From: Peter Krempa <pkrempa(a)redhat.com> Overriding the blockio settings for disk passthrough via "<disk device='lun'>" doesn't make sense and in fact the 'scsi-block' device in qemu doesn't even expose the appropriate properties: qemu-system-x86_64: -device {"driver":"scsi-block","bus":"scsi0.0","channel":0,"scsi-id":0,"lun":0,"drive":"libvirt-1-format","id":"scsi0-0-0-0","logical_block_size":512,"physical_block_size":512}: Property 'scsi-block.physical_block_size' not found Reject those at validation. Resolves: https://redhat.atlassian.net/browse/RHEL-145937 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/conf/domain_validate.c | 8 ++++++ .../disk-blockio-device-lun.x86_64-latest.err | 1 + .../disk-blockio-device-lun.xml | 26 +++++++++++++++++++ tests/qemuxmlconftest.c | 1 + 4 files changed, 36 insertions(+) create mode 100644 tests/qemuxmlconfdata/disk-blockio-device-lun.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/disk-blockio-device-lun.xml diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index a49156061f..3946f92182 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -786,6 +786,14 @@ virDomainDiskDefValidate(const virDomainDef *def, if (disk->device == VIR_DOMAIN_DISK_DEVICE_LUN) { if (virDomainDiskDefSourceLUNValidate(disk->src) < 0) return -1; + + if (disk->blockio.logical_block_size > 0 || + disk->blockio.physical_block_size > 0 || + disk->blockio.discard_granularity_specified) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("blockio is not supported with device='lun'")); + return -1; + } } else { if (disk->src->pr) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", diff --git a/tests/qemuxmlconfdata/disk-blockio-device-lun.x86_64-latest.err b/tests/qemuxmlconfdata/disk-blockio-device-lun.x86_64-latest.err new file mode 100644 index 0000000000..508abf7a97 --- /dev/null +++ b/tests/qemuxmlconfdata/disk-blockio-device-lun.x86_64-latest.err @@ -0,0 +1 @@ +unsupported configuration: blockio is not supported with device='lun' diff --git a/tests/qemuxmlconfdata/disk-blockio-device-lun.xml b/tests/qemuxmlconfdata/disk-blockio-device-lun.xml new file mode 100644 index 0000000000..862e064d4f --- /dev/null +++ b/tests/qemuxmlconfdata/disk-blockio-device-lun.xml @@ -0,0 +1,26 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='block' device='lun'> + <source dev='/dev/something'/> + <target dev='sda' bus='scsi'/> + <blockio logical_block_size='512' physical_block_size='512' discard_granularity='4096'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c index 14aa723ec5..4c9b55693a 100644 --- a/tests/qemuxmlconftest.c +++ b/tests/qemuxmlconftest.c @@ -1613,6 +1613,7 @@ mymain(void) DO_TEST_CAPS_LATEST("disk-geometry"); DO_TEST_CAPS_LATEST("disk-blockio"); DO_TEST_CAPS_LATEST("disk-blockio-no-discard"); + DO_TEST_CAPS_LATEST_PARSE_ERROR("disk-blockio-device-lun"); driver.config->storageUseNbdkit = 1; DO_TEST_CAPS_LATEST_NBDKIT("disk-cdrom-network-nbdkit", QEMU_NBDKIT_CAPS_PLUGIN_CURL); -- 2.53.0

2 1

[PATCH 1/2] bhyve: implement domainInterfaceAddresses and domainGetHostname
by Roman Bogorodskiy 14 Apr '26

14 Apr '26

Implement the domainInterfaceAddresses and domainGetHostname APIs. These APIs could use multiple sources of information, though for bhyve only the 'lease' source is supported. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_driver.c | 149 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index a7bd16704e..33a772ccdb 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -1846,6 +1846,153 @@ bhyveDomainGetVcpuPinInfo(virDomainPtr domain, return ret; } + +static int +bhyveDomainInterfaceAddresses(virDomainPtr domain, + virDomainInterfacePtr **ifaces, + unsigned int source, + unsigned int flags) +{ + virDomainObj *vm = NULL; + int ret = -1; + + virCheckFlags(0, -1); + + if (!(vm = bhyveDomObjFromDomain(domain))) + goto cleanup; + + if (virDomainInterfaceAddressesEnsureACL(domain->conn, vm->def, source) < 0) + goto cleanup; + + if (virDomainObjCheckActive(vm) < 0) + goto cleanup; + + switch (source) { + case VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_LEASE: + ret = virDomainNetDHCPInterfaces(vm->def, ifaces); + break; + + case VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_AGENT: + case VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP: + virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, + _("Unsupported IP address data source %1$d"), + source); + break; + + default: + virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, + _("Unknown IP address data source %1$d"), + source); + break; + } + + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} + + +static int +bhyveDomainGetHostnameLease(virDomainObj *vm, + char **hostname) +{ + char macaddr[VIR_MAC_STRING_BUFLEN]; + g_autoptr(virConnect) conn = NULL; + virNetworkDHCPLeasePtr *leases = NULL; + int n_leases; + size_t i, j; + int ret = -1; + + if (virDomainObjBeginJob(vm, VIR_JOB_QUERY) < 0) + return -1; + + if (virDomainObjCheckActive(vm) < 0) + goto endjob; + + if (!(conn = virGetConnectNetwork())) + goto endjob; + + for (i = 0; i < vm->def->nnets; i++) { + g_autoptr(virNetwork) network = NULL; + virDomainNetDef *net = vm->def->nets[i]; + + if (net->type != VIR_DOMAIN_NET_TYPE_NETWORK) + continue; + + virMacAddrFormat(&net->mac, macaddr); + network = virNetworkLookupByName(conn, net->data.network.name); + + if (!network) + goto endjob; + + if ((n_leases = virNetworkGetDHCPLeases(network, macaddr, + &leases, 0)) < 0) + goto endjob; + + for (j = 0; j < n_leases; j++) { + virNetworkDHCPLeasePtr lease = leases[j]; + if (lease->hostname && !*hostname) + *hostname = g_strdup(lease->hostname); + + virNetworkDHCPLeaseFree(lease); + } + + VIR_FREE(leases); + + if (*hostname) + break; + } + + ret = 0; + endjob: + virDomainObjEndJob(vm); + return ret; +} + +static char * +bhyveDomainGetHostname(virDomainPtr domain, + unsigned int flags) +{ + virDomainObj *vm = NULL; + char *hostname = NULL; + + virCheckFlags(VIR_DOMAIN_GET_HOSTNAME_LEASE | + VIR_DOMAIN_GET_HOSTNAME_AGENT, NULL); + + VIR_EXCLUSIVE_FLAGS_RET(VIR_DOMAIN_GET_HOSTNAME_LEASE, + VIR_DOMAIN_GET_HOSTNAME_AGENT, + NULL); + + if (!(flags & VIR_DOMAIN_GET_HOSTNAME_AGENT)) + flags |= VIR_DOMAIN_GET_HOSTNAME_LEASE; + + if (!(vm = bhyveDomObjFromDomain(domain))) + return NULL; + + if (virDomainGetHostnameEnsureACL(domain->conn, vm->def) < 0) + goto cleanup; + + if (flags & VIR_DOMAIN_GET_HOSTNAME_AGENT) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("getting hostname from agent is not supported")); + goto cleanup; + } else if (flags & VIR_DOMAIN_GET_HOSTNAME_LEASE) { + if (bhyveDomainGetHostnameLease(vm, &hostname) < 0) + goto cleanup; + } + + if (!hostname) { + virReportError(VIR_ERR_NO_HOSTNAME, + _("no hostname found for domain %1$s"), + vm->def->name); + goto cleanup; + } + + cleanup: + virDomainObjEndAPI(&vm); + return hostname; +} + static virHypervisorDriver bhyveHypervisorDriver = { .name = "bhyve", .connectURIProbe = bhyveConnectURIProbe, @@ -1912,6 +2059,8 @@ static virHypervisorDriver bhyveHypervisorDriver = { .domainGetVcpusFlags = bhyveDomainGetVcpusFlags, /* 12.1.0 */ .domainGetMaxVcpus = bhyveDomainGetMaxVcpus, /* 12.1.0 */ .domainGetVcpuPinInfo = bhyveDomainGetVcpuPinInfo, /* 12.1.0 */ + .domainInterfaceAddresses = bhyveDomainInterfaceAddresses, /* 12.3.0 */ + .domainGetHostname = bhyveDomainGetHostname, /* 12.3.0 */ }; -- 2.52.0

2 5

[PATCH 0/2] Fix memory leaks
by Pavel Hrdina 14 Apr '26

14 Apr '26

Pavel Hrdina (2): virNetworkIPDefFormat: Fix memory leaks chSocketRecv: Fix memory leak src/ch/ch_process.c | 2 +- src/conf/network_conf.c | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) -- 2.53.0

3 5

[PATCH-for-11.0?] target/i386: Mandate monitor 'info lapic' take a vCPU ID argument
by Philippe Mathieu-Daudé 14 Apr '26

14 Apr '26

With SMP configurations, using the 'current vCPU' under the monitor isn't recommended, as it changes during runtime. Better to specify which vCPU we want to monitor by its index. Deprecate the default of 'info lapic', mentioning an argument is expected, so we can remove this unpredictable behavior one day. Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- The other command with this unpredictable behavior is 'info tlb' which we'll deal with differently, after the v11.0 release. --- docs/about/deprecated.rst | 6 ++++++ target/i386/cpu-apic.c | 2 ++ hmp-commands-info.hx | 3 +-- 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a6d6a713265..a62da93259a 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -169,6 +169,12 @@ The ``stopcapture`` command is deprecated and will be removed in a future releas The ``info capture`` command is deprecated and will be removed in a future release. +``info lapic`` without ``apic-id`` argument (since 11.0) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +When no APIC ID is provided, ``info lapic`` defaults to the current vCPU. +This behavior is now deprecated, the ID will be mandatory in a future release. + Host Architectures ------------------ diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c index eaa10ad2a3d..9ca569f62b8 100644 --- a/target/i386/cpu-apic.c +++ b/target/i386/cpu-apic.c @@ -97,6 +97,8 @@ void hmp_info_local_apic(Monitor *mon, const QDict *qdict) cpu_synchronize_state(cs); } } else { + monitor_printf(mon, "Not specifying the local apic id is deprecated" + " (using the current CPU one)\n"); cs = mon_get_cpu(mon); } diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx index 74c741f80e2..e4206d329fc 100644 --- a/hmp-commands-info.hx +++ b/hmp-commands-info.hx @@ -118,8 +118,7 @@ ERST .name = "lapic", .args_type = "apic-id:i?", .params = "[apic-id]", - .help = "show local apic state (apic-id: local apic to read, default is which of current CPU)", - + .help = "show local apic state (apic-id: local apic to read)", .cmd = hmp_info_local_apic, }, #endif -- 2.53.0

3 3

[PATCH v2 0/2] virnetdevmacvlan: Wait for udev to settle after creating macvtap
by Michal Privoznik 13 Apr '26

13 Apr '26

This is a v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/YRT3… diff to v1: - Dropped all virWaitForDevices() but the one in virNetDevMacVLanCreate() which is also made conditional Michal Prívozník (2): virnetdevmacvlan: Wait for udev to settle after creating macvtap virnetdevmacvlan: Drop udev busy loop from virNetDevMacVLanTapOpen() src/util/virnetdevmacvlan.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) -- 2.52.0

2 3

Re: Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by Peter Krempa 10 Apr '26

10 Apr '26

On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote: > Hello libvirt community, > > I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). > > **Environment:** > - libvirt version: 10.5.0 Note that this was released almost a year ago. > - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 > - Disk image format: qcow2 > - Host OS: RHEL 9.5 > > **Steps to reproduce:** > 1. Create an external snapshot: > virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic > 2. Delete the snapshot: > virsh snapshot-delete <vm> --snapshotname snap1 > > **Observed behavior:** > - Changes from the overlay (snapshot) file are merged into the base image. > - The snapshot metadata is removed from libvirt. > - The snapshot file remains on disk (appears orphaned). You mean that the original overlay images remained on disk? e.g. /path/to/originalimage.snap1 ? > **Questions:** > - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. Yes it is intended, because deleting a snapshot is effectively meaning "I don't want to return to this point any more" so the extra overlay makes no sense. > - Should the snapshot file be deleted automatically, or is manual cleanup required? If you mean the overlay, then yes it should have been deleted. > - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? The semantics of external and internal snapshots are supposed to be indentical. I don't think we document to a deep extent the actual behaviour WRT to the disk files.

2 1

[RFC] nftables: switch to nft -f
by Dion Bosschieter 09 Apr '26

09 Apr '26

Hi, I'd like to propose switching from individual nft commands to nft -f in the nftables firewall backend — either as a new backend or as an extension of the existing one. The main motivation is performance. In benchmarking, nft -f is about 46% faster: The following commands are run on the .args files in the nwfilter nftables v6 patch. $ time for i in *.args; do n=$(echo $i | sed s/.args$//); sudo ./reset-tables.sh; sudo sh -e $i; done real 0m8.335s user 0m0.320s sys 0m0.564s $ time for i in *.output; do sudo ./reset-tables.sh skipvmap; sudo nft -f $i; done real 0m4.518s user 0m0.274s sys 0m0.498s On top of that, loading a full ruleset via nft -f is atomic for the whole set of changes, which allows us to remove the rollback logic and removes the need for tmp rules. One issue I see is that the current approach allows certain commands to fail silently, deleting something that doesn't exist won't abort the operation. That's not the case with nft -f, where a failure stops the whole load. One approach here is to only use nft -f for sections that don't contain ignore-errors commands, and run those separately as individual commands. As described earlier: to handle the current non-atomic nature, we have a few extra commands in place — a temporary jump rule, delete vmap entry, add vmap entry. The tmp jump can be replaced by running nft -f instead. I wonder what your opinions are about adding nft -f. Regards, Dion

2 2