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
