Bug 2025296 - [RFE] Guest agent should report interfaces from non root network namespaces
Summary: [RFE] Guest agent should report interfaces from non root network namespaces
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: 9.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Kostiantyn Kostiuk
QA Contact: dehanmeng
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-21 14:13 UTC by oshoval
Modified: 2022-11-29 21:46 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Feature Request
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-103432 0 None None None 2021-11-21 14:16:00 UTC

Description oshoval 2021-11-21 14:13:56 UTC
Description of problem:

Guest agent reports only interfaces from the root network namespace,
in case an interface is on other namespace it won't be reported


Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:

Move an interface to other namespace

sudo su
ip netns add dummyns
ip link set eth0 netns dummyns

run:
virsh qemu-agent-command vm_name '{"execute":"guest-network-get-interfaces"}'

Actual results:

eth0 should be reported

Expected results:

eth0 isn't reported anymore

Additional info:

Comment 2 Qianqian Zhu 2021-11-22 03:27:02 UTC
Hi Shoval,

Does it only support on RHEL8? Would you help clone it to RHEL9 if we also support it there?

Thanks,
Qianqian

Comment 3 oshoval 2021-11-22 07:25:52 UTC
Hi
It is not just for RHEL8, it is a general RFE for the guest agent from my understanding
just wasn't sure what to fill in the product field,

I am not part of RHEL product, but part of CNV (kubevirt).

Comment 4 John Ferlan 2021-11-23 18:42:38 UTC
Moving this to RHEL9 for action. Once a resolution is closer we can make the decision to clone to RHEL8. No sense in having 2 bugs for now.

Assigned to developer w/ Medium priority and added CNV as dependent product.

Comment 5 Marc-Andre Lureau 2021-11-23 20:36:14 UTC
should the command take an optional argument with the name of the namespace to query? (default to root)

The current code simply uses getifaddrs(), which doesn't know about namespaces.

Most likely we will have to implement this with netlink socket instead.

I wonder if those advanced Linux-specific usages aren't better served by simply forwarding to guest-exec "ip -j"...

Comment 6 oshoval 2021-11-24 07:24:38 UTC
I think that it would be good to have a parameter
1. default - root (as you said)
2. ns_name - specific ns query
3. all - to fetch all namespaces

Might worth to consider telling what ns the interface belong to in case "all" is used.

I don't think guest-exec is a good idea, its too intrusive, and the guest can disable it IIRC,
while still desire to get the interfaces via the common API.

Thanks

Comment 7 Marc-Andre Lureau 2021-11-24 09:13:47 UTC
It's correct that guest-exec is often disabled.

However, qemu-ga commands are meant to be portable. You are asking for Linux-specific behaviour and results. I am not fond of reimplementing Linux "ip" in qemu-ga.

Maybe we could have a finer allow-guest-exec command list?

Or a "guest-exec-ip" ?

I think we should bring the discussion of those enhancements on the QEMU ML.

Comment 11 Edward Haas 2022-01-19 09:43:02 UTC
(In reply to Marc-Andre Lureau from comment #7)
> It's correct that guest-exec is often disabled.
> 
> However, qemu-ga commands are meant to be portable. You are asking for
> Linux-specific behaviour and results. I am not fond of reimplementing Linux
> "ip" in qemu-ga.

Although this is Linux specific, the user of the information is interested to
learn about all interfaces defined in the guest, even if they are hidden
by a namespace today.
Adding a namespace field does not collide with other platforms, they will just
have this field marked with the root ns I guess.

From an implementation perspective, I guess even today the information is
collected per the platform, its not that we have a standard in place. Isn't this the case?

> 
> Maybe we could have a finer allow-guest-exec command list?
> 
> Or a "guest-exec-ip" ?

I do not think that we can use such an option for production usage.
We need an one-way direction report, like the current one is providing.

The usages of network namespaces has increased substantially in the last few years.
VM/s which run kubernetes nodes are widely used today and there everything is handled
in namespaces.
Without this information, it becomes hard to troubleshoot guests and observe the real
network state.

Comment 12 Marc-Andre Lureau 2022-01-19 10:13:21 UTC
(In reply to Edward Haas from comment #11)
> (In reply to Marc-Andre Lureau from comment #7)
> > It's correct that guest-exec is often disabled.
> > 
> > However, qemu-ga commands are meant to be portable. You are asking for
> > Linux-specific behaviour and results. I am not fond of reimplementing Linux
> > "ip" in qemu-ga.
> 
> Although this is Linux specific, the user of the information is interested to
> learn about all interfaces defined in the guest, even if they are hidden
> by a namespace today.
> Adding a namespace field does not collide with other platforms, they will
> just
> have this field marked with the root ns I guess.
> 
> From an implementation perspective, I guess even today the information is
> collected per the platform, its not that we have a standard in place. Isn't
> this the case?

The code is fairly generic today for Unix, using mostly POSIX calls.

> 
> > 
> > Maybe we could have a finer allow-guest-exec command list?
> > 
> > Or a "guest-exec-ip" ?
> 
> I do not think that we can use such an option for production usage.

Why not? Calling ip directly (it has json output we could embed), would be straightforward and more future proof. The implementation of "ip" with netlink socket isn't trivial...

> We need an one-way direction report, like the current one is providing.

What do you mean?

Comment 13 Edward Haas 2022-01-19 13:15:54 UTC
(In reply to Marc-Andre Lureau from comment #12)
> > > Or a "guest-exec-ip" ?
> > 
> > I do not think that we can use such an option for production usage.
> 
> Why not? Calling ip directly (it has json output we could embed), would be
> straightforward and more future proof. The implementation of "ip" with
> netlink socket isn't trivial...
> 
> > We need an one-way direction report, like the current one is providing.
> 
> What do you mean?

I meant that we cannot execute command into the guest, this is intrusive.
No one, even not the operator of the VM is allowed to intrusively access or
perform operation in the guest. It has operational and security implications.

When I say "one-way direction", I mean data can only get out of the guest via
the agent report, nothing is inputted, not even restricted commands.

Comment 14 Marc-Andre Lureau 2022-01-19 13:38:11 UTC
(In reply to Edward Haas from comment #13)
> (In reply to Marc-Andre Lureau from comment #12)
> > > > Or a "guest-exec-ip" ?
> > > 
> > > I do not think that we can use such an option for production usage.
> > 
> > Why not? Calling ip directly (it has json output we could embed), would be
> > straightforward and more future proof. The implementation of "ip" with
> > netlink socket isn't trivial...
> > 
> > > We need an one-way direction report, like the current one is providing.
> > 
> > What do you mean?
> 
> I meant that we cannot execute command into the guest, this is intrusive.
> No one, even not the operator of the VM is allowed to intrusively access or
> perform operation in the guest. It has operational and security implications.
> 

qga is not a stand-alone binary. It already exec a couple of helper programs, ranging from: shutdown, passwd, hwclock, hooks, and of course arbitrary commands if allowed to via guest-exec.

We could simply call "ip" with a _restricted set_ of arguments, in the back of a top-level "guest-linux-ip" command..

> When I say "one-way direction", I mean data can only get out of the guest via
> the agent report, nothing is inputted, not even restricted commands.

Comment 15 Edward Haas 2022-01-25 07:18:53 UTC
(In reply to Marc-Andre Lureau from comment #14)
> qga is not a stand-alone binary. It already exec a couple of helper
> programs, ranging from: shutdown, passwd, hwclock, hooks, and of course
> arbitrary commands if allowed to via guest-exec.

It provides an abstracted API to perform actions on the guest OS and this
is exactly what we want in this request.
The use of arbitrary commands is not enabled by default because it is not
something one will like to expose due to its potential security risk and
arguable improper API for production use.

> We could simply call "ip" with a _restricted set_ of arguments, in the back
> of a top-level "guest-linux-ip" command..

I understand that this is an option, however, as a user of this API, I probably
do not know what guest OS is running, which is why (I guess) we have all the
other API commands abstracting away this detail.
We could probably examine the OS info provided from another command and based
on that act, but this complicates the client.

I believe that network namespaces is today a basic property of a network interface,
therefore, it fits as another property to the existing interfaces report.
If this is not possible, then adding another command can work as well, but we
would prefer to have this abstracted away (how you use it and with what commands).
For platforms that do not support it, no info needs to be returned or the fields can
be set with a blank or default values.

Comment 16 Marc-Andre Lureau 2022-01-26 20:47:14 UTC
(In reply to oshoval from comment #6)
> I think that it would be good to have a parameter
> 1. default - root (as you said)
> 2. ns_name - specific ns query
> 3. all - to fetch all namespaces
> 

netns are referred to by fd or path. 

The convention on Linux is to mount nsfs on /var/run/netns/NAME.

But there might be other netns elsewhere and discovering them is tricky. See also https://unix.stackexchange.com/questions/505112/how-do-i-find-all-interfaces-that-have-been-configured-in-linux-including-those.

Can we limit this argument to ns names available on /var/run/netns ?

Comment 17 Edward Haas 2022-01-27 11:10:16 UTC
(In reply to Marc-Andre Lureau from comment #16)
> Can we limit this argument to ns names available on /var/run/netns ?

It is indeed odd that no library/tool exist that will provide such information already.
I think that this BZ originated from the containers ecosystem, and there the network
namespace is bind to the pid.
Therefore, IMO it is worth starting from there.

I guess the next common usage are VNF/s (e.g. routers, firewalls, etc), which may
use mount points like /var/run/netns. It is also useful for testing.

IMO we better start with the containers use case and from there expand per need.

There is another option, which will benefit not only here but in general: Ask
the kernel community to expose the active network namespaces through a dedicated
centralized API (netlink?).

Comment 18 oshoval 2022-02-16 09:33:31 UTC
> netns are referred to by fd or path. 
> 
> The convention on Linux is to mount nsfs on /var/run/netns/NAME.
> 
> But there might be other netns elsewhere and discovering them is tricky. See
> also
> https://unix.stackexchange.com/questions/505112/how-do-i-find-all-interfaces-
> that-have-been-configured-in-linux-including-those.
> 
> Can we limit this argument to ns names available on /var/run/netns ?

Hi
I agree with Edy (comment #17) that we should stick to the most common case first, i.e containers
(the link of stackexchange also mention this is the common case IIUC)
later on it can be extended, step by step please

Thanks

Comment 19 John Ferlan 2022-11-29 21:46:00 UTC
Reassigning since you've been picking up qga tasks from Marc-Andre.

May be worth the cycles to just figure out what is necessary given the above and the reality that this bug hasn't had cycles for 9+ months.


Note You need to log in before you can comment on or make changes to this bug.