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 Devel wrote:
> > 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 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.