Re: Thoughts on interface modes / multiple guest addresses

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 5 Jan 2026 15:26:34 +1100
David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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