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.

---

Removing Local Zone File Systems On Solaris 10 Unix

Hey There,

Today's post is a follow-up to our very recent posts on modifying existing local zone filesystems and creating new file systems in a local zone on Solaris 10. Today, we're moving to completion with this simple how-to on removing filesystems on local zones. We'll follow up with another simple post on how to create and destroy (all in one) local zones on Solaris 10. Even though I can write 500 hundred words on why I can't write less than 500 words, that post should be short ;) It almost "has" to be!

NOTE: This note is the same as in the last two posts. Nothing has changed ;) For those of you who haven't read those (or find this post all on its lonesome ;) here it is: When removing existing filesystems on a Solaris 10 local zone, all changes must be made to the filesystem from the global zone (assuming that you originally mounted it from there)!

1. First things first; you can't unmount a filesystem from within a local zone if it was created in the global zone. As per our notation in the post on creating filesystems on local zones, this does not apply to NFS, NAS or any other remote-or-network-mounted filesystems. These are mounted directly from the local zone and, as such, can be unmounted directly from the local zone.

One interesting thing, if you have your filesystem set up under the local zone's root, is that it won't show up on the global zone's "df -k" or "df -h," etc output. If you want to see the mount from the global zone (assuming you forgot where you put it or you just want to make sure), you can find out what filesystems are mounted in your local zone, from the global zone, (at least, this is one way) by running:

host # zoneadm list -vc <-- To list out the zones on your system from the global zone (DING is our example zone).
host # zonecfg -z DING info <-- This will list out more information than you need. Basically, look for the line at the top titled "zonepath:" You can then look under that zone path to see your local zone's root filesystem mounts. Note that you could just use "grep" to find all the lines in /etc/vfstab that include your local zone's name.

2. Back to cold harsh (but mercifully swift ;) reality. From the global zone, simply unmount your local zone filesystem, like so:

host # umount /zones/DING/root/DONG

3. Then, all that's left to do is to remove the local zone from the overall zone configuration (we're assuming that you've unmounted all of "your" local zone's filesystems before continuing and executing the steps here :) Again, this can all be done very simply by using the zonecfg command:

zonecfg –z DING
zonecfg:DING> remove fs dir=/DONG
zonecfg:DING:fs> commit
zonecfg:DING:fs> quit

4. Okay; step 3 included a white lie ;) If you don't want to get error messages or, worse, cause your system not to boot properly, it's recommended that you remove the local zone filesystem entries from /etc/vfstab in the global zone, as well.

And now (I kind of promise ;) you should be all set :) We'll post that creation/destruction post very soon, if not tomorrow. After that, we'll get back to Linux, AIX or any Operation System other than Solaris 10. We try to keep a fair spread given the sheer amount of distro's the term "Linux and Unix" actually encompasses. On the bright side, this blog's subject matter could easily be much more vague ;)

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

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