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