Creating And Deleting Local Zones On Solaris 10 Unix

Hey There,

Today's post is the final post in our quick series on dealing with local zones on Solaris 10. If you want to check the previous entries out, finish this paragraph. If you don't (or already have), just skip past this one :) The previous posts in this series have dealt with already-created local zones and how to create new file systems in a local zone on Solaris 10, modify filesystems in existing local zones and remove file systems in a local zone.

Today's "how to" is going to cover the bookends of this mini-series; creating local zones in Solaris 10 and destroying them.

NOTE: This notation is fairly obvious in this post (it was more appropriate in the following three), but I'll include it for completeness' sake. You have to be in the global zone to create or destroy a new local zone. See what I mean? ;) Also, resource/storage pools, etc, are outside the scope of this series of posts. If you're curious to learn a bit more about that aspect, check out our older series of posts dealing with using storage pools in Solaris 10. The link is to the final post, but all the preceding posts are linked to on that page; much like they are on this one.

Now, we'll go, step by step, through creating a local zone (up through the final "installation" phase) and, subsequently, undoing all of our hard work by destroying it ;)

1. First of all, fire up your old friend zonecfg and we'll get the party started. For our examples, we'll call our new local zone "DING" to maintain consistency with our other posts and we'll call our pool "CLOCK" (ding dong, yeah, it's sappy ;) You'll notice that you define the zone name when you invoke zonecfg, although just doing that doesn't actually "create" it, like so:

host # zonecfg -z DING <-- This is going to give you an error, but you can safely ignore it. Basically, the error just indicates that you're trying to configure a zone that hasn't been created yet. That's o.k., because we're just about to :)
zonecfg:DING> create

2. Next, we'll set up all of the minimally necessary parts of this local zone (note that we've already checked that enough resources (disk, IP, etc) exist in order for us to be able to install our new zone):

zonecfg:DING> set zonepath=/zones/DING/
zonecfg:DING> set autoboot=true <-- I would recommend leaving this as "false" until you know you're good, but the worst that can happen isn't really all that bad, since a local zone caught in an auto-boot-loop won't cause you the same headache a straight-up box with the same issue would.
zonecfg:DING> add net <-- Notice how this puts you in a sub-menu, which shows up in the prompt. This happens for most device configuration and is pretty helpful if you have to walk away from your build for a while and come back to a screen where someone's hit enter 500 times ;)
zonecfg:DING:net> set address=99.99.99.1
zonecfg:DING:net> set physical=bge0
zonecfg:DING:net> end <-- and this, universally, takes us back down (or up, depending on how you look at it) a menu, so we end up back at
zonecfg:DING>

3. Then, with the process just about completed, we'll assign the zone to the "CLOCK" storage pool (outside the scope of these posts, but you can checkout our older 4-part post on working with storage pools). Once that's complete, we'll verify our zone and commit the configuration, like this:

zonecfg:DING> set pool=CLOCK
zonecfg:DING> verify
zonecfg:DING> commit <-- This writes the configuration, which, up until this point, is held in-memory.
zonecfg:DING> exit (or ^D [Ctrl d])

4. The last step in creating a zone isn't entirely obvious. The first time I did this, I thought I was done when I completed step three. The zone was created, I'd assigned it all of the resources it required (and tweaked all of those) and then verified and committed the zone. Alas, I was wrong, there was still one last thing left to do.

The final act, in creating and enabling your new local zone is to "install" the zone with the zoneadm command. This will not only re-verify all of your zone's resources, check and see if your new zone will run on your system (or any other, for that matter), but also installs all the necessary files in the local zone's root filesystem and creates all mount points as necessary. It's very simple to run and very easy to deal with (Although it may take a little bit more time, even if your setup is good :) - Just run it, simply, like this:

host # zoneadm -z DING install
Preparing to install zone email-zone
...
Zone DING is initialized.

And that's, basically, all you need to do to set up a local zone :) Of course, you should run "zoneadm -z DING boot," zlogin, etc, to boot the zone up, login and run your own tests, just to be sure everything is the way you like it. If you need to make any adjustments, you can still use zonecfg to modify your zone's configuration (theoretically ad infinitum).

Now let's get to work ruining it all, by destroying our local zone ;) It's actually very simple and only includes one "real" step. We'll do the first part, just do to be polite, and shutdown the zone before we destroy it, like so:

host # zoneadm -z DING halt <-- Totally unnecessary if you're going to utterly destroy your zone anyway

Then, all we need to do is run one command to end it all:

host # zonecfg -z DING delete <-- You can also use the -F flag if it won't go away. Note, also, that no commit is necessary, as it was when we created the local zone.

And there we have it; the poignant story a local zone from birth to death ;)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Branded Linux Zones In Open Solaris?

Hey again,

Today, we're going to be looking at installing "branded" zones in Open Solaris; specifically, RedHat Enterprise Linux (although CentOS is also supported). We'll take a look at what Linux OS's and hardware are supported in Open Solaris, do a quick rundown of how to set up a Branded Linux zone and sneak a quick peak at some test results from Sun's site.

STOP: Please.. Before you go any further, read this paragraph regarding the question mark at the end of this post's title. Today's post is a bit lengthy (mostly due to examples of the configuration of Linux Branded zones on Open Solaris) so, if you're thinking to yourself something along the lines of "why in the world would I want to run Linux on top of Solaris on a machine that's perfectly capable of running Linux without Solaris?," or "I already use VMWare, or something similar, to virtualize Linux hosts on a single physical machine, so what do I need with an extra Operating System?" you should just stop reading right now. Following is a long list of specifications and walk-throughs that will probably not change your mind or your answer to either question. If you're just curious, hop on in. The water's fine ;)

Supported Hardware for Linux Branded zones (This definition is fairly loose, since all I could find were lists of supported processors - I guess the natural assumption would be that, if you can get Branded Linux to run on your Open Solaris box, you'd be able to use any other hardware that would normally be supported by RedHat or CentOS):

Intel Chipset - Pentium Pro, Pentium II, Pentium III, Celeron, Xeon, Pentium 4, PentiumM, PentiumD, Pentium Extreme Edition, Core, Core 2 (x86 in general)
AMD Chipset - Opteron, Athlon XP, Athlon 64, Athlon 64 X2, Athlon FX, Duron, Sempron, Turion 64, Turion 64 X2 (x64 in general)

Supported Linux Operating Systems: RedHat Enterprise Linux 3.x and the CentOS equivalent.

Supported Linux Kernels: kernel 2.4.21/glibc 2.3 is "emulated" by Sun's Branded Linux zone. If you attempt to install RedHat (or any Vendor's) Linux that doesn't use this kernel/gcc revision, there's no guarantee that it will work at all.

On to the good stuff. How to set up a Linux Branded zone on Open Solaris:

1. Download and install the Open Solaris/Solaris Express - Community Release from opensolaris.org. You have your choice of 6 CD's, a 2 segment DVD or a single image DVD. Extras, including a CentOS tarball and additional script for Scientific Linux 3.0.8 can be found at the Branded Zones Download Page.

NOTE: If you already have Open Solaris 10 Release 8/07 or newer installed, you probably won't need to re-install, upgrade or add any pkg's to your existing configuration. An easy way to tell if you already have support for Branded Zones installed (assuming you're running Open Solaris, of course :) is to use the zoneadm command's list option:

host # zoneadm list -v 
ID NAME             STATUS     PATH                           BRAND
0  global           running    /                              native
host # head -1 /etc/release
Solaris 10 8/07 s10x_u4wos_12b X86
host # uname -a
SunOS TheDeadZone 5.10 Generic_120012-14 i86pc i386 i86pc

since we see that there's a "BRAND" column, we know that we're okay to proceed. The output from /etc/release confirms the date. I always like to use "zoneadm list" to make extra sure, as I will generally replace the contents of /etc/release-type files on boxes I build with a generic security warning, so that I don't advertise what version of exploits people should look for when they're thinking about attacking my site. For this reason I also check the output of "uname -a" to be sure that we have an x86 or x64 processor. Sparc-based systems support Branded zones as well, but don't support the Linux Branded zone!

Finally, check that you have the Linux Branded zone pkg file installed:

host # pkginfo|grep SUNWlx

If you get an error that this package cannot be found, you should be able to download it from opensolaris.org or get it off of your installation media. Also, and this is a point that sometimes get missed, make sure that you're running "Open Solaris" and not "Solaris 10" - Some folks (like me, for instance, when they both first came out) confuse them with one another or, more commonly, may assume they're the same thing.

2. From the "global" zone on your system, use the zonecfg command to begin setting up the zone:

host # zonecfg -z linuxzone <-- You will probably receive an error here, like "No such zone. Use create..." etc. This is normal for the first time you invoke zonecfg with a not-yet-existent zone name.
zonecfg:linuxzone> create -t SUNWlx <-- here we're using the -t flag that, technically stands for "template." In this instance we're using the SUNWlx pkg as the template for the Branded zone, rather than a template from another similar zone that we'd already created. It's more confusing to explain than it is to do ;)

And then, we proceed to install the bare necessities (zonepath, network adapter address, etc), similar to the following (this example is very sparse compared to the amount of options you can set in the zone, but will allow you to build and run):

zonecfg:linuxzone> set zonepath=/export/linuxzone_root <-- this directory will be created for you when the "commit" step is taken.
zonecfg:linuxzone> add net
zonecfg:linuxzone:net> set address=10.10.99.99/16
zonecfg:linuxzone:net> set physical=ce1
zonecfg:linuxzone:net> end <-- This just ends the network part. If we were doing a more complex setup, we could continue to add more attributes after going from the net setup back to the basic setup (shown in the zonecfg prompt)
zonecfg:linuxzone> commit
zonecfg:linuxzone> exit <-- It should be noted that if you just "exit," the zonecfg command will attempt to do a "commit" anyway. This is okay, if you decided you didn't want the zone, because you can destroy it just as easily as you created it ("zonecfg -z linuxzone delete -F" should do it). Just FYI :)

If you're so inclined, you can also do this all from the command line in one fell swoop. Until you get comfortable with it, it's generally easier to use the interactive mode, as shown above, since your zone setup has the potential to be as incredibly complicated and specific as you'd like and interactive mode allows you to ask for context-relevant help.

host # zonecfg -z linuxzone "create -t SUNWlx; set zonepath=/export/linuxzone_root; add net; set address=10.10.99.99/16; set physical=c1; end; commit"

3. Now, we need to install our new Linux Branded zone, from the global zone on our host:

Ensure that "volfs" is running (unless you're not installing Linux from a CD or DVD):

host # svcs | grep volfs <-- It's not running, so we'll start it. It doesn't hurt either way.
host # svcadm enable svc:/system/filesystem/volfs:default
host # svcs | grep volfs
online 14:22 svc:/system/filesystem/volfs:default

Now, either install from a tarball on the local system, like so:

host # zoneadm -z linuxzone install -d /path/to/tarball

or you can be specific about where you want the CD image to be read from:

host # zoneadm -z linuxzone install -d /cdrom/cdrom0 <-- /cdrom/cdrom0 is actually the path that gets used by default if you don't supply the -d option on the command line.

or

host # zoneadm -z linuxzone install -d /path/to/your/RedHat/ISO <-- If you want to install from an ISO or other image

If you prefer to be as specific as you can, at this point, you can follow any of the above commands with a directive indicating a subset of packages that you want installed, instead of the entire distribution. Your options are: core, server, desktop, developer and all - with each subset of packages containing more stuff that you may or may not need. Each subset (in order) is hierarchical, so the "developer" subset contains all the packages in core, server and desktop, as well. I don't know exactly what packages are in which, but on the Open Solaris BrandZ Site it must be listed out somewhere. Or, maybe not ;) - So assuming we wanted to install the server subset, our command would only be altered to a slight degree from:

host # zoneadm -z linuxzone install -d /cdrom/cdrom0

to

host # zoneadm -z linuxzone install -d /cdrom/cdrom0 server

4. Now we'll verify that the zone is installed using the same command from step 1, except we'll add the "-i" flag to show "installed" zones as well as running ones:

host # zoneadm list -iv 
ID NAME             STATUS     PATH                           BRAND
0  global           running    /                              native
1  linuxzone        installed  /export/linuxzone_root         lx

5. And, finally, assuming all has gone well, we can boot the Branded Linux Zone, like so:

host # zoneadm -z linuxzone boot

double check it to make sure it's out of the "installed" state:

host # zoneadm list -iv 
ID NAME             STATUS     PATH                           BRAND
0  global           running    /                              native
1  linuxzone        running   /export/linuxzone_root          lx 

and then we can login (NOTE: You have to log in locally with Linux Branded zones at this point. Even though we configured networking in the zone, the network interface won't work properly until we do the next few quick steps. Goofy ;)

host # zlogin linuxzone

linuxzone # hostname
linuxzone

6. Now, we'll set up the networking. You do it pretty much exactly the way you do in RedHat, normally. At the very simplest (since we only have one NIC and one IP), we'd just edit /etc/sysconfig/network and add:

NETWORKING=yes
HOSTNAME=linuxzone

and then just type:

linuxzone # reboot

like you would on a normal machine and it should come back up with networking all set. You can bring up the network manually, in a number of ways, also, but (at least on the first go at installation) I like to do the reboot so I can see if there are any startup errors that I might need to check out. You can also do the whole reboot process from the global zone using the zoneadm command (zoneadm -z linuxzone reboot) after simply exiting from your login shell in the new zone.

And that's all there is to it :)

If you eventually find this to be a "huge" waste of your time, don't say I didn't warn ya ;) If you want, check out this page that lists Linux applications that are certified to run on Open Solaris in a Linux Branded zone. I thought it was interesting that pretty much everything that got a "green" rating (the best) already works fine on Linux and on Solaris (like Apache). But, don't take my word for it, go there and be pessimistic for yourself ;)

Have a great weekend!

, Mike

Dealing With ZFS-Rooted Zones on Solaris 10 Unix

Hey there,

Today, we're going to take a look at a problem that's been haunting Solaris 10 (and, to a degree, Open Solaris) for almost 3 years now. This ties back pretty closely to earlier posts we put out on migrating zones, patching local and global zones and working with zfs filesystems, since it has exactly to do with a problem concerning zfs, Solaris 10 zones and one specific way in which they can be created.

Theoretically, it would seem, that the one way that's causing the most problems is the one way that should be the most desirable way to configure your setup (???)

Here's a little something to think about when considering creating zones with a zfs filesystem. Although this quote is taken out of context, directly from Sun, it was actually put out there as a selling point (in its own context actually):

zones are integrated into the operating system, providing seamless functionality and a smooth upgrade path.

However, as many of you may be aware by now (it being July 2nd, 2008 and, officially, version 5/08 of Solaris 10 is on the market), although creating bootable zfs zones and zones with zfs root filesystems is now finally possible (I believe it was originally introduced, in a small way, back in 6/05 -right before the 06/06 official release), it still suffers from some severe issues, that may not be initially evident. That is to say, if you didn't do your homework before you took advantage of this seemingly great feature, you've probably gotten burned in one fashion
or another, with regards to the upgrade process. Per Sun, again:

Solaris 10 6/06 supports the use of ZFS file systems. It is possible to install a zone into a ZFS fs, but the installer/upgrader program does not yet understand ZFS well enough to upgrade zones that "live" on a ZFS file system.

Because of this (and repeating this ;) upgrading a system that has a zone installed on a ZFS file system is not yet supported. To this day (to my knowledge) the problem still hasn't been completely resolved. Again, from Sun's bug list (And, I know I sound like I'm Sun-bashing here, but I am coming to a positive point. I swear :)

zoneadm attach command Might Fail (6550154)
when you attach a zone, if the original host and the new host have packages at the same patch level but at different intermediate patch histories, the zone attach might fail. various error messages are displayed. The error message depends on the patch histories of the two hosts.
workaround: Ensure that the original host and the new host machines have had the same sequence of patch versions applied for each patch.

Basically, the way things stand now, if you have a zone built on a zfs root filesystem (rather than, say ufs), if you need to upgrade, you officially have 3 options:

l. Be pro-active and "Don't do it!"

2. Go ahead and do it, but be sure to uninstall your zones before upgrading to a new release of Solaris 10, and then reinstall them when your upgrade to the new release is completed.

3. Go ahead and do it, but instead of following the more traditional upgrade-path, completely reinstall the system in order to perform the upgrade. This option makes the least sense, since reinstallation and upgrading aren't synonymous.

Now, for the rainbow after the storm. Yes, rainbows are somewhat illusory and their beauty isn't necessarily the matched-opposite of the horrors of nature you may have had to endure in order for it to bring you to that phenomenon, but it's a lot better than nothing, right ;)

The situation, as you may have guessed, is still pretty much up-in-the air, but there is hope; and in more than one area. For x86 (and possibly Sparc), this initiative is being fast-tracked by Sun for Open Solaris/Solaris 10 (Note that it's dated June 27th, 2008 :) - It basically proposes a -b flag to zoneadm attach, to be used in conjunction with the -u flag, to allow for backing patches out of a zone before an OS update. The full discussion, to date, is located here on openSolaris.org.

Why is this important?

As we noted above, the biggest problem Solaris 10 has with upgrading the OS on machines that have zones with zfs roots is that every single patch and package must be the same after the upgrade in order for it to be considered successful and Solaris 10's update software doesn't work with ZFS well enough to be able to guarantee that patches that get installed in one zone will necessarily get installed in another (global vs. local, zfs vs. ufs/vxfs, even zfs vs. zfs). If we were allowed to ignore certain patches and/or packages in our upgrades, this might make the likelihood of failure drop dramatically!

And here's one more ray of hope (which might be even better by the time you need to apply it). Here's how to upgrade your OS, assuming it has zones mounted on zfs roots, and (possibly) get away with not having to go to the extremes Sun is obligated to recommend. It's actually fairly simple. Mostly because it isn't guaranteed to work ;) The one good thing is that, if it doesn't work, you'll have your data saved off, so (if this procedure fails) you can still do it the hard way and not lose anything, except time, by trying :)

Do the following. We'll assume you've read our previous posts on migrating and patching both local and global zones and understand the basic system-down commands that would necessarily precede the following:

l. Halt and detach each of your zones that sits on a zfs root (I'd personally do this for all of my zones), like so:

host # zoneadm -z ZONENAME1 halt
host # zoneadm -z ZONENAME1 detach

2. Export all of your zfs pools:

host # zpool export ZONENAME1 <-Make sure that you note the names here, for the reverse process, just in case!
host # zpool export ZONENAME2

3. Perform your upgrade however you prefer.

4. Import all of your zfs pools

host # zpool import <--If this doesn't work, use the names you specified during the export previously.

or

host # zpool import ZONENAME1
host # zpool import ZONENAME2

5. Reattach and boot/install your zones using the -F flag to force the issue (of course you can leave it out if you want, just to see what happens. Sometimes forcing makes things work that are flagged as errors, but aren't really. You can also use the -n flag to do a dry-run):

host# zoneadm -z ZONENAME1 attach -F
host# zoneadm -z ZONENAME1 boot -F <--Note that for the zoneadm command. if you don't list a zone name with the -z flag, the subcommand (halt, detach, attach, boot, etc) would apply to all zones!

And you should either be all set or have a more limited set of issues to deal with (probably mostly patch related).

Later on in the week (if we don't run out of screen space ;) we'll look at ways to troubleshoot a Solaris 10 zfs-root zone upgrade gone bad.

Until that bright and sunny day:)

, Mike

Migrating Non-Global Zones Between Machines On Solaris 10

Apologies for the length of this post. I couldn't find any reasonable way to make it any shorter - so I'm including a link to where Sun is officially keeping all their documentation on this subject, should you want to explore it beyond this post. You can acess that info here!

As I always say when working with Solaris 10 (or whatever the latest version of Solaris is) you should do a trial run of a zone migration before you actually move any zone from one machine to another. Make up a bogus zone (like "origzone") set up the basic attributes and use that before you risk your important data!

The move is fairly simple at a high level (I will avoid breaching the subject of Solaris' RBAC to keep this at least somewhat short!):

1. The zone is halted and detached from its current host.
2. The zone is packed up.
3. The zonepath is moved to the target host, where it's attached.

In order to migrate the zone, you have to meet a few pre-requisites:

1. The global zone on the target system has to be running the same Solaris release as the original host.

2. To ensure that the zone will run properly, the target system needs to have the same versions of required OS packages and patches as the original. Any other packages and packages can be different; for instance any third party products and their respective patches don't need to be the same. Any packages that are OS-related and/or zone-inheritable must be included!

3. The host and target systems have to be of the same machine architecture (easily verifiable using "uname -m").

Once that's all been cofirmed, we're off! Running "zoneadm detach" on the original host sets the zone up so it can be attached to the target system. Running "zoneadm attach" on the target system attaches the migrated zone and verifies that the new system can host it.

Now we'll walk step-by-step through migrating the non-global zone from the original machine to the target host. Again, this process must be run as root in the global zone in order to ensure that it works without error (not to mention at all ;)

1. Become the root user and halt the zone to be migrated ("origzone" in this procedure).

orighost.xyz.com# zoneadm -z origzone halt

2. Now detach the zone.

orighost.xyz.com# zoneadm -z my-zone detach

3. Move the zonepath for origzone to the new host.

You can do this any way you want, basically. Just cd into /export/zones, and tar up the contents of the origzone directory. Then move the tarred up zone file to the target server using whatever file transfer facility you prefer, so that you have /export/zones/origzone set up on your target host.

4. On the target host, configure the zone:

targethost.xyz.com# zonecfg -z origzone

You will get a message from Solaris letting you know that origzone doesn't exist on the target machine, and needs to be created. This is only partially true ;)

5. To create the zone origzone on the target host, run "zonecfg -a /export/zones/origzone" on the target host. Then do the following:

zonecfg:origzone> create -a /export/zones/origzone

6. Make any necessary modifications to the configuration. For instance, to borrow from the example on sun.com, the NIC on the target host may be different, or other devices may not be the same. To change the NIC:

zonecfg:origzone> select net physical=ce0
zonecfg:origzone:net> set physical=bge0
zonecfg:origzone:net> end

7. Now, commit the new configuration and exit.

zonecfg:origzone> commit
zonecfg:origzone> exit

8. Attach the zone on the target host using the included validation.

targethost.xyz.com# zoneadm -z origzone attach

Note that, at this point, you'll be warned if you didn't meet any of the pre-requisites regarding required-same packages and patches on the target host, as we mentioned above.

As an additonal end-note, you can force the attach operation without performing the validation if you're absolutely sure that everything is okay and the message is in error. Of course, if the message is correct, and you're not, forcing the attach may result in random and bizarre zone behaviour later on. It's not recommended (By Sun or by me :)

targetzone.xyz.com# zoneadm -z origzone attach -F

Hopefully now you've gotten your zone migrated, and can script out as much as possible, to make mass migrations as simple and expeditious as possible in the future!

, Mike

linux unix internet technology