On (06/02/10 12:01), Edward Pilatowicz wrote: > > > 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?
yes, you are correct, there's no way to differentiate between the two, as I too later realized. And yes, the property is stored within the ngz. So unless we have some special hooks that clears the property before detach, it will not get cleared by itself. But that behavior would match the behavior of other properties (e.g., dladm/datalink.conf or ipadm.conf or other smf properties) across detach/attach of exclusive IP zones. > > 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 not possible? But I already have a prototype for this (for both "do it on every boot" and "do it on first boot only") which correctly picks up the current zonecfg address/defrouter information at all times. What part do you think would not be possible? > 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 The behavior matches the behavior for DHCP, where you always acquire both the IP address and default router from the "address acquisition protocol" (DHCP, or "from_gz", where the latter is set up as kernel nvlists). As with DHCP, if you acquire the from_gz address, you also get the default route. If, otoh, you persistently delete the from_gz interface using ipadm, you do not acquire either address or defrouter (which would be analogous to not starting DHCP). > 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. that's perhaps a topic that we (you, Erik, I) should discuss offline this friday.. one thing to remember is that the changes to the value of the IP address or default router *must* always be made via zonecfg in the GZ, regardless of whether we configure the interfaces on every boot, or only on the first boot. It's only for persistent control of the IP interface properties that the "ipmgmtd is involved in setting up config on the first boot only" change was introduced. > 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. _______________________________________________ opensolaris-arc mailing list [email protected]
