It's been a long 9 months since the release of the IBM XIV HAK 2.2.0 and we're back with a new exciting release - IBM XIV HAK 2.3.0 .
This release brings in a few new features, and most of them are responses for requests from our customers.
The first feature derives from issues in the field where rescan operation did not do what people expected. Although the rescan operation worked well and found new devices, in many cases there were leftovers from old mappings that were previously removed. A stale device is something that happens for various reasons like network issues where the issue is should be resolved in a short period of time. But when a stale device is left for a long time it becomes a maintenance issue, especially when there is an amount of such devices. These stale devices can cause a variety of problems, ranging from slower performance on the low end, to applications being stuck on the high end.
To solve these issues xiv_iscsi_admin and xiv_fc_admin have an additional option that complements rescan and cleans up stale devices. Now, you may ask yourself why did we add it as an option and not just always clean up stale devices. Well, stale devices are a sensitive issue. For example, let's assume your host has 2 paths to your XIV storage and one of them fails due to a temporary network issue. When the network issue is resolved, the device will be automatically up and running. So in such a case, removing the device would be a mistake. So the bottom line is that this calls for a human decision. This is a powerful option and as the saying goes "with great power comes great responsibility".
Example 1: Cleaning up a stale device
The next feature is also a response to customers needs. People using Veritas Dynamic Multi-Pathing (DMP) had issues running xiv_attach, as it always configured and initiated the native multipath framework. Two multipath frameworks on the same host is like having two managers not speaking to each other, each pulling in another direction.
To solve this issue we went over all our tools and made changes that enable them to work without using the native framework. in case of xiv_attach, if you have Veritas DMP installed on your system, you will be asked to choose between the multipath frameworks. If you are running any other utility you are required to add a --no-native-multipath flag to the utility. And what happens if you run the tools by mistake without the flag, will it ruin all your work? In case there Veritas DMP already in the system and the tools are run without this parameter, the utilities will issue a warning, but will not cause any damages.
Example 2: xiv_attach in presence of Veritas DMP
A third feature relates to the new release of XIV Microcode 11.5 and a feature we call Multi-Tenancy. Let's say you have two companies working on the same storage, each with it's own data that should never ever get to the other company. The storage can be divided into domains so that each is maintained by separate people, unaware of each others work. From the point of view of the storage administrator running xiv_attach or xiv_iscsi/fc_admin, he just uses his credentials to connect to the storage and everything behaves as expected. In case a user is able to see more than one domain (e.g. in case of domain per department) he is able to specify the domain the host should be using via a flag in the xiv_iscsi/fc_admin command line.
We should make it clear that support for XIV Microcode 11.5 also means that xiv_host_profiler and its rule file were updated.
We've added support for the major release of Redhat Enterprise Linux 7.0. And a bunch of other minor versions for Redhat and AIX. We made some nice changes in xiv_diag, xiv_syslist, and a variety of fixes that you can find in the release notes.
To download the IBM XIV Host Attachment Kit version 2.3.0 and the related documentation, please visit IBM Fix Central. You will need an IBM ID to download the files.
The IBM Host Software Group