HP Logical Server Management Best Practices

36
The XML file contains a number of <StorageEntry> elements, each with various tagged properties and a number
of <Volume> and <SanPort> elements. As noted earlier, the <id> is used for matching. When the XML file is used
to facilitate communication between the server and storage administrators, the storage pool entry <id> would be left
unmodified (as would many of the properties such as <name>, <description>, <type>, and
<portabilityGroupName>). The <Volume> specifications represent the requests from the server administrator,
with <storageSize> and <storageSizeType> (MB or GB), the <raidLevel>, <bootDisk> (true or false,
etc.) and the <SanPort> specifications supply <fabric> names and initiator WWNs within <ServerWWN>. The
storage administrator would be able to use those initiators when creating, presenting, and zoning the needed storage
volumes. The storage controller port WWNs (and LUN numbers) can then be edited into the <SanVolumePath>
elements. The storage administrator might define the <priority> and <port> for each <SanVolumePath>, or
may leave it to the server administrator to do that via the modify storage pool entry interface. The <ready> value
should be set to true when the storage is available for use (i.e., created, presented, and zoned); it is a parallel to the
Ready checkbox in the GUI.
When the XML file is used for the bulk creation of storage pool entries, the <id> tag can be left unspecified, as
Matrix OE will define ID values as the import command creates the corresponding entries. For each
<StorageEntry> the storage administrator would need to specify the <name>, <description>, <type> as
SAN, <portabilityGroupName> value (based on their understanding of the environment in which the storage will
be used), <operatingSystem> (e.g., Windows, Linux, HP-UX), <useRedundancy> as true or false, and the
number of <sharers> (at least 1).
The <Volume> elements provide information on the volumes, including <storageSize>, <storageSizeType>
(MB or GB), <raidLevel> (NONE, RAID0, RAID1, RAID4, RAID5, RAID6, RAID10, or RAID50), <bootDisk> as
true or false, <useRedundancy> as true or false and <SanVolumePath> describing the storage controller ports
(with <targetWWN> and <LUN> information). The <SanVolumePath> <priority> element can be set to
PRIMARY, SECONDARY, USEBIOS, or DISABLED.
The <SanPort> elements provide information about the <fabric> and <ServerWWN> values. The server HBA
initiator WWN values must be valid Virtual Connect WWNs (probably reserved via lsmutil –reserve -wwn).
The <nodeValue> field can be left blank or populated with a valid WWN value and is used by some arrays and
switches. If left blank, a WWN will be allocated. The <type> and <allocatedValue> values are fields set by
Matrix OE and should not be changed if the file was generated by lsmutil, otherwise when creating a new
storage pool entry the value for <type> should be set to zero and <allocatedValue> should be left blank. The
<ready> value should be set to true (since the volumes should have been created, presented, and zoned prior to
being made available for import) and the <inProfile> value would be false for new entries (since Matrix OE has
not yet configured the WWNs into the Virtual Connect profile for the logical server).
Storage pool entry tagging
Matrix OE provides the ability to specify tag values for storage pool entries. These arbitrary text strings can reflect a
dictionary of terms agreed to by the server and storage administrator and may represent tiers of storage (e.g., tier 1,
tier 2, tier 3, gold, silver, bronze), intended storage use (e.g., shared database), organizational alignment (e.g.,
finance, data entry, test-dev) or other aspects meaningful for the customer environment (e.g., if the storage can be
configured for replication).
Tags are defined from the storage pool screen (accessed via the Virtualization tab, Modify menu, and Logical
Server Storage Pools…). Figure 27 shows the “Manage Tags” button, while Figure 28 shows a variety of tags
which have been defined.