Difference between revisions of "OpenSolaris zones"

From VistApedia
Jump to: navigation, search
(First draft of OpenSolaris zones setup)
 
(Added a Glossary link to Configuration~)
 
(33 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Setting up an lx26 zone on OpenSolaris
+
==Why I wrote this document, and why you should consider OpenSolaris==
  
Section 1
+
Q. Why did I write this?<br />
Document Scope
+
A. Several reasons; here are a few of them:
 +
* First and foremost, choice:  OpenSolaris is a tool you may want to use to tackle whatever endeavor you are contemplating.  In the context of this article, you might consider using it as a platform for VistA.
 +
* To inform:  Relatively few people know that OpenSolaris even exists, and even fewer know anything about using it.  This is something it shares with VistA.  They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything.  That very expansiveness fosters a community of users, from all parts of the world. 
 +
* To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007.  I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.
  
This document describes how to setup lx26 zones on OpenSolaris, with the goal of installing a Linux based VistA implementationThis information applies to OpenSolaris on the x86, and x64 platformsSPARC based systems are not covered.
+
Q. Why should you consider OpenSolaris?<br />
 +
A. I think a better question might be, why '''''shouldn't''''' you try OpenSolaris.  If you're reading thiAs then you must be at least slightly interested, so here are a few reasons why you should try it.
 +
 +
* [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris] was designed from the beginning for enterprise computing.
 +
* [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] "The last word in filesystems!"
 +
* [http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit Dtrace] Wanna know what your program is doing?  Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
 +
* [http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome xVM] The OpenSolaris version of the popular Xen hypervisor. 
 +
* [http://hub.opensolaris.org/bin/view/Community+Group+zones/WebHome Zones/Containers].  OS level virtualization, zones allow for completely isolated instances for running software.  This is similar to the xVM hypervisor in that it allows absolute containment of [[application~|Application]]s and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system.  Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model.  However, xVM and Zones are ''NOT'' mutually exclusive, and work quite well in parallel.  Zones are the main focus of this document.
 +
* [http://hub.opensolaris.org/bin/view/Project+crossbow/WebHome Crossbow]:  The new virtualized networking stack built into the current release of OpenSolaris
 +
* Support:  You can get help from the [http://opensolaris.org/jive/index.jspa forums], [http://www.sun.com/service/opensolaris/ support contracts] from Sun, and as with most any other question, [http://www.google.com Google] is an invaluable resource.   
 +
* [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome BrandZ]: An extension of the zone/container framework, designed to support Linux [[application~|Application]]s on the OpenSolaris platform.  People have run apps ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.MThere is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.
  
This document assumes several things, including that you have either root level access, or you have been assigned RBAC priveleges for zones on an OpenSolaris machine.
+
==What this document is==
  
When I use the term “virtual machine” in this document, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to something like VirtualBox, or the Xen and vmWare hypervisorsIn the latter cases I will refer to them by name.
+
This is a brief how to on settting up [http://hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome lx26 zones] on [http://hub.opensolaris.org/bin/view/Main/ OpenSolaris].  (That's a lower case "L" and is a reference to LinuX kernel 2.6).  The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platformsSPARC based systems are not covered.
  
Something else worth noting.  This will not likely work on Amazons EC2 cloud architecture, owing to the fact that zones require a dedicated IP address of their own.  There are ways to work around this, however the details of such things are well beyond the scope or intent of this document
+
==What this document is not==
  
1.1) What this document is not
+
This document is not meant as the be-all-end-all of zone documentation.  There is a great deal more to the technology than I'm even going to begin to cover in this write up.  If you want to know more about lx26 zones, you can find lots of information [http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6 here].
This document is not meant to be the be all end all, of zone documentation.  If you want to know more about zones in OpenSolaris go here: http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6
+
 
 +
These instructions are not meant for Amazon's EC2.  The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.
 +
 
 +
==What are zones?==
 +
* A virtualized operating system environment
 +
* Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
 +
* Isolated [[application~|Application]] environments within a single OS instance
 +
 
 +
==Document Conventions==
 +
 
 +
When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors.  In the latter 3 cases I will refer to them by name.
 +
 
 +
==What's needed==
  
1.2) Whats needed
 
 
Before beginning the install process you need several things, most of which are covered in this how-to:
 
Before beginning the install process you need several things, most of which are covered in this how-to:
1.Time.  How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
+
# Time.  How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
2.You need internet access on the machine where you will be doing the installation.
+
# You need internet access on the machine where you will be doing the installation.
3.You need to have a 32bit CentOS 5.x filesystem tarball.  That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know unstable)
+
# You need to have a 32bit CentOS 5.x filesystem tarball.  At the time of this writing you can download the tarball right [http://download.openvz.org/template/precreated/centos-5-x86.tar.gz here].  Note that 64-bit support is still in development and currently unstable.
4.You need to decide where in the filesystem you want the zones to be created.  Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances.   
+
# You need to decide where in the filesystem you want the zones to be created.  Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances.  After complete setup I've personally found that 6Gb is enough space when using [http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome ZFS] compression.
5.You need to obtain a unique static IP address for each zone.
+
# You need to obtain a unique static IP address for each zone.
6.You need to decide how your going to name your zones.  Zones, are a method of virtualization, and should be treated as if they are individual systems. (IP, hostnames, etc.)
+
# You need to decide how your going to name your zones.  Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
7.You need to decide if you want the zones to start up on boot of the main system?
+
# You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up.  In a testing environment this is purely a matter of preference. 
8.You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.)  I will briefly cover the 3 at the end of this how-to.
+
# You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.)  I will briefly cover these 3 at the end of this how-to.
 +
# You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being that a container is a zone with resource management tools applied.  [http://hub.opensolaris.org/bin/view/Project+rm/WebHome Resource management] is not covered in this document.
 +
 
 +
==Assumptions==
 +
 
 +
Setting and [[configuration~|Configuration]]s based on how I did this: (Adjust to your specific situation)
 +
# You have either root level access, or you have been assigned [http://hub.opensolaris.org/bin/view/Community+Group+security/rbac RBAC] privileges for zones on an OpenSolaris machine.
 +
# You know how to add users and set permissions on a directory.
 +
# You are using a network [http://docs.sun.com/app/docs/doc/819-6990/gdysx?l=en&a=view&q=Link+aggregation link aggregation] (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
 +
# The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
 +
# The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
 +
# For purposes of this demonstration I have simply called the zone, zone1.  You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be.  Use a naming scheme that works for you.  This is purely preferential.
 +
# The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
 +
# The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.
  
1.3)
+
==Setting up the virtualization environment==
Conventions used throughout this how-to, based on how I did this: (Adjust to your specific situation)
 
1.You are using a network link aggregation (known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
 
2.The IP address that set aside for this is 192.168.1.7/24, it is also the IP that will be used throughout these examples.
 
3.The fs path I used for the zone files is, /zones ( I know it just reaks of creatvity :) )
 
4.For purposes of this demonstration I have simply called the zone, zone1.  You should name it something meaningful, perhaps even name the zone, whatever the hostname of the “virtual machine” will be.
 
5.The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
 
6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...
 
  
Section 2
+
To enable lx26 zone support
Setting up the virtualization environment
 
  
To enable lx26 zone support download the template file:
+
===Download the template file===
  
# cd /etc/zones
+
<pre>
# wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
+
user@computer# cd /etc/zones
# chown root:bin SUNWlx26.xml
+
user@computer# wget http://hub.opensolaris.org/bin/download/Community+Group+zones/files/SUNWlx26.xml
# chmod 444 SUNWlx26.xml
+
user@computer# chown root:bin SUNWlx26.xml
 +
user@computer# chmod 444 SUNWlx26.xml
 +
</pre>
 +
 
 +
===Create the zone===
  
2.1)  Zone creation and installation
 
 
This section shows the commands to use, and the relative output:
 
This section shows the commands to use, and the relative output:
 
+
<pre>
# zonecfg -z zone1
+
user@computer# zonecfg -z zone1
 
zone1: No such zone configured
 
zone1: No such zone configured
 
Use 'create' to begin configuring a new zone.
 
Use 'create' to begin configuring a new zone.
Line 61: Line 93:
 
zonecfg:zone1>commit
 
zonecfg:zone1>commit
 
zonecfg:zone1>exit
 
zonecfg:zone1>exit
 +
</pre>
  
Installing the zone:
+
===Install the zone:===
  
Download a CentOS 5.x tarball
+
====Download and install a CentOS 5.x tarball====
  
# cd /export/home/butch/software/
+
<pre>
# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
+
user@computer# cd /export/home/butch/software/
# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
+
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
 +
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
 
Preparing to install zone <zone1>.
 
Preparing to install zone <zone1>.
 +
</pre>
 +
Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...
  
Depending on your computers overall speed, this process may take only a few short minutes, or “a considerable amount of time”...
+
====Pre-boot zone setup====
 
 
2.2)  Pre-boot zone setup.
 
  
 
Edit the following files to complete the networking setup:
 
Edit the following files to complete the networking setup:
 
+
<pre>
# vi /zones/zone1/root/etc/sysconfig/network
+
user@computer# vi /zones/zone1/root/etc/sysconfig/network
 
NETWORKING=yes
 
NETWORKING=yes
 
HOSTNAME=zone1
 
HOSTNAME=zone1
 
GATEWAY=192.168.1.1
 
GATEWAY=192.168.1.1
  
# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
+
user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
 
hosts: files dns nis
 
hosts: files dns nis
  
# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network configuration.  I used public nameservers for this demo.)
+
user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network [[configuration~|Configuration]].   
 +
I used public nameservers for this demo.)
 
domain opendns.org
 
domain opendns.org
 
nameserver 208.67.220.220
 
nameserver 208.67.220.220
 
nameserver 208.67.222.222
 
nameserver 208.67.222.222
 +
</pre>
  
2.3)  Booting and logging in to the zone
+
====Booting and logging in to the zone====
  
 
At this point the zone should be configured and installed.  Now it's time to log into the zone, which can be done as a 1 or 2 part process.   
 
At this point the zone should be configured and installed.  Now it's time to log into the zone, which can be done as a 1 or 2 part process.   
  
 
First, you need to ensure the zone is running: You should see output similar to the following.
 
First, you need to ensure the zone is running: You should see output similar to the following.
 
+
<pre>
# zoneadm list
+
user@computer# zoneadm list
 
global
 
global
 
zone1
 
zone1
 
+
</pre>
 
If zone1 is not listed in the output, then it's not yet running.  To bring it online use:
 
If zone1 is not listed in the output, then it's not yet running.  To bring it online use:
 
+
<pre>
# zoneadm -z zone1 boot
+
user@computer# zoneadm -z zone1 boot
 
+
</pre>
 
Wait a few seconds, and re-run the zoneadm list command.  Once the zone is running, log into it using the zlogin -S command.
 
Wait a few seconds, and re-run the zoneadm list command.  Once the zone is running, log into it using the zlogin -S command.
 
+
<pre>
# zlogin -S zone1
+
user@computer# zlogin -S zone1
 
sh-3.2#
 
sh-3.2#
 
+
</pre>
At this point, you have a login that resembles a Linux run level 1 command prompt.  The reason for logging in this way, is to reset the root password to something of a known value.   
+
At this point, you have a login that resembles a Linux run level 1 command [[prompt~|Prompt]].  The reason for logging in this way is to reset the root password to something of a known value.   
 
+
<pre>
 
sh-3.2# passwd root
 
sh-3.2# passwd root
  
 
Changing password for user root.
 
Changing password for user root.
 
 
New UNIX password:  
 
New UNIX password:  
 
 
Retype new UNIX password:  
 
Retype new UNIX password:  
 
 
passwd: all authentication tokens updated successfully.
 
passwd: all authentication tokens updated successfully.
 
 
sh-3.2#  
 
sh-3.2#  
 +
</pre>
 +
===Finishing up===
 +
At this point you need logout and back into the virtual machine, either by SSH or by zlogin without the -S flag. 
 +
<pre>
 +
user@computer# zlogin zone1
 +
</pre>
 +
The logout/in process is necessary to do as logging in with zlogin -S gives you the equivalent of a single user Linux environment, and many of the tools and such wont work.
  
 +
Now that the zone is running, and the root password is set, it's time to run some basic commands.  Start by making sure that all the existing packages are up to date.
 +
<pre>
 +
user@computer# yum update
 +
</pre>
 +
This process may take a considerable amount of time, but it's well worth doing.  Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system.  Current testing shows no negative impact on [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm] based VistA installations.
  
You can at this point, logout and ssh back into the machine, although it's not really necessary to do what needs doing.  Now that the zone is running, and the root password is set, it's time to run some basic commands.  Start by making sure that all the existing packages are up to date.
+
Now your zone is ready to take for a spinEven though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want.  There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums [http://opensolaris.org/jive/index.jspa here].  The next section has some very brief information about installing VistA inside of the completed zone.
 
 
sh-3.2#  yum update
 
 
 
This process may take a considerable amount of time, but it's well worth doingUnless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. 
 
 
 
Ok, thats it.  The zone is now useable for most anything you want to use it for.  The next section has some very brief information about installing VistA inside a zone.
 
  
 +
==OpenSolaris Zones and VistA installation overview==
  
 +
Basically this section contains brief notes about installing VistA via 3 different methods.  Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer.  This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment.  Each method has its place, and a time to use it.  That however is up to the end user to decide. 
  
 
+
===Nancy's installation instructions===
Section 3
+
This method is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know.  However, being that it is a completely manual process, it is prone to errors if you don't follow the instructions explicitly.  Cut and paste will be your friend with this method.
OpenSolaris Zones and VistA installation overview
 
 
 
Basically this section contains brief notes about installing VistA via 3 different methods.  Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer.  This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment.  Each method has it's place, and a time to use them.  That decision however is up to the end user to decide. 
 
 
 
3.1)  Nancy's installation instructions
 
This method, is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know.  However, being that it is a completely manual process, it is prone to errors, if you don't follow the instructions explicitly.  Cut and paste will be your friend with this method.
 
 
My thanks to Nancy for producing this document.
 
My thanks to Nancy for producing this document.
 +
===The Astronaut auto-installer===
 +
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes.  Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process.  What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces.  This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier.  There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products.  This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system. 
 +
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have.  Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admin's point of view. 
 +
===The Medsphere installation method===
 +
This method is similar to the Astronaut installation method, in that many of the tasks are automated.  Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method.  Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package.  Current testing within a zone environment also shows some problems with Medsphere's packages. 
 +
'''NOTE:'''  These problems are not inherent in the packages themselves.  Testing on a full CentOS 5.3 environment does not show problems.  Using these packages within a zone environment is not how they were initially intended to be used.  I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time.
 +
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.
  
3.2)  The Astronaut auto-installer
+
--<br />
This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes.  Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process.  What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces.  This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier.  There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products.  This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system. 
+
[[User:Butch | Butch]]
My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have.  Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admins point of view. 
 
 
 
3.3)  The Medsphere installation method. 
 
This method, is similar to the Astronaut installation method, in that many of the tasks involved are automated.  Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method.  Installing the OpenVistA server packages, involves things like adding the EPEL software repo, as well as the yum-priorities package.  Current testing within a zone environment also shows some problems with Medspheres packages. 
 
NOTE: These problems are not inherent in the packages themselves.  Testing on a full CentOS 5.3 environment do not show any of these problems.  Using these packages within a zone environment, is not how they were initially inteded to be used.  I am working with the OpenSolaris community, as well as Medsphere to try and work these things out, but it's going to take time. 
 
My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing this on OpenSolaris.
 

Latest revision as of 06:03, 4 December 2012

Why I wrote this document, and why you should consider OpenSolaris

Q. Why did I write this?
A. Several reasons; here are a few of them:

  • First and foremost, choice: OpenSolaris is a tool you may want to use to tackle whatever endeavor you are contemplating. In the context of this article, you might consider using it as a platform for VistA.
  • To inform: Relatively few people know that OpenSolaris even exists, and even fewer know anything about using it. This is something it shares with VistA. They are both extremely powerful software environments, and are so expansive that it would be nearly impossible for any one person to know everything. That very expansiveness fosters a community of users, from all parts of the world.
  • To share: I have been using OpenSolaris for over a year now, and previously used Solaris 10 since 2007. I have gained a lot of experience with the OS, and think that I may be able to provide help and insight as to different ways to attack a given problem.

Q. Why should you consider OpenSolaris?
A. I think a better question might be, why shouldn't you try OpenSolaris. If you're reading thiAs then you must be at least slightly interested, so here are a few reasons why you should try it.

  • OpenSolaris was designed from the beginning for enterprise computing.
  • ZFS "The last word in filesystems!"
  • Dtrace Wanna know what your program is doing? Dtrace allows developers and system admins, ways to look at running programs in ways that weren't possible before.
  • xVM The OpenSolaris version of the popular Xen hypervisor.
  • Zones/Containers. OS level virtualization, zones allow for completely isolated instances for running software. This is similar to the xVM hypervisor in that it allows absolute containment of Applications and utilities, the biggest difference being, xVM requires a separate kernel, and running operating system. Zones utilize a single operating system instance, and don't incur the overhead associated with a hypervisor based model. However, xVM and Zones are NOT mutually exclusive, and work quite well in parallel. Zones are the main focus of this document.
  • Crossbow: The new virtualized networking stack built into the current release of OpenSolaris
  • Support: You can get help from the forums, support contracts from Sun, and as with most any other question, Google is an invaluable resource.
  • BrandZ: An extension of the zone/container framework, designed to support Linux Applications on the OpenSolaris platform. People have run apps ranging from Apache for Linux, to Unreal Tournament 2004 (playable with audio), to modern day game servers, to GT.M. There is a pretty high likelihood that if you can do it in Linux, you can do it in a zone/container.

What this document is

This is a brief how to on settting up lx26 zones on OpenSolaris. (That's a lower case "L" and is a reference to LinuX kernel 2.6). The goal here is to facilitate a Linux based VistA implementation on x86, and x64 OpenSolaris platforms. SPARC based systems are not covered.

What this document is not

This document is not meant as the be-all-end-all of zone documentation. There is a great deal more to the technology than I'm even going to begin to cover in this write up. If you want to know more about lx26 zones, you can find lots of information here.

These instructions are not meant for Amazon's EC2. The architecture of EC2 requires several additional steps, however the details of such are well beyond the scope or intent of this document.

What are zones?

  • A virtualized operating system environment
  • Each zone has its own characteristics e.g. zonename, IP addresses, hostname, naming services, root and non-root users
  • Isolated Application environments within a single OS instance

Document Conventions

When I use the term “virtual machine”, unless specifically labeled otherwise, I'm talking about OS level virtualization, as opposed to VirtualBox, or the Xen and vmWare hypervisors. In the latter 3 cases I will refer to them by name.

What's needed

Before beginning the install process you need several things, most of which are covered in this how-to:

  1. Time. How much depends on several factors, including your skill and comfort level with OpenSolaris and the UNIX CLI, the machine used for testing, and probably several other factors I'm overlooking.
  2. You need internet access on the machine where you will be doing the installation.
  3. You need to have a 32bit CentOS 5.x filesystem tarball. At the time of this writing you can download the tarball right here. Note that 64-bit support is still in development and currently unstable.
  4. You need to decide where in the filesystem you want the zones to be created. Each zone needs a minimum of about 10Gb, give or take depending on your personal circumstances. After complete setup I've personally found that 6Gb is enough space when using ZFS compression.
  5. You need to obtain a unique static IP address for each zone.
  6. You need to decide how your going to name your zones. Zones are a method of virtualization, and should be treated as if they were individual systems. (IP, hostnames, etc.) This is no different than if you were using Xen or vmWare.
  7. You need to decide if you want the zones to start up on boot of the main system, or if you want to boot them manually after system start up. In a testing environment this is purely a matter of preference.
  8. You need to decide what method you are going to use to install VistA. (Astronaut, Nancy's instructions, Medsphere's installation method etc.) I will briefly cover these 3 at the end of this how-to.
  9. You need to be aware that the terms Zones and Containers are often used interchangeably, the difference being that a container is a zone with resource management tools applied. Resource management is not covered in this document.

Assumptions

Setting and Configurations based on how I did this: (Adjust to your specific situation)

  1. You have either root level access, or you have been assigned RBAC privileges for zones on an OpenSolaris machine.
  2. You know how to add users and set permissions on a directory.
  3. You are using a network link aggregation (also known as link bonding in Linux) named aggr0, and that your network is 192.168.1.0 with a netmask of 255.255.255.0
  4. The IP address that is used in this demo is 192.168.1.7/24, this is the IP that will be used throughout these examples.
  5. The fs path I used for the zone files is, /zones ( I know it just reeks of creativity :)
  6. For purposes of this demonstration I have simply called the zone, zone1. You should name it something meaningful, perhaps even name the zone whatever the hostname of the “virtual machine” will be. Use a naming scheme that works for you. This is purely preferential.
  7. The CentOS 5.x tarball will be downloaded to /export/home/butch/software/
  8. The username that I used for the demo is butch, cause using something other than my name seemed a tad silly...substitute whatever name you feel appropriate, where it's appropriate.

Setting up the virtualization environment

To enable lx26 zone support

Download the template file

user@computer# cd /etc/zones
user@computer# wget  http://hub.opensolaris.org/bin/download/Community+Group+zones/files/SUNWlx26.xml
user@computer# chown root:bin SUNWlx26.xml
user@computer# chmod 444 SUNWlx26.xml

Create the zone

This section shows the commands to use, and the relative output:

user@computer# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1>create -t SUNWlx26
zonecfg:zone1>set zonepath=/zones/zone1
zonecfg:zone1>set autoboot=true
zonecfg:zone1>add net
zonecfg:zone1:net>set address=192.168.1.7/24
zonecfg:zone1:net>set physical=aggr0
zonecfg:zone1:net>end
zonecfg:zone1>verify
zonecfg:zone1>commit
zonecfg:zone1>exit

Install the zone:

Download and install a CentOS 5.x tarball

user@computer# cd /export/home/butch/software/
user@computer# wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
user@computer# zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.

Depending on your computer's overall speed, this process may take only a few short minutes, or “a considerable amount of time”...

Pre-boot zone setup

Edit the following files to complete the networking setup:

user@computer# vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zone1
GATEWAY=192.168.1.1

user@computer# vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
hosts: files dns nis

user@computer# vi /zones/zone1/root/etc/resolv.conf (Edit the file according to your network [[configuration~|Configuration]].  
I used public nameservers for this demo.)
domain opendns.org
nameserver 208.67.220.220
nameserver 208.67.222.222

Booting and logging in to the zone

At this point the zone should be configured and installed. Now it's time to log into the zone, which can be done as a 1 or 2 part process.

First, you need to ensure the zone is running: You should see output similar to the following.

user@computer# zoneadm list
global
zone1

If zone1 is not listed in the output, then it's not yet running. To bring it online use:

user@computer# zoneadm -z zone1 boot

Wait a few seconds, and re-run the zoneadm list command. Once the zone is running, log into it using the zlogin -S command.

user@computer# zlogin -S zone1
sh-3.2#

At this point, you have a login that resembles a Linux run level 1 command Prompt. The reason for logging in this way is to reset the root password to something of a known value.

sh-3.2# passwd root

Changing password for user root.
New UNIX password: 
Retype new UNIX password: 
passwd: all authentication tokens updated successfully.
sh-3.2# 

Finishing up

At this point you need logout and back into the virtual machine, either by SSH or by zlogin without the -S flag.

user@computer# zlogin zone1

The logout/in process is necessary to do as logging in with zlogin -S gives you the equivalent of a single user Linux environment, and many of the tools and such wont work.

Now that the zone is running, and the root password is set, it's time to run some basic commands. Start by making sure that all the existing packages are up to date.

user@computer# yum update

This process may take a considerable amount of time, but it's well worth doing. Unless you have specific reasons to not do so, (you already know that an updated package is going to interfere with whatever else your doing, etc.) update the system. Current testing shows no negative impact on rpm based VistA installations.

Now your zone is ready to take for a spin. Even though this document was written with installing VistA in mind, you now have a Linux 2.6 environment you can use for most anything you want. There are some additional steps that need to be undertaken if you want to use audio programs and such, much of that is covered in the forums here. The next section has some very brief information about installing VistA inside of the completed zone.

OpenSolaris Zones and VistA installation overview

Basically this section contains brief notes about installing VistA via 3 different methods. Astronaut installer, the manual installation method authored by Nancy Anthracite, and the installation method for installing Medsphere's OpenVistA package, without using the astronaut installer. This over view is not intended to say that one method is better than another, it's only here to let you know what methods I have tried in the zone environment. Each method has its place, and a time to use it. That however is up to the end user to decide.

Nancy's installation instructions

This method is probably the oldest written installation method available, and is likewise in turn, probably responsible for more installations than we will ever know. However, being that it is a completely manual process, it is prone to errors if you don't follow the instructions explicitly. Cut and paste will be your friend with this method. My thanks to Nancy for producing this document.

The Astronaut auto-installer

This method was the first fully automated method that I am aware of, and is developed and maintained by Ignacio Valdes. Using the functionality of dpkg and rpm (and their corresponding front ends) Ignacio has automated the entire installation process. What started as an all in one installer that was designed to get the product into the hands of as many people as possible, is quickly maturing, and is beginning to be broken out into it's component pieces. This will make it much more appealing to sys admins, who don't want to install extra software on their systems, and it should make maintaining an Astronaut based, VistA system easier. There is a version of the Astronaut installer for both WorldVistA and Medsphere's OpenVistA server products. This installer seems to work out of the box, within the OpenSolaris zone environment with no problems, that are not present in a standard installation on any other system. My thanks to Ignacio for producing this installer, as well as allowing me to be involved as much as I have. Which has included ripping apart and analyzing almost every version of the installer that he has released so far, and offering input and insight from a sys admin's point of view.

The Medsphere installation method

This method is similar to the Astronaut installation method, in that many of the tasks are automated. Installing Medsphere's OpenVistA packages is somewhat more involved than using Astronaut, but not nearly as involved as the manual method. Installing the OpenVistA server packages requires manually adding the EPEL software repo as well as the yum-priorities package. Current testing within a zone environment also shows some problems with Medsphere's packages. NOTE: These problems are not inherent in the packages themselves. Testing on a full CentOS 5.3 environment does not show problems. Using these packages within a zone environment is not how they were initially intended to be used. I am working with the OpenSolaris community as well as Medsphere to try to work these things out, but it's going to take time. My thanks to Medsphere's OpenVistA team for producing this software, and for working with me in testing it on OpenSolaris.

--
Butch