liveupgrade uses a different logic for zones-root filesystems/mountpoints.

If the physical mountpoint /zonesroot stays the same, then it 
copies the zone-root and renames the copy like:

/zoneroot/zone_name_one  -->> /zoneroot/zone_name_one-s10u4-patched

later on, if you boot the new environment, the old mountpoint
for the zone may be named as /zoneroot/zone_name_one-s10u4

If you use a dedicated filesystem for each zones-root, then you
might relocate like this (untested):

   -m /zoneroot/zone_name_one:/dev/md/dsk/d103:ufs,mirror \
   -m /zoneroot/zone_name_one:/dev/md/dsk/d23:detach,attach,preserve

This would detach the mirror for this zone, and recreate a new
top-level metadevice but could avoid the copy (in subsequent LU runs,
probably not the first since the path changes).

So you have two choices:
 - copy all the zones-roots and stay in the same physical Filesystem
   with alternate zones-root-mountpoints (/etc/zones/* config gets adjusted)
 - use a different Filesystem but each zone has it's own Filesystem

If anyone knows other options, pls jump in :-).

The above is from my experience on Nevada/OpenSolaris around 80-84..


On Wed, Mar 26, 2008 at 12:36:50PM -0700, Moore, Joe wrote:
> I'm seeing some odd behavior when I'm trying to upgrade my Solaris 10u4
> (sparc) system.
> I have SVM configured with a mirrored root (d0) and /zoneroot (d3)
> filesystems:
> d0 -m d10 d20
> d10 1 1 c1t0d0s0
> d20 1 1 c1t1d0s0
> d3 -m d13 d23
> d13 1 1 c1t0d0s3
> d23 1 1 c1t1d0s3
> There's a sparse zone with zoneroot at /zoneroot.
> My lucreate command is:
> lucreate -n s10u4-patched \
>       -m /:/dev/md/dsk/d100:ufs,mirror \
>       -m /:/dev/md/dsk/d20:detach,attach,preserve \
>       -m /zoneroot:/dev/md/dsk/d103:ufs,mirror \
>       -m /zoneroot:/dev/md/dsk/d23:detach,attach,preserve
> So if I'm reading things right, this should split off the 2nd submirror
> from the 2 filesystems, and preserve their contents when creating the
> new BE.  The BE creation should be (relatively) quick -- just the
> compare database generation.  And when I don't have a zone defined
> (zoneadm detatch and zonecfg delete), it does go very quickly.
> But when the zone is present, lucreate does copy the zoneroot via cpio,
> even though that filesystem should have been preserved.
> Why?  Can't zulu recognize that the filesystem (zoneroot) is already in
> place?  Any thoughts?
> --Joe
> _______________________________________________
> zones-discuss mailing list

Thomas Wagner
zones-discuss mailing list

Reply via email to