Re: QMP: exposing the host TAP interface name

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Sep 16, 2026 at 05:18:05PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Sep 16, 2026 at 10:22 AM Tim Foerster via qemu development
> <qemu-devel@nongnu.org> wrote:
> >
> > Hi,
> >
> > I'd like to query the host TAP interface name of a network backend via QMP, especially when the TAP FD is passed to QEMU using SCM_RIGHTS
> > and then assigned to a backend through fd=.
> >
> > In my current setup, retrieving this information externally requires CAP_SYS_PTRACE. This gives the management process far more access
> > than needed and conflicts with the Landlock sandboxing I want to apply, due to Landlock's ptrace restrictions [1].
> >
> > QEMU already owns the FD, and tap_fd_get_ifname() can retrieve the name using TUNGETIFF on Linux. For a TAP passed through fd=, x-query-
> > network currently reports the following (simplified):
> >
> > {
> >   "name": "hostnet0",
> >   "type": "tap",
> >   "info-str": "fd=42"
> > }
> >
> > I'd like to obtain the actual interface name in a structured field, regardless of how the TAP was created or passed to QEMU. For example:
> >
> > {
> >   "name": "hostnet0",
> >   "type": "tap",
> >   "info-str": "fd=42",
> >   "data": {
> >     "ifname": "vnet7"
> >   }
> > }
> >
> > Would extending x-query-network be the preferred approach? If so, would you prefer a dedicated ifname field or a type-specific data object
> > selected by the existing type field?
> 
> x- QMP commands are not meant for any other usage than debugging and
> testing (in fact, we should probably exclude them in production
> builds!). In particular, this command is currently only meant to be a
> HMP "info network" substitute for test/debugging only atm.
> 
> >
> > Personally, I'd prefer an approach that is reasonably easy to backport downstream to older QEMU releases. Since x-query-network is
> > relatively new, extending it would also require bringing that command to releases which don't have it yet, potentially increasing the
> > backporting effort.
> >
> > A type-specific data object could also accommodate additional TAP properties later, such as multiqueue mode or vnet_hdr. However, those
> > are outside my current scope, I only need the interface name.
> 
> I'd suggest a new query-network-tap(name: hostnet0) -> TAPInfo command
> for your specific case. Eventually, later, NetworkClientInfo could
> later embed that data.
> 
> Let see what other people & maintainers think

A minor nitpick about naming, on the command line and QMP command
we use the term 'netdev' for the modern config approach, rather
than "net" or "network" which is the original terminology prior
to "netdev".

On the general design though, IMHO, adding such narrow commands
is not very desirable.

On the input side we already have a data structure defined for
the input arguments to 'netdev-add', namely "Netdev", which
has fields for all the possible config options of all the
backends via a discriminated union.

In the case of TAP devices there are two scenarios - the low
level backend represented in NetdevTapOptions, and the high
level backend rerpesented in NetdevBridgeOptions.

The NetdevTapOptions struct already includes a "ifname" field.v
In the case of passing in an FD during 'netdev-add', 'fd' would
be set, while 'ifname' would be left unset.

It is reasonable to say, however, then upon querying the live
NetdevTapOptions, *only* the "ifname" field ought to be present,
either the orignal value from the user, or the derived value
from calling tap_fd_get_ifname(). 

IOW, what I'm saying is that if we want to query the live netdv
backend config, we should have:

   { 'command': 'query-netdevs', 'data': ['Netdev'] }

as a formal QAPI model.

Aside from the general plumbing work, two things to be aware of

 * After creating the netdev initially, we throw away the
   original "Netdev" struct data. We would need to preserve
   that struct, so that we can later report it back with
   query-netdevs. The TAP backend would also have to fill-in
   the 'ifname' field when given an 'fd' initially.


 * In theory someone could still be using '-net' instead
   of '-netdev', where IIUC, we will have an "Netdev"
   struct at any point.

   The idealized thing todo is to fold "-net" onto "-netdev"
   by making it synthesize a "Netdev" and then go through
   the Netdev setup code path, but their semantics aren't a
   perfect match which is why they're separate to begin
   with. So ignore that idea.

   The more practical thing to do is merely document that
   'query-netdevs' only reports on backends created via
   '-netdev' and thus declare '-net' compatibility entirely
   out of scope.

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 :|