Using cio_ignore under z/VM

More and more installation tools use the cio_ignore kernel parameter. This parameter has been developed to allow hiding of devices from Linux, especially when using production Linux systems in LPAR.
The approach used in installers / automation systems is to first exclude everything and then explicitly define a white list of devices that Linux should see and use. So something like

cio_ignore=all,!0.0.5000-0.5002,!0.0.4711

will significantly speed up the IPL boot process as only those four devices need to be scanned and initialized.

The drawback is that with a line like this under z/VM the console is not available. So you log into your green screen and it seems that Linux doesn't IPL as there are no messages. If you wait long enough you can log in using the normal network. The z/VM console has the number 0.0.0009, so the line above needs to be modified to

cio_ignore=all,!0.0009,!0.0.5000-0.5002,!0.0.4711

So in general for a z/VM guest cio_ignore is not really needed as the access to devices can be controlled through the z/VM user directory. For guests that should come fast up in LPAR and z/VM add the console to the white list.

Methods to pause a z/VM guest: Optimize the resource utilization of idling servers

The startup time for servers increased during the last years. So even for development and test servers it's now common to either let them run or pause them. On z/VM with Linux on System z there are two different methods to accomplish that:

1. the basic Linux suspend / resume feature 
2. CP STOP and BEGIN mechanism

There is now a new publication looking at this in more detail, especially focused on overall performance. The paper is available on Infocenter in HTML and as PDF.

Bug fix for Linux on System z extensive swapping

Recently there has been a small bug fix for the swap behavior of Linux on System z. The following problem has been observed by several users:

The first time Linux started swapping it was doing so really extensively even though only a small amount of additional memory was needed. Depending on the disk speed and size of the swap space this can take a while.

The fix is included in

• RHEL 5.7.z update 2.6.18-274.11.1
• RHEL 6.2 base 2.6.32-220
• SLES 10 SP4 kernel update 2.6.16.60-0.91.1
• SLES 11 SP1 kernel update 2.6.32.45-0.3.1

and will be available for the other distros in the future as well.

As the system becomes totally unresponsive during that period I really recommend to get this fix installed if your system has more than a minimal swap attached and you are experiencing heavy first time swapping now and then. Contact your distribution partner or service provider in this case to get a temp fix.

Oracle 11g R2 - RMAN compression eating up CPU resources