QMP: exposing the host TAP interface name

QMP: exposing the host TAP interface name

[Tim Foerster via qemu development]

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?

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.

Is there an existing alternative I've missed?

Thanks!

[1] https://docs.kernel.org/userspace-api/landlock.html#ptrace-restrictions

Re: QMP: exposing the host TAP interface name

[Marc-André Lureau]

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

thanks

-- 
Marc-André Lureau

Re: QMP: exposing the host TAP interface name

[Tim Foerster via qemu development]

Hi,

On Wed Sep 16, 2026 at 3:18 PM CEST, 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.

Well, I know about this concern, I was mainly trying to open a door there.
Not sure how flexible we will end up being here. I also did not get into which
patterns should be part of the HMP and which should only be exposed to the QMP
layer.

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

I like the idea of having a `query-network-tap(name: hostnet0)`. I can
also try to send a patch, but wanted to collect your opinions first.
Once we agree on an API layout, I'll give it a try.

>
> Let see what other people & maintainers think
>
> thanks

Re: QMP: exposing the host TAP interface name

[Daniel P. Berrangé]

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

Re: QMP: exposing the host TAP interface name

[Tim Foerster via qemu development]

On Thu Sep 17, 2026 at 10:27 AM CEST, Daniel P. Berrangé wrote:
> 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.

Hi Daniel,

Thanks, the generic query-netdevs approach makes sense to me.

One thing I'd like to clarify is the intended scope: should this expose
live backend details broadly for convenience, or focus on information
an external management process cannot obtain without additional privileges?

My original problem is the latter: reliably identifying the host TAP
interface associated with a qemu netdev currently requires
CAP_SYS_PTRACE in my setup. qemu already owns the FD and can obtain
the name directly.

I'd be comfortable starting with the current TAP interface name for
both tap and bridge backends. I'd query it via TUNGETIFF even when
ifname was originally supplied, since the interface may have been
renamed on the host.

Would that fit your intended scope? For bridge, would you prefer
extending NetdevBridgeOptions with ifname, or keeping such runtime
details in a separate query result type?

Thanks,
Tim

>
> With regards,
> Daniel

Re: QMP: exposing the host TAP interface name

[Daniel P. Berrangé]

On Thu, Sep 17, 2026 at 11:13:30AM +0200, Tim Foerster wrote:
> On Thu Sep 17, 2026 at 10:27 AM CEST, Daniel P. Berrangé wrote:
> > 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.
> 
> Hi Daniel,
> 
> Thanks, the generic query-netdevs approach makes sense to me.
> 
> One thing I'd like to clarify is the intended scope: should this expose
> live backend details broadly for convenience, or focus on information
> an external management process cannot obtain without additional privileges?
>
> My original problem is the latter: reliably identifying the host TAP
> interface associated with a qemu netdev currently requires
> CAP_SYS_PTRACE in my setup. qemu already owns the FD and can obtain
> the name directly.

I see it as primarily reflecting the current configuration that
QEMU runs with. That some of this information is dynamically
updated "live" such that it solves your ifname use case, is an
added benefit.


> I'd be comfortable starting with the current TAP interface name for
> both tap and bridge backends. I'd query it via TUNGETIFF even when
> ifname was originally supplied, since the interface may have been
> renamed on the host.

Yes, refreshing the ifname name to cope wth renames sounds reasonable

> Would that fit your intended scope? For bridge, would you prefer
> extending NetdevBridgeOptions with ifname, or keeping such runtime
> details in a separate query result type?

I would extend NetdevBridgeOptions with ifname. Conceptually it
would be reasonable for the user to set a desired ifname when
requesting the bridge to begin with, but I'm not asking you to
do that, unless you really want to go down the rabbit hole.


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

Re: QMP: exposing the host TAP interface name

[Tim Foerster via qemu development]

On Thu Sep 17, 2026 at 11:51 AM CEST, Daniel P. Berrangé wrote:
> On Thu, Sep 17, 2026 at 11:13:30AM +0200, Tim Foerster wrote:
>> On Thu Sep 17, 2026 at 10:27 AM CEST, Daniel P. Berrangé wrote:
>> > 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.
>> 
>> Hi Daniel,
>> 
>> Thanks, the generic query-netdevs approach makes sense to me.
>> 
>> One thing I'd like to clarify is the intended scope: should this expose
>> live backend details broadly for convenience, or focus on information
>> an external management process cannot obtain without additional privileges?
>>
>> My original problem is the latter: reliably identifying the host TAP
>> interface associated with a qemu netdev currently requires
>> CAP_SYS_PTRACE in my setup. qemu already owns the FD and can obtain
>> the name directly.
>
> I see it as primarily reflecting the current configuration that
> QEMU runs with. That some of this information is dynamically
> updated "live" such that it solves your ifname use case, is an
> added benefit.
>
>
>> I'd be comfortable starting with the current TAP interface name for
>> both tap and bridge backends. I'd query it via TUNGETIFF even when
>> ifname was originally supplied, since the interface may have been
>> renamed on the host.
>
> Yes, refreshing the ifname name to cope wth renames sounds reasonable
>
>> Would that fit your intended scope? For bridge, would you prefer
>> extending NetdevBridgeOptions with ifname, or keeping such runtime
>> details in a separate query result type?
>
> I would extend NetdevBridgeOptions with ifname. Conceptually it
> would be reasonable for the user to set a desired ifname when
> requesting the bridge to begin with, but I'm not asking you to
> do that, unless you really want to go down the rabbit hole.
>

Alright, at least to me the scope seems quite clear. Not sure how the
process goes from here. Do we wait for feedback from the (other)
responsible maintainers, or is this low-hanging enough to move ahead?
My goal is to just submit this patch for now and ask for help later
(feel free to be harsh with your feedback, I think I can handle it),
if that's okay with you. :D

>
> With regards,
> Daniel