Here's what the project team (work done by Eric & Mike Cc'ed) 
implemented to address the upgrade :

In both bfu and the postinstall script of SUNWcnetr:
- We parse /etc/hostname*.* and come up with list of linknames & VIDs 
configured in the global zone.
- From the output of zonecfg info net of each configured zone, we get 
the liist of PPA hack VLANs for the zones.
- With these two lists, we add the appropriate dladm create-vlan 
commands to /var/svc/profile/upgrade_datalink
Upon reboot, the right vlan data links get created.

I'll capture that in the section 4.3 of the opinion.

Thanks,

Kais & Eric.

On 12/01/08 12:05, James Carlson wrote:
> 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.
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081201/a2724f05/attachment.html>

Reply via email to