On Wed 28 May 2008 at 02:54PM, Dean Roehrich wrote:
> All SAM-QFS packages will be updated with the following attributes and
> settings, to allow installs into the global zone and to prevent the
> install from propagating into non-global zones and prevent the package
> from being visible in any non-global zones [1]:
>
> SUNW_PKG_ALLZONES=false
> SUNW_PKG_HOLLOW=false
> SUNW_PKG_THISZONE=true
>
> This does not, however, prevent the packages from being installed
> directly into a non-global zone. To address this the packaging will
> fail to install unless the zonename is 'global'.
Presumably there are no SAM/QFS commands provided which would be
of interest to users inside of zones? I am not sufficiently familiar
with the product to be sure.
I would recommend you have your packaging reviewed by the Zones team
if you have any further questions.
> Booting zones that use Shared-QFS filesystems:
>
> When Shared-QFS filesystems are intended to be accessible from
> multiple non-global zones those filesystems must be mounted in the
> global zone and then non-global zones must use loopback mounts to
> access those filesystems.
Is this because there's no way to directly mount those filesystems? Why
is it not acceptable to simply specify these filesystems in zonecfg
(using 'add fs')?
> To address this issue, the zones will be booted only after the
> Shared-QFS filesystems have been mounted in the global zone. The
> existing sam-fsd daemon will be modified to monitor the filesystems
> and will boot the zones when their required filesystems become
> available.
I agree with Glenn that this is not acceptable.
> Zones being booted by sam-fsd must be marked as autoboot=false,
> and they must be listed in /etc/opt/SUNWsamfs/samzone.conf with the
> names of the filesystems on which they depend. The sam-fsd
> daemon will start any zone as soon as the Shared-QFS filesystems
> requested by that zone become available.
I disagree with this as well-- it fragments the zones architecture
for no obvious benefit-- offloading work onto the sysadmin and making
automation of zones that much more difficult. Additionally, it means
that zones are not readily migrateable from host to host, since you've
introduced a non-zones-managed configuration file.
If you need a hook in the zones framework, then let's figure out how
to provide you one, rather than hacking something onto the side.
Please come talk to the zones team before proceeding with this work,
via zones-core at sun.com, or we can set up a conference call.
> The new samzoneops tool will configure zones to use SAM-QFS. This
> tool uses libxml2 to parse the zone config files in /etc/zones. This
These files are private to the zones project, are subject to change
without notice, and are not an interface. You must not consume them.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
