Cathy Zhou wrote: >>> 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. >> > Hmm, maybe it is not a fair comparison, but in my implementation, > allowing ifconfig bge1000 plumb but not allowing dladm create-vlan -d > bge0 -v 1 is not very difficult, as it goes through different code-path.
In the current clearview_iptun code, ifconfig attempts to open /dev/net/ip.tun0. If that fails (because /dev/net/ip.tun0 doesn't exist), then ifconfig calls into libiptun to create the ip.tun0 link, then does the open again. This requires ifconfig to know which special interface names correspond to "backward compatible" IP tunnel interface names so that it doesn't attempt this dance with any other interface names. These are "ip.tun#", "ip6.tun#", and "ip.6to4tun#" Perhaps this model can be revisited to work more like implicit VLAN creation, where the creation is driven by /dev/net itself rather than by ifconfig. I would think it entirely possible, and it would keep ifconfig free of this kludge... This is a bit of a tangent from this current discussion, but what do others think about this? Regardless, I really don't see why we'd want to explicitly restrict the creation of tunnels using dladm to the global zone if it just works with no additional code given the current design. >> 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. >> > I might miss something, but to create /dev/net nodes in a local zone is > not difficult. Actually yesterday in my prototype I can create VLAN > using ifconfig plumb bge1000 in a exlusive zone with no problem. I only > add the restriction code to disallow creation of the /dev/net/bge1000 in > a local zone today. The code has been putback to the clearview-uv gate, > you can have a look and see whether it will help to create the /dev/net > node for iptuns. Okay. I'll have a look at your code. I'm in the process of migrating the clearview_iptun gate to be a child of the UV gate anyway. > > But I think the questions I mentioned still need to be answered. A restriction on use of dladm from within a non-global zone seems artificial to me, unless there are technical issues preventing its use that I don't yet understand. What reason would there be to restrict the use of dladm within non-global zones? Is it technical? >>> 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? >> > I'd like to see the discussion result of this thread, especially how the > link name namespace in global zone would look like. Okay. I have no problem with your original proposal of having separate namespaces for each zone, and not allowing observability of those namespaces in the global zone. -Seb
