On Wed, Jun 02, 2010 at 03:03:12AM -0700, [email protected] wrote: > On (06/01/10 13:42), Edward Pilatowicz wrote: > > > > hey sowmini, > > > > so i had some concerns about one small bit below... > : > > i'm concerned about the "on the first boot" bit above. i think that > > condition may be hard to detect due to zones life cycle. some examples: > > - if a detach and attach a zone and then boot it, is that a first boot? > > - if a detach and attach a zone on another host and then boot it, is > > that a first boot? > > - if a install a zone via cloning of another zone and then boot it, is > > that a first boot? > > The "first boot" state is actually detected by an internal private property > inside ipmgmtd/ipadm, and the property is initialized exactly once. > So the latter 2 cases would constitute a "first boot" whereas the first > one would not. >
how is case 1 differentiated from case 2? last i check the zones framework doesn't differentiate the two cases. also, if the property is stored in ipmgmtd/ipadm, presumably it is stored in the ngz. (since each ngz has it's own ipmgmtd.) so how does this property get cleared during detach/attach and after a clone? > > it seems that above you've already specified the default behavior for > > all subsequent boots. so is there any reason this same behavior can't > > be applied to all boots, without having to identify a "first boot"? > > The motivation for this (based on feedback from Erik) is primarily > to allow the NGZ admin the flexibility to persistently modify > interface properties on, or even completely disable, the datalinks > handed down from the GZ to the NGZ. If we blindly set up the interface > on every boot, the Admin would have to resort to /etc/rc/*.d scripts > to do these things, which is less than optimal > > "Setting up persistent interface configuration on the first boot only" > also allows us to make the zone boot procedure parallel the Install > procedures so that, if/when we switch to using an Install profiles for > zones down the road, the changes would be minor. ok. so i understand the motivation, but i'm not sure from an implementation perspective it's possible. also, this behavior seems inconsistent with the behavior we have for default routes. for default routes specified via zonecfg, we already have the limitation that the ngz is free to delete a zonecfg specified default, but the route will re-appear after the zone is rebooted. i'm ok if we have the same behavior for network interfaces ip addresses specified via zonecfg. really, having the zone administrator change these within the zone persistently is just a workaround, if persistent change is needed it should be made via zonecfg. of course, this argument doesn't apply to other datalink properties not specified via zonecfg. for those, the user should be able to specify them and have them persist across zone reboots. ed _______________________________________________ opensolaris-arc mailing list [email protected]
