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 _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
