Ben Rockwood writes: > When I say "migration" I'm refering to moving zones either: > A) From one system to another > B) Exporting a zone prior to upgrade, and then importing it after the upgrade.
I don't see how (B) can be supported with the current software. > In either case we've got two problems: > > 1) Damage or invalidation of the package database (frankly I don't care much) If you ever upgrade, install any new packages, or use patches, then I'd think it likely that having an intact packaging database would be important. > 2) Non-current /etc files. (I do care about this) Yes, and many of these are updated as a part of upgrade process via class action and packaging scripts. If the zone is detached during the upgrade, then there's no way those files will be updated, and reattaching (if forced) will leave you in an inconsistent state. > In the latter case, effectively what I need is a generic version of ACR. > > Even though migrations may not be kosher, I'm doing them today quite a bit. What I think would be needed is (possibly) some way for the 'attach' process to run the necessary upgrade against the zone before allowing it to be imported, so that the packaging and patching databases are updated along with running the appropriate migration scripts. It might be possible to hack up a version of ACR to do some of that instead, but that solution sounds far enough off the path that we really want to go with Zones that I don't think it's something worth doing. But, if you do, then propose an "ACR for detached zones" project and have at it. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
