> In the current implementation it's the case that a link exists before > it is assigned to a zone, so the link is already represented in the > namespace of the global zone. Will Clearview + IP Instances allow a > non-global zone administrator to change the name of a link that is > assigned to the non-global zone? > It is possible, but I would think it will be in the scope of another project.
> Your suggestion, viewed in this light, suggests that the link > namespace should be "per zone", which seems right. Maybe a necessary > consequence of this is that the global zone cannot manipulate links > that are part of a non-global zone's namespace. > I agree. But what kind of operation is seen as a manipulation of the link.? For example, whether global zone can create a VLAN or a aggregation over a physical link after the link is assigned to an exclusive zone? Whether a global zone can export a VLAN over this physical link to anther zone (which currently is valid operation)? > It also makes me wonder about whether links that are assigned to a > non-global zone should become "exclusive" to that zone - they are > removed from the global zone namespace. > That would be ideal, then the namespace split would be a clear cut. > To facilitate zone migration it would also be useful to explore > genericising[1] the link names used by a zone (i.e. switch to "link0", > "link1"). > Although it is not decided yet, but we (the Clearview project team) are planning to name the links "netN", for a fresh-install system. But for a upgraded system, we have to keep the hardward associated name for the backward compatibility reasons. Regarding the link names in a local zone, we could do the same in the future. and for simplicity reason, especially because currently the global zone and the local exclusive zone can see the same link if the link is assigned by the global zone, I would think the name for this type of links should be the same both in the global and local zones. Note for now, as ip.tun0 will be the only case a link could be created in a local zone. > The "two level" namespace could be a way out of this (prefix the link > name with that of the zone, or perhaps just a "zone" specifier as an > argument to link namespace manipulation tools). > As I described in my first mail, we don't think to have zone as an argument is a good idea. I propose to just not show local-zone-created links in the global zone. Thanks - Cathy
