Re: [PATCH RFE] conf: Add extraArgs option to passt backend
On Wed, Jun 25, 2025 at 11:50 AM Daniel P. Berrangé <berrange(a)redhat.com wrote:
--
Quique Llorente
CNV networking Senior Software Engineer
Red Hat EMEA
ellorent(a)redhat.com
@RedHat Red Hat Red Hat
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(a)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.
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 :|
Attachments:
- attachment.html (text/html — 4.5 KB)