Most flavors of UNIX® and Linux® on the market today are similar enough that even a novice systems administrator can navigate the various operating systems with ease. But when you need to switch from one operating system to another—be it because of a change in business direction, technology enhancements, or cost savings—making the switch can be tough.
This article looks at practical migration information for switching from the Oracle® (formerly Sun Microsystems) Solaris operating system and associated hardware to the IBM System p® platform with the IBM AIX® operating system. It covers key information that administrators should know about what differentiates the two systems and shows how you can start running quickly.
The most basic thing a Solaris administrator should know about managing System p hardware is how to access the servers and get things running. In the Solaris world, you do this through the Advanced Lights Out Manager, Remote System Control, or other forms of console access; for most AIX systems, you use the Hardware Management Console (HMC).
The HMC is a multifunction stand-alone system that can interact with multiple System p computers simultaneously. It communicates with the servers' firmware through a special area called the hypervisor, which manages the servers' resources. Using the HMC, you can allot CPU, memory, disk, and other hardware resources to individual LPARs, which serve as virtual AIX servers within the host System p hardware. In addition, resources can be shared or micro-partitioned among multiple LPARs.
The HMC is accessible either directly in the console or by configuring remote connectivity, which allows login functionality by directing a web browser to a secured page available on the HMC.
Begin setting up your system by creating a spreadsheet with the location of your Fibre Channel and network cards on a per-drawer basis. Cables can get plugged into the wrong places easily and logging in at the HMC won't show the drawer or rack elevations, so the spreadsheet is invaluable. To set up your spreadsheet, complete these steps:
- Log in to the HMC as hscroot.
The default password, if you've never logged in before, is abc1234.
- In the left column, expand the Systems Management view and then the Servers menu. Click the managed server you need to examine.
- Click the Properties menu.
- On the I/O tab, record a list of all of the cards by drawer and physically compare them to the server, noting at what elevations the particular drawers are located.
One of the first tasks a Solaris systems administrator learns is to access the open boot PROM—also known as the OK prompt. This low-level area of the hardware allows you to reset a hung system, boot from a specific device (like a CD or a network boot), or get into single-user mode. Although there is no direct equivalent on System p hardware, there is a similar low-level interface known as System Management Services (SMS).
SMS is a numerically driven menu system that allows you to set the boot list order (that is, CD, hard disk, network), set the boot IP address in the Remote Initial Program Load subsection for a Network Installation Manager build-out (similar to Solaris Jumpstart), or perform lower-level diagnostic work.
You access this menu by pressing the F1 or 1 key when you power on a System p computer or LPAR. Alternatively, an LPAR can boot directly into the SMS menu by changing the Boot Option sub-menu through the HMC when activating the LPAR.
If you are in the SMS and going to boot from a disk but have multiple hard drives mapped from a SAN across a number of adapters, the SMS can take significant time to probe all the hardware addresses. To boot from a hard drive quickly, perform these steps:
- If applicable for a SAN-boot architecture, have your SAN administrator map only the root disk to the server. Or, pick a unique size for the rootvg disk so that it will stand out from the rest easily.
- Boot the system into the SMS, and open a terminal window (if applicable).
- Click Select Boot Options, then click Select Install/Boot Device.
- Click Hard Drive and navigate to the type of disk desired, or click List all devices.
The Object Data Manager and System Management Interface Tool
In the Solaris world, everything is tracked through flat files. Networking is covered by
files like /etc/defaultrouter, /etc/netmasks, and /etc/hostname.bge0. Software
packages are tracked down via the /var/sadm/install directory path, and file
systems are mapped to device files like /dev/dsk/c0t0d0s0 with /etc/vfstab. There
are a few menu-driven systems for administration, but tools like
admintool are limited in scope and functionality.
AIX uses a specialized database similar to the Windows® Registry called the
Object Data Manager (ODM). The ODM retains information on those same
aforementioned tasks typically managed by flat files on Solaris. Although not directly
vi or text-based editors, ODM is controlled
by several higher-level commands that add routes, detect new hardware, and so on.
One of the simplest ways to interact with the ODM and administer the server is through
the System Management Interface Tool (SMIT). This robust menu system allows you
to do everything from shutting down the server to changing tuning settings. By typing
smitty in a command
shell, SMIT allows you to perform common tasks and, more importantly, learn the
command-line instructions (by pressing F6 to view the commands executed behind
the scenes). Fastpaths to specific commands, such as using
smitty shutdown to shut down the server, are also
available; you can determine these fastpaths by pressing the F8 key.
You don't manage everything using the ODM or SMIT, however. There are still plenty of flat files that the two operating systems have in common, such as /etc/passwd, /etc/group, and /etc/hosts, and that you can modify directly. But subtle differences do exist, such as /etc/shadow versus /etc/security/passwd or /etc/nsswitch.conf rather than /etc/netsvc.conf. Unfortunately, there is no rule of thumb as to which files are identical between the two operating systems or what the ODM may not cover, so be sure to take notes and check online resources to learn the differences between files.
Hands on with SMIT
Within the SMIT menus, it helps to know what the prompts mean and how to
select items. An asterisk (
*) means that a field
is required. A plus sign (
+) means that you can
press F4 to see a list of options. If you want to search through those options,
press the slash key (
/) to look up items by keyword,
or press F7 to select multiple options. For example, to create a user with SMIT,
perform these steps:
- As root, type
- Give the user ID a name in the User NAME field.
- In the Group SET field, press F4, then use the F7 key to select the staff and lp groups.
- In the HOME Directory field, give the user ID a different home directory location.
- Press F6 to view the command that will run. Press F3 to go back, then press Enter to run the command.
- Press F10 to exit SMIT, and set the user's password by running
One other virtue about AIX is its ability to detect and manage devices easily. With Solaris,
determining which device correlates to something like
/ssm@0,0/pci@1c,700000/pci@1/SUNW,isptwo@4 (scsi) is sometimes
complicated. Or, if you have the wrong set of device drivers installed, running
devfsadm might not configure that Fibre Channel adapter
you're trying to set up.
In AIX, the
cfgmgr command detects any hardware devices
present on the system and even tells you which device drivers may be missing. A
common set of commands, such as
lsattr, provide information on the devices installed in
plain English, their base configuration information, and any attributes or tunables
set for the devices. Devices can be presented in one of two states—available
or defined—denoting whether the device can be used. All of this information is
tracked in the ODM, where it persists across reboots and can be ported easily.
Hands on with device control
AIX often creates logical devices that point back to physical counterparts. For example, an Ethernet adapter of ent0 has the logical device of en0 bridged off of it. This is done, because although a setting like the MTU size controls the physical aspects of the system, an IP address does not physically change the adapter. For example, to check a Fibre Channel device for parent-child devices and configuration settings, perform these steps:
lsdev –C | grep fcsto view all Fibre Channel devices on the system.
- Note the address (third) field, and pick one of the adapters.
lsdev –C | grep $ADDR, substituting the address field to view the child devices.
lscfg –vl $FCSto get the Worldwide Number of the adapter.
lsattr –el $FSCSIto see the tunable options for the device.
Software and patching
Solaris breaks down its operating system software and patch management into two main
levels: versions and patch clusters. These levels are based on the system's kernel levels
and software package subsets. In contrast, AIX is broken down into four main operating
system levels: version, release, technology level (TL), and service pack (SP). Version
and release are most commonly referred to in the name of AIX, such as
AIX 7.1. TLs are major releases of the operating system that have been
updated, and SPs contain minor updates. Running a command like
identifies a code like
6100-04-05-1015, which shows that
this server is at AIX 6.1, TL 04, SP 05.
Each installed software component on AIX is commonly called a fileset, though
the word package is used when discussing a compiled Red Hat Package
Manager package that can be installed on AIX. These filesets are gathered into larger
Licensed Program Products that can be maintained individually on the
server, like an installation of IBM DB2®. But you can view any piece of software
registered with the ODM using the
lslpp command, checking
its level and all associated files.
Hands on with patching
IBM sometimes releases Authorized Program Analysis Reports (APARs) that fix
particular bugs. You can view APARs using the
command, but this command has a second feature, as well: It tells you whether
specific filesets are missing from a particular TL. Use this procedure on a server
after installing newer operating system filesets:
- Check the server's operating system level by running
- Run the
instfix –i | grep MLcommand to determine whether any TL has missing filesets.
- Run the
instfix -i | grep _SPcommand to determine whether any SP has missing filesets.
- If any TLs or SPs have missing filesets, run
instfix -icqk $TL | grep :-:to see which filesets are missing.
I was thrown off when I first started learning Solaris and heard that out of the box, I could make a maximum of seven file systems (slices) per disk and that once those file systems were carved up, their sizes were pretty well fixed. AIX is much more versatile, in part because of how its Logical Volume Manager (LVM) works.
Figure 1 shows a series of disks with small cylinders. One cylinder, labeled Physical Volume, has a grid drawn on it to represent the individual physical partitions (PPs) on it. Above the physical volume (PV), three other cylinders are grouped by an ellipse showing how they together represent a volume group (VG). A rectangle running across the three disks shows a logical volume (LV) placed across the three disks.
Figure 1. LVM on disk
In AIX, disks—known as PVs—are divided into smaller homogeneous blocks of storage called physical partitions. These PVs are gathered logically into VGs; within VGs, LVs are laid down across sets of PPs to build structure onto the PVs. If there is disk mirroring, they may be mapped to one LPs that points to two or more PPs. Then, a JFS or an Enhanced JFS (JFS2) is established on the LV, tracked with the /etc/filesystems file automatically, and ready for use. Once they are mounted, they can be dynamically grown, shrunk, or modified, and adding more space to the VG is as simple as adding another PV. This is similar to how Veritas Volume Manager can provide disk management tools but comes integrated with the AIX operating system at no extra charge.
Although Solaris does let you customize your file system layout, even going as far as having one root file system to contain everything, AIX comes with several default file systems for more granularity: /, /usr, /var, /tmp, /home, /opt, and /admin. However, in AIX, the /tmp file system is not the same thing as swap or virtual memory. Instead, such memory is managed by paging space, which resides on one or more independent LVs.
Hands on with file systems
grep command has an interesting
–p¬ flag that lets you search for information
according to paragraphs rather than just for lines. This flag is useful when
searching through the /etc/filesystems file for specific file system information,
because it pulls back just the stanzas pertaining to the file system you want to
examine. Try the following procedure:
- Pick a file system like /home, and use
grep –pto gather its information out of /etc/filesystems.
- Examine the same file system with the
lsfscommand to see what information is similar and different between it and the
With the advent of the most recent version of the operating system, Solaris 10 took a page
from the play book of how other operating systems like Linux manage services and
created the Service Management Facility. Using commands like
svcadm, this concept was brought in to handle things
inetd and NFS with simple start-and-stop directives.
AIX uses the System Resource Controller (SRC) to accomplish the same goals. This
srcmstr, which gets kicked off by the /etc/inittab
file at boot time, controls various services by breaking them into groups, subsystems,
and sub-servers. For example, the tcpip group contains the
subsystem, which manages the Telnet sub-server.
Figure 2 depicts a series of concentric circles illustrating the hierarchy
srcsmstr groups, subsystems, and sub-servers. The largest
circle is labeled with the encompassing
Under that, as an example, is the tcpip group. Within that is a circle labeled
subservers, which has some of the various tcpip sub-servers, such as
snmpd and named. Finally, the innermost circle has subsystems
inetd, including Telnet, FTP, and RSH.
Figure 2. The srcmstr in action
These individual groups can be found in configuration files in /etc, typically with an
rc. prefix, with a corresponding entry in the
or something called from the
inittab, such as /etc/rc.tcpip,
managing those services just described.
However, since AIX 5.1 came out, it is also possible to start and stop some services and applications similar to the System V model used in prior versions of Solaris. The /etc/rc.d directory structure can be used to put in S and K files at the various run levels listed to bring up or down processes. But AIX does not adhere quite as strictly to the run level model as Solaris or Linux, so it is important to place any custom start and stop scripts in the right places.
Hands on with services management
There are many ways to skin the proverbial cat for starting processes at boot
time. In the past, many administrators would add an
entry to the
inittab to kick off a local, home brew
/etc/rc.local script to load applications. But since AIX 5.1, it has become
possible to make your own service kicked off by
for applications such as SSH or Samba by using the
command. Try the following process:
- Install a third-party application like SSH to start or stop scripts. Note where the executables are located.
- Use the following command to set up the
SSHDdaemon to have it run as root, with standard signals for stopping the process (
9for kill), and be a part of the test group:
/usr/bin/mkssys -s sshd -p /usr/sbin/sshd -u 0 -S -n 15 -f 9 -G test.
- Start the subsystem by running
startsrc –s sshd.
VIO and WPAR
Recently, virtualization has become a big buzzword in the UNIX field, with companies trying to determine how to get the most bang for their buck. In Solaris, this push led to the introduction of zone technology, where a global zone server would have several zones underneath it that contain their own micro-partitions running as independent servers. Drawbacks of this technology include how the zones use disk space from the global zone itself, and the operating systems have to be the same level, with any patching that warrants a reboot affecting all zones.
In AIX, virtual I/O (VIO) expands on this idea. The main premise of VIO technology is to create specific servers on a piece of System p hardware that aggregate and use the underlying disk and network resources, serving them out to all of the AIX servers in a passthrough function. With VIO, the individual LPARs can all be at various operating system levels but use the Fiber Channel, SCSI, and Ethernet resources concurrently. Building two VIO servers into the same System p hardware can provide redundancy in case one component fails.
Figure 3 depicts two sets of computing environments, illustrating Solaris zones and AIX VIO. On the Solaris zones side, you can see how the servers are held up by the global zone and that one outage there will make all of the resources unavailable. On the AIX VIO side, you can see how the VIO servers act as a passthrough for the LPARs and that an outage in one VIO server will not affect the larger architecture. Similarly, it's clear how the LPARs can be at disparate operating system levels, unlike the Solaris zones.
Figure 3. Solaris zones versus the AIX VIO
Similar to zones, IBM introduced WPARs in AIX 6.1, which allow for the creation of mini-servers that run under the auspices of a larger system. But these WPARs can also be configured to traverse multiple AIX servers across System p hardware instead of being stuck on one piece of equipment.
Hands on with VIO
A specialized superuser, padmin, is used for most aspects of setting up VIO servers. However, although the commands available to the padmin user look the same as many of the root-level user commands, they often have a vastly different flag or word structure. Perform the following steps:
- Log in as padmin, and run the
help lsdevcommand. Note the flags that are available.
- Become root by running
oem_setup_env(notice that you don't use the standard
man lsdev, and check the flags available. Compare the flags between these two commands: Note that padmin is far more verbose.
Although picking up another operating system takes time to learn all its nuances and particulars, this article provide background to put Solaris administrators more at ease when migrating to AIX servers. You should now have the base-level foundation to help you understand the key concepts and main differences between the two operating systems.
- Read more about the HMC in the Hardware Management Console V7 Handbook.
- If you're an RHEL 4 administrator, you will find the developerWorks article, AIX tips for RHEL4 administrators (Christian Pruett, November 2009), helpful.
- Find helpful VIO tips and tricks in the developerWorks article, The VIO cheat sheet (Christian Pruett, July 2010).
- Check out the UNIX Rosetta Stone.
- AIX and UNIX developerWorks zone: The AIX and UNIX zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
- New to AIX and UNIX? Visit the New to AIX and UNIX page to learn more.
- Technology bookstore: Browse the technology bookstore for books on this and other technical topics.
Get products and technologies
- Try out IBM software for free. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.
- Follow developerWorks on Twitter.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Get involved in the My developerWorks community.
- Participate in the AIX and UNIX® forums:
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.