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 \
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)
> 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?
> zones-discuss mailing list
zones-discuss mailing list