Host Configuration Guide

IBM AIX
SANsymphony-V
June 2015

Global Leader in Storage Virtualization Software

Table of contents
Overview
Recent changes made to this document
List of qualified AIX Versions

3
3
4

Notes on qualification

AIX

DataCore Server Settings

AIX 5.2

AIX 5.3

AIX 6.1 and 7.1

Host Settings
Applies to any AIX Host
Appendix A
Notes on the Preferred Server & Preferred Path settings
Appendix B

9
9
11
11
13

Configuring Disk Pools

13

Reclaiming Storage from Disk Pools

13

Previous Changes

15

Overview
This document provides AIX-specific settings when serving Virtual Disks from a DataCore
Server.
Fundamental AIX administration skills are assumed; including how to connect AIX Hosts to
storage array target ports (i.e. DataCore Server Front End ports) using Fibre Channel, along
with the process of discovering, mounting and formatting disk devices in general.
Note: iSCSI connections from AIX are not currently supported

Recent changes made to this document

New information added since last update (February 2015)

Added new information:

List of qualified AIX Versions - Notes on qualification
This section has been updated and new information added regarding the definitions of all
qualified, unqualified and not supported labels. A new section on AIX versions that are
no longer in development has also been added at the end of this section.

SANsymphony-V 8.x is now End of Life

Please see End of Life Notifications http://datacore.custhelp.com/app/answers/detail/a_id/1329

Previous changes made to this document

Please see page 15

Page | 3

Host Configuration Guide IBM AIX

List of qualified AIX Versions

Notes on qualification
DataCore Software will always support any SANsymphony-V installation that has a valid
support contract. Even installations that are using Hosts listed as not supported will still
be able to get technical support but we will never guarantee the behavior of a Host
operating system that is listed as not supported if using Mirrored Virtual Disks.

Qualified
AIX versions that are listed as qualified are considered fully supported with redundant,
mirrored Virtual Disks as long as all the configuration settings listed in this document, and
that are specific to your AIX versions have been followed.

Unqualified
AIX versions that are listed as unqualified have not been tested with SANsymphony-V and
so may not work (i.e. failover or failback) as expected with redundant, mirrored Virtual
Disks; even if all the configuration settings listed in this document, and that are specific to
your AIX version, have been followed.
Unqualified AIX versions can be self-qualified by following the process documented here:
DataCore Component Self-Qualification Process
http://datacore.custhelp.com/app/answers/detail/a_id/1506

Not Supported with Mirrored or Dual Virtual Disks

These AIX versions are only supported when using non-mirrored Virtual Disks.
Any Mirrored or Dual Virtual Disk served to a Host operating system indicated as not
supported is done at the users own risk.
Versions that are explicitly marked as not supported can never be self-qualified.

Page | 4

Host Configuration Guide IBM AIX

What about other AIX versions?

All other AIX versions (i.e. newer) that are not listed in this document are considered as
unqualified for mirrored or dual Virtual Disks when using SANsymphony-V and, just like all
the unqualified versions of AIX that are listed in this document, the behavior with
SANsymphony-V cannot be guaranteed.
These other distributions can also self-qualified by following the same process mentioned
in the previous page.
Non-mirrored Virtual Disks are always supported, even on other distributions.

AIX versions that are no longer in development

Support for any AIX versions that is considered End of Life by the vendor or has no active
development/Long Term Support can still be self-qualified but only if there is an agreed
support contract with the supplier/HP.
In this case, DataCore Technical Support will help the customer to get the Host Operating
system accessing Virtual Disks, but will not then do any root-cause analysis.

AIX
The following table shows which specific versions of each version of AIX that are
considered Qualified (), Unqualified (?) or Not Supported with Mirrored or Dual Virtual
Disks (X) with SANsymphony-V 1
Note: iSCSI connections to AIX Hosts are not supported.
SANsymphony-V
Version 9.x

Version 10.x

AIX

ALUA

Non-ALUA

ALUA

Non-ALUA

5.2

5.3

6.1

7.1

See the section Notes on qualification on page 4 for definitions of Qualified, Unqualified and Not Supported
with Mirrored or Dual Virtual Disks
1

Page | 5

Host Configuration Guide IBM AIX

DataCore Server Settings

These are the Host-specific settings that need to be configured directly on the DataCore
Server.
See the Registering Hosts section from the SANsymphony-V Help:
http://www.datacore.com/SSV-Webhelp/Hosts.htm

Operating System Type

AIX 5.2
When registering the Host running AIX versions 5.2 with ML9 or earlier, choose the IBM
AIX Native MPIO Legacy entry.
When registering the Host running AIX versions 5.2 with TL10 or greater, choose the IBM
AIX entry.

AIX 5.3
When registering the Host running AIX versions 5.3 with ML5 or earlier, choose the IBM
AIX Native MPIO Legacy entry.
When registering the Host running AIX versions 5.3 with TL6 or greater, choose the IBM
AIX entry.

AIX 6.1 and 7.1

When registering the Host running AIX version 6.1.x, choose the IBM AIX entry.

Page | 6

Host Configuration Guide IBM AIX

Port Roles
Ports used for serving Virtual Disks to Hosts should only have the Front End (FE) role
enabled. Mixing other Port Role types may cause unexpected results as Ports that only have
the FE role enabled will be turned off when the DataCore Server software is stopped (even
if the physical server remains running). This guarantees that any Hosts do not still try to
access FE Ports, for any reason, once the software is stopped.
Any Port with the Mirror and/or Back End role enabled do not shut off when the DataCore
Server software is stopped, but remain active.

Mirrored or Dual Virtual Disks

When registering the Host, Multipathing Support should be enabled so that Mirrored
Virtual Disks or Dual Virtual Disks can be served to Hosts from all available DataCore FE
ports.
See the Multipathing Support section from the SANsymphony-V Help:
http://www.datacore.com/SSV-Webhelp/Hosts.htm

Asymmetrical Logical Unit Access (ALUA) support

ALUA is not supported for AIX Hosts.

Single Virtual Disks

Single Virtual Disks (i.e. that are not mirrored or are not configured as Dual) can still be
served to multiple Hosts and/or multiple Host Ports from one or more DataCore Server FE
Ports if required; in this case the Host can use its own multipathing software to manage the
multiple Host paths to the Single Virtual Disk as if it was a Mirrored or Dual Virtual Disk.
Note: Hosts that only have Single Virtual Disks served to them do not need Multipathing
Support enabled unless they have other Mirrored or Dual Virtual Disks served as well.

Serving Virtual Disks to the Hosts for the first time

DataCore recommends that before serving Virtual Disks to a Host for the first time to make
sure that access to all FE paths for all DataCore Servers are correctly discovered on the
Host and that from within the SANsymphony-V Management Console the Virtual Disks are
marked Online and up to date and that the storage sources have a host access of Read/Write.

Page | 7

Host Configuration Guide IBM AIX

Mappings
DataCore recommend that the same Virtual Disk served to more than one Host or Host Port
should use same LUN number for its mapping. While Virtual Disks have their own unique
Network Address Authority (NAA) identifier, DataCore cannot guarantee that this is
enough for a Host Operating System to identify the same Virtual Disk served to different
Paths on the same Host. Using the same LUN often guarantees some sort of consistency for
device identification in these cases.
Also see the SCSI Standard Inquiry Data section from the SANsymphony-V Help:
http://www.datacore.com/SSV-Webhelp/Changing_Virtual_Disk_Settings.htm
Note: The LUN number for Mirror Paths does not need to be the same as the Front End port
mappings (or indeed as other Mirror Path mappings for the same Virtual Disk) as the Host
does not see these.

Page | 8

Host Configuration Guide IBM AIX

Host Settings
These are the Host-specific settings that need to be configured directly on the Host Server.

Applies to any AIX Host

Install the DataCore Support for AIX MPIO software
In order for SANsymphony-V Virtual Disks to be recognized as MPIO-capable disk devices
on AIX, additional software needs to be installed on the Host. Please download and install
the DataCore Support for AIX MPIO software from the DataCore Technical Support website
(a login is required). All installation instructions can be found in the release notes that
come with the software:
DataCore Software Downloads
http://datacore.custhelp.com/app/answers/detail/a_id/1419

Setting Disk Timeouts

Once DataCore Virtual Disk(s) have been discovered on the Host, change the Disk
rw_timeout to 60 seconds.
To determine the current rw_timeout value, run the command:
lsattr l hdiskX E
Where X is the number of the DataCore Disk Device (as seen on the AIX Host).
Use the chdev command to change the rw_timeout to 60 (if not already set)
chdev l hdiskX a rw_timeout=60
Where X is the number of the DataCore Disk Device (as seen on the AIX Host).

Page | 9

Host Configuration Guide IBM AIX

Configure a dummy LUN

AIXs MPIO always requires a healthy LUN 0 to be able to detect and use additional LUNs
served to the same port on the Host. DataCore recommend that a very small, non-mirrored
Virtual Disk be served up to the Host port as a dummy LUN 0 from each DataCore Front
End port to all AIX Host Ports that are intended to be used.
Do not set this dummy LUN as a mirrored Virtual Disk to avoid unnecessary cases where
the DataCore Servers mirror partner will set the local storage source for the Virtual Disk as
down on the AIX Host, thereby preventing potential access or discovery of other LUNs
served to the same Host port. There is no need to write any data to this LUN on the AIX
Host.

Page | 10

Host Configuration Guide IBM AIX

Appendix A
Notes on the Preferred Server & Preferred Path settings
See the Preferred Servers and Preferred Paths sections from the SANsymphony-V Help:
http://www.datacore.com/SSV-Webhelp/Port_Connections_and_Paths.htm

Without ALUA enabled

If Hosts are registered without ALUA support, the Preferred Server and Preferred Path
settings will serve no function. All DataCore Servers and their respective Front End (FE)
paths are considered equal.
It is up to the Hosts own Operating System or Failover Software to determine which
DataCore Server is its preferred server.

With ALUA enabled

Note: ALUA is not supported for AIX Hosts so the following is for information only.
Setting the Preferred Server to Auto (or an explicit DataCore Server), determines the
DataCore Server that is designated Active Optimized for Host IO. The other DataCore
Server is designated Active Non-Optimized.
If for any reason the Storage Source on the preferred DataCore Server becomes unavailable,
and the Host Access for the Virtual Disk is set to Offline or Disabled, then the other DataCore
Server will be designated the Active Optimized side. The Host will be notified by both
DataCore Servers that there has been an ALUA state change, forcing the Host to re-check
the ALUA state of both DataCore Servers and act accordingly.
If the Storage Source on the preferred DataCore Server becomes unavailable but the Host
Access for the Virtual Disk remains Read/Write, for example if only the Storage behind the
DataCore Server is unavailable but the FE and MR paths are all connected or if the Host
physically becomes disconnected from the preferred DataCore Server (e.g. Fibre Channel or
iSCSI Cable failure) then the ALUA state will not change for the remaining, Active Nonoptimized side. However, in this case, the DataCore Server will not prevent access to the
Host nor will it change the way READ or WRITE IO is handled compared to the Active
Optimized side, but the Host will still register this DataCore Servers Paths as Active NonOptimized which may (or may not) affect how the Host behaves generally.

Page | 11

Host Configuration Guide IBM AIX

In the case where the Preferred Server is set to All, then both DataCore Servers are
designated Active Optimized for Host IO.
All IO requests from a Host will use all Paths to all DataCore Servers equally, regardless of
the distance that the IO has to travel to the DataCore Server. For this reason, the All setting
is not normally recommended. If a Host has to send a WRITE IO to a remote DataCore
Server (where the IO Path is significantly distant compared to the other local DataCore
Server), then the WAIT times accrued by having to send the IO not only across the SAN to
the remote DataCore Server, but for the remote DataCore Server to mirror back to the local
DataCore Server and then for the mirror write to be acknowledged from the local DataCore
Server to the remote DataCore Server and finally for the acknowledgement to be sent to the
Host back across the SAN, can be significant.
The benefits of being able to use all Paths to all DataCore Servers for all Virtual Disks are
not always clear cut. Testing is advised.
For Preferred Path settings it is stated in the SANsymphony-V Help:
A preferred front-end path setting can also be set manually for a particular virtual disk. In
this case, the manual setting for a virtual disk overrides the preferred path created by the
preferred server setting for the host.
So for example, if the Preferred Server is designated as DataCore Server A and the
Preferred Paths are designated as DataCore Server B, then DataCore Server B will be the
Active Optimized Side not DataCore Server A.
In a two-node Server group there is usually nothing to be gained by making the Preferred
Path setting different to the Preferred Server setting and it may also cause confusion when
trying to diagnose path problems, or when redesigning your DataCore SAN with regard to
Host IO Paths.
Where there are three or more Servers in a Server Group, and where one or more of these
DataCore Servers shares Mirror Paths between different DataCore Servers then setting the
Preferred Path makes more sense. So for example, DataCore Server A has two mirrored
Virtual Disks, one with DataCore Server B, and one with DataCore Server C and
DataCore Server B also has a mirrored Virtual Disk with DataCore Server C then using
just the Preferred Server setting to designate the Active Optimized side for the Hosts
Virtual Disks becomes more complicated. In this case the Preferred Path setting can be used
to override the Preferred Server setting for a much more granular level of control.

Page | 12

Host Configuration Guide IBM AIX

Appendix B
Configuring Disk Pools
See Creating Disk Pools and Adding Physical Disks from the SANsymphony-V Help:
http://www.datacore.com/SSV-Webhelp/About_Disk_Pools.htm
The smaller the SAU size, the larger the number of indexes are required, by the Disk Pool
driver, to keep track of the equivalent amount of allocated storage compared to a Disk Pool
with a larger SAU size; e.g. there are potentially four times as many indexes required in a
Disk Pool using a 32MB SAU size compared to one using 128MB the default SAU size.
As SAUs are allocated for the very first time, the Disk Pool needs to update these indexes
and this may cause a slight delay for IO completion and might be noticeable on the Host.
However this will depend on a number of factors such as the speed of the physical disks,
the number of Hosts accessing the Disk Pool and their IO READ/WRITE patterns, the
number of Virtual Disks in the Disk Pool and their corresponding Storage Profiles.
Therefore, DataCore usually recommend using the default SAU size (128MB) as it is a good
compromise between physical storage allocation and IO overhead during the initial SAU
allocation index update. Should a smaller SAU size be preferred, the configuration should
be tested to make sure that a potential increased number of initial SAU allocations does not
impact the overall Host performance.

Reclaiming Storage from Disk Pools

Using SCSI UNMAP / ATA Trim commands
As of SANsymphony-V 9.0 PSP4 there is support for ATA Trim commands; however please
refer to your vendors documentation to determine which version of AIX including which
file system type(s) support Trim commands. The SCSI UNMAP feature is not supported
with AIX Hosts on DataCore Servers.

Automatic Reclamation
Since SANsymphony-V 9.0 PSP4 the DataCore Server will, in the background, continuously
scan each Physical Disk in a Pool for any SAUs that contain all-zero data which are then
reclaimed back into the Disk Pool. The Automatic Reclamation process runs at a low
priority, so as to not potentially interfere with overall Disk Pool performance, and so will
generally take longer to scan a Physical Disk in a Pool compared to a Manual Reclamation
request (see below). However no user intervention is required.
Page | 13

Host Configuration Guide IBM AIX

Manual Reclamation
For AIX Hosts that either do not support the fstrim command, or are using Virtual Disks
served from DataCore Servers running SANsymphony-V 9.0 PSP3 update2 or earlier
(including all versions of SANsymphony-V 8.x); a suggestion would be to create a sparse file
of an appropriate size (If there is enough free space available in the file system) and then
zero-fill it using the dd command.
This example will write zeroes within an empty file of 2GB in size (called my_file) using
the dd command:

dd if=/dev/zero of=my_file bs=1024 count=2097152

Then either wait for an Automatic Reclamation to take place or run a Manual Reclamation.
See the Performing Reclamation section from the SANsymphony-V Help:
http://www.datacore.com/SSV-Webhelp/Reclaiming_Virtual_Disk_Space.htm
Note that it is also possible to script manual reclamation using the
Start-DcsVirtualDiskReclamation PowerShell Command.

How much storage will be reclaimed?

It is impossible to predict exactly how many Storage Allocation Units (SAUs) will be
reclaimed. For reclamation of an SAU to take place, it must contain only all-zero block data
over the entire SAU else it will remain allocated and this is entirely dependent on how and
where the Host has written its data on the DataCore LUN. For example, if the Host has
written the data in such a way that every allocated SAU contains a small amount of nonzero block data, even if the total amount of data is significantly less than the total amount of
SAU allocation, then no SAUs can be reclaimed.
It may be possible, in some cases, to use the Host Operating Systems own defragmentation
tools to force the non-zero block data to be moved to a more contiguous pattern, so leaving
the end of the DataCore LUN full of SAUs that no longer have non-zero data on them that
can then be reclaimed. However care should be taken that the act of defragmenting the data
does not itself cause more SAU allocation as the block data is moved around during the reorganization. DataCore Software can offer no guarantees.

Page | 14

Host Configuration Guide IBM AIX

Previous Changes
2015
February 2015

Updated section:
List of qualified AIX Versions
AIX 7.1 is now qualified with SANsymphony-V 10.x using non-ALUA settings.
Note: iSCSI is still not considered qualified at this time; all qualified versions are with Fibre Channel
only.

2014
December 2014
No new technical information has been added but this document now combines all of DataCores AIX-related
information from older Technical Bulletins into a single document including:
Technical Bulletin 6: AIX Hosts
Technical Bulletin 8: Formatting Hosts File Systems on Virtual Disks created from Disk Pools
Technical Bulletin 11: Disk Timeout Settings on Hosts
Technical Bulletin 16: Reclaiming Space in Disk Pools

Added new information:

Which Distributions are qualified?
Added new tables to show which versions are explicitly qualified, unqualified and not supported with
either SANsymphony-V 8.1 PSP1 Update 4, 9.x and 10.x, and if the configuration is with or without
ALUA enabled Hosts.
Note that the minimum requirement for SANsymphony-V 8.x is now 8.1 PSP1 Update 4
Appendix A
This section gives more detail on the Preferred Server and Preferred Path settings with regard to how
it may affect a Host.
Appendix B
This section incorporates information regarding Reclaiming Space in Disk Pools (from Technical
Bulletin 16) that is specific to AIX Hosts.

Updated existing entries:

Host Settings - Improved explanations to most of the required Host Settings and DataCore Server
Settings generally.

Page | 15

Host Configuration Guide IBM AIX

2013
Technical Bulletin 6: AIX Hosts
April 2013
Removed all references to SANmelody as this is now End of Life of December 31 2012. Removed all
references to iSCSI as this is not supported with AIX.
July 2012
Updated for SANsymphony-V 9.x. No new technical information.
January 2012
Updated DataCore Server and Host minimum requirements. Removed all references to End of Life
SANsymphony and SANmelody versions that are no longer supported as of December 31 2011.
June 2011
Added AIX 7.1.
November 2011
Removed all references to End of Life SANsymphony and SANmelody versions that are no longer supported
as of July 31 2011.
October 2011
Added SANsymphony-V 8.x
July 2009
Added AIX 6.1.x.
March 2009
Initial publication of Technical Bulletin. Added AIX 5.2 TL10

Page | 16

Host Configuration Guide IBM AIX

COPYRIGHT
Copyright 2015 by DataCore Software Corporation. All rights reserved.
DataCore, the DataCore logo and SANsymphony are trademarks of DataCore Software Corporation.
Other DataCore product or service names or logos referenced herein are trademarks of DataCore
Software Corporation. All other products, services and company names mentioned herein may
be trademarks of their respective owners.
ALTHOUGH THE MATERIAL PRESENTED IN THIS DOCUMENT IS BELIEVED TO BE
ACCURATE, IT IS PROVIDED AS IS AND USERS MUST TAKE ALL RESPONSIBILITY FOR
THE USE OR APPLICATION OF THE PRODUCTS DESCRIBED AND THE INFORMATION
CONTAINED IN THIS DOCUMENT. NEITHER DATACORE NOR ITS SUPPLIERS MAKE ANY
EXPRESS OR IMPLIED REPRESENTATION, WARRANTY OR ENDORSEMENT REGARDING,
AND SHALL HAVE NO LIABILITY FOR, THE USE OR APPLICATION OF ANY DATACORE
OR THIRD PARTY PRODUCTS OR THE OTHER INFORMATION REFERRED TO IN THIS
DOCUMENT. ALL SUCH WARRANTIES (INCLUDING ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE
AND AGAINST HIDDEN DEFECTS) AND LIABILITY ARE HEREBY DISCLAIMED TO
THE FULLEST EXTENT PERMITTED BY LAW.
No part of this document may be copied, reproduced, translated or
reduced to any electronic medium or machine-readable form
without the prior written consent of DataCore Software
Corporation