Hi On Wed, Sep 16, 2026 at 10:22 AM Tim Foerster via qemu development <[email protected]> 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
