Solaris to AIX

Practical migration information

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.

Frequently used acronyms FTP : File Transfer Protocol

: File Transfer Protocol JFS : Journaling file system

: Journaling file system LPAR : Logical partition

: Logical partition MTU : Maximum transmission unit

: Maximum transmission unit NFS : Network file system

: Network file system RHEL : Red Hat Enterprise Linux

: Red Hat Enterprise Linux RSH : Remote shell

: Remote shell SAN : Storage area network

: Storage area network SSH : Secure shell

: Secure shell WPAR: Workload partition

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.

Systems management

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.

Low-level management

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 editable by 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 smit or 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 smitty mkuser . 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 passwd $USER .

Device control

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 lsdev , lscfg , and 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:

Run lsdev –C | grep fcs to view all Fibre Channel devices on the system. Note the address (third) field, and pick one of the adapters. Run lsdev –C | grep $ADDR , substituting the address field to view the child devices. Run lscfg –vl $FCS to get the Worldwide Number of the adapter. Run lsattr –el $FSCSI to 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 oslevel –s 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 instfix 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 oslevel –s . Run the instfix –i | grep ML command to determine whether any TL has missing filesets. Run the instfix -i | grep _SP command 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.

File systems

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

The AIX 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 –p to gather its information out of /etc/filesystems. Examine the same file system with the lsfs command to see what information is similar and different between it and the grep output.

Services management

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 svcs and svcadm , this concept was brought in to handle things like inetd and NFS with simple start-and-stop directives.

AIX uses the System Resource Controller (SRC) to accomplish the same goals. This daemon, 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 inetd subsystem, which manages the Telnet sub-server.

Figure 2 depicts a series of concentric circles illustrating the hierarchy of srcsmstr groups, subsystems, and sub-servers. The largest circle is labeled with the encompassing srcmstr process. 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 of 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 inittab 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 rclocal 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 srcmstr for applications such as SSH or Samba by using the mkssys 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 SSHD daemon to have it run as root, with standard signals for stopping the process ( 15 for normal, 9 for 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 lsdev command. Note the flags that are available. Become root by running oem_setup_env (notice that you don't use the standard su command). Run man lsdev , and check the flags available. Compare the flags between these two commands: Note that padmin is far more verbose.

Conclusion

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.

Downloadable resources

Related topics