Home > Uncategorized > An Introduction to Solaris 11 Zones

An Introduction to Solaris 11 Zones

In Solaris 10, the default IP type for zones was shared, which meant that the zone shared the IP stack with the global zone. Within a zone on Solaris 10, an administrator was unable to configure network settings, unless exclusive IP was used, in which case the zone would be bound to a physical NIC in the global zone, and that NIC would only be available for exclusive use by that zone. With Solaris 11, and virtual networking, all zones can be created with an exclusive IP type. A Virtual NIC (VNIC) is created for each zone, over some physical NIC on the global zone. This network virtualisation allows each zone to maintain its own TCP/IP stack, and the zone administrator can change the zone’s network configuration from within the zone itself. A new anet interface type has been introduced within zonecfg to handle this.

Solaris 11 zones are now provisioned using the new Image Packaging System (IPS) and in a default configuration, packages will be installed from the repository configured (http://pkg.oracle.com, for example) in the global zone. It would make sense to have a local repository if you were rolling out large numbers of systems or zones, but for our testing purposes, downloading a couple of hundred megabytes of packages is no big issue.

This article will walk through the creation of a simple Solaris 11 zone, and introduce a method of installing zones without operator intervention using System Profiles.

Filesystem Creation

Zones are tightly integrated with ZFS in Solaris 11, and a new ZFS dataset (or datasets, depending on the configuration) will be created for each new zone provisioned. To aid in administration, I’ll create a new dataset to hold my zones. I have a ZPool available (datapool) and will create the new dataset within this:

I only have 19.4GB available, but as zones are an extremely sparse form of virtualisation technology, it will suffice for our requirements.

Zone Creation

Next, create the zone using zonecfg and set it’s zonepath to a subdirectory of our new /zones filesystem:

You’ll note that the zone has been created and is now in the configured state:

Here you can see that the zone is created with exclusive IP. A new VNIC will be created when the zone is booted, so for now you’ll see no additional interfaces when running dladm show-link – just the interfaces currently configured in the global zone:

System Profiles

The sysconfig utility provided with Solaris 11 allows us to unconfigure or reconfigure a Solaris instance. It is essentially a “fancy” version of sys-unconfig provided with earlier Solaris versions. One of the subcommands, however, supplied by sysconfig is create-profile. This allows us to step through all of the screens normally presented at system installation time (whether provisioning physical systems or zones) and will write out an XML file containing all the choices we made – a System Profile. This new XML format replaces the older sysidcfg format used previously when jumpstarting servers or provisioning zones. I can generate a master copy of this file from the global zone, and modify it to provide a template. This template can then be copied for each zone we wish to create, with the appropriate parameters substituted. Once the zone is installed using this profile, and booted, the appropriate system configuration will be performed automatically and the operator will not be prompted for information. This means that it’s easy to script the installation of Solaris 11 zones (as it was with Solaris 10).

Let’s create our system profile:

Work through the screens as if you were installing Solaris for the first time, configuring network, timezone, root password, user, naming services, etc. It will have NO EFFECT on current system configuration, so don’t be scared of it. I configured the parameters that I’ll be changing with obviously bogus values for my configuration – Hostname: NEWHOST, IP Address: 123.123.123.123, Gateway: 123.123.123.1, and DNS Servers: 123.1.2.1 and 123.1.2.3. Once the XML file had been generated and reviewed, I moved it to a secure location:

Then, I created a copy of the configuration for the zone I was about to provision – testzone-01, with the first substitution for hostname being made during the redirection to the new file:

I then substituted appropriate values for IP address, gateway and DNS servers. The netmask I specified during sysconfig create-profile is already correct for my network, so just substituting the correct IP address in place of 123.123.123.123 (my templated IP) will work:

Substitute the value for the default gateway, and DNS servers, similarly using gsed:

The profile is now ready to use.

Zone Installation

Our zone is now ready to be installed using the new profile. Use the new -c <profile_name> option to zoneadm install when installing the zone. Note that the -c option expects an absolute pathname to the profile, or at least that’s what I found to prevent strange errors about being unable to find the file. If we didn’t use a system profile, we’d have to step through the configuration screens on the first boot of the zone and specify all the information by hand.

Install the zone:

You will note that the IPS has been used for the zone installation and a new dataset has been created for this zone at datapool/zonefs/testzone-01.

Let’s verify the zone state:

Note the status change from configured to installed.

Our new VNIC has not yet been created.

Booting and Verifying the Zone

Boot the zone for the first time:

And connect to the zone’s console, checking for errors during initial boot, manifest import, and system identification (which should be automated thanks to our system profile):

Note that I specify a different escape sequence here (#.) from the default, to save confusion and possible disconnection via SSH escape sequences.

During zone boot, you may see the following message displayed on the zone console if you’re deploying your zones on a virtualised global zone (for example: under VMware or VirtualBox):

Disconnect from the zone’s console if no other errors are generated. The “Unable to verify add of static route” message is because you need to enable promiscuous mode on the global zone’s interface (whichever one the VNIC is being created over) for networking within the zone to work when the global zone itself is virtualised.

This can be done from the global zone. To determine the physical network interface that needs to be placed into promiscuous mode, run dladm show-link:

You can also see that a VNIC has now been created for our zone (testzone-01/net0) over net0. Run a snoop on the physical interface in the global zone (in our case, net0 is virtualised at the VMware layer) identified via dladm show-link:

Now, log into the zone and verify network connectivity:

Looks good. Our zone was provisioned with the minimum of fuss, and we now have the foundations of a scriptable solution to provision many zones on-the-fly.

Logging into the zone, review the default ZFS configuration and ownership of our network interface:

Of course, other datasets can be created in the global zone and added to a zone using zonecfg (as indeed can new VNICs with dladm create-vnic) but as you can see even a default zone configuration makes good use of the underlying core technologies present in Solaris 11.

Back in the global zone, review that the zone is reported as running:

And review the various ZFS filesystems that were created in the global zone during the creation of testzone-01 (note that the user we specified to create during sysconfig also has their own ZFS dataset) :

It’s worth noting that our zone only consumes 441MB from the above – highlighting how sparse the zones actually are – a complete operating environment in less than 0.5GB.

Conclusion

This article has provided a brief introduction to zones on Solaris 11, how to provision them and some insights on how to automate their provisioning. Zones have been even more tightly integrated with the technologies at the core of Solaris, and enable simple segregation of services, or the ability to delegate administration of an entire operating environment to a different sysadmin. Whilst not covered in this article, zones can be used to virtualise Solaris 10 instances into branded zones and thus consolidate existing infrastructure – you can run your Solaris 10 applications unmodified on Solaris 11 in a Solaris 10 branded zone.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: