David Edmondson wrote:
> On Fri, Mar 09, 2007 at 03:41:47PM +0800, Cathy Zhou wrote:
>> So today, one can do:
>>
>> # dladm set-linkprop -t zoneid=foo bge1
>> # dladm reset-linkprop -t zoneid bge1
>>
>> in a global zone to change or reset zoneid for a given link, even
>> this link has been assigned to a exclusive zone. Do you suggest that
>> we remove this support?
>
> It's necessary to have a way to move links between zones (i.e. perform
> the assignment, manipulate the namespace). If this is the way to do
> that then it would be wrong to remove it. If there is a different way
> to manipulate the namespace then perhaps this would be redundant.
I've finally caught up on this thread, and I don't have any issues with
the limited-scope clearview approach to allow tunnels to be created in
exclusive-IP zones.
But some thoughts on the longer term and larger picture.
There is a need to have some per-zone link names to allow exclusive-IP
zones to create link names (for tunnels, and down the road VLANs,
aggregations etc).
There is also a need for the global zone to be able to assign link names
to exclusive-IP zones (implicitly by zoneadmd or explicitly by dladm.)
One suggestion is to do this assignment by name space manipulations
(remove the name from the global zone) but that has certain downsides;
for one the above reset-linkprop would be problematic, but also
observing ("who is using bge3?") is hard.
As I understand David's proposal this could be handled by the name
actually changing as part of the assignment. Thus after bge3 is assigned
to zoneA its name as viewed from the GZ is some concatenation of "zoneA"
and "bge3".
But it seems to me that conceptually what happens at the *assign*
operation is much more of an *ownership* change for a file.
Thus before the assignment, changes to bge3 require the PRIV_MUMBLE and
being in the global zone. After the assignment to zoneA, changes to bge3
require PRIV_MUMBLE and being in zoneA.
Only "reset-linkprop -t zoneid" needs to be special in that the global
zone can do this (as long as zoneA isn't currently using the link.)
In this "ownership" model it naturally falls out that only the owner of
a link can use that to create aggregations, VLANs, etc.
That seems a bit different than the name space approach David was
suggesting. As I understand that model the global zone would still see
the link (with e.g. a "zoneA-bge3" name) but that doesn't inherently say
whether the global zone can modify properties for that link name, nor
whether it can use the link name to construct aggregations or VLANs.
I don't know what factors and considerations I'm missing, so feel free
to enlighten me.
Erik
