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

> 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

Reply via email to