Opinion for review: 2006/357 Crossbow - Network Virtualization and Resource Partitioning

[James Carlson]

Erik Nordmark writes:
> >      (There are other places this could be done, and it's unclear to
> >      me how this interacts with exclusive IP stack zones.)
> 
> FWIW if you have an exclusive-IP zone which uses bge1003 there wouldn't 
> be a /etc/hostname.bge1003 in the global zone; the zonecfg xml file is 
> the only place the global zone knows about the VLAN. (The non-global 
> zone is likely to have a /etc/hostname.bge1003, but the ngz doesn't have 
> the privileges to create the vlan.)

I wasn't sure if the VLAN was created in the global zone in that case,
or if it was just generated ad-hoc by zoneadmd.

If it's the latter, then having the upgrade (or subsequent after-boot
but before-zones) script seek out those /etc/zones/*.xml files and do
what's necessary via dladm would be the obvious solution.  It
shouldn't be hard.

> >   b) Modify ifconfig itself to recognize the VLAN naming pattern and,
> >      if the device named doesn't exist, use libdladm to create it
> >      first.
> 
> That one also has issues with exclusive-IP zones since the ifconfig 
> plumb is run in the ngz which doesn't have the privilege to create the vlan.

I didn't expect so.

> For exclusive-IP zones zoneadm(d) does issue an ioctl to tell the kernel 
> that a datalink name will be used by a zone, but I don't know exactly 
> what gld does with the ioctl and whether than can be extended to create 
> the vlan.

Yes; that'd be the equivalent of (for the global zone) modifying
ifconfig.

I don't really care which one we pick, but given that the VLAN hack
first appeared over 8 years ago and was backported to S8 and S9, I
think use is pretty widespread at this point.  Even if we think the
VLAN hack is ugly (and it _is_ ugly), compatibility -- particularly in
administrative interfaces and system configuration, if not kernel
behavior -- shouldn't be an optional feature.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677