> Whole Root Zones
> * Each zone is assigned its own root file system and cannot see that of others

Each zone has it's own root directory, regardless of sparse, whole, 
native or branded.  And you cannot see outside of your root directory
tree unless you have a grossly misconfigured system.

So this is the same for all types of zones.

>  A zone can be created as a whole-rootzone
>   > The zone gets its own writable copy of all Solaris file systems
> * Advantages of a whole root zone
>   > installation of software such as WebSphere MQ v6.0 is easily acomplished 
> since MQ must be installed into an environment where /opt and /usr are 
> writable.
>   > portabilit

/opt is not a part of a sparse root zone by default.  I use the term
hypersparse to indicate when a zone has more than the default 4
directories (/usr /lib /sbin and /platform) inherited from the 
global zone.

And the real use case here is when a software package expects to write
into several /usr locations, so many that it is not feasible to work
around it.  Something that writes a little bit in /usr/bin and something
in /usr/lib.  If an application writes in a single place in /usr then it
can be dealt with using a lofs or symbolic link.  Same is true for
hypersparse (my term) zones with an inherited /opt.

Some examples that don't force you into a whole root zone would be your
own private /usr/local that you want to write to.  A separate version of
Java in /usr/java.   Both of these cases are self-contained (although
the merit of a different version of Java in /usr/java is a point of
debate) and don't require whole root zones.

I would add that whole root zones enable minimizing your global zone.
Install only the packages you need to in the global zone (a pretty small
subset of the possible packages) and then create whole root zones with
the packages you need for the application.  You are still subject to
the restrictions of PKG_ALL_ZONES, but you can tailor your zones to
what they need and not bring along a lot of extra baggage.

Add to this conversation that zones on ZFS will enable very efficient
cloning of whole root zones (both in space and time).  I wish we had
a file level dedupe for ZFS as this would make this combination
absolutely rock!

> Sparse Zones
>   > The default file system configuration is called a sparse-rootzone
>   > The zone contains its own writable /etc, /var, /proc, /dev

Actually /dev isn't writable in the way you might think.  You can't do
mknods.  /dev is populated at zone installation time by the LU process
and again at boot time by zoneadmd (based on the contents of the zone
configuration file in /etc/zones).

>   > Inherited file systems (/usr, /lib, /platform, /sbin) are read-only 
> mounted via a loopback file system (LOFS)

Add to this definition that the packing and patching system understands
that writes to inherited-pkg-dir will fail and that doesn't cause the
patch or packing tools to emit an error.   That's the difference between
an inherited-pkg-dir and a read-only LOFS mount.

>   > /opt is a good candidate for inheriting

In cases where you have lots of packages that are common across all of
your zones and the zones do not need to write in /opt, absolutely.
A great use case for this is the Blastwave repository.  /opt/sfw can get
pretty large.

> * Advantages of a sparse root zone
>   > Faster patching and installation due to inheritance of /usr and /lib

Potentially much smaller disk footprint.  For a SUNWcxall metacluster,
Solaris can be about 3GB.  Throw in the software companion or a
reasonable set of packages from Blastwave and it's another 2 or 3GB.

So a whole root zone will cost you 6 GB per zone in this case.  A sparse
root zone maybe only 70 or so MB, growing to 200 perhaps to take into
consideration logging in /var.

>   > Read-only access prevents trojan horse attacks against other zones

Actually, it's a trojan horse attack against the current zone.  If you
can't write into /usr then it's pretty hard to leave an infection
behind in a place like /usr/bin where someone may trip over it (good
opportunity for sysadmin training - the hard way).

>   > Libraries shared across all zones reducing VM footprint

That is true.   Unless you have a very memory constrained system, you
probably won't notice this unless you have many many zones.

I would also add that sparse root zones are easier to migrate since the
zoneroot payload is potentially much smaller.   I suppose you could
argue that that are actually harder to migrate since the global zone
has to match more packages and patches.  I'd rather rcp 75MB than
6GB :-)

So my short summary of why I recommend sparse zones

- smaller disk footprint
- better security since /usr and /lib are not writable
- faster to create and patch
- easier to migrate

I like whole root zones when

- apps have to write all over /usr (not just /usr/java or /usr/local)
- I practice security though package minimization
- when I can put the zoneroots on ZFS :-)


zones-discuss mailing list

Reply via email to