solaris zones

I’ve finally completed my first successful experiment with Solaris 8 Migration Assistant (S8MA) today – a new product from Sun which allows you to run Solaris 8 branded zones. It’s a fully and officially supported solution (for an extra price), but you can download the free 90-day trial to play with it and understand how really cool it is.

Why use Solaris 8 zones?

First of all, just a few words about the niche for this product. Many companies are rather conservative about their Solaris upgrades. Most systems are still running Solaris 8, if not something older. Quite often this is also dictated by third-party software dependencies – products which were bought and configured for Solaris 8, which are now so tightly integrated that there isn’t an easy way to migrated them into Solaris 10. Such systems are doomed for slow but very expensive death. Expensive, because with every year the hardware support for servers capable of running Solaris 8 raises again and again.

If you have just arrived at this page, then you might want to start with Solaris 10 zones: a working example and Solaris 10 zones: resource types posts. Today I’ll tell you about root filesystem models for non-global zones in Solaris.

Two filesystem models in Solaris 10 zones

As you probably know, there are two such models in Solaris 10: sparse root and whole root. The former approach means that the newly created non-global zone’s root filesystem will only partially consist of actually copied into it packages and files, the rest will be inherited from the global zone. Such a model needs approximately 100Mb of disk space per zone, which is obviously much less than a full Solaris 10 installation, which happens in a case of a whole root approach. I’ve already mentioned this earlier.

Solaris 8 Migration Assistant (Project Etude)

Why use Solaris 8 zones?

Zones in Solaris 10: part three – sparse root and whole root

Two filesystem models in Solaris 10 zones