On Wed, Jun 25, 2025 at 11:50 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Jun 25, 2025 at 11:39:55AM +0200, Enrique Llorente Pastora via
On Wed, Jun 25, 2025 at 10:38 AM Pavel Hrdina <phrdina@redhat.com> wrote:
On Wed, Jun 25, 2025 at 09:40:16AM +0200, Enrique Llorente via Devel
wrote:
Add support for passing extra arguments to the passt binary through the domain XML configuration. This allows users to specify additional command-line arguments for passt that are not covered by existing structured fields.
The new extraArgs attribute is added to the backend element: <backend type='passt' extraArgs='--debug --no-dhcp -v'/>
The extraArgs string is parsed using g_shell_parse_argv() to split it into individual arguments before passing them to the passt command.
This change includes: - New field in virDomainNetBackend structure - XML schema update to allow extraArgs attribute - Parsing and formatting support in domain_conf.c - Backend comparison function update - Memory cleanup for the new field - QEMU passt integration to use the extra arguments - Comprehensive tests for both user and vhostuser interfaces
This is an RFE to gather feedback on the approach. I have a few questions for the community:
1. Is this general approach of adding extraArgs reasonable, or should we instead focus on adding specific structured fields for each
Devel wrote: passt option?
No, this is not something we would add to VM XML. If there is
something
missing from our XML it should be added as proper attribute and or element.
2. Should extraArgs be marked as unsupported/unstable in the documentation, with a clear indication that it's primarily intended for development and testing purposes?
We do have similar "feature" for QEMU where you can pass any argument you want for development/testing purposes, see [1].
Should we implement this with a new new <passt:commandline> tag under the passt backend ?
If you're wanting this in order to consume it from Kubevirt then we really need to be formally modelling the required features in the XML, not doing a passthrough as we would not expect mgmt apps like Kubevirt to consume this feature.
This is not suppose to be exposed at kubevirt interfaces at all, the use case would be for kubevirt developers to test new passt arguments not yet implemented at libvirt, so they will open a PR at kubevirt harcoding passt:commandline at the generated domain and that's it.
The QEMU passthrough is an escape hatch for ad-hoc experiments and debugging, not production usage.
With regards, Daniel -- |: https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- Quique Llorente CNV networking Senior Software Engineer Red Hat EMEA ellorent@redhat.com @RedHat Red Hat Red Hat