RFC: extending QGA guest-network-get-interfaces

RFC: extending QGA guest-network-get-interfaces

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hi

Or Shoval filed two RFE for guest-network-get-interfaces:
- "Guest agent should report the interface Permanent address"
https://bugzilla.redhat.com/show_bug.cgi?id=2025303
- "Guest agent should report interfaces from non root network namespaces"
https://bugzilla.redhat.com/show_bug.cgi?id=2025296

They have in common that the implementation requires a bit more
system-specific calls than what is currently being done afaik, and may be
specific to Linux using a netlink socket.

Rather than extending guest-network-get-interfaces with system-specific and
more complex code (and re-implementing "ip" as we add more features), I am
wondering if it wouldn't make more sense to add some kind of
"guest-exec-linux-ip" command. Since "ip" can output its result as JSON
with -j, the response could be embedded, or let the client parse it from an
escaped "output" string.

Any opinion or idea?

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 1770 bytes --]

Re: RFC: extending QGA guest-network-get-interfaces

[Michal Prívozník]

On 11/24/21 15:00, Marc-André Lureau wrote:
> Hi
> 
> Or Shoval filed two RFE for guest-network-get-interfaces:
> - "Guest agent should report the interface Permanent address"
> https://bugzilla.redhat.com/show_bug.cgi?id=2025303
> <https://bugzilla.redhat.com/show_bug.cgi?id=2025303>

As I've replied in the BZ, this is something that Libvirt can improve
on. What happens when guest changes a MAC address is that
NIC_RX_FILTER_CHANGED event is emitted and libvirt processes it (mostly
to update guest XML, but not limited only to that). But, Libvirt does
not forward this event further to users. Therefore, if a mgmt app on the
top of Libvirt wants to keep track of MAC addresses, it can't do that
simply.

> - "Guest agent should report interfaces from non root network
> namespaces"  https://bugzilla.redhat.com/show_bug.cgi?id=2025296
> <https://bugzilla.redhat.com/show_bug.cgi?id=2025296>

This is a bit tricky to achieve. There's no easy way to list all nsids
(they don't form a hierarchy like other NSs). We could traverse all
mount points (be aware of mount namespaces), all PIDs (be aware of PID
namespaces) and hope we covered all net NSs (a net namespace can have no
nsid).

IOW, network NSs behave different to other namespaces.

Michal