--- For SMF, I'm not sure why this should be a problem. Zoneadm boot should block until zoneadmd has started the boot process, and even though the zone itself isn't entirely up at this point, the networking and file systems *have* been set up. If that's not working -- if depending on svc:/system/zones:default isn't enough -- then I'd consider it a bug that needs to be investigated. It ought to be fixable, and you shouldn't have to have separate waits. ---
Well, unless I'm doing something very wrong(which isn't an all too outlandish idea), that's how it looks to me. The zones-default-routes service(my ugly little script) never starts before the zones service is online, and svcs -d seems to confirm the dependency: [i]root at xxxxxxx # svcs -d zones-default-routes STATE STIME FMRI online 14:27:45 svc:/system/zones:default [/i] I just added a little "ifconfig -a > /tmp/ifconfig.out" to the top of the method script, and the aliases for the zones are indeed not up by the time the zones service has come online. As for the general concept of zones being on separate networks, is that something that just "kinda works", or is it a more generally bad idea? The boxes we're running this on are T2000's, so we just put one physical interface(ipge0) on one net, where we access the box, and we put another physical interface(ipge1) on another net, and plumb this interface without an IP address, then add the aliases for the zones to ipge1. If this is a fundamentally bad idea, it'd be nice to know before we really get going with this project :) Thanks for your reply. This message posted from opensolaris.org
