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.

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.

That's where the Solaris 8 zones come in. It's very easy, really: you create a flar-copy fo your existing physical server under Solaris 8, then create a Solaris 8 zone, import your flar-archive and get a virtual copy of your Solaris 8 environment, with all your processes, programs and startup scripts.

To make things easier, it's even possible to configure your hostid in Solaris 8 zone to match the one of the physical Solaris 8 system, this way no programs running in the zone will even guess that they've been virtualized.

Who knows, maybe I'll tell you more about this technology some other day, but for now - just the simplest list of actions and commands for your S8MA proof of concept:

1. Find and prepare a sparc box with Solaris 10u4. It is important to have the latest Solaris 10 update. Preparations are usually limited to applying a kernel patch, 127111-01 in my case.

2. Download the Solaris 8 Migration Assitant (current version is 1.0) from this location: Solaris 8 Migration Assistant. The 3 packages in archive are dead easy to install using standard pkgadd.

Here are the packages you'll get:


3. Make a flar-archive of your Solaris 8 system

Log onto your Solaris 8 box, and run the command. In this and all the following examples, solaris8 is nothing but an arbitrary name I've chosen for my zone. You might as well call it anything you like.



4. Create the basic Solaris 8 zone.

Here's how you do it:


Naturally, your IP and network device name will be different. As of now, our zone is fully configured, but not yet installed.

5. Install the Solaris 8 zone using our flar-archive



In my case the Solaris 8 zone got stuck on sys-unconfig, and so I had to connect to the virtual console of the zone to help it move on:

Here's how you connect to a zone's console:

Today I'll tell you about root filesystem models for non-global zones in Solaris.

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.

By default, there are four directories of your global zone's root filesystem which are accessible to a non-global zone via sparse root model: /lib, /platform, /sbin and /usr.

If a non-global zone is created with at least one resource of inherit-pkg-dir type, such a zone is said to be a sparse root one.

If you look at the zone's description, you can easily see how exactly such an access is configured:

zonecfg -z zone1 export



Remember: resources of this type can only be created when a zone is in a configured state, in other words - when it's set up, but no Solaris 10 installation copied any packages into it just yet. Thus, if you decide to alter these resources for an existing zone, you're going to have to uninstall it first (by doing something like zonecfg -z zone1 uninstall).

A sparse root model does the following: when installing Solaris 10 into your non-global zone, only the most necessary files are copied - the ones from packages where SUNW_PKGTYPE parameter is set to root. All the rest packages won't be installed into the non-global zone, and later files from these packages will be accessible from withing the zone via loopback filesystems (lofs) in a read-only mode. Imagine how much space is saved with such an approach!

If you don't know anything about lofs, please read man lofs, and most things will probably clear up ;)

As an example, do the following:



Now, if you cd inot /var/tmp/hey and try to create or remove any file, you won't be able to, simply because /var/tmp/hey is a read-only mounted filesystem view of a /usr directory.

Just to sum it all up: if a non-global zone doesn't have any inherit-pkg-dir resources, such a zone is said to be a whole root one, since all of the Solaris 10 packages are properly and fully copied into it. Such a mode takes up much more space, but you gain a great deal of flexibility - inside such a zone you can easily remove any files and packages, which isn't always possible within a zone with inherit-pkg-dir resources.

Now that we know how to create non-global zones in Solaris, it's probably time to learn some basics of zones configuration. Most work is done with zonecfg which has been mentioned in my previous entry already.

For starters, let's have a look at the full configuration of our zone. You've probably guessed by now, that we only specified the minimal number of parameters when creating our zone. Now I'll show you how to get a full view of our zone's configuration, and I'll also talk a bit about types of resources you can allocate to a non-global zone.

Start zonecfg with export command to get a full configuration (export is a command line parameter in my example, but if you like, you can do zonecfg -z zone1 and then type export when prompted for a command):

zonecfg -z zone1 export



As you can guess from the name of the command - export, we're getting a full list of commands for zonecfg to create a similar zone. We're exporting the config. I'll talk about this a bit more some other time.

Lookinf at the output, you can recognize some of the commands we've actually typed following the instructions from my previous entry, but there are also few new commands. Particularly, they are the file-system (packages) related ones. I'll definitely have a separate blog entry on file systems in zones, but for now I'll just talk about resources for zones.

Each non-global zone can be allocated any resources you have on your actual system. Resources are added with an add command, which you can see now in the output I've given. This commands takes a parameter - a resource type.

Solaris 10 ones could have resources of the following types:

net - a network interface. As you remember, when adding such a resource, you have to specify a physically present network adapter card you have in your box, and zone's network interface will be a virtual interface on this network adapter.

device - any additional device. Using device names mask (for instance, /dev/pts*), you can allow a non-global zone access any devices you have on your actual system.

fs - a file system. You can grant access to a physical disk or any directory of your actual system to any non-global zone. You can specify a file system type along with mount options, which is very convenient.

inherit-pkg-dir - a globa zone root filesystem directory which is inherited by a non-global zone. Specifying a directory name, you're pointing to the fact that all the files from this directory of your actual system (global zone) will not be physically copied into the non-global zone, but insteal will be inherited. The fact is, files from these directories will be accessible through a read-only loopback filesystem in your non-global zone (thanks, Dan!)

attr - an attribute. With resources of this type you can create text comments for your zones - these comments might come in handy when you get back to reconfiguring your zone some time later.

rctl - a zone-wide resource control. At this stage, there are only two parameters of this type - zone.cpu-shares and zone.max-lwps, but there will be more in the future. These parameters allow you to limit a CPU time given to a zone, and limit a max number of lwp processes which can be created in a zone.

Many of you have already heard about Solaris 10 zones - it's a virtualization technology which allows you to create isolated and secure environments for running applications. For end-users these environments look just like separate abstract machines with Solaris 10 installed on them. Inside each zone, all the processes don't see anything happening in all the other zones on a system. Isolation is done on such a level that processes of one zone can't see or affect processes of any other zone.

All of this is done on a software level, and by default every Solaris 10 machine has a global zone - only from this zone you can view processes of all the rest zones on your system. You probably didn't even notice, but upon the completion of your Solaris 10 install, you're immediately put into the global zone. It's very easy to see this zone:



To create a non-global zone, just plan some hard drive space for it, and work away! You're going to need a zonecfg command. You must specify a zone name as a command line parameter:

zonecfg -z zone3

If the zone specified doesn't exist, you'll see a message about it, and zonecfg will put you into it's command interface, where you can manage or create zones. Type the following (line by line):



This set of commands will create you a simple zone. There aren't that many parameters initially, as you can see:

zonepath is the full path to the directory where the specified zone's files will reside
autoboot is a flag used to determine whether a non-global zone should be automatically booted up every time your actual system (with your global zone) boots.

Further on, we're assigning one network interface to our zone, and give it an IP address. You should specify the name of the real network interface present in your global zone. For the zone you're creating, zonecfg will have a virtual interface based off the real one you specify.

Now it's time to verify your config - this command makes sure all the necessary parameters have got their values set. After this, we're done.

Now, if you look at the list of your zones again, you're going to see a newly created zone as well:



Right now our zone is in a "configured" state - it can't be used until we install OS onto it and it gets its unique ID. Obviously, you won't be able to boot your zone unless it has installed OS.

Here's a list of the states a non-global zone can be in:

configured - our zone is configured, but it's yet to have its initial boot

incomplete - zoneadm command sets a zone's state to this value while installing and uninstalling a zone. When the operation is completed, zone's status is changed.

installed - zone is fully configured, OS packages have been installed. It's a ready-to-use zone, all you have to do is to boot it. The zone has no virtual platform associated yet.

ready - the zone is ready. It already has a virtual platform established, the kernel has created a zsched process, all the network interfaces are plumbed, devices are configured and file systems are mounted. No processes have been started yet, but since the zone is ready it already has a unique ID assigned to it. We normally don't see a zone in this state, and it always moves one to the next one - running.

running - the zone is up and running. You can connect to the zone. It's a fully working environment now.

shutting down and down are short-term states which are shown when the zone is being halted. Upon completion of halt, the zone gets back into installed state.

Now, it's time to continue configuring our zone. We should install it. It is done with the following command:

zoneadm -z zone3 install

After this you can watch the process of packages installation for your zone, and when all the packages are installed, you'll get the location of the OS installation log file. That's it! Our zone is ready, and you can boot it:

zoneadm -z zone3 boot

Wonderful. But we still can't log in... Why? Because we've yet to configure the OS inside our zone - just like we would configure any box we've just installed with Solaris. As you've noticed, the order of OS installation is slightly different - in real life you have to configure the box first, and then you get to watch all the packages installing on it, with zones it's the other way around - first copy all the stuff, then configure the OS.

What we need now is connect to the zone's console and answer all the standard Configuration Assistant's questions, one of them is the root password. After this, your zone will want to reboot, and you'll be able to log in as root on your console. If you want to allow remote root logins, you'll obviously need to add the CONSOLE=/dev/console line to /etc/default/login.

To reach a zone's console, you should use zlogin command, -C means "console":
zlogin -C zone3

You can disconnect from the console using the standard combination: "~." (tilda dot)

One more thing. Since non-global zones will share the physical network interface with your global zone - you've got to make sure your system (your global zone) can see your non-global zones networks.

For instance, here's the ifconfig -a from my laptop:



As you can see, interfaces assigned to zones are marked with the "zone" parameter. I had to create a virtual interface (bge0:2) from the same subnet as the IPs of my zones. This way, I can ping interfaces assigned to each of the zones configured.

One more thing I wanted to mention: software packages, installed in a zone. Most curious of you have probably looked inside the installation log file, and noticed, that most of the standard Solaris 10 packages have been installed in our zone. At the same time, the directory with our zone's files takes up roughly 70mb... Such an incostistancy is explained by one of the key features of the zones virtualization: non-global zones can easily share files with the global zone. Thus, you can specify for each zone, that some files (packages), when required by the installer, should not be actually copied and installed, but just borrowed from the global zone - every time you'll want to access some of these files in your non-global zone, they'll be taken from the ones in your actual system - from your global zone. Obviously, all the files inherited in such a way by non-global zone, will be read-only.This technique allows you save lots of space, and by default all the files from /lib, /platform, /usr and /sbin directories are shared with the global zone. It is important to undestand that this happens only to the standard packages. So, if you've added some files of yours in the abovenamed directories, they will obviously NOT be shared with non-global zones.

Well, I guess it's enough for the part one of my notes on Solaris zones - with any luck you should now have a working zone which you can access remotely - log in, manage services, do whatever you want.

I'll add more stuff whenever I have a minute to spare....