On Wed, Jun 02, 2010 at 12:14:04PM -0700, [email protected] wrote: > 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? >
i'm thinking that the "on first boot only" is very difficult to detect, even after you define "first boot" (which i think is also non-trivial). also, "first boot" wouldn't take into account changes made via zonecfg(1m). > > 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). > last i check, dhcp and l3 protect are incompatible. if you specify an ip address in zonecfg, you get l3 protect and you can't use dhcp what i was trying to compare this to is the default route behavior of: if you have an interface configured with a default route in zonecfg, and you delete that default route from with the zone, and then reboot the zone, that default route will re-appear. ie, you can't persistently delete just a default route. i think that this same behavior would be fine wrt network interfaces. i mean, what is the use case for assigning an interface to a zone via zonecfg if the admin of that zone is going to persistently disable that interface? > > 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. > sure. ed _______________________________________________ opensolaris-arc mailing list [email protected]
