Joe,
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)
or
- 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..
Regards,
Thomas
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
zones-discuss@opensolaris.org
--
Thomas Wagner
+49-171-6135989 http://www.wagner-net.net
___
zones-discuss mailing list
zones-discuss@opensolaris.org
