Unless otherwise noted, articles © 2005-2008 Doug Spencer, SecurityBulletins.com. Linking to articles is welcomed. Articles on this site are general information and are NOT GUARANTEED to work for your specific needs. I offer paid professional consulting services and will be happy to develop custom solutions for your specific needs. View the consulting page for more information.
Moving Solaris 10 Zones
© 2005-2006 Doug Spencer, Initially written 5/12/05
Visit http://securitybulletins.com/ for additional articles.
Note that the latest Solaris 10 releases have an official method of moving zones. Their procedure can be viewed at Sun.com and should be the procedure used with modern Solaris 10 revisions. I am keeping this article available for people using older Solaris 10 revisions and for reference regarding storing a zone on NFS and similar items detailed in this article.
Solaris 10 zones are a powerful concept that can provide significant benefits not found in quite the same way in other operating systems. Zones can improve system utilization and aide in consolidation of applications. One drawback is Sun's official claim that Zones are not mobile between multiple systems. This limits their usefulness in high availability situations and capacity planning.
I've determined how to move a Solaris 10 Zone from one system to another. This method is not officially supported by Sun, but it does work, at least at during my testing. This method should allow for clustered failover of entire zones, as well as allowing a zone to move to a better sized system to utilize available resources and minimize downtime.
Here is a summary of the filesystem areas that are used by Solaris 10 Zones:
/etc/zones – Stores zone configuration data including an index of available zones and configuration for individual zones in XML format.
zonepath – This is the path you specify when you issue a 'set zonepath=<path>' command in zonecfg.
/var/run/zones – Stores lock files and information about running zones. During my testing, I've not had to do anything with this.
Most everything else in a basic zone is a loopback mount in the form of an inherit-pkg-dir which presents a read-only version of the host system's directory structures. Other items will be shared storage and read-write LOFS mounts that you have defined for the zone. These will obviously need to be available on your new system.
How to move a Zone
All systems you want to run a zone need to have access to its configuration, which is the /etc/zones directory. I put this on an NFS share and mounted it read/write and anon=0 on all systems I wanted to be able to run the zone. You could probably use rsync or something similar to sync your files if you don't want to use NFS.
Next, the zonepath needs to be accessible by the system you want the zone to run on. This needs to be a filesystem that is accessible via /dev/*, which normally excludes NFS. I have a workaround that will work with NFS that I will discuss later in this article. I've used a SAN connection exported on a per-zone basis, but a cluster filesystem or A5200 or D1000 should work as well. You just need storage that can be moved from one system to another and has a /dev/* presence.
Mount your shared storage where you want your zonepath for the particular zone. For our example, I'll use /zones/testzone.
mount /dev/cxdxtxsx /zones/testzone # for SAN/D1000/A5000 devices mount /dev/lofi/1 /zones/testzone # for NFS lofi devices
At this point, you should have /etc/zones mounted as an NFS mount with the data originally in /etc/zones copied to the NFS share. You should also have /zones/testzone mounted as a standard device mount.
Now, just run the normal procedure to create a zone on one system. For my example, this would be:
# zonecfg -z testzone testzone: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:testzone> create zonecfg:testzone> set zonepath=/zones/testzone zonecfg:testzone> commit zonecfg:testzone> exit Note that you can use "create -b" above if you want most everything copied into the zone rather than loopback mounted read-only # zoneadm -z testzone install Preparing to install zone <testzone>. Creating list of files to copy from the global zone. ... # zoneadm -z testzone boot
Once your zone is created, installed, and booted on one system, here's how to move it to another system:
# On first system, with actively running zone: # zoneadm -z testzone halt # umount /zones/testzone # On second system: # mount /dev/xxxx /zones/testzone # xxxx= the device where your zone is located (lofi, SAN, etc) # zoneadm -z testzone boot
There you go, it should boot on the second system.
Storing a zone on NFS
If you want to place your zonepath data on NFS, I've found that making a LOFI image which is then stored on NFS works. The following is an example of setting up a LOFI filesystem for using zones:
# mkfile 128m /nfs/zonename.lofi # lofiadm -a /nfs/zonename.lofi /dev/lofi/1 # newfs /dev/rlofi/1 # for UFS filesystem # mkfs -F vxfs /dev/rlofi/1 # for Veritas filesystem
Issues with transporting zones:
- Patching and installing packages in the global zone of the system that is not running the zone. I've seen some packages that fail to install if they can't reach all the zones on a system. They go through a process of booting each zone in an administrative mode so the pkgmap and some other files can be updated in each zone.
- Zone can only be running on one system at a time. If you have shared storage, you will need to be sure the zone is shutdown on one system before starting it on another. This could easily be achieved with Veritas Cluster System or Sun Cluster by writing a custom agent to start, stop, and monitor the zone. You can then use the cluster system to move the zone between systems or failover if there is an outage on a particular system.
- If the system you're moving the zone to has different network interfaces, you might have to modify the physical network interfaces prior to starting the zone on the new system.
- This article is the result of my proof of concept testing on two identical machines, there is a good possibility that other issues might arise when this method is tested further. I'd advise against using it in production until better tested. If you use the information in this article, you do so at your own risk, I do not assume any liability if you suffer any loss due to information in this article. As I mentioned earlier, this method is not supported by Sun at this time either.
About the author:
I'm a BrainBench Most Valuable Professional for Internet Security, Network Concepts, and Linux Administration. BrainBench can be reached at BrainBench
I'm a consultant specializing in Unix, Linux and related technologies. If you need a knowledgeable, experienced professional contact mailto:firstname.lastname@example.org