Difference between revisions of "OpenSolaris zones"
(First draft of OpenSolaris zones setup) |
m |
||
Line 1: | Line 1: | ||
Setting up an lx26 zone on OpenSolaris | Setting up an lx26 zone on OpenSolaris | ||
− | Section 1 | + | Section 1.0 |
Document Scope | Document Scope | ||
Line 35: | Line 35: | ||
6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly... | 6.The username that I used for the demo is butch, cause using something other than my name seemed a tad silly... | ||
− | Section 2 | + | Section 2.0 |
Setting up the virtualization environment | Setting up the virtualization environment | ||
Line 135: | Line 135: | ||
− | Section 3 | + | Section 3.0 |
OpenSolaris Zones and VistA installation overview | OpenSolaris Zones and VistA installation overview | ||
Revision as of 16:00, 26 October 2009
Setting up an lx26 zone on OpenSolaris
Section 1.0 Document Scope
This document describes how to setup lx26 zones on OpenSolaris, with the goal of installing a Linux based VistA implementation. This information applies to OpenSolaris on the x86, and x64 platforms. SPARC based systems are not covered.
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.
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 hypervisors. In the latter cases I will refer to them by name.
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.
1.1) What this document is not 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
1.2) Whats 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. That can be gotten from the OpenVZ website. (64-bit support is still in the works and as far as I know 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. 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 are individual systems. (IP, hostnames, etc.) 7.You need to decide if you want the zones to start up on boot of the main system? 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.
1.3) 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.0 Setting up the virtualization environment
To enable lx26 zone support download the template file:
- cd /etc/zones
- wget http://www.opensolaris.org/os/community/brandz/files/SUNWlx26.xml
- chown root:bin SUNWlx26.xml
- chmod 444 SUNWlx26.xml
2.1) Zone creation and installation This section shows the commands to use, and the relative output:
- 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
Installing the zone:
Download a CentOS 5.x tarball
- cd /export/home/butch/software/
- wget http://download.openvz.org/template/precreated/centos-5-x86.tar.gz
- zoneadm -z zone1 install -d /export/home/butch/software/centos-5-x86.tar.gz
Preparing to install zone <zone1>.
Depending on your computers overall speed, this process may take only a few short minutes, or “a considerable amount of time”...
2.2) Pre-boot zone setup.
Edit the following files to complete the networking setup:
- vi /zones/zone1/root/etc/sysconfig/network
NETWORKING=yes HOSTNAME=zone1 GATEWAY=192.168.1.1
- vi /zones/zone1/root/etc/nsswitch.conf (Edit the hosts line to read)
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.)
domain opendns.org nameserver 208.67.220.220 nameserver 208.67.222.222
2.3) 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.
- zoneadm list
global zone1
If zone1 is not listed in the output, then it's not yet running. To bring it online use:
- 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.
- 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#
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.
sh-3.2# 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.
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.
Section 3.0
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.
3.2) 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 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.