Prev: IPMP - Preventing Outbound Packet Loadbalancin
Next: Solaris Zones - memory management?
From: ravanos on 7 May 2008 09:26
Hey all,

Recently, I had the idea to build a development machine that could
provide a separate development possibilities for each of our
developers, so they wouldn't get in each others way by screwing up the
libraries or so. The problem was that we use Solaris 9 and Solaris 10
systems, and that there is a difference in the locations and versions
of the libraries. When I heard about branded zones I was exited,
because that could be the answer. Recently, Solaris 9 branded zones
have become available and everything works as planned.

It occurred to me that it could come in handy to install a Solaris 10
zone from a flar, just like you would install a branded Solaris 9
zone. You could use this feature to quickly restore a machine with
hardware defects in a solaris container. However, this was not
possible by default. It took me some time to figure it out, but I have
installed a Solaris 10 zone from a flash archive. Here is what I did:

* When in zonecfg you can set the brand of the zone by typing: 'set
brand=solaris9'. The default brand is native. The branding information
is located in /usr/lib/brand/<solaris_version_or_native>. I made a
copy of the /usr/lib/brand/native directory to /usr/lib/brand/
solaris10.

The directory contains several files, most importantly config.xml.
This file provides the information used to install and boot (zoneadm)
and verify (zonecfg) the zone or zone's configuration. I then looked
into the solaris9 config.xml and took the appropriate information from
that file. I made the following edits to the solaris10 config.xml:
1) replace native with solaris10
2) replace
<install>/usr/lib/lu/lucreatezone -z %z</install>
with
<install>/usr/lib/brand/solaris10/s10_install %z %R %*</install>
3) replace
<installopts></installopts>
with
<installopts>a:d:DhpsuvV</installopts>
4) replace
<verify_cfg></verify_cfg>
with
<verify_cfg>/usr/lib/brand/solaris10/s10_support verify</verify_cfg>

The first replacement defines the name of the brand, the second
replacement defines the command to install the zone, the third
replacement defines the allowed options for the install executable or
script, and the fourth replacement defines which file to use for
verification of the zones configuration.

* I then copied the following files from the solaris9 to the solaris10
brand:
-s9_install --> s10_install
-s9_p2v --> s10_p2v
-s9_servicetag --> s10_servicetag
-s9_support --> s10_support
-s9_system --> s10_system

The s10_install file contains information on how to install the
system. I edited this file to replace every instance of solaris9 or s9
to solaris10 or s10. The most important change is that you redefine
the location of the right-to-use (RTU) patchorder file, and the
location of the p2v postprocessing script.

The s10_p2v file contains postprocessing information. I replaced every
instance of solaris9 or s9 to solaris10 or s10. The most important
features are the location of the mods and the location of the
s10_system file.

The s10_servicetag file ads a servicetag to the zone. Since the
executable (/usr/bin/stclient) wasn't on my system, I only replaced
the entries as before.

The s10_support file is an executable the can verify the
configuration. Naturally, I didn't change the executable. It comes in
handy, as it will tell you to remove the inherit-pkg-dir in zonecfg,
so I kept it.

The s10_system file modifies the zones system file. I just replaced
some entries.

* Since the above listed files require some files or directories to be
empty, I created these directories:
-/usr/lib/brand/solaris10/mods
-/usr/lib/brand/solaris10/files
-/usr/lib/brand/solaris10/files/patches
The directory patches contains a file called 'order' that lists the
patches that need to be applied post-install. At this point, the list
is empty.

* now that all the files are in place, and the configuration is
correct, I created the solaris10 branded zone:
-zonecfg -z flarzone
-create
-set zonepath=/export/zones/flarzone
-remove inherit-pkg-dir
-add net
-set physical=eri0
-set address=10.0.0.2/24
-end
-set brand=solaris10
-verify (this calls the s10_support function)
-commit
-exit

* now the zone is ready to be installed from the flar:
-zoneadm -z flarzone install -p -a /var/tmp/solaris10.flar

* after installation I booted the zone and discovered a few things
that neede to be fixed:
-the /etc/vfstab file needs to be edited (remove all /dev/
dsk/cxtxdxsx entries)
-the following services need to be deleted, as they are
unable to run within a zone:
- svc:/system/device/fc-fabric:default
- svc:/system/dumpadm:default
- svc:/system/fmd:default
- svc:/system/picl:default
- svc:/system/scheduler:default
- svc:/system/sysevent:default

I rebooted the machine, and everything worked well. Off course, the
postinstall processing should be done via a script. Possibly, I can
update the p2v script to incorporate these changes.

Anyhow, I would like to know how others feel about this approach. Is
it valid, or is it simply asking for problems?

Any comment is welcome.

Rob.
 | 
Pages: 1
Prev: IPMP - Preventing Outbound Packet Loadbalancin
Next: Solaris Zones - memory management?