- Devel - libvirt List Archives

[PATCH] util: remove duplicate logging of firewall command
by Daniel P. Berrangé 12 Feb '26

12 Feb '26

From: Daniel P. Berrangé <berrange(a)redhat.com> The vircommand.c code will always log the argv about to be run, so logging it again in virfirewall.c is redundant. Removing the dupe avoids the repeated memory allocation from the array -> string conversion. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/util/virfirewall.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/src/util/virfirewall.c b/src/util/virfirewall.c index 69521e2b46..a64f8b69c7 100644 --- a/src/util/virfirewall.c +++ b/src/util/virfirewall.c @@ -571,7 +571,6 @@ virFirewallCmdIptablesApply(virFirewall *firewall, VIR_FIREWALL_TRANSACTION_AUTO_ROLLBACK); bool needRollback = false; g_autoptr(virCommand) cmd = NULL; - g_autofree char *cmdStr = NULL; g_autofree char *error = NULL; size_t i; int status; @@ -607,9 +606,6 @@ virFirewallCmdIptablesApply(virFirewall *firewall, virCommandAddArg(cmd, fwCmd->args[i]); } - cmdStr = virCommandToString(cmd, false); - VIR_INFO("Running firewall command '%s'", NULLSTR(cmdStr)); - virCommandSetOutputBuffer(cmd, output); virCommandSetErrorBuffer(cmd, &error); @@ -622,6 +618,7 @@ virFirewallCmdIptablesApply(virFirewall *firewall, VIR_DEBUG("Ignoring error running command"); return 0; } else { + g_autofree char *cmdStr = virCommandToString(cmd, false); virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to run firewall command %1$s: %2$s"), NULLSTR(cmdStr), NULLSTR(error)); @@ -671,7 +668,6 @@ virFirewallCmdNftablesApply(virFirewall *firewall G_GNUC_UNUSED, size_t cmdIdx = 0; const char *objectType = NULL; g_autoptr(virCommand) cmd = NULL; - g_autofree char *cmdStr = NULL; g_autofree char *error = NULL; size_t i; int status; @@ -727,9 +723,6 @@ virFirewallCmdNftablesApply(virFirewall *firewall G_GNUC_UNUSED, for (i = 0; i < fwCmd->argsLen; i++) virCommandAddArg(cmd, fwCmd->args[i]); - cmdStr = virCommandToString(cmd, false); - VIR_INFO("Applying '%s'", NULLSTR(cmdStr)); - virCommandSetOutputBuffer(cmd, output); virCommandSetErrorBuffer(cmd, &error); @@ -745,6 +738,7 @@ virFirewallCmdNftablesApply(virFirewall *firewall G_GNUC_UNUSED, } else if (fwCmd->ignoreErrors) { VIR_DEBUG("Ignoring error running command"); } else { + g_autofree char *cmdStr = virCommandToString(cmd, false); virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to apply firewall command '%1$s': %2$s"), NULLSTR(cmdStr), NULLSTR(error)); @@ -776,6 +770,7 @@ virFirewallCmdNftablesApply(virFirewall *firewall G_GNUC_UNUSED, } if (!handleLen) { + g_autofree char *cmdStr = virCommandToString(cmd, false); virReportError(VIR_ERR_INTERNAL_ERROR, _("couldn't register rollback command - command '%1$s' had no valid handle in output ('%2$s')"), NULLSTR(cmdStr), NULLSTR(*output)); -- 2.53.0

3 6

[PATCH 0/9] qemu: add support for block latency histogram collection
by Peter Krempa 12 Feb '26

12 Feb '26

This patchset introduces configuration of the block latency histogram feature in qemu as well as exposes the histograms via bulk domain stats. The feature was in qemu for a long time so no capabilities are needed. Peter Krempa (9): qemu: Extract disk setup done via QMP into a separate helper qemu: process: Rename 'qemuProcessSetupDiskThrottling' to 'qemuProcessSetupDisks' qemu: monitor: Extract block latency histogram stats into 'qemuBlockStats' Expose latency histograms via 'virConnectGetAllDomainStats' qemu: monitor: Add handlers for 'block-latency-histogram-set' docs: formatdomain: Fix indentation of docs for <disk><driver><statistics> element docs: formatdomain: Reword section about the '<statistics>' element under disk driver Introduce support for disk operation latency histogram collection qemu: Setup disk latency histograms on startup/hotplug/update docs/formatdomain.rst | 77 ++++++++-- docs/manpages/virsh.rst | 7 + include/libvirt/libvirt-domain.h | 113 +++++++++++++++ src/conf/domain_conf.c | 133 +++++++++++++++++- src/conf/domain_conf.h | 7 + src/conf/schemas/domaincommon.rng | 37 ++++- src/qemu/qemu_domain.c | 17 +++ src/qemu/qemu_domain.h | 3 + src/qemu/qemu_driver.c | 43 ++++++ src/qemu/qemu_hotplug.c | 52 ++++--- src/qemu/qemu_monitor.c | 41 ++++++ src/qemu/qemu_monitor.h | 27 ++++ src/qemu/qemu_monitor_json.c | 115 +++++++++++++++ src/qemu/qemu_monitor_json.h | 9 ++ src/qemu/qemu_process.c | 63 ++++++--- src/qemu/qemu_process.h | 3 + tests/qemumonitorjsontest.c | 9 ++ ...isk-statistics-intervals.x86_64-latest.xml | 29 ++++ .../disk-statistics-intervals.xml | 25 ++++ 19 files changed, 748 insertions(+), 62 deletions(-) -- 2.52.0

1 10

[PATCH v2 0/4] hyperv: Implement virDomainInterfaceAddresses()
by Michal Privoznik 12 Feb '26

12 Feb '26

v2 of: diff to v1: - In 2/4 document corner case behavior of virSocketAddrSubnetToPrefix, - In 2/4 make the test report actual and expected values, - In 4/4 fix a possible mem leak if hypervDomainInterfaceAddressesParseOne() fails Michal Prívozník (4): datatypes: Declare autofree func for virDomainInterface type virsocketaddr: Introduce virSocketAddrSubnetToPrefix() hyperv: Move MAC parsing into a separate function hyperv: Implement virDomainInterfaceAddresses() src/datatypes.h | 2 + src/hyperv/hyperv_driver.c | 226 +++++++++++++++++++++++--- src/hyperv/hyperv_wmi_generator.input | 12 ++ src/libvirt_private.syms | 1 + src/util/virsocketaddr.c | 53 ++++++ src/util/virsocketaddr.h | 2 + tests/sockettest.c | 33 ++++ 7 files changed, 304 insertions(+), 25 deletions(-) -- 2.52.0

2 5

[PATCH v6 0/6] cover: RFE libvirt secret encryption on disk
by Arun Menon 12 Feb '26

12 Feb '26

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. 1. Introduce the GnuTLS decryption wrapper functions that work exact opposite to the encryption wrappers. 2. Add a new service called virt-secrets-init-encryption, that is linked to the virtsecretd service. virtsecretd service only starts after the new service generates a random encryption key. 3. Add a new secrets.conf configuration file that helps user to set a. secrets_encryption_key - allows the user to specify the encryption key file path, in case the default key is not to be used. b. encrypt_data - set to 0 or 1. If set to 1, then the newly added secrets will be encrypted. 4. Add encryption scheme or cipher attribute that will allow us to choose the last used cipher. 5. Once we have the encryption key, and a reliable way to tell the daemon what encryption scheme the secret object is using, we can encrypt the secrets on disk and store them in <uuid>.<encryption_scheme> format. It is important to note that if the encryption key is changed between restarts, then the respective secret will not be loaded by the driver. 6. Add documentation. This is a sincere attempt to improve upon the already submitted patch https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KE6G… Resolves: https://issues.redhat.com/browse/RHEL-7125 --- Changes in v6: - changes to use obj->secretValueFile as base - does local suffix lookups - refactors code so that the base64 encoding is in common code paths - moves local variable declaration inside blocks using them - refactors loader to use virFileReadAll instead of open-coding - fixes virSecretObjDeleteData to not rely on the actual filename Changes in v5: - Fix the bug of updating old secrets, prior to 12.1.0. Old secrets, when updated, now are stored with the latest encryption scheme if encryption is on. - Remove any logic in setting the secretValueFile in virSecretObjListAdd. Move it to virSecretLoadValue and virSecretObjSetValue. - Change urandom to random. Change default permission bits to 0077. - Update the documentation. Changes in v4: - Fix the regression of loading unencrypted secrets after an upgrade. Previously the .base64 unencrypted secrets were not being loaded. - Add documentation on encrypted secrets. Changes in v3: - Secrets xml configuration no longer stores the encryption scheme, therefore not allowing the user to toggle between ciphers. - Removed unnecessary socket files of the new service. It now has a general configuration with which it starts. - Addressed review comments from Peter on coding style and design. - Loading of secrets is dependent on the file extension. Most recent cipher is used while saving the secrets. Changes in v2: - Corrected the encryption key length check. It should be 32. - Added a new patch that introduces the encryption scheme attribute. This will help us identify which secrets are encrypted. - A new systemd unit service file added that starts before virtsecretd, helping us to construct a random encryption key and pass it to the virtsecretd service. - Parsing logic of secrets.conf moved to a separate file. - Spec file changes, augeas. Arun Menon (6): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secret.conf configuration file and parse it secret: Rename virSecretObj structure attribute from base64File to secretValueFile secret: Add functionality to load and save secrets in encrypted format docs: secret: Add documentation of secret encryption feature docs/drvsecret.rst | 4 + docs/meson.build | 1 + docs/secretencryption.rst | 105 +++++++++ include/libvirt/virterror.h | 1 + libvirt.spec.in | 8 + po/POTFILES | 1 + src/conf/virsecretobj.c | 210 +++++++++++++----- src/conf/virsecretobj.h | 14 +- src/libvirt_private.syms | 1 + src/meson.build | 1 + src/remote/libvirtd.service.in | 4 + src/secret/libvirt_secrets.aug | 40 ++++ src/secret/meson.build | 32 +++ src/secret/secret.conf.in | 14 ++ src/secret/secret_config.c | 179 +++++++++++++++ src/secret/secret_config.h | 40 ++++ src/secret/secret_driver.c | 29 ++- src/secret/test_libvirt_secrets.aug.in | 6 + .../virt-secret-init-encryption.service.in | 8 + src/secret/virtsecretd.service.extra.in | 8 + src/util/vircrypto.c | 126 ++++++++++- src/util/vircrypto.h | 8 + src/util/virerror.c | 3 + tests/vircryptotest.c | 65 ++++++ 24 files changed, 840 insertions(+), 68 deletions(-) create mode 100644 docs/secretencryption.rst create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret.conf.in create mode 100644 src/secret/secret_config.c create mode 100644 src/secret/secret_config.h create mode 100644 src/secret/test_libvirt_secrets.aug.in create mode 100644 src/secret/virt-secret-init-encryption.service.in -- 2.51.1

2 7

Re: [PATCH v2 00/21] qom: introduce property flags to track external user input
by BALATON Zoltan 12 Feb '26

12 Feb '26

On Thu, 12 Feb 2026, Zhao Liu wrote: > On Wed, Feb 11, 2026 at 12:28:13PM +0100, BALATON Zoltan wrote: >> Date: Wed, 11 Feb 2026 12:28:13 +0100 >> From: BALATON Zoltan <balaton(a)eik.bme.hu> >> Subject: Re: [PATCH v2 00/21] qom: introduce property flags to track >> external user input >> >> On Wed, 11 Feb 2026, Zhao Liu wrote: >>>> So another way could be to not use properties for internal settings but add >>>> another set of internal properties for those. These could be set the same >>>> way but stored in a different hash table and not get mixed with >>>> introspectable and user changable properties. But maybe that would be too >>>> much refactoring. >>> >>> Yes, it may require adding interfaces similar to object_property_add/get/ >>> set, which would need significant changes. >> >> Maybe not that part needs significant changes as you could still use a flag >> the same way adding a parameter to object_property_add/get/set to tell it >> should put the propery in the internal hash but then you need to add the >> other hash and maybe related changes. I don't know how much would those be >> but no new interface is needed just extending existing one as you did >> already. > > Yes, you're right, the flag-related interfaces in this series provide > enough support. But I haven't quite figured out what the advantages of > using an independent hash table would be, or what problems it could > address... I feel like I need to think about it more :). Storing internal properties in another hash could avoid needing INTERNAL and USER_SET flags as then there would be no way to set internal properties other than from code and may save some checks as then you would not need to special case internal properties in the user inspectable/settable properties handling. But I don't know how much other infrastructure it would need and if that would end up simpler than your approach or not. I think it may be simpler by avoiding the special cases and flags and clearly separating properties but as you say that would need more thinking and I did not try to think further just throwing the idea at you :-). The part creating, setting and storing internal properties should be simple but I don't know if the usage of these would have a problem when getting properties use the same interface for both external and internal properties. But if all these internal properties just set device state fields then all that's needed might be changing the property definition to use internal property and the compat props to set such properties (but compat may use some user settable properties too so this may make those a bit more complex). Regards, BALATON Zoltan

1 0

[PATCH 00/20] qemu: Optimize calls to 'query-block'
by Peter Krempa 12 Feb '26

12 Feb '26

We call query-block on each start of a VM but as it turns out there isn't much information that we actually probe from it. This series: - refactors 'query-block' use - removes unneeded calls - adds support for upcoming more optimal mode (RFC) Patches 19 and 20 are RFC as the qemu patches weren't accepted yet. I'll post them also separately with a capability dump update once that hits upstream. Peter Krempa (20): qemuDomainDiskInfo: Drop 'nodename' field qemu: Remove 'removable' field from 'qemuDomainDiskPrivate' qemuProcessRefreshDiskProps: Drop code to remove disk source qemu: Drop 'empty' filed from 'qemuDomainDiskInfo' qemuMigrationSrcBegin: Drop disk refresh step qemu: process: Unexport 'qemuProcessRefreshDisks' qemu: Drop 'removable' field from 'qemuDomainDiskInfo' qemuMonitorJSONHandleMigrationStatus: Simplify error case qemu: monitor: Add test validating that 'eventHandlers' are properly sorted qemuMonitorJSONHandleMemoryFailure: Simplify error case and value extraction qemuMonitorJSONGetBlockInfo: Don't fail if 'io-status' field gets new values qemuDomainDiskInfo: Use proper type for 'io_status' conf: domain: Add VIR_DOMAIN_DISK_TRAY_NONE state for devices without tray qemuDomainDiskPrivate: Remove unused 'tray' field qemuDomainAttachDiskGeneric: Avoid unneeded disk property refresh after hotplug qemu: Refactor tray_status handling qemuProcessUpdateVideoRamSize: Remove 'driver' argument and adjust callers qemuProcessRefreshDisks: Don't bother to refresh disks on cold boot qemu: capabilities: Introduce QEMU_CAPS_QUERY_BLOCK_FLAT qemu: monitor: Use 'flat' mode of 'query-block' src/conf/domain_conf.c | 17 +++- src/conf/domain_conf.h | 3 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.h | 12 +-- src/qemu/qemu_driver.c | 10 +-- src/qemu/qemu_hotplug.c | 18 ++-- src/qemu/qemu_migration.c | 12 +-- src/qemu/qemu_monitor.c | 44 +-------- src/qemu/qemu_monitor.h | 3 - src/qemu/qemu_monitor_json.c | 149 ++++++++++++++++++++----------- src/qemu/qemu_monitor_json.h | 3 + src/qemu/qemu_monitor_priv.h | 3 + src/qemu/qemu_process.c | 167 +++++++++++++++++------------------ src/qemu/qemu_process.h | 9 +- src/qemu/qemu_saveimage.c | 2 +- tests/qemuhotplugtest.c | 38 +++----- tests/qemumonitorjsontest.c | 31 +++++-- 18 files changed, 254 insertions(+), 270 deletions(-) -- 2.53.0

2 28

Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
by Daniel P. Berrangé 12 Feb '26

12 Feb '26

On Thu, Feb 12, 2026 at 11:25:17PM +0800, Zhao Liu wrote: > On Wed, Feb 11, 2026 at 04:58:47PM +0000, Daniel P. Berrangé wrote: > > Date: Wed, 11 Feb 2026 16:58:47 +0000 > > From: "Daniel P. Berrangé" <berrange(a)redhat.com> > > Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev > > properties accept flags > > > > On Wed, Feb 11, 2026 at 03:30:06PM +0800, Zhao Liu wrote: > > > On Tue, Feb 10, 2026 at 09:56:08AM +0000, Daniel P. Berrangé wrote: > > > > Date: Tue, 10 Feb 2026 09:56:08 +0000 > > > > From: "Daniel P. Berrangé" <berrange(a)redhat.com> > > > > Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev > > > > properties accept flags > > > > > > > > On Tue, Feb 10, 2026 at 11:23:41AM +0800, Zhao Liu wrote: > > > > > Update qdev property interfaces (qdev_property_add_static() and > > > > > qdev_class_add_property()) to accept and pass 'ObjectPropertyFlags'. > > > > > This enables marking qdev properties with flags such as DEPRECATED or > > > > > INTERNAL. > > > > > > > > > > To facilitate this at the definition level, extend the boolean and > > > > > uint8_t property macros (as the examples) to accept variable arguments > > > > > (VA_ARGS). This allows callers to optionally specify flags in the > > > > > property definition. > > > > > > > > > > Example: > > > > > > > > > > DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF, > > > > > .flags = OBJECT_PROPERTY_DEPRECATED), > > > > > > > > In other places where we track deprecation in QEMU, we have not used > > > > a boolean flag. Instead we have used a "const char *deprecation_note" > > > > internally, which lets us provide a user facing message, to be printed > > > > out in the warn_report, informing them what to do instead (either the > > > > feature is entirely removed, or there is a better alternative). IMHO > > > > we should be following the same pattern for properties, as it is much > > > > more user friendly than just printing a totally generic message > > > > "XXXX is deprecated, stop using it" > > > > > > Yes, rich deprecation hint is better. I think this still depends on > > > USER_SET - distinguish internal/external or not :-(. > > > > > > Since when we mark a property as deprecated, its code remains in the > > > code tree, and internal calls should not trigger warnings. Deprecation > > > hints are intended to reminder external users. > > > > This depends on where you put the deprecation check. IIUC, all the user > > facing codepaths for setting properties end up calling through > > object_set_properties_from_qdict, but internal codepaths don't use that. > > > > That method can check & emit the deprecation warnings, without us needing > > any explicit tracking of "user set" - the use context is derived from the > > codepath > > Yeah, most property setting paths are covered by > object_set_properties_from_qdict() (I listes these cases in patch 12, > including the most common ones: -object/-device and their related HMP/QMP > commands). > > But there're some corner cases which don't go through > object_set_properties_from_qdict(), e.g., -global/-accel/"qom-set", etc, > those were considerred in patch 9/11/13 (and sorry I should list all > cases affected in cover letter :(). These cases are where I find > things to be both trivial and tricky, so I manually check them and mark > them using USER_SET. > > Therefore, I think the unified entry point for externally setting > properties resides at a lower level—specifically, is object_property_set(), > then we need to dientify when object_property_set() is called by > external user or not - that's how USER_SET works...(I feel like I'm back > where I started). There's a significant different there. Emitting deprecation messages in the API entry points tied to user data is a clear purpose, not open to abuse. Recording the difference between user set & internally set against the object instance persistently is an open ended purpose and based on what we've seen in QEMU in the past, that is highly likely to be mis-used. The idea of supporting deprecations on properties is definitely something we should do, but I really dn't want to see that expressed via the 'user set' mechanism from this series. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|

1 0

[PATCH] In virFDStreamRead(), fill buffer from this and next messages
by Erik Hulsmann 12 Feb '26

12 Feb '26

Before this change, buffers returned from virFDStreamRead() would alternate in size (262120 and 24), because it only consumed the bytes remaining from the current background thread message. As the background thread reads 262144 bytes (256kB) of data in each chunk, where the maximum size returned from virFDStreamRead() to be transferred over the remote protocol is only 262120, 24 bytes would be left in the buffer on each iteration. The next iteration leaves 24 bytes, which used to be returned without considering messages waiting in the queue. Signed-off-by: Erik Huelsmann <ehuels(a)gmail.com> --- src/util/virfdstream.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/src/util/virfdstream.c b/src/util/virfdstream.c index 26a1f00..4c974ba 100644 --- a/src/util/virfdstream.c +++ b/src/util/virfdstream.c @@ -905,7 +905,10 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) if (fdst->thread) { virFDStreamMsg *msg = NULL; + size_t got = 0; + size_t bsz = 0; + more: while (!(msg = fdst->msg)) { if (fdst->threadQuit || fdst->threadErr) { if (nbytes) { @@ -917,7 +920,7 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) virReportSystemError(EBADF, "%s", _("stream is not open")); } else { - ret = 0; + ret = got; } goto cleanup; } else { @@ -931,7 +934,7 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) * return 0 immediately. */ if (msg->type == VIR_FDSTREAM_MSG_TYPE_HOLE && msg->stream.hole.len == 0) { - ret = 0; + ret = got; goto cleanup; } @@ -942,21 +945,26 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) goto cleanup; } - if (nbytes > msg->stream.data.len - msg->stream.data.offset) - nbytes = msg->stream.data.len - msg->stream.data.offset; + bsz = msg->stream.data.len - msg->stream.data.offset; + if (nbytes < bsz) + bsz = nbytes; - memcpy(bytes, + memcpy(bytes + got, msg->stream.data.buf + msg->stream.data.offset, - nbytes); + bsz); + got += bsz; + nbytes -= bsz; - msg->stream.data.offset += nbytes; + msg->stream.data.offset += bsz; if (msg->stream.data.offset == msg->stream.data.len) { virFDStreamMsgQueuePop(fdst, fdst->fd, "pipe"); virFDStreamMsgFree(msg); } - ret = nbytes; - + ret = got; + if (nbytes > 0) { + goto more; + } } else { retry: ret = read(fdst->fd, bytes, nbytes); -- 2.43.0

2 3

[PATCH v4 0/5] nwfilter: add nwfilter nftables driver
by Dion Bosschieter 12 Feb '26

12 Feb '26

This series aims to implement nftables as a backend driver for the nwfilter feature. The idea is that eventually it will replace the ebiptables driver and provide an easy way for users to switch from one driver to another. The first 2 patches are moving of functions and renames, meant to decouple nwfilter from the currently only existing ebiptables driver. The 3rd patch introduces the new nwfilter driver. After which nwfilter allows users to choose it in the 4th patch. The last patch introduces unit testing of the new nftables driver. - Implemented very basic nwfilter.conf reading and choosing a nwfilter driver based on the name of the drivers (nftables/ebiptables). Defaults to the nftables driver, based on the firewall_backend_priority meson option, following the bridge driver logic. - Resolves issue https://gitlab.com/libvirt/libvirt/-/issues/603 benchmarks showed that the amount of iifname jumps for each interface with is the cause for this. Switched the nftables driver towards a vmap (verdict map) so we can have 1 rule that jumps to the correct root input/output chain per interface. Which improves throughput as when the number of interface check and jump rules increases the throughput decreases. The issue describes the interface matching works using the interface name and the majority of the effort is the strncpy, this commit also switches nftables to an interface_index compare instead. However, just using the interface_index is not enough, the amount of oif and iif jump rules causes quite a performance issue, the vmap instead solves this. - Split rules into separate tables: "libvirt-nwfilter-ethernet" and "libvirt-nwfilter-other" to preserve existing firewall behavior. - Reworked chain logic for clarity with root -input/-output chains per interface. input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). - Stuck with prerouting and postrouting as hooks for input / output on the -ethernet and -other table. This makes it easier to merge the tables in the future. Saving management of two tables and decreasing the amount of tables a packet sees. Currently ebtables filtering happens via PREROUTING and POSTROUTING hooks, while ip/ip6tables filtering happens in the output/forward hooks. - Stuck with 2 tables for compatibility reasons with eb iptables, unifying into 1 table will break users firewall definitions, which depend on being able to do accepts on ethernet rules (which currently get defined via ebtables) and additional filtering via the ip rules (which currently get defined via ip(6)tables). The nwfilter_nftables_driver keeps splitting the ethernet and non ethernet (other) rules in seperate tables "libvirt-nwfilter-ethernet" and "libvirt-nwfilter-other". - Rewrote chain logic, so it is easier to understand, input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). -ethernet and -other table follow the same style and hook in the same way. - Simplified conntrack handling: rules with accept+conntrack are duplicated to the opposite chain for symmetric behavior, to support the existing ebiptables logic. - Firewall updates continue use tmp names for atomic replacement. Unsupported nwfilter features (for now): - STP filtering - Gratuitous ARP filtering - IPSets (potential future support via nft sets) - Reject due to filtering in pre/postrouting, using drop instead of reject, copying logic from existing ebiptables ebtables actions Future improvements: - Use `nft -f` for atomic rule application. - Optional single-table mode via nwfilter.conf. - Optimize boot phase with chain hash comparison. --- Changes in v4: - Fix rarp nft commands "arp saddr ether" "arp daddr ether" - Filter chain creation, don't create unnecessary chains - Apply danpb seperate argument suggestion - Fix table not existing errors in drop all rules - Fix table not existing errors in apply basic rules Changes in v3: - Renamed -other to -inet - Renamed - to _ in table names - Updated rule / chain sorting on ethernet table to to copy ebtables logic - Fix possible broken revert path - Fix remove rules not working in some cases, EBUSY - Shared functions camel case commit - Rename config option - Add extra config params, enable_trace, enable_counters This required passing the config struct to the ebip/nft nwfilter drivers - Add extra augeaus files Changes in v2: - Rename {ebip,nf}tables specific test files in 1 directory instead of seperating them in different directories. - Added default nwfilter.conf file in git, documented including augeas files - Replaced hardcoding of default driver based on existing firewall_backend_priority meson option. - Added nwfilter_driver_conf.{h,c} for configuration handling, to match the common pattern used in other drivers. Dion Bosschieter (5): nwfilter: rename generic names to virNWFilter* and CamelCase nwfilter: move shared nwfilter driver functions into nwfilter_tech_driver.c nwfilter: add nwfilter nftables driver nwfilter: allow use of nftables nwfilter driver via nwfilter.conf nwfilter: add unit tests and test data for nwfilter nftables driver libvirt.spec.in | 7 + po/POTFILES | 3 + src/conf/virnwfilterobj.h | 20 - src/nwfilter/libvirtd_nwfilter.aug | 45 + src/nwfilter/meson.build | 39 + src/nwfilter/nwfilter.conf.in | 50 + src/nwfilter/nwfilter_driver.c | 66 +- src/nwfilter/nwfilter_driver_conf.c | 214 + src/nwfilter/nwfilter_driver_conf.h | 69 + src/nwfilter/nwfilter_ebiptables_driver.c | 671 +-- src/nwfilter/nwfilter_ebiptables_driver.h | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 65 +- src/nwfilter/nwfilter_gentech_driver.h | 5 +- src/nwfilter/nwfilter_nftables_driver.c | 2518 +++++++++++ src/nwfilter/nwfilter_nftables_driver.h | 28 + src/nwfilter/nwfilter_tech_driver.c | 249 ++ src/nwfilter/nwfilter_tech_driver.h | 55 +- src/nwfilter/test_libvirtd_nwfilter.aug.in | 7 + tests/meson.build | 2 + tests/nwfilternftablestest.c | 426 ++ .../ah-ipv6-linux.nftables.args | 310 ++ .../ah-linux.nftables.args | 304 ++ .../all-ipv6-linux.nftables.args | 292 ++ .../all-linux.nftables.args | 286 ++ .../arp-linux.nftables.args | 231 + .../nwfilterxml2firewalldata/arp.nftables.xml | 27 + .../comment-linux.nftables.args | 510 +++ .../conntrack-linux.nftables.args | 198 + .../esp-ipv6-linux.nftables.args | 310 ++ .../esp-linux.nftables.args | 304 ++ .../example-1-linux.nftables.args | 268 ++ .../example-2-linux.nftables.args | 352 ++ .../hex-data-linux.nftables.args | 384 ++ .../icmp-direction-linux.nftables.args | 238 ++ .../icmp-direction2-linux.nftables.args | 238 ++ .../icmp-direction3-linux.nftables.args | 184 + .../icmp-linux.nftables.args | 256 ++ .../icmpv6-linux.nftables.args | 328 ++ .../igmp-linux.nftables.args | 304 ++ .../ip-linux.nftables.args | 205 + .../ipt-no-macspoof-linux.nftables.args | 172 + .../ipv6-linux.nftables.args | 511 +++ .../iter1-linux.nftables.args | 304 ++ .../iter2-linux.nftables.args | 3760 +++++++++++++++++ .../iter3-linux.nftables.args | 430 ++ .../mac-linux.nftables.args | 184 + .../rarp-linux.nftables.args | 231 + .../sctp-ipv6-linux.nftables.args | 328 ++ .../sctp-linux.nftables.args | 328 ++ .../target-linux.nftables.args | 466 ++ .../target2-linux.nftables.args | 322 ++ .../tcp-ipv6-linux.nftables.args | 328 ++ .../tcp-linux.nftables.args | 476 +++ .../udp-ipv6-linux.nftables.args | 328 ++ .../udp-linux.nftables.args | 328 ++ .../udplite-ipv6-linux.nftables.args | 310 ++ .../udplite-linux.nftables.args | 304 ++ .../vlan-linux.nftables.args | 271 ++ tests/nwfilterxml2nftfirewalltest.c | 438 ++ 59 files changed, 19320 insertions(+), 569 deletions(-) create mode 100644 src/nwfilter/libvirtd_nwfilter.aug create mode 100644 src/nwfilter/nwfilter.conf.in create mode 100644 src/nwfilter/nwfilter_driver_conf.c create mode 100644 src/nwfilter/nwfilter_driver_conf.h create mode 100644 src/nwfilter/nwfilter_nftables_driver.c create mode 100644 src/nwfilter/nwfilter_nftables_driver.h create mode 100644 src/nwfilter/nwfilter_tech_driver.c create mode 100644 src/nwfilter/test_libvirtd_nwfilter.aug.in create mode 100644 tests/nwfilternftablestest.c create mode 100755 tests/nwfilterxml2firewalldata/ah-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ah-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/arp-linux.nftables.args create mode 100644 tests/nwfilterxml2firewalldata/arp.nftables.xml create mode 100755 tests/nwfilterxml2firewalldata/comment-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/conntrack-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/hex-data-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmpv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/igmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ip-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipt-no-macspoof-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/mac-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/rarp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/vlan-linux.nftables.args create mode 100644 tests/nwfilterxml2nftfirewalltest.c -- 2.43.0

2 11

[PATCH] network: add comment to table that it belongs to libvirt
by Daniel P. Berrangé 12 Feb '26

12 Feb '26

From: Daniel P. Berrangé <berrange(a)redhat.com> The result looks like $ nft list ruleset ...snip... table ip6 libvirt_network { comment "Managed by libvirt for virtual networks: https://libvirt.org/firewall.html#the-virtual-network-driver" chain forward { ...snip... This should reduce the number of people wondering why these rules exists. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/network/network_nftables.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/network/network_nftables.c b/src/network/network_nftables.c index cffe8072f5..cd46ff8d83 100644 --- a/src/network/network_nftables.c +++ b/src/network/network_nftables.c @@ -61,6 +61,10 @@ VIR_LOG_INIT("network.nftables"); #define VIR_NFTABLES_PRIVATE_TABLE "libvirt_network" +#define VIR_NFTABLES_COMMENT \ + "{ comment \"Managed by libvirt for virtual networks: " \ + "https://libvirt.org/firewall.html#the-virtual-network-driver\"; }" + /* nftables backend uses the same binary (nft) for all layers, but * IPv4 and IPv6 have their rules in separate classes of tables, * either "ip" or "ip6". (there is also an "inet" class of tables that @@ -165,7 +169,9 @@ nftablesPrivateChainCreate(virFirewall *fw, if (!tableMatch) { virFirewallAddCmd(fw, layer, "add", "table", - layerStr, VIR_NFTABLES_PRIVATE_TABLE, NULL); + layerStr, VIR_NFTABLES_PRIVATE_TABLE, + VIR_NFTABLES_COMMENT, + NULL); } for (i = 0; i < data->nchains; i++) { -- 2.53.0

3 2