Arindam Sarkar - Sun Microsystems writes:
> Can someone pls comment if it is a recommended practice to create a
> non-global zone such that its zoneroot is same as an existing
> mountpoint. I tried using LU with a non-global zone which has the
> zoneroot as the mountpoint.
The zone path can be the same as an existing mount point. When using
LU, you'll need to specify that mount point as an unshared file system
or LU will (or at least _should_) fail.
The zone root itself, though, cannot be a separate mount point. The
zone root ($ZONEPATH/root) is an internal implementation detail of the
> at this point, when creating the BE, you can either specify an
> explicit mountpoint for this same filesystem, or not, ie:
> # lucreate -n newbe -m /:c1t0d0s5:ufs
I would not expect that case to work well.
> Doing pkgadd of SUNWcsu to /
> pkgadd: ERROR: unable to remove file
> Wcsu>: No such file or directory
> pkgadd: ERROR: unable to unpack package <SUNWcsu> from stream
I'm not sure what would cause that sort of failure, but this looks to
me like an unrelated problem; file a bug.
> The scenario is that each zone has a dedicated filesystem. that
> filesystem is on shared
> VxVM SAN storage, and is mounted at the zoneroot.
You can't do upgrades with shared storage. That's a fundamental
requirement of LU and is independent of zones -- the storage that
contains packaged software must be unshared.
There are multiple ways to achieve that state, but if you have zone
paths set on shared file systems, you're in trouble, because you'll
end up with a live, running zone being updated. The whole point of LU
is that you upgrade an inactive copy.
> We need to determine if creating a non-global zone with the above
> configuration a recommended practice. If so, then we have a bug in LU
> which need to be fixed. However, if such zone configuration is not
> recommended, can someone pls point me to a document which _does_ state
> about this fact and what are the possible problems with such
We discussed the sharing issues at length during Zulu development, and
the information ended up in the design documents. I don't know,
though, how that was translated into user documentation.
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 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