[Bug 185619] [VNET] Name conflict not checked when a child vnet goes away and returns its interface(s) back to the parent

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185619

Zhenlei Huang <zlei@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kp@freebsd.org,
                   |                            |melifaro@FreeBSD.org

--- Comment #4 from Zhenlei Huang <zlei@FreeBSD.org> ---
(In reply to Eugene M. Kim from comment #0)
> Option 2 is more predictable and deterministic, at the cost of more complex 
> implementation.  And it doesn't cover the case of pseudo-interfaces created locally 
> inside a vnet, because such interfaces have no shadowed name in the parent vnet; 
> falling back to option 1 would be one way to solve this.

For pseudo-interfaces created locally inside a vnet (n), their's `home-vnet` is
same with its vnet (n) and will be destroyed on vnet destroy, so no name
conflicts.

I think that is a design defeat, as FreeBSD assumes the name of interface is
unique in one vnet (namespace) and it allows renaming interfaces.

An combination of Option 1 and Option 2:
> Option 1: Give the returned interface a random, unique name.
> Option 2: When injecting an interface into a child vnet, leave a "shadow" of its
> name in the parent vnet.  Don't let other interfaces in the parent vnet take the 
> shadowed name, and give the shadowed name to the moved interface when it returns 
> from the child vnet.

I think we may give the interface a global unique unchangeable name (called
xname) on create (physical or cloned ones), and refine current name as an alias
and guarantee the uniqueness only within its vnet (namespace). (In practical an
interface may have multiple aliases).

On vnet destroy an interface returns to its home-vnet, if the alias name
conflicts we can remove the alias.

That may require KPI/ABI changes.

Linux has similar mechanic called `altname`, see
https://lwn.net/Articles/794289/ 

CC @kp and @melifaro

-- 
You are receiving this mail because:
You are the assignee for the bug.