Re: QMP: exposing the host TAP interface name

["Tim Foerster" via qemu development <qemu-devel@nongnu.org>]

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