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 zone. > 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 > </var/tmp//installsxaaDF/dstreAAAtxaaDF/SUN > Wcsu>: No such file or directory > pkgadd: ERROR: unable to unpack package <SUNWcsu> from stream > </proc/self/fd/9> 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 > configurations. 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 zones-discuss@opensolaris.org
