Introduction

In the world of operating systems, Unix is one of the foundations on which today’s computing is based. Designed in the 60s and 70s at AT&T Bell Labs by Dennis Ritchie and Ken Thompson, Unix revolutionized the way computers are used. Thanks to its reliability, stability, and security, Unix and its derivatives have gained wide recognition among corporate users, academics, and technology enthusiasts worldwide.

There have been many Unix family systems developed (excluding Linux distributions, which are derived from Unix), but unfortunately, only a few have survived to the present day. Although HP-UX, Solaris, and others still have their enthusiasts, it’s hard to speak of the development of these systems, as new versions have not appeared for several years.

The situation is different for the IBM AIX system, considered the last of the Unix systems still holding a position in the market.

The AIX system certainly has a long history, as it was released in 1986. Despite this, it is still being developed by IBM, and the roadmap below indicates that it is unlikely to be abandoned anytime soon.

AIX vs Linux

Questions about why one should use the AIX system instead of a Linux distribution have been asked by people for many, many years. Interestingly, in 2019, IBM acquired the company RedHat, which for obvious reasons could have been seen as the beginning of the end for AIX.

Red Hat’s flagship product is a Linux distribution named “Red Hat Enterprise Linux”, so it was speculated that IBM would primarily develop this system, and AIX would be abandoned. Interestingly, 2 years later, a new, major version of AIX, version 7.3, was released, and IBM has not announced any intention to abandon AIX, even though almost 5 years have passed since the purchase of RedHat.

Personally, even before I started dealing with AIX administration, I was a big fan of Linux. At home, I played with Slackware, Gentoo, CentOS, and Debian, and on servers, I worked with RHEL and SLES distributions.

I still highly value Linux systems and continue to work with them, but I would like to show through examples why AIX earns my respect as an Enterprise-class system.

Simplicity of Administration

Due to the POSIX standard, many commands, and the way of using the system, have a lot in common between AIX and Linux distributions. However, what is worth noting is the simplicity of administration and the syntax of commands.

For example, most commands in AIX follow the naming pattern below:

• Commands starting with ls* (list) are used for displaying
• Commands starting with ch* (change) are used for modifying
• Commands starting with rm* (remove) are used for deleting

Simple and logical.

Examples can be seen in the table below:

An administrator theoretically should know a multitude of commands with which they can do magic in the system (and ideally, all their parameters as well).

In practice, an administrator can use the SMIT tool, which is a graphical interface in the console for managing the system. There’s no need for a real graphical mode. SSH is sufficient.

A very useful feature is that from within the selected SMIT tool screen, one can preview the command that will be executed on the system. Is this tool only for beginner administrators? No. Advanced administrators also use it because it is simply convenient and significantly reduces mistakes compared to typing commands in the CLI. Of course, this does not exclude the need for administrators to still use the CLI and write various scripts, but it is a pleasant facilitation.

AIX is not difficult. It is an easy system to administer, but we use it for difficult and complicated tasks.

If someone has administered the SLES system, they will certainly be familiar with the YAST tool, which allows working on a similar principle. However, in my opinion, SMIT wins in such a comparison. I think those who have used both solutions will likely have a similar opinion 🙂

Work with Storage

How does the detection of new disks look like in the case of AIX and Linux?

AIX

cfgmgr

Linux

# echo "- - -" > /sys/class/scsi_host/host(n)/scan  

# (executed for all HBAs)

The simplicity of executing the command (and the risk of a typo) is noticeable. Of course, there are facilitations, as one can run the script rescan-scsi-bus.sh, but by default, we may not have it in the system (in RHEL, for example, the additional “sg_utils3” package must be installed).

This is one of the examples that shows that AIX is by default adapted to work with disk space provided by external storage.

How does Reducing the Filesystem look in AIX and Linux?

Let’s assume the administrator simply made a mistake and allocated too much space, for example, to the filesystem mounted to the /DATA mount point (e.g., 30 GB instead of 3GB).

AIX

# chfs -a size=-30G /DATA

That’s all.

It can be done ONLINE, also in a production environment. If the space we want to release has already been allocated, the system will simply return an error and will not perform the “shrinking” operation.

Linux

In case of filesystem types such as ext2/3/4 it could be done after unmounting the filesystem and still with a high risk, but for example, with the XFS filesystem type, which is the default in RHEL systems from version 7, it is much “simpler” than in AIX, because… it simply cannot be done 🙁

Logical Volume Manager

Anyone who has ever used LVM knows the great flexibility it offers, including in terms of expanding disk space, mirroring data, migrating between disk arrays, etc.

In the case of Linux distributions, the LVM implementation known from HP-UX is used. However, a complication arises when partitions are used under LVM. While for additional disks, e.g., for application data, this should not be a problem, as PV (Physical Volume) can be created directly on the disk, the matter becomes significantly more complicated for the system disk because the /boot filesystem containing the system kernel can only be created on a standard partition – LVM is not supported here, even in RHEL 9.

As a result, it usually looks like this: /boot is located on the sda1/xvda1 partition, and for LVM, a partition must be created, e.g., sda2/xvda2. Unfortunately, such an approach loses its simplicity.

Expanding a partition, for example, using fdisk or parted, unfortunately, is not among the simplest and easiest tasks (it requires deleting a partition and creating a new one with the correct size), and the partitions themselves can greatly limit the flexibility of LVM.

What does Expanding the System Disk in AIX look like? (e.g., after extending a LUN at the disk array level)

# chvg -g rootvg

That’s all. It is done ONLINE and does not require a restart.

As for RHEL, the procedure is too long to include in the article. Theoretically, one could use the growpart tool, which significantly simplifies the process, but from the information I found, it is not supported by RedHat, and using it is at your own risk.

What is Working with Partitions like in the case of AIX?

Hmm… What partitions?

Working on AIX, you can forget about partitions and work with fdisk, because they simply do not exist (of course, this does not apply to PP- Physical Partition at the LVM level). PV is made directly on the disks, including the system disk. One PV is made on one disk. Simple as that.

I think that most AIX administrators see classic partitions as a very outdated solution, even though for Linux it is still a necessity due to the bootloader (but still Linux is commonly seen as more modern and flexible than the old Unix).

Of course, one could list many more examples of differences, but I tried to choose the more interesting ones that came to my mind.

In my opinion, it is easier to switch from administering Linux distributions to AIX, rather than the other way around. The ease of using certain things in system administration is often hard to give up. I’ve also encountered opinions on the Internet, that AIX makes administrators lazy, and I must admit there is some truth to that.

System Update

The approach to system updating significantly differs between AIX and, for example, RHEL.

In the case of RHEL, an update is usually done with dnf update, so the situation is straightforward.

In AIX, the procedure is a bit more difficult but also has its advantages – you have the option to perform a PREVIEW installation, which means conducting a “simulated” installation or update without harming the system to identify potential errors or deficiencies in the system. I think that practically every experienced AIX administrator performs a PREVIEW before manually installing or updating filesets, and only after that, do they proceed with the actual installation process.

While upgrading the TL (Technology Level) or SP (Service Pack) is not a big problem, installing iFix (interim Fix), which are patches to the system that have not yet been introduced to the Service Pack, can be problematic. It happens that these patches may conflict, and in such a case, you have to ask support to prepare a Combo FIX. Automating the installation of iFixes is possible, but it requires a significant effort in preparing the appropriate scripts/playbooks, etc., due to the difficulty of handling exceptions, when iFixes conflict with others or are prepared for a specific set of installed Filesets versions (automation can use data downloading from FLRT – Fix Level Recommendation Tool).

Live Update

For RHEL systems, there is something known as live kernel patching, which is limited to installing only selected patches for the kernel (using the tool kpatch).

https://www.redhat.com/sysadmin/kernel-live-patching-linux

In the case of AIX, the Live Update process is something that, in my opinion, strongly demonstrates the Enterprise class of this system.

Upgrading AIX system version ONLINE (even with a running database, e.g., Oracle) is possible not only for Service Packs but also for Technology Levels!

This is made possible by using an additional, temporary LPAR, which is used like a “surrogate”, and I can confirm that this is not just marketing, but I have seen Live Update with my own eyes, and it really works 🙂

For more information, I refer you to the documentation on the IBM websites:

https://www.ibm.com/docs/en/aix/7.3?topic=updates-live-update

Upgrading the system by a Major Version

Upgrading RHEL by one version is possible but jumping from RHEL 7 to 9 is not. It’s required to first upgrade the system to version 8 and then to version 9. This is also not exactly a simple operation, and to assess this for yourself, you can take a look at the official documentation –> link.

What does it look like in AIX?

Personally, I have performed many upgrades directly from AIX 5.3 to AIX 7.2, despite the 11-year difference in the release time of these systems. The operation itself is quite simple, and the version migration usually took about 30 minutes.

Multithreading

Processor multithreading does not entirely stem from the operating system, as it is dependent on the processor’s architecture. The AIX system operates exclusively on the IBM Power platform and allows for working in up to 8 processor threads (various SMT modes are available).

Systems running on the x86 architecture use Hyper-Threading (HT) technology and have only 2 processor threads available.

An exception here, for example, is RHEL if it is run on the Power platform – in such a case, it can also utilize SMT-8, for machines of Power8 generation and above, and with newer versions of the system.

Powerful Tools

In managing Linux systems, I definitely miss an equivalent to mksysb, the ability to perform a bootable system copy. I’ve heard that there are supposedly some open-source equivalents, but I personally have not had the chance to test them and do not know if they are suitable for use on production systems.

I actually don’t fully understand why Linux systems, especially those with Enterprise in their name, do not offer an mksysb equivalent as standard.

In AIX administration, creating an mksysb image (as a system copy) cyclically or, for example, before maintenance work is something obvious. This can be done ONLINE, without any impact on the operation of the production system. If we want to restore the system from a backup, we simply perform a system installation from the mksysb image. We can also install other AIX systems from the same mksysb image (thanks to this, we have some configuration compatibility). The tool is very simple to use but also powerful at the same time.

While for a virtual machine on x86, you can take a snapshot of the virtual machine with Linux (although it is still not the same solution), the real challenge comes when the system must run on a bare-metal server – the convenience of using mksysb compared to working with tools like dd, etc., is incomparable.

Another AIX system tool that I personally miss in Linux distributions is Alternate Disk Copy (alt_disk_copy command). If we have an additional, empty disk, we can clone the system disk on it (also ONLINE, without impact on the operation of the production system). In the event that, for some reason, the system suffers serious damage during maintenance work, we simply change the bootlist to the backup disk and reboot the LPAR. We have the state before the failure, and returning to the previous state only costs us a restart. Also, a very easy-to-use tool, but I suspect that it has saved hundreds or thousands of systems worldwide from being restored from a backup 🙂

On the Alternate Disk Copy volume can also be done an update of AIX, while it is running – this can reduce the system downtime to just the restart and booting from that disk.

Of course, there are more examples, but these two are what I personally miss the most, especially in distributions known as “Enterprise”.

(fortunately, the NMON tool, which originally was developed for AIX and is a standard in it, was written for Linux as well 🙂 – https://nmon.sourceforge.io)

Modern World – DevOps and Cloud

AIX is often perceived by people as a less flexible system compared to Linux distributions.

I think that in the period when tools such as Puppet, Chef, Salt, and Ansible began to gain popularity, which allowed for significant automation capabilities and describing infrastructure as code, AIX was somewhat problematic, among other things, due to the lesser availability of dedicated modules/collections of such tools and the availability or difficulty of installing software like Ruby or Python, required by some of them.

For example, installing Python on AIX required some effort to figure out from where to obtain it, how to fulfil the dependencies it required, and how to maintain its version, especially in times when YUM for additional RPM packages was not yet available on AIX.

Currently, the situation has improved significantly, because AIX 7.3 comes with Python 3.9 as standard, as well as the DNF tool (known from RHEL systems), which allows for the easy installation of open-source tools from the AIX Toolbox repository, provided by IBM and maintained by community.

It’s also very pleasing that IBM provides Ansible collections, not only for AIX but also for VIOS, HMC, and PowerHA, among others. This provides a significant potential for automation and infrastructure-as-code descriptions.

Containers

Actually, AIX had its version of containers long before they became fashionable.

I’m referring to the WPAR (Workload Partition) technology, which, in my opinion, had significant potential but hasn’t been particularly popularized or developed by IBM to match the versatility of popular container technologies.

It seems to me that IBM clients usually use WPARs only to maintain old versions of AIX for outdated applications, but the potential of WPARs, in my opinion, is the ability to set up AIX as temporary environments for testing, for example, scripts or playbooks/cookbooks, and their use in CI/CD processes.

I know from experience that it can be done, and it helps a lot when working within DevOps, but it seems few are aware of this.

Cloud

AIX can be used not only in IBM Cloud but also in Google Cloud Platform, Microsoft Azure, and Amazon AWS in the case of public clouds.

What about private cloud? Here we have PowerVC software, based on OpenStack. In this case, we benefit from both the advantages of OpenStack and the Power platform.

PowerVC can be integrated, for example, with Terraform, as well as tools like Ansible, so when it comes to deploying LPARs and describing infrastructure as code, the possibilities are quite extensive.

Software Availability

Here is, in my opinion, AIX’s weakest point.

While there is no problem accessing databases like Informix, Oracle, or DB2, for example Postgres, requires source compilation.

In many cases, the reason for this situation is like the difference in software availability between Windows and Linux – it depends on the software manufacturer or developers and the system’s popularity.

Another reason is that access to AIX for a long time required having IBM Power hardware, which is unfortunately not cheap. I know of cases where, in response to user reports, software developers explained that they could not prepare a compilation for AIX because they simply did not have access to the hardware platform and system on which they could compile the code and prepare an installation package.

I think a potential light at the end of the tunnel for improving this situation could be the ability to use AIX as part of the PowerVS service, which I will discuss in the next point.

Regarding popular open-source tools, the situation has significantly improved over the years, and installing rpm packages is no longer as problematic as it used to be. This improvement came first with the YUM tool, and currently with DNF.

For example, to install curl, there’s no need to download packages from various odd sources (and additionally deal with dependency hell); it’s enough to do it as on RHEL, i.e. “dnf install curl” from the AIX Toolbox repository, and this significantly eases life 🙂

Availability of AIX

The AIX system operates on the IBM Power platform (theoretically, it can also be run on QEMU on x86, but certainly, this is not a state that allows for normal and stable operation).

For a very long time, this was a significant issue because to get to know AIX, one had to work in an organization that could afford the Power server, or alternatively, be lucky enough to study at a university that owned it.

Of course, there are valuable books, video courses, YouTube materials, and IBM documentation, but having the opportunity to work with a real system is very important.

In my opinion, IBM should provide a free version of AIX for learning, for students, and individuals who would like to get to know the system, thereby spreading competence and popularising IBM products. – Editor’s Note “Totally agree with Michals comments! Please listen IBM!“

Such a system should be easy to deploy in the cloud and free, although with a limited LPAR life cycle or limited functionality.

The basics of Linux can be learned at home, on one’s own, inexpensive equipment. Solaris had its counterpart on x86, so its basics could also be learned in a home environment, for example, on a small virtual machine without having a SPARC machine.

Fortunately, for some time now, there has been the IBM Power Virtual Server (PowerVS) service, which allows the use of the AIX system in the cloud (IaaS). From descriptions available online, it appears that the cost starts at €3, so it’s no longer a fortune.

A lot of useful information about PowerVS and learning AIX, along with links to YouTube materials, can be found at the address:

https://www.ibm.com/support/pages/learning-aix-system-administration-powervs

I think PowerVS could offer significant potential for making it easier for developers to compile and test software for this operating system and to enable education without spending huge amounts of money on the Power server.

Still, I believe that a free, educational version of AIX would be beneficial.

Summary

In my opinion, the presence of the AIX system in the modern IT world still makes sense. It is an operating system that can be described as Enterprise, offering functionalities hard to find in other solutions.

Its ability to operate in a cloud approach, and increasingly better integration capabilities with automation tools, allow for the modern use of this system, where infrastructure is defined as code, and changes can be tested in dynamically created environments.

AIX still retains the features of Unix philosophy, while modern Linux distributions working with systemd are often considered to be in conflict with this philosophy. This, of course, has its pros and cons, as well as its supporters and opponents.

https://en.wikipedia.org/wiki/Unix_philosophy

I have, of course, encountered reluctance towards AIX and comparisons with other systems. Though I can understand the criticism regarding software availability, most negative opinions stemmed from ignorance or aversion to what is unknown.

I completely omitted the issues of performance, stability, security, and flexibility resulting from running on the Power platform in the article because I considered it to be sufficient material for another publication.

I hope you found the article interesting 🙂