Edit: I really like articles that cover more than one topic
Originally published by TechChannel February 17, 2021
Rob McNelly explains why older AIX versions run slower, and why it’s time to move on from AIX 7.1
Upon checking the error log, a client noticed errors that were pointing to a fiber port on their system. While the port physically existed on the machine, a fiber cable wasn’t connecting that port to a switch. The client acknowledged the port could be needed at some point, but for now they didn’t want it to logically exist. And naturally, they wanted the errors to stop.
The solution is provided in this IBM Support document:
“Usually when there are unused ports on FC Adapters, it is possible to disable those ports… and stop cfgdev/cfgmgr from configuring the devices… [This] will stop all the error log messages.
The steps and information provided… are intended to disable ports that are not connected and are intended to be not connected… [If] the errors are logged against ports that should be connected or should be in the “Available” status, please troubleshoot those adapters accordingly.”
The doc covers four methods for disabling a port, depending on how the card is configured. If it’s allocated directly to an LPAR, run the procedure that’s described for the root user. Alternatively, you can run the procedure using smitty, or you can script it. Finally, if you’re in a VIO server, you can run the following as padmin:
Remove the fcs# device and all child devices.
> rmdev -dev fcs# -recursive -ucfg
Set the fscsi# device to not autoconfigure.
> chdev -dev fscsi# -attr autoconfig=defined
fscsi# changed
At a future date when you need to use the port, you can enable it;
> chdev -dev fscsi# -attr autoconfig=available
fscsi# changed
Then run cfgdev to configure the devices.
> cfgdev
The Benefits of Baseboard Management Controllers
Baseboard management controllers (BMCs) are becoming more common in Power Systems environments. They can be used to manage OpenPower systems like the LC921, and they also work with newer POWER-based HMC appliances:
“IBM Power Systems servers use a… BMC and the Intelligent Platform Management Interface (IPMI) for system service management, monitoring, maintenance, and control. The BMC also provides access to the system event logs (SEL). The BMC is a specialized service processor that monitors the physical state of the system by using sensors. A system administrator or service representative can communicate with the BMC through an independent connection. The BMC uses IPMI and is contained on the system backplane. IPMI provides one communication method to the BMC, by using a command line interface. IPMItool can be used either from a remote Linux system, or from the host operating system console window. IPMItool remote connections to the BMC can be done by using either the serial connection to the BMC, or through a configured Ethernet port. The BMC provides a web interface, which provides a graphical user interface (GUI) that can be accessed from a management console or workstation that has network connectivity to the BMC. This connection requires an Ethernet port to be configured for use by the BMC.”
If you have a POWER-based HMC appliance in a lights-out data center, or if you’re not currently traveling to data centers, powering on/off with a BMC is a handy option.
Replacing a Physical Disk in a VIOS Environment
Have you had a physical disk fail in configurations where VIOS is booting from internal disk? Here’s a good procedure to follow if your disk replacement skills are rusty:
“Question
How to free up a failing disk that’s part of a PowerVM Virtual I/O Server, mirrored rootvg in preparation to replace the disk. This applies to VIOS 3.1.
Cause
Mirrored VIOS rootvg disk is failing.
Note: to determine if the disk may need to be replaced, contact your local Hardware Support Representative.”
Scroll to the bottom of that page, and you’ll find a link that explains how to mirror rootvg again once you’ve replaced the disk.
These concepts may seem basic, but many administrators come from non-AIX backgrounds (including IBM i) and are unfamiliar with these sorts of tasks. For anyone who hasn’t set up VIOS and doesn’t know how to manage it, these types of documents can be very helpful.
Managing VIOS Backups
Here’s something many of us have been looking forward to for awhile: With HMC version 9.2.950, you can manage the I/O configuration of VIOS and backup VIOS images directly from the HMC. This could eliminate the need to have a NIM server to manage VIOS backup and restore operations, although—just as some people prefer belts and suspenders—you may be more comfortable doing both until your confidence grows with this new option.
Here are the steps involved:
1. In the navigation area, click the HMC Management icon, and then select Templates and OS Images.
2. From the Templates and OS Images window, select the VIOS Images tab, and then click Manage Virtual I/O Server Backups.
3. In the Manage Virtual I/O Server Backups window, select the Virtual I/O Server Configuration Backup tab. A table is displayed that lists all the backup files of the VIOS configuration that is taken by the HMC. Additionally, you can view the time at which the configuration file was last edited.
a) To take the backup of the input/output configuration of a VIOS, click Backup I/O configuration. In the Backup I/O configuration window, select the managed system and the VIOS for which the backup is created, and then specify a name for the backup file. The name you specify must consist of 1-40 characters including file extension .tar.gz. You can use the characters A-Z and a-z, the numbers of 0-9, the dot (.), the dash (-) and the underscore (_) characters.
b) To rename an existing backup file that is stored in the HMC, select a configuration file from the table and click Action > Rename.
c) To restore the VIOS input/output configuration, select a backup file which contains the I/O configuration of the VIOS that you want to restore, and click Action > Restore.
4. In the Manage Virtual I/O Server Backups window, click the Virtual I/O Server Backup tab. A table is displayed that list all the VIOS image backup that are taken in the HMC. Additionally, you can also view the name and size of the VIOS image, the time when the VIOS image file was last edited, the managed system and the VIOS from which the image was captured.
a) To take the backup of the VIOS image, click Create Backup. In the Create Backup window, select the managed system and the VIOS for which the backup is created, and then specify a name for the backup file. The name you specify must consist of 1-40 characters including file extension .tar. You can use the characters A-Z and a-z, the numbers of 0-9, the dot (.), the dash (-) and the underscore (_) characters.
b) To rename an existing VIOS image backup file that is stored in the HMC, select a backup file from the table and click Action > Rename.
c) To remove a VIOS image backup file from the HMC, select a backup file which contains the VIOS configuration that you want to remove from the table, and click Action > Remove.
5. Click OK.
x86 HMC Reaches End of Service
If you haven’t heard, it’s time to upgrade your x86 HMC:
“HMC V9 R1 is the last release to support the 7042 machine type. HMC V9R2 will support the 7063 machine type and Virtual HMC Appliances (x86/ppc64le) only.
Note: iFixes and Service packs for V9 R1 will be supported on 7042 machine types until EoS of V9 R1.”
A Quick Case for Upgrading to AIX 7.2
In his AIXpert blog, Nigel Griffiths explains why AIX 7.1 users should upgrade to AIX 7.2:
“No sensible technical person would be running anything older than AIX 7.1 at this point in time, due to:
- Lack of support or support comes at a high price via Service Extensions
- Lack of security updates
- Missing advanced functions and advanced features that are only found in later AIX releases, particularly AIX 7.2
- Not making full use of POWER8 and POWER9 servers. For example, AIX 6.1 can only do SMT=1,2 and 4 (no SMT=8!).
- Missing years of development into removing serialization on locks and latches, adding parallel execution, shortening path lengths (less CPU cycles used to get work done), better performance tuning options, better out-of-box performance settings, and field hardening like trace and diagnostics.”
Putting these all together: older AIX versions run slower.