Re: Thoughts on interface modes / multiple guest addresses

On Mon, 5 Jan 2026 15:26:34 +1100 David Gibson wrote:

On Thu, Dec 18, 2025 at 06:32:49AM +0100, Stefano Brivio wrote:

...

On Thu, 18 Dec 2025 14:47:06 +1100 David Gibson wrote:

...

For multi-address support there are at least four things to consider:

For the bits related https://bugs.passt.top/show_bug.cgi?id=141, I thought Jon was working on a proposal.

...

(a) What goes in our internal list of addresses to give the guest?

a.1. Everything listed with -a?

If anything is passed, yes, those, and just those (separately for IP version), because the user is clearly overriding addresses (as currently implemented and documented).

So far, so good. But including both explicit addresses and host addresses seems potentially useful to me (especially for an intermittently online host). It's not the first step, but I think we want to think about how we'd allow this.

I'd really keep it for much later and I didn't, on purpose, add this to https://pad.passt.top/p/netlinkMonitor. But I guess we could eventually have some pointers / special values for -a, say, -a 192.0.2.1 -a eth0/* would add all the addresses that will ever be added to eth0, while keeping 192.0.2.1 ("preferred"?). For scrapers: if, instead, you pass -a *, that will obviously add the list of filenames in the current directory as IP addresses. Not many know this, but .. is indeed a valid IPv6 address, in this paragraph.

...

...

a.2. Everything on the host?

No, because you can't assume you can configure all those addresses on a single interface. Adding multiple interfaces is something we could consider later.

Hm, depends what you mean by "can". The only case I can see they really can't be configured on the same interface is if they're link-local. But AFAICT, there's nothing to really stop you putting any combination of global-scope addresses on a single interface. It will less resemble the host's configuration, but again, there are degrees of transparency not a single standard.

Hmm, right, I was actually thinking of the associated routes: it might be impossible to have meaningful routes / default gateways. We don't necessarily care though. In any case, I'd just pick addresses from the template interface for the moment being. It's the least surprising option, the closest to what we do now.

...

...

a.3. Everything on the host template interface?

Everything on the host template interface if available (as currently documented).

As a first step, sure.

...

...

a.4. A link local address we pick?

A link-local address if nothing else is available (as currently documented). This will need to be permanent for the requirement we already discussed months ago with Podman developers.

Right, but if this is permanent it potentially conflicts with link-local addresses from the host interface

Ah, well, yes, but we should never copy those. If the same address appears on the host... mark things as broken and fallback to NAT? This is something we should take care of right away, I guess. But the problem is actually pre-existing because we already have "local mode". I'm not sure if there's a problem, actually, I guess we should check. -- Stefano