[OpenIndiana-discuss] New Zone User Questions

[Jim Klimov]

Hello Peter,

   As others have already answered, since the switch to IPS there are
no longer sparse zones. In fact, one of the rationales in their favor,
the ability to upgrade and patch the software which runs in the zone
automatically along with the global zone - is directly counter to the
IPS goals, of having each operating environment as much independent
as possible, in terms of software versions as well.

   Other bonuses of sparse zones included space savings which can also
be gained by making template zones and then zfs-clone'ing them (I think
zone cloning should now involve this step automatically), or by use of
deduplication (which places a toll on system resources, but with such
predictably duplicate datasets it may be worth it). Cloning is fixed
in time, so upgrades of two zones would store identical files twice -
unlike dedup case. With 2 GB RAM however, I don't think you should
even as much as whisper "zfs dedup" lest the system breaks down in
advance ;)

   And another bonus was, apparently, shared memory space for libraries
and binaries - as well as singular caching of their FS objects.

   I think this can be to an extent redone with lofs-mounted directories
from GZ into LZ's - for example, we now maintain customized JDK versions
in the GZ (customizations include recent timezone data, trust to local
CA, etc.) and instead of customizing new JDK deployments for each zone
with J2SE appservers, we have the /usr/jdk path mounted into all zones
and pointing with /usr/jdk/latest symlink to the current JVM version.
I don't know really about memory savings, but disk and admin overheads
went down considerably ;)

   As for your other questions...

   GUI - it is enough that you have it in the GZ, you can then run a
terminal which zlogin's into a local zone. As a root you might also
use "zlogin -S" which bypasses the login mechanisms - i.e. if they
broke down in a zone, for example. Also if your zones do contain the
graphics libraries (which you might need to run some installers - i.e.
of Sun and Oracle software suites), you can export DISPLAY variable
to point to your GZ's GUI desktop session (in that session you'd need
to "xhost + localzoneaddress" first). In fact, a trivial desktop like
TWM may suffice - we run that in a VNC session by default on some
boxes and on demand on others, so that no local heavy GNOME console
is even spawned.

   As for netmasks, each OE (GZ or LZ) has a /etc/netmasks file.
You can configure your connected subnets (or all in your LAN, so as
to never go back into it) into this file, like:
192.168.0.0  255.255.255.0
   This especially concerns "non-standard" masks, like for 10.*/24
nets which are by default expected to be a big /8 net.

   If you use shared IP stack, you can also provide a netmask there,
in the zone configuration. However, there's really less and less case
for shared stack, now that we have VNICs, that it should be preferred
over an exclusive one with the fully-fledged network. Maybe, to an
extent, security (you can't sniff from a zone on a shared-stack net,
but can on an exclusive interface).

   Resource capping and/or setting up resource shares is possible -
but rarely needed. By default all of your system's processes would
just time-share the CPU and other resources, and it is usually OK.
The few examples I've seen need for explicit tweaks were to conform
to licensing (i.e. provide only 4 logical CPUs to a program), and
to keep interrupt processing on some cores while others do the math.
And, perhaps, to keep memory-leaking processes at bay so they can't
starve the whole OS on RAM, but only their sandbox zone. In the
latter case you might also want to limit permitted swap space and
the /tmp filesystem size (via the zone's /etc/vfstab).

HTH,
//Jim Klimov