Thanks for the summary, Cathy. I haven't caught up with the entirety of this thread, so apologies if I'm rehashing things.
Cathy Zhou wrote: > Meem and I had a discussion about the link name zone administration > yesterday, and here is a summary: > > we both feel strongly that local zone administration should not run into > random errors because link names are already used in other zones, which > the local zone doesn't have any knowledge of. Erik Nordmark brought up a good argument in defense of this approach recently in the context of IP tunnel creation in non-global zones, and it has to do with migration of networking configuration data between systems or zones. If zones' interface names are restricted by interface names in use in other zones, then migration of configuration to another system that might have a different set of zones each with different interface names might also fail randomly. This is highly undesirable. > On the current Nevada release, one can plumb interfaces in two different > zones with the same interface name ip.tun0 without a problem. That > matches what we think is optimal - link name should be per-zone instead > of per-system. Agreed. > we also discussed about dladm operation within a zone and think there > are still lots of questions need to be answerer. At this time, we'd > rather not to include that in the scope of the Clearview project, that > we just support implicit iptun creation to preserve the backward > compatibility with current Nevada. Interestingly, allowing "ifconfig plumb ip.tun0" from within a non-global zone makes it automatically possible for someone within that zone to do "dladm create-iptun -T ipv4 ip.tun0". They call the same API and execute the same code. We'd have to go out of our way to restrict the use of dladm. As such, I'm not sure if we can avoid having this discussion. > One question we talked about is that when the global zone assigns a > physical link to a exclusive local zone, say zone a, does that mean that > in zone a, one can create VLANs and aggregations over this physical > link? Note that today, the global zone can assign a VLAN over the same > physical link to another exclusive zone, say zone b. Because of this, > the administrator in zone a might see random errors when creating VLANs > aggregations in that local zone. My feeling is that once we overcome the technical hurdles in the way of allowing "ifconfig plumb ip.tun0" to work within a non-global zone (one of which is node creation in /dev/net), then we'll be able to easily implement VLAN and aggregation creation from within a non-global zones. > There surely are some questions that need some more thoughts. For > example, do we start linkmgmtd in each exlusive local zone? and if so, > how to manage the link id name spaces etc. But I think this discussion > can be a start. linkmgmtd coordination is interesting. Perhaps a single daemon in the global zone with a doors interface that non-global zones can access is one possibility? -Seb
