Ibm Bto SNV1 Student Guide Book 1 375 450 PDF

V10.
0
Student Notebook
Uempty
Host object details and I/O group counts

IBM_2145:BLANC_SVC:admin>lshost 0
id 0
name BLANCWIN1 Each host is, by default,
port_count 2
type generic is entitled to access volumes
mask 11111111...11111111
iogrp_count 4 owned by all four I/O groups
status online
WWPN 21000024FF4B7B9F
node_logged_in_count 4
state active
WWPN 21000024FF4B7B9E Physical access to volumes
node_logged_in_count 4 is enabled by SAN zoning
state active
for Fibre Channel hosts
id 1
name BLANCAIX BLANCAIX is
port_count 2
type generic entitled to access volumes
mask 11111111...11111111
iogrp_count 2 owned by two I/O groups
status online
WWPN 10000000C9757E2F
state inactive These two host WWPNs are
WWPN 10000000C9757E2E logged in to four SVC nodes
state inactive
© Copyright IBM Corporation 2011, 2014
Figure 4-17. Host object details and I/O group counts SNV13.0
Notes:
The lshost <hostname> (or ID) command returns the details associated with the specific
host object. It displays the values of all the WWPNs defined for the host object. The node logged in
count is the number of SVC nodes that the host WWPN has logged in.
© Copyright IBM Corp. 2011, 2014 Unit 4. SVC host access 4-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Student Notebook
Manage host object counts per I/O group

IBM_2145:BLANC_SVC:admin> rmhostiogrp -iogrp io_grp1 BLANCAIX
Removed host BLANCAIX’s
entitlement to access volumes
IBM_2145:BLANC_SVC:admin>lsiogrp owned by io_grp1
id name node_count vdisk_count host_count
0 io_grp0 2 4 3
1 io_grp1 2 5 1 Host count decreased for
2 io_grp2 0 0 1
3 io_grp3 0 0 1 io_grp1 (from 2 to 1)
4 recovery_io_grp 0 0 0
id 1
name BLANCAIX
port_count 2 BLANCAIX is now entitled
type generic
mask 11111111...111111111 to access volumes
iogrp_count 1
status online owned by one I/O group
WWPN 10000000C9757E2F
node_logged_in_count 4 Entitlement is NOT the same
state inactive
WWPN 10000000C9757E2E as the ability to access.
node_logged_in_count 4 BLANCAIX can be
state inactive
IBM_2145:BLANC_SVC:admin> lshostiogrp 1 enabled to access
id name
0 io_grp0 BLANCAIX is entitled to access volumes io_grp0 volumes
owned by io_grp0 with proper zoning
Figure 4-18. Manage host object counts per I/O group SNV13.0
Notes:
To support more than 256 host objects per SVC cluster (or 512 host objects for a cluster with
2145-xx8 nodes) the rmhostiogrp command is used to remove an I/O group eligibility from an
existing host object.
The host object to I/O group associations only define a host object’s entitlement to access volumes
owned by the I/O groups. Physical access to the volumes require proper SAN zoning for Fibre
Channel hosts and IP connectivity for iSCSI hosts.
4-20 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

V10.0
Student Notebook
Uempty
iSCSI initiator and target IQNs

id 2
Host BLANCiSCSI is entitled
name BLANCiSCSI
port_count 1 to access volumes
type generic owned by one I/O group
mask 11111111. . .11111111
iogrp_count 1 Host IQN defined
status online to SVC
iscsi_name iqn.1991-05.com.microsoft:blancwin2
state inactive
IBM_2145:BLANC_SVC:admin> lsnode 1
IP
id 1
name NODE1
…
SVC node IQN
iscsi_name iqn.1986-03.com.ibm:2145.blancsvc.node1
iscsi_alias defined to host
failover_active no
failover_name NODE2 Physical access to volumes
failover_iscsi_name iqn.1986-03.com.ibm:2145.blancsvc.node2 is enabled by iSCSI IP
failover_iscsi_alias
connectivity for iSCSI hosts
panel_name 170209
Figure 4-19. iSCSI initiator and target IQNs SNV13.0
Notes:
The iSCSI attached hosts are eligible by default to access volumes in all four I/O groups.
For Fibre Channel attached hosts, the host WWPNs need to be zoned to the SVC nodes in the I/O
groups that contain volumes for a given host.
For iSCSI attached hosts, the host needs IP network connectivity to the nodes in the I/O groups that
contain volumes for the given host.
Student Notebook
SVC 2145-CG8 and CF8 nodes: Ethernet ports for

iSCSI connectivity
10GbE
1 2 3 4 E3 E4 iSCSI
1GbE
E1 E2 iSCSI
IBM_2145:BLANC_SVC:admin>lsportip -delim , -filtervalue node_id=1

id,node_id,node_name,IP_address,mask,gateway,IP_address_6,prefix_6,gateway
_6,MAC,duplex,state,speed,failover,link_state
1,1,NODE1,10.62.161.100,255.255.255.0,10.62.161.254,,,,34:40:b5:d7:6d:80,F
ull,configured,1Gb/s,no,active
1,1,NODE1,,,,,,,34:40:b5:d7:6d:80,Full,configured,1Gb/s,yes,active
2,1,NODE1,10.62.161.101,255.255.255.0,10.62.161.254,,,,34:40:b5:d7:6d:82,F
2,1,NODE1,,,,,,,34:40:b5:d7:6d:82,Full,configured,1Gb/s,yes,active
E1 and E2 ports of NODE1 and NODE2
of io_grp0 are configured for iSCSI IP
IBM_2145:BLANC_SVC:admin>lsportip -delim , -filtervalue node_id=2
id,node_id,node_name,IP_address,mask,gateway,IP_address_6,prefix_6,gateway
_6,MAC,duplex,state,speed,failover,link_state
1,2,NODE2,10.62.161.102,255.255.255.0,10.62.161.254,,,,34:40:b5:d7:26:3c,F
1,2,NODE2,,,,,,,34:40:b5:d7:26:3c,Full,configured,1Gb/s,yes,active
2,2,NODE2,10.62.161.103,255.255.255.0,10.62.161.254,,,,34:40:b5:d7:26:3e,F
2,2,NODE2,,,,,,,34:40:b5:d7:26:3e,Full,configured,1Gb/s,yes,active
Assigned volumes owned by io_grp0
to host BLANCiSCSI.
Figure 4-20. SVC 2145-CG8 and CF8 nodes: Ethernet ports for iSCSI connectivity SNV13.0
Notes:
The lsportip command output displays the iSCSI IP port configuration of the nodes of the
cluster. Use the -filtervalue node_id= keyword to filter the output by node.
In the example, Ethernet ports 1 and 2 of NODE1 and NODE2 have been configured with IP
addresses for iSCSI access.
The 2145-CG8 and CF8 models support 10GbE iSCSI capability through I/O ports E3 and E4.
Keep in mind that a volume is owned by an I/O group. The iSCSI ports of the nodes in that I/O
group must be configured with an IP address in order for the iSCSI host initiator to access the
volumes of the I/O group.

V10.0
Student Notebook
Uempty
SVC 2145-DH8 node: Ethernet ports for iSCSI
connectivity
• Option for dual port 10 GbE adapter for iSCSI capability
• I/O port E2 and E5 both nodes of the I/O group
10 Gb Ethernet-fault LEDs.
Slot 2 and Slot 5
10 GbE
1 2 3 4 iSCSI
1 GbE
iSCSI
1 Gb Ethernet port x3
Figure 4-21. SVC 2145-DH8 node: Ethernet ports for iSCSI connectivity SNV13.0
Notes:
The 2145-DH8 model supports the option for dual port 10GbE adapter for iSCSI capability through
I/O ports E2 and E5, which can be used for iSCSI host attachment. The 2145-CG8 node also
supports the optional use of SSD devices (up to four). However, both options cannot coexist on the
same SVC node.
Student Notebook
For access: Volumes must be assigned to a host

BLANCAIX is entitled to access volumes
owned by io_grp0
BLANCWIN1 is entitled to access volumes

owned by all four I/O groups
Up to 512 volume mappings
per host object;
2145-Cx8 models increase
maximum to 2048
Figure 4-22. For access: Volumes must be assigned to a host SNV13.0
Notes:
Volumes are mapped to a host for access. If a volume is mapped to multiple hosts then there must
be software to provide for integrity of these hosts sharing a volume (cluster servers such as MSCS
or shared file systems such as GPFS).
To view volumes assigned to a given host, select Volumes > Volumes by Host and click the host
object name in the Host Filter list. Volumes that have been mapped or assigned to the selected host
are displayed.
If a host is defined with access to only a subset of I/O groups then that subset is displayed with the
host. In the example, BLANCAIX is only entitled to access volumes owned by I/O group 0.
BLANCWIN1 had been defined with access to all four I/O groups. Therefore no I/O group list is
displayed with the host in this panel. The default being each host object is entitled to access
volumes owned by all four I/O groups.
A volume can be assigned to more than one host if host based clustering or serialization software is
implemented.

V10.0
Student Notebook
Uempty
Host volume mapping and I/O group verification
Gee: What if io_grp1 volume

gets assigned to
BLANCAIX?
Phew: System is smart

enough to know
better -
Figure 4-23. Host volume mapping and I/O group verification SNV13.0
Notes:
SVC polices the volume to host mapping assignments based on the I/O group entitlement of the
host object. Since the BLANCAIX host is only entitled to access volumes owned by I/O group 0 then
the assignment of volumes owned by other I/O groups is prohibited by the SVC system.
Student Notebook
Host objects, volume mappings, and I/O groups

supported maximums
Volume mappings Host objects Host objects

SVC node model
per host object per I/O group per SVC cluster
2145-8F4 512 256 1024
2145-8G4 512 256 1024
2145-8A4 512 256 1024
2145-CF8 2048 512 2048
2145-CG8 2048 512 2048
2145-DH8 2048 512 2048
• SVC v7 increased scalability for 2145-Cx8 and 2145-DH8 models

• Clusters with mixture of node types have the lower limit for all I/O groups
Figure 4-24. Host objects, volume mappings, and I/O groups supported maximums SNV13.0
Notes:
The visual shows a chart that lists the maximum host objects, volume mappings, and I/O groups
supported on the SVC. SVC v7 increased the scalability for 2145-CF8, 2145-CG8, and 2145-DH8.

V10.0
Student Notebook
Uempty
SVC host access topics (2 of 4)

• Host to SVC volume access infrastructure
• Fibre Channel host to SVC SAN fabric zoning
• Non Disruptive Volume Move (NDVM)
• iSCSI host to SVC IP connectivity
Figure 4-25. SVC host access topics (2 of 4) SNV13.0
Notes:
In this topic, we will discuss Fibre Channel host access to the SVC fabric zoning.
Student Notebook
Multipathing and host LUN access control

Example
Host
Multipath driver
SDD
multipath manages SDDDSM
support multiple paths SDDPCM
MPIO to volume
Exploits multipath device access:
2 4 9 Dynamic load balancing -
L2 L11 L3 L4
4 based on policy
9 Dynamic reconfiguration
3
1 4 1 3 9 Automatic path failover
2 Switch 9 Automatic path reclamation
9 Automatic path failback
Supports SVC preferred node
for multipathing
L
Figure 4-26. Multipathing and host LUN access control SNV13.0
Notes:
In a SAN environment, a host system with a multiple Fibre Channel adapter ports which connect
through a switch to multiple storage ports is considered to have multiple paths. Due to these
multiple paths, the same LUN is reported to the host system more than once.
For availability, host systems generally have two HBA ports installed; and storage systems typically
have multiple ports as well. The number of multiple instances of the same LUN increases as more
ports are added.
Most host platforms support this environment which is called Multipath I/O or MPIO. For Windows
and AIX only a multipath driver that instructs the OS which path to pick for a given I/O is required.
These drivers are the device-specific module (DSM) and the path control module (PCM) for
Windows and AIX respectively.
The SDD provides multipath support for certain OS environments that do not have native MPIO
capability. SDD also enhances the functions of the Windows DSM and AIX PCM MPIO frameworks.

V10.0
Student Notebook
Uempty
Host zone definition: AIX1 four-paths example

AIX1-A1 zone AIX1 AIX1-A2 zone
[(21,1) (11,1) (11,2)] A1 A2 [(22,1) (12,1) (12,2)]
1 1
ID ID
A1 21 A2 22
Fabric 1 Fabric 2
1 2 1 2
ID
E3 11 21 14 24 F1 E1 11
E4 13 23 12 22 F2 E2 ID
12
11 12 13 14 21 22 23 24
NODE1 NODE2
AIX1 host port and
one port per Note: No storage
SVC node system ports!
Figure 4-27. Host zone definition: AIX1 four-paths example SNV13.0
Notes:
Host servers should have two or more HBAs ports but no more than four HBA ports. This allows for
a minimum of four paths and a maximum of eight paths between the host and the I/O group.
Each host HBA port is zoned with one port of each SVC node of an I/O group in a four-path
environment. In the example, HBA A1 is zoned with one port from NODE1 and one from NODE2.
HBA A2 is also zoned with one port from each SVC node.
Host HBA ports accessing only SVC-surfaced volumes should not be in the same zone as
back-end storage ports.
Student Notebook
AIX1 volume1 preferred node and paths

[(21,1) (11,1) (11,2)] A1 A2 [(22,1) (12,1) (12,2)]
V1
1 1
ID ID
A1 21 A2 22
Fabric 1 Fabric 2
1 2 1 2
ID
E3 11 21 14 24 F1 E1 11
E4 13 23 12 22 F2 E2 ID
12
Preferred Alternate
paths paths
11 12 13 14 21 22 23 24
NODE1 V1 NODE2
Preferred node I/O group Alternate node
Figure 4-28. AIX1 volume1 preferred node and paths SNV13.0
Notes:
A volume is assigned to an SVC node at creation and this node is the preferred node through which
the volume is normally accessed. That is, the SDDPCM path selection algorithm drives I/O and load
balances across the paths to the preferred node.
For the AIX1 zoning example, AIX1 has four paths to the SVC I/O group. When volume V1 (whose
preferred node is NODE1) is accessed for I/O then the path selection algorithms will load balance
across the two paths to NODE1 (its preferred node). The other two paths defined in this zone are to
NODE2 (the alternate node for volume V1). These paths are not used unless path failures occur.

V10.0
Student Notebook
Uempty
AIX1 volume2 preferred node and paths

[(21,1) (11,1) (11,2)] A1 A2 [(22,1) (12,1) (12,2)]
V2
1 1
ID ID
A1 21 A2 22
Fabric 1 Fabric 2
1 2 1 2
ID
E3 11 21 14 24 F1 E1 E4 13 23 12 22 F2 E2 ID
11 12
Alternate Preferred
paths paths
11 12 13 14 21 22 23 24
NODE1 V2 NODE2
Alternate node I/O group Preferred node
Figure 4-29. AIX1 volume2 preferred node and paths SNV13.0
Notes:
When a volume is created then the preferred node can be specified by the administrator or
defaulted. The default alternates the assignment of the preferred node between the two SVC nodes
in the I/O group as each volume is created.
Continuing with the AIX1 example, at volume creation the volume V2 was assigned to NODE2 as
its preferred node. SDDPCM path selection will load balance I/Os for volume V2 across paths to its
preferred node NODE2.
Host AIX1 is zoned to have four paths to the SVC I/O group. Access from AIX1 is with the assigned
paths to the volume’s preferred node by SDDPCM. All four paths are used to handle AIX1’s I/O
requests if the ownership of volumes is spread across both SVC nodes in the I/O group.
Student Notebook
Host zone: W2K1 host exercise

W2K1-W1 zone? W2K1 W2K1-W2 zone?
( ) W1 W2 ( )
V3
0 1 0 1
ID ID
W1 A1 21 W2 A2 22
Fabric 1 Fabric 2
0 1 2 3 4 5 6 0 1 2 3 4 5 6
ID
E3 11 21 14 24 F1 E1 E4 13 23 12 22 F2 E2 ID
11 12
11 12 13 14 21 22 23 24
NODE1 V3 NODE2
Alternate node I/O group Preferred node
Figure 4-30. Host zone: W2K1 host exercise SNV13.0
Notes:
Each host should have its own zone. This is referred by some in the SAN industry as single initiator
zoning.
The workload of each SVC port should be somewhat equal. Therefore, distribute the SVC ports
across host zone definitions.
Exercise: Review the visual and code the zone definition for the W2K1 host using port zoning.
Fabric 1: _____________________________________
Fabric 2: _____________________________________

V10.0
Student Notebook
Uempty
Host zone: Linux1 host exercise

Linux1 zone? Linux1 Linux1-L2 zone?
( ) L1 L2 ( )
V4
ID ID
W1 A1 L1 21
W2 A2 L2 22
Fabric 1 Fabric 2
ID
E3 11 21 14 24 F1 E1 E4 13 23 12 22 F2 E2 ID
11 12
Paths?
11 12 13 14 21 22 23 24
NODE1 V4 NODE2
Figure 4-31. Host zone: Linux1 host exercise SNV13.0
Notes:
Exercise: Complete the following:
• Assign SVC ports to the Linux1 host. Allow four paths access to the SVC node pair.
• Code the zone definitions for the Linux1 host for both fabrics.
Student Notebook
Host ports zoned for four paths: GUI example
Each host WWPN is zoned with

one SVC WWPN per node.
Figure 4-32. Host ports zoned for four paths: GUI example SNV13.0
Notes:
The GUI Fibre Channel view can be used to verify zoning between a host and the SVC ports.
The BLANCWIN1 host is zoned for four-path access to its volumes. The guideline for four-path host
zoning is to zone each host port with one SVC port per node.
The connectivity data displayed confirms that each host port (Remote WWPN) has four entries (one
per node). The Local WWPN column lists the specific SVC node ports zoned with a given host
WWPN. Notice that the top host port is zoned with port 2 of each SVC node (Q value 3 in the
WWPNs) and the bottom host port is zone with port 1 of each SVC node (Q value 4 in the WWPNs).

V10.0
Student Notebook
Uempty
Host zoned with four paths and volume access

IBM_2145:BLANC_SVC:admin>lshostvdiskmap -delim , 0
id,name,SCSI_id,vdisk_id,vdisk_name,vdisk_UID,IO_group_id,IO_group_name
0,BLANCWIN1,3,7,SPUNKY,6005076801818781F800000000000008,0,io_grp0
0,BLANCWIN1,0,4,SPUNK,6005076801818781F800000000000005,1,io_grp1
0,BLANCWIN1,1,5,SPUNKER,6005076801818781F800000000000006,1,io_grp1
0,BLANCWIN1,2,6,SPUNKS,6005076801818781F800000000000007,1,io_grp1
Windows host
BLANCWIN1
(7B9E) (7B9F)
Q Q
13 io_grp0 14
NODE1 (F03F) SPUNKY NODE1 (F03F)
ID 7
23 UID…08 24
SCSI ID 3
NODE2 (EE17) NODE2 (EE17)
33 io_grp1 34
NODE3 (ED34) SPUNK NODE3 (ED34)
ID 4
43 UID…05 44
SCSI ID 0
NODE4 (EBA4) NODE4 (EBA4)
Figure 4-33. Host zoned with four paths and volume access SNV13.0
Notes:
The lsvhostvdiskmap command shows four volumes mapped to host object ID 0 (BLANCWIN1).
Focus on the first two volume entries since they belong to two different I/O groups. Note the last
couple of bytes of the UID is x’0008’ for volume SPUNKY and x’0005’ for volume SPUNK.
Note also the (XXXX) is the last couple of bytes of the WWPN (host and SVC node ports).
Based on the GUI Fibre Channel connectivity output, the Windows host is zoned to access volumes
from both I/O groups with four paths. Specifically:
• Host WWPN that ends with (7B9E) is zoned to access the port with a WWPN Q value of 3 for
each of the four SVC nodes in the cluster.
• Host WWPN that ends with (7B9F) is zoned to access the port with a WWPN Q value of 4 for
each of the four SVC nodes in the cluster.
Student Notebook
Host HBA to SVC ports: Zoning verification
Each host WWPN is zoned with

one SVC WWPN per node
Figure 4-34. Host HBA to SVC ports: Zoning verification SNV13.0
Notes:
For Windows, vendor-supplied utilities are typically used to display the Fibre Channel configuration.
For QLogic HBAs, the Q ConvergeConsole utility can be used. Examine the SAN connectivity from
this QLogic HBA reporting tool for the BLANCWIN1 host (located at IP address 10.62.161.140).
• The top left half the chart shows host HBA port1 discovered devices on the SAN. The low order
third byte of all four entries have a x’30’ (Q value 3) for the WWPN of each of the four SVC
nodes. The top right box contains the host initiator QLogic WWPN which ends with x’7B9E’.
• The bottom left half the chart shows host HBA port2 discovered devices on the SAN. The low
order third byte of all four entries have a x’40’ (Q value 4) for the WWPN of each of the four SVC
nodes. The bottom right box contains the host initiator QLogic WWPN which ends with x’7B9F’.
This connectivity data matches the GUI Settings > Network > Fibre Channel view output for the
same host.

V10.0
Student Notebook
Uempty
Host zoned for four paths: Host paths view
Figure 4-35. Host zoned for four paths: Host paths view SNV13.0
Notes:
From the Windows host perspective, the SVC volumes are standard SCSI disks.
The SDDDSM datapath query device command output enables the correlation between
Windows disks and SVC volumes based on the serial number shown for the disk (which is the SVC
UID for the volume).
Four paths are displayed with each disk or SVC volume. This validates the four-path zoning
objective. Even though these two volumes are owned by different I/O groups this information isn’t
obvious from the SDD output.
The -l parameter is appended to the datapath query device command and causes SDDDSM to
flag paths to the alternate (non-preferred node) with an asterisk. The 0 and 1 values of the
command identifies the SDD device number range of the Windows disks to be displayed.
Student Notebook
Host zoned for four paths: Host device view
SDDDSM manages
four 2145 Multi-Path devices
each with four paths
based on its 4 reported
2145 SCSI disk devices
Figure 4-36. Host zoned for four paths: Host device view SNV13.0
Notes:
Due to four-path zoning, each volume has been reported four times during host HBA SAN device
discovery. This is seen in the Windows Device Manager view for Disk drives.
SDDDSM (a Windows MPIO compliant multipath driver) recognizes and supports the 2145 device
type. SDDDSM ascertains that each of the four 2145 SCSI Disk Device instances correlates to one
SVC volume and thus creates a 2145 Multi-Path Disk Device to represent that volume. SDDDSM
also manages the path selection to the four paths of each volume.
The SDDDSM datapath query device command is simply displaying this database of
information that SDDDSM is maintaining for each volume managed.

V10.0
Student Notebook
Uempty
Zone definition: Eight paths option example

AIX1-A1 zone AIX1-A2 zone
AIX1
(21,1;11,1;11,2; (22,1;12,1;12,2;
11,3;11,4) A1 A2 12,3;12,4)
V1
1 1
ID ID
A1 21 A2 22
Fabric 1 Fabric 2
1 2 3 4 1 2 3 4
ID
E3 11 21 14 24 F1 E1 11
E4 13 23 12 22 F2 E2 ID
12
AIX1 host port and

two ports per
11 12 13 14 21 22 23 24
SVC node NODE1 V1 NODE2
Figure 4-37. Zone definition: Eight paths option example SNV13.0
Notes:
The maximum number of paths from a host to the SVC I/O group is eight.
In the example, each host HBA port is zoned with two ports from each SVC node thus providing a
total of eight paths. SDDPCM path selection will drive I/O to the four paths associated with a volume
preferred node.
From the perspective of the AIX1 host, the eight paths do not necessarily provide performance
improvement over the four paths environment. However from an SVC perspective the AIX1 activity
is balanced across the four ports of NODE1. Usually there are multiple hosts connected to an SVC
cluster. The eight path configuration provides for an automatic load leveling of activity across the
four SVC node ports as opposed to the manual load placement approach of the four path
configuration. With a manual load placement it is easy to introduce a skew of activity to a subset of
ports on a node. The skew manifests itself as higher utilization on some ports and therefore longer
response times for I/O operations.
Student Notebook
AIX host object and ports example
IBM_2145:BLANC_SVC:admin>lshost BLANCAIX
id 1
name BLANCAIX
port_count 2
type generic
mask 1111111111111111111111111111111111111111111111111111111111111111
iogrp_count 1
status online
WWPN 10000000C9757E2F
state active
WWPN 10000000C9757E2E
state active
Figure 4-38. AIX host object and ports example SNV13.0
Notes:
The visual shows details of the BLANCAIX host object using both the GUI and the CLI. Observe the
WWPN values of its two ports. From the CLI output, the BLANCAIX host has an object ID of 1.
The BLANCAIX host is entitled to only access volumes owned by I/O group 0.

V10.0
Student Notebook
Uempty
AIX Host ports zoned for eight paths: CLI example

IBM_2145:BLANC_SVC:admin> lsfabric -delim , -host 1
remote_wwpn,remote_nportid,id,node_name,local_wwpn,local_port,local_nportid,state,nam
e,cluster_name,type
10000000C9757E2F,010A00,1,NODE1,500507680130F03F,2,010400,active,BLANCAIX,,host
10000000C9757E2F,010A00,1,NODE1,500507680110F03F,3,010200,active,BLANCAIX,,host
10000000C9757E2F,010A00,2,NODE2,500507680130EE17,2,010300,active,BLANCAIX,,host
10000000C9757E2F,010A00,2,NODE2,500507680110EE17,3,010100,active,BLANCAIX,,host
10000000C9757E2F,010A00,3,NODE3,500507680130ED34,2,011200,inactive,BLANCAIX,,host
10000000C9757E2F,010A00,3,NODE3,500507680110ED34,3,011000,inactive,BLANCAIX,,host
10000000C9757E2F,010A00,4,NODE4,500507680130EBA4,2,011300,inactive,BLANCAIX,,host
10000000C9757E2F,010A00,4,NODE4,500507680110EBA4,3,011100,inactive,BLANCAIX,,host
10000000C9757E2E,010A00,1,NODE1,500507680140F03F,1,010400,active,BLANCAIX,,host
10000000C9757E2E,010A00,1,NODE1,500507680120F03F,4,010200,active,BLANCAIX,,host
10000000C9757E2E,010A00,2,NODE2,500507680140EE17,1,010300,active,BLANCAIX,,host
10000000C9757E2E,010A00,2,NODE2,500507680120EE17,4,010100,active,BLANCAIX,,host
10000000C9757E2E,010A00,3,NODE3,500507680140ED34,1,011200,inactive,BLANCAIX,,host
10000000C9757E2E,010A00,3,NODE3,500507680120ED34,4,011000,inactive,BLANCAIX,,host
10000000C9757E2E,010A00,4,NODE4,500507680140EBA4,1,011300,inactive,BLANCAIX,,host
10000000C9757E2E,010A00,4,NODE4,500507680120EBA4,4,011100,inactive,BLANCAIX,,host
Each host WWPN is zoned with Q

two SVC WWPN per node
Figure 4-39. AIX Host ports zoned for eight paths: CLI example SNV13.0
Notes:
The lsfabric command provides SAN connectivity data between the SVC and its attaching ports.
It is actually the command invoked by the GUI Fibre Channel connectivity view.
The BLANCAIX is zoned for eight paths which means that each host port is zoned with two SVC
ports per SVC node. The top BLANCAIX HBA port is zoned with SVC ports with Q values of 1 and
3 of each node and the bottom BLANCAIX HBA port is zoned with SVC ports with Q values of 2 and
4.
Even though this host is zoned with both I/O groups of the SVC cluster, it is still only entitled to
access volumes owned by I/O group 0. Volumes owned by I/O group 1 can’t even be assigned
(mapped) to this host. However, should the host object be given permission to access volumes
owned by I/O group 1 sometime in the future then the zoning is already setup.
Student Notebook
AIX host bus adapter details: Host WWPNs

{aix_blanc_course} / # lscfg -vl fscsi0
fscsi0 U5796.001.0629517-P1-C4-T1 FC SCSI I/O Controller Protocol Device
{aix_blanc_course} / # lscfg -vl fcs0
fcs0 U5796.001.0629517-P1-C4-T1 FC Adapter
Part Number.................10N8620
Serial Number...............1F8100C060
Manufacturer................001F
EC Level....................A
Customer Card ID Number.....5759
FRU Number.................. 10N8620
Device Specific.(ZM)........3
Network Address.............10000000C9757E2E
{aix_blanc_course} / # lscfg -vl fscsi1

fscsi1 U5796.001.0629517-P1-C4-T2 FC SCSI I/O Controller Protocol Device
{aix_blanc_course} / # lscfg -vl fcs1
fcs1 U5796.001.0629517-P1-C4-T2 FC Adapter
Part Number.................10N8620
Serial Number...............1F8100C060
Manufacturer................001F
EC Level....................A
Customer Card ID Number.....5759
FRU Number.................. 10N8620
Device Specific.(ZM)........3
Network Address.............10000000C9757E2F
Figure 4-40. AIX host bus adapter details: Host WWPNs SNV13.0
Notes:
The AIX command lsdev -Cc adapter |grep fcs shows the names of the Fibre Channel
adapters in this AIX system. The Network Address of the lscfg -vl fcs0 and lscfg -vl fcs1
output identifies the WWPN of each HBA port.
The fscsi0 and fscsi1 devices are protocol conversion devices in AIX. They are child devices of fcs0
and fcs1 respectively.

V10.0
Student Notebook
Uempty
Host zoned with eight paths and volume access

id,name,SCSI_id,vdisk_id,vdisk_name,vdisk_UID,IO_group_id,IO_group_name
1,BLANCAIX,0,1,WISKEE,6005076801818781F800000000000004,0,io_grp0
1,BLANCAIX,1,8,SNUGGUS,6005076801818781F800000000000009,0,io_grp0
AIX host
BLANCAIX
(7E2F) (7E2E)
Q Q
11 13 io_grp0 12 14
NODE1 (F03F) SNUGGUS NODE1 (F03F)
21 23 ID 8 22 24
UID…09
NODE2 (EE17) SCSI ID 1 NODE2 (EE17)
31 33 32 34
io_grp1
NODE3 (ED34) NODE3 (ED34)
41 43 42 44
NODE4 (EBA4) NODE4 (EBA4)
Figure 4-41. Host zoned with eight paths and volume access SNV13.0
Notes:
Based on the lshostvdiskmap output there are two volumes mapped to host BLANCAIX. Focus
will be on the second volume called SNUGGUS with a UID that ends with x’0009’.
The visual shows the zoning between the BLANCAIX host and the four SVC nodes for eight paths.
It is based on the lsfabric output for this host.
Student Notebook
Details for volume SNUGGUS

IBM_2145:BLANC_SVC:admin>
lsvdisk SNUGGUS
id 8
name SNUGGUS
IO_group_id 0 SNUGGUS details continued
IO_group_name io_grp0 copy_id 0
status online status online
mdisk_grp_id 0 sync yes
mdisk_grp_name BLANCDS3K_SASpool primary yes
capacity 8.00GB mdisk_grp_id 0
type striped mdisk_grp_name
formatted no BLANCDS3K_SASpool
mdisk_id type striped
mdisk_name mdisk_id
FC_id mdisk_name
FC_name fast_write_state empty
RC_id used_capacity 8.00GB
RC_name real_capacity 8.00GB
vdisk_UID free_capacity 0.00MB
6005076801818781F800000000000009 overallocation 100
throttling 0 autoexpand
preferred_node_id 1 warning
fast_write_state empty grainsize
cache readwrite se_copy no
udid easy_tier on
fc_map_count 0 easy_tier_status inactive
sync_rate 50 tier generic_ssd
copy_count 1 NODE1 (F03F) tier_capacity 0.00MB
se_copy_count 0 tier generic_hdd
filesystem tier_capacity 8.00GB
mirror_write_priority latency compressed_copy no
RC_change no uncompressed_used_capacity
compressed_copy_count 0 8.00GB
access_IO_group_count 1
Figure 4-42. Details for volume SNUGGUS SNV13.0
Notes:
The lsvdisk SNUGGUS command output provides details for this volume. The vdisk_UID is a
hardware serial number of the volume that is transmitted to the host and ends with x’0009’. The
volume is owned by io_grp0 with a preferred node ID of 1.

V10.0
Student Notebook
Uempty
Host zoned for eight paths: Host paths view

{aix_blanc_course} / # lsdev -Cc disk
hdisk0 Available Virtual SCSI Disk Drive
hdisk1 Available 00-09-02 MPIO FC 2145
{aix_blanc_course} / # lscfg -vl hdisk2
hdisk2 U5796.001.0629517-P1-C4-T2-W500507680110EE17-L1000000000000
MPIO FC 2145
Manufacturer................IBM
Machine Type and Model......2145
ROS Level and ID............0000
Device Specific.(Z0)........0000063268181002
Serial Number...............6005076801818781F800000000000009
{aix_blanc_course} / # pcmpath query device 2
DEV#: 2 DEVICE NAME: hdisk2 TYPE: 2145 ALGORITHM: Load Balance
SERIAL: 6005076801818781F800000000000009
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
0* fscsi0/path0 OPEN NORMAL 42 0
1 fscsi0/path1 OPEN NORMAL 1134 0
Figure 4-43. Host zoned for eight paths: Host paths view SNV13.0
Notes:
The SVC externalized volumes have a device type of 2145.
The lscfg -vl command output for the hdisk identifies the SVC port that reported this LUN to AIX
as SCSI LUN 1 (L1).
The UID from the SVC CLI lsvdisk output is displayed as the serial number in the SDDPCM
pcmpath query device output. So hdisk2 is the SNUGGUS volume.
The SDDPCM output displays eight paths for this hdisk which is an indication that eight-path zoning
was implemented for this host. Half of the paths are flagged with an asterisk to indicate that the path
is not to the preferred node. Therefore, the other four paths (1, 3, 5, and 7) are paths to node ID 1
which is the preferred node for this volume/hdisk.
Student Notebook
Host provided path details for volume (1 of 2)

{aix_blanc_course} / # odmget -q "name=hdisk2" CuPath
CuPath:
name = "hdisk2"
NODE1 (F03F) Preferred node
parent = "fscsi0"
connection = "500507680120ee17,1000000000000"
alias = ""
path_status = 1
path_id = 0
CuPath:
name = "hdisk2"
parent = "fscsi0"
connection = "500507680120f03f,1000000000000" 12
alias = ""
path_status = 1 NODE1 (F03F)
path_id = 1
CuPath:
name = "hdisk2"
parent = "fscsi0"
connection = "500507680140ee17,1000000000000"
alias = ""
path_status = 1
path_id = 2
CuPath:
name = "hdisk2"
parent = "fscsi0"
connection = "500507680140f03f,1000000000000"
14
alias = ""
path_id = 3
Figure 4-44. Host provided path details for volume (1 of 2) SNV13.0
Notes:
The AIX odmget command can be used to obtain detailed information regarding the paths of a
given hdisk.
The WWPN is shown as connection ((remember the Q value in the WWPN). Thus, the connection
identifies the SVC node and port that is represented by this path.
The path_id fields for values of 1, 3, 5, and 7 represent the four ports of SVC node ID 1 (the
volume’s preferred node). Match the lsfabric output for host 1 (BLANCAIX) in a previous visual to
the SVC node ID 1 WWNN and WWPNs.

V10.0
Student Notebook
Uempty
Host provided path details for volume (2 of 2)

CuPath:
name = "hdisk2"
parent = "fscsi1" NODE1 (F03F) Preferred node
connection = "500507680110ee17,1000000000000"
alias = ""
path_status = 1
path_id = 4
CuPath:
name = "hdisk2"
parent = "fscsi1"
connection = "500507680110f03f,1000000000000" 11
alias = ""
path_id = 5
CuPath:
name = "hdisk2"
parent = "fscsi1"
connection = "500507680130ee17,1000000000000"
alias = ""
path_status = 1
path_id = 6
CuPath:
name = "hdisk2"
parent = "fscsi1"
connection = "500507680130f03f,1000000000000"
alias = ""
13
path_id = 7
Figure 4-45. Host provided path details for volume (2 of 2) SNV13.0
Notes:
This is a continuation of the host provided path details for volume.
Student Notebook
Host paths to volume’s preferred node

{aix_blanc_course} /SNUGVGMP # pcmpath query device 2
DEV#: 2 DEVICE NAME: hdisk2 TYPE: 2145 ALGORITHM: Load Balance

SERIAL: 6005076801818781F800000000000009
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
BLANCAIX
fscsi1 fscsi0
Path5 7E2F 7E2E Path3
io_grp0
Path7 Path1
SNUGGUS
11 13 ID 2 12 14
UID…03
NODE1 F03F) SCSI ID 0 NODE1 (F03F)
Figure 4-46. Host paths to volume’s preferred node SNV13.0
Notes:
From the previous two command output sets, an understanding of the path configuration can be
obtained and host zoning can be validated. Under normal circumstances, the SDD distributes I/O
requests across these four paths to the volume’s preferred node. The output of the pcmpath
query device command validates the I/O distribution across the paths of the preferred node of
the volume (or hdisk2).

V10.0
Student Notebook
Uempty
Summary of zones: Four paths host zones

Zones Fabric 1 Fabric 2
Nodes 11 21 14 24 13 23 12 22
Stgbox1 11 21 14 24 F1 13 23 12 22 F2
Stgbox2 11 21 14 24 E1 E3 13 23 12 22 E2 E4
AIX1 11 21 A1 13 23 A2
W2K 14 24 W1 12 22 W2
Linux 14 24 L1 12 22 L2
non-virtualized zone
Figure 4-47. Summary of zones: Four paths host zones SNV13.0
Notes:
By creating a worksheet that documents which host ports should be assigned to which SVC ports
can aid in spreading the workload across the SVC HBA ports. This might be particularly helpful
when host ports are set up with four paths to the SVC I/O group.
Student Notebook
Summary of zones: Eight paths host zones
Nodes 11 21 14 24 13 23 12 22
Stgbox1 11 21 14 24 F1 13 23 12 22 F2
Stgbox2 11 21 14 24 E1 E3 13 23 12 22 E2 E4
AIX1 11 21 14 24 A1 13 23 12 22 A2
W2K 11 21 14 24 W1 13 23 12 22 W2
Linux 11 21 14 24 L1 13 23 12 22 L2
non-virtualized zones
Figure 4-48. Summary of zones: Eight paths host zones SNV13.0
Notes:
Not all OS platforms recommend or support eight (or even four) paths between the host ports and
the I/O group. Consult the SVC Information Center for platform-specific host attachment details.

V10.0
Student Notebook
Uempty
Implement zone configuration definitions

Nodes 11 21 14 24 13 23 12 22
Stgbox1 11 21 14 24 F1 13 23 12 22 F2
Stgbox2 11 21 14 24 E1 E3 13 23 12 22 E2 E4
AIX1 11 21 A1 13 23 A2
W2K 14 24 W1 12 22 W2
Linux 14 24 L1 12 22 L2
non-virtualized zone
Create
SVC_Cluster zone SVC_Cluster
configuration
Fabric 1 Fabric 2
Figure 4-49. Implement zone configuration definitions SNV13.0
Notes:
The updated zone definitions should be implemented in both fabrics.
Student Notebook

Notes:
This topic discusses the non-disruptive movement of volumes between the I/O groups.

V10.0
Student Notebook
Uempty
Move unassigned volume to new I/O group (1 of 2)
Move SYLVEST (ID 3)

from io_grp1 to io_grp0
and preferred node NODE2
GUI knows this

volume is NOT
assigned to a host
Figure 4-51. Move unassigned volume to new I/O group (1 of 2) SNV13.0
Notes:
A volume is owned by a caching I/O group as active I/O data of the volume is cached in the nodes
of this I/O group. If a volume is not assigned to a host, such as volume SYLVEST (ID 3), changing
its I/O group is simple. None of its data is cached yet.
The GUI is able to discern the volume is not assigned (mapped) to a host yet. Right-click the
volume entry and select Move to Another I/O group. The Move Volume to a New I/O Group pane
is populated with the name of the other I/O group (since this cluster has two I/O groups, otherwise
the drop-down list allows selection).
A preferred node can also be explicitly selected, such as NODE2 in the example. The default is to
let the system assign the preferred node automatically. Click the Move button to continue.
Student Notebook
Move unassigned volume to new I/O group (2 of 2)
Move volume ID 3’s

caching I/O group to io_grp0
and preferred node ID 2
Allow access to
volume ID 3 from
ports of io_grp0 as well
Remove access to
volume ID 3 from
ports of io_grp1
Figure 4-52. Move unassigned volume to new I/O group (2 of 2) SNV13.0
Notes:
Three commands are generated to move volume ID 3 to a new caching I/O group:
• The movevdisk -iogrp command enables the caching I/O group of the volume to be
changed. The -node parameter allows the preferred node of the volume to be explicitly
specified. Otherwise the system load balances between the two nodes of the specified I/O
group.
• The addvdiskaccess -iogrp command adds the specified I/O group to the volume’s access
list. At this point, the volume is actually accessible from the ports of both I/O groups. However
the volume’s data is only cached in its new caching I/O group.
• The rmvdiskaccess -iogrp command removes the access to the volume from the ports of
the specified I/O group. The volume is now only accessible through the ports of its newly
assigned caching I/O group.
With code levels prior to v6.4.0, the CLI chvdisk -iogrp command is used to change the
volume’s I/O group.

V10.0
Student Notebook
Uempty
Volume moved to io_grp0 and BLANCAIX access

id,name,SCSI_id,vdisk_id,vdisk_name,vdisk_UID,IO_group_id,IO_group_na
me
1,BLANCAIX,0,1,WISKEE,6005076801818781F800000000000004,0,io_grp0
1,BLANCAIX,1,8,SNUGGUS,6005076801818781F800000000000009,0,io_grp0
1,BLANCAIX,2,3,SYLVEST,6005076801818781F800000000000003,0,io_grp0
{aix_blanc_course} /SNUGVGMP # cfgmgr

{aix_blanc_course} /SNUGVGMP # lsdev -Cc disk
hdisk0 Available Virtual SCSI Disk Drive
{aix_blanc_course} /SNUGVGMP # lscfg -vl hdisk3

hdisk3 U5796.001.0629517-P1-C4-T1-W500507680120EE17-L2000000000000
MPIO FC 2145
Manufacturer................IBM
Machine Type and Model......2145
ROS Level and ID............0000
Serial Number...............6005076801818781F800000000000003
Figure 4-53. Volume moved to io_grp0 and BLANCAIX access SNV13.0
Notes:
After the ownership of volume ID 3 has been changed to io_grp0, it was successfully assigned to
the BLANCAIX host (only entitled to be assigned volumes in I/O group 0).
Student Notebook
Nondisruptively move host volume’s I/O group
Move WIN3VOL1
(volume ID 9)
(with on-going I/O)
4-paths to io_grp1.
asterisk = path to
non-preferred node.
Figure 4-54. Nondisruptively move host volume’s I/O group SNV13.0
Notes:
The ensuing pages illustrate changing the caching I/O group of a volume that has been assigned to
a host. Prior to v6.4.0, this is a disruptive operation in that the host I/O operations must be quiesced
prior to the move. Beginning with v6.4.0, this operation is nondisruptive for selected host
environments.
The example environment is running Windows 2008 with the SDDDSM multipath driver. Since
paths to the new I/O group need to be discovered and managed, the multipath driver support is
critical for nondisruptive volume move between I/O groups.
A common use case for changing a volume’s I/O group is after the addition of a new I/O group to
the SVC cluster. A requirement might be to balance the workload among the I/O groups by moving
existing volumes to the added I/O group. WIN3VOL1 is such a volume in that it needs to be moved
from its current caching I/O group of io_grp1 to io_grp0.
Review the SDDDSM paths for Disk 1or the WIN3VOL1 volume. Four-path zoning to io_grp1 is
implemented. The two paths with I/O counts are paths to the preferred node. The other two paths
(flagged with asterisk) are paths to the other node of io_grp1.

V10.0
Student Notebook
Uempty
Support for Non Disruptive Volume Move (NDVM)
Figure 4-55. Support for Non Disruptive Volume Move (NDVM) SNV13.0
Notes:
Support information for the SVC is based on code level. One easy way to locate its web page is to
perform a web search using the key words ‘IBM SVC v7 supported hardware list’.
Within the v7 support page, locate and click the link to Non-Disruptive Volume Move (NDVM).
Host system multipath driver support information is also found on this web page.
Student Notebook
NDVM: Supported OS and multipath drivers
See NDVM web page for

supported OS platforms
A volume in a Metro/Global Mirror
relationship cannot change
its caching I/O group.
Figure 4-56. NDVM: Supported OS and multipath drivers SNV13.0
Notes:
The NDVM link provides a list of host environments that supports nondisruptively moving a volume
between I/O groups. The Multipathing column identifies the multipath driver required. After the
move, paths to the prior I/O group might not be deleted until a host reboot occurs.

V10.0
Student Notebook
Uempty
Move volume WIN3VOL1 to another I/O group
Move WIN3VOL1
(volume ID 9)
(with on-going I/O)
GUI knows
volume is GUI provides guidance
assigned to a host on when to perform host
device path discovery
Figure 4-57. Move volume WIN3VOL1 to another I/O group SNV13.0
Notes:
In this example, we right-clicked the WIN3VOL1 volume entry and selected Move to Another I/O
Group in the pop-up list. For subsequent reference, note that its volume ID is 9.
Because the volume is assigned to a host, the Move Volume to a New I/O group Wizard opens to
its Welcome page. The Wizard provides step by step guidance of tasks that need to occur on the
associated host.
Student Notebook
Select I/O group and preferred node
Move WIN3VOL1 (ID 9)

from io_grp1 to io_grp0;
select preferred node
or let system assign node
Move volume ID 9’s

caching I/O group
to io_grp0
CLI output: Volume Allow access to

is now accessible from volume ID 9 from
io_grp0 and io_grp1 ports ports of io_grp0
IBM_2145:BLANC_SVC:admin>lsvdiskaccess 9
vdisk_id vdisk_name IO_group_id IO_group_name
9 WIN3VOL1 0 io_grp0
Figure 4-58. Select I/O group and preferred node SNV13.0
Notes:
A new I/O group and preferred node can be specified for the WIN3VOL1 volume (ID 9). The
example takes the default of letting the system assign a preferred node.
The Move to New I/O group and Update Access pane contains the GUI generated commands to
begin the volume move:
• The movevdisk command with the -iogrp is used to move volume ID 9 to io_grp0. Cached
data in its previous I/O group, io_grp1 for WIN3VOL1, is flushed at this point.
• The addvdiskaccess command is then used to allow the volume to be accessible from ports of
io_grp1.
At this point the volume’s caching I/O group has been moved from io_grp1 to io_grp0. The volume
is accessible through ports of both I/O groups. This is confirmed by the output of the
lsvdiskaccess command. A volume’s data is only cached in its caching I/O group.

V10.0
Student Notebook
Uempty
Go to identified host to detect new paths
Go to listed host to perform

device path discovery
Do NOT click
until above task
completed on host
Figure 4-59. Go to identified host to detect new paths SNV13.0
Notes:
Since a new I/O group has been added to the volume, paths to the I/O group should be discovered
from the attaching host.
The wizard progresses to the Detect New Paths pane and lists the name of the affected host and
volume. The volume’s UID (ending in x’000B’ in this case) is also displayed.
Go to the host to perform device path discovery and then return to the GUI to complete the move of
the volume.
A volume’s name might be changed dynamically. Once a volume is deleted then the associated
volume ID is freed and might be reused by the system for a subsequent volume creation request.
But a volume’s UID is unique for the life of the SVC cluster. It is never reassigned to another
volume.
Student Notebook
On-going I/O and perform host device discovery

Recall io_grp0 is now

the caching I/O group
Paths to io_grp0
added after
host device discovery.
Note asterisked paths;
I/O already directed
to paths of preferred
node in io_grp0
by SDDDSM
Figure 4-60. On-going I/O and perform host device discovery SNV13.0
Notes:
After Windows device rescan is performed, the paths to the WIN3VOL1 volume using io_grp0 are
discovered.
Review the SDDDSM datapath query device output for this volume (whose serial or UID ends
with x’000B’). The four new paths to io_grp0 have been added to the device path lists. Even though
the four paths to io_grp1 are still accessible and functional (OPEN), they are no longer used (the
path is flagged with an asterisk) by SDDDSM. I/Os are directed to the two paths of its preferred
node in io_grp0.
Cached data in io_grp1 for WIN3VOL1 had been flushed by the SVC when the volume was moved
to io_grp0. SDDDSM optimizes this environment by ensuring that no new I/O traffic is sent to
io_grp1. I/Os are driven to io_grp0 which is the volume’s new caching I/O group.

V10.0
Student Notebook
Uempty
Inform GUI path discovery has completed on host
Return to the GUI

to complete move
to io_grp0
Remove access to
volume ID 9 from
ports of io_grp1
Figure 4-61. Inform GUI path discovery has completed on host SNV13.0
Notes:
After host device discovery has completed and newly discovered paths are operational, return to
the GUI. Click the Apply and Next> button.
The GUI then generates the rmvdiskaccess command to remove the volume’s access from its prior
I/O group, io_grp1.
Student Notebook
Volume Removed from the old I/O group
Figure 4-62. Volume Removed from the old I/O group SNV13.0
Notes:
After the rmvdiskaccess command executes, the GUI progresses to the Volume Removed from
the old I/O group pane. The host is no longer able to access the volume through paths to the old
I/O group.
Click Finish to complete the process of non-disruptively moving a mapped host volume to a new
caching I/O group.

V10.0
Student Notebook
Uempty
On-going I/O and paths to old I/O group closed

Paths to io_grp1
are now in
CLOSE state
Figure 4-63. On-going I/O and paths to old I/O group closed SNV13.0
Notes:
After the access removal of volume WIN3VOL1 from io_grp1, subsequent I/O activity to the volume
caused SDDDSM to discern the paths associated with io_grp1 are no longer functional. SDDDSM
marks these paths in the CLOSE state and continues to drive I/O to the volume using paths to its
preferred node in io_grp0.
Actually, due to the support provided by SDDDSM the state of the paths to io_grp1 is somewhat
irrelevant. SDDDSM does not drive I/O to these paths once it detected that the caching I/O group of
the volume has been changed to io_grp0.
If I/O requests were driven to an accessible I/O group then they are routed by the SVC to the
volume’s caching I/O group (if needed since accessible I/O groups include the caching I/O group).
Data is only cached in the volume’s caching I/O group. Accessible (but not caching) I/O groups offer
the means to moving the volume from one caching I/O group to another caching I/O group.
Student Notebook
Closed paths removed after host reboot
Only paths to
io_grp0 remain
Figure 4-64. Closed paths removed after host reboot SNV13.0
Notes:
As described by the NDVM support web page entry for Windows 2008, a host reboot removes the
stale or CLOSE paths to io_grp1 for WIN3VOL1.

V10.0
Student Notebook
Uempty
Non Disruptive Volume Move: Notes and summary

• A volume could be configured so that it can be accessed through all I/O
groups at all times.
– I/O data for the volume is only cached in the volume’s caching I/O group
– The maximum number of paths supported between the volume and all its I/O
groups is still 8-paths.
• The caching I/O group of a volume must be online to be able to access
the volume; even if the volume is accessible through other I/O groups
• A volume which is mapped to a host through multiple I/O groups, might
not have the same SCSI ID across these I/O groups.
– This may cause problems with some operating systems
• A volume in a Metro or Global Mirror relationship cannot change its
caching I/O group.
• If a volume in a FlashCopy mapping is moved, its bitmap is left in the
original I/O group.
– This causes additional inter-node messaging during FlashCopy operations.
Figure 4-65. Non Disruptive Volume Move: Notes and summary SNV13.0
Notes:
The visual shows some addition notes and summary on Non-Disruptive Volume Move (NDVM).
Student Notebook

Notes:
This topic focuses on configuring an iSCSI host.

V10.0
Student Notebook
Uempty
Connecting iSCSI hosts to the SVC cluster

iSCSI initiator
iSCSI
Admin
Host
10.6.5.51 10.6.6.52
iSCSI IP Management IP
iSCSI targets addresses addresses
10.6.5.100 10.6.5.60
NODE1
Config node 10.6.6.101 10.6.6.60
10.6.5.x 10.6.5.1
10.6.5.102 Gateway
NODE2
Partner node 10.6.6.103
Rest of IP
network
SVC
Fibre Channel 10.6.6.1

10.6.6.x
Gateway
SAN
Fibre Channel
storage
iSCSI Email
iSNS
host gateway
Figure 4-67. Connecting iSCSI hosts to the SVC cluster SNV13.0
Notes:
In a manner analogous to the dual fabric (redundant fabric) Fibre Channel environment, a highly
available environment can be created for iSCSI attached hosts through the use of two Ethernet
NICs and two independent LANs. Both Ethernet ports in an SVC node are connected to the two
LANs and in conjunction with the two host NICs a multipathing environment is created for access to
volumes.
Student Notebook
Install host OS-specific MPIO support

iSCSI initiator
iSCSI
Host
10.6.5.51 10.6.6.52
Figure 4-68. Install host OS-specific MPIO support SNV13.0
Notes:
Consult the SVC Support website for supported iSCSI host platforms and if multipathing support is
available for the host OS.
The example included in this section is based on Windows 2008. Windows MPIO support should be
implemented when more than one path or connection is desired between the host and the SVC
cluster.
The host server used in the examples in this section is known as REDWIN2. It has two IP interface
port address:
• Host port 1: 10.6.5.51
• Host port 2: 10.6.6.52
Two subnets, 10.6.5.x and 10.6.6.x, are configured for network redundancy.

V10.0
Student Notebook
Uempty
Configure SVC node iSCSI IP addresses

addresses addresses
iSCSI targets
10.6.5.100 10.6.5.60
NODE1
Config node 10.6.6.101 10.6.6.60
10.6.5.102
NODE2
SVC
Enter iSCSI IP address

NODE1 port1
Figure 4-69. Configure SVC node iSCSI IP addresses SNV13.0
Notes:
The iSCSI IP configuration for an SVC node can be performed from the GUI by clicking Settings >
Network and selecting the iSCSI from the Network filter list.
In the iSCSI Configuration pane, select the I/O group to be configured. Then enter the iSCSI IP
address for each node port. Click the OK button to cause the GUI to generate the appropriate
command to add the port address.
Both Ethernet port 1 and port 2 of each node can be configured for iSCSI traffic. The 2145-xx8
models with the 10GbE ports installed can also be used for iSCSI.
Student Notebook
Command to set iSCSI IP for NODE1 port 1
Configure the IP port of

node 1 port 1 for iSCSI
Repeated for the
remaining
three node ports
IBM_2145:RED_SVC:admin> lsportip -delim , -filtervalue node_id=1
id,node_id,node_name,IP_address,mask,gateway,IP_address_6,prefix_6,gateway_6,MAC,duplex,state,spe
ed,failover,link_state
1,1,NODE1,10.6.5.100,255.255.255.0,10.6.5.1,,,,e4:1f:13:69:92:1c,Full,configured,1Gb/s,no,active
1,1,NODE1,,,,,,,e4:1f:13:69:92:1c,Full,configured,1Gb/s,yes,active
2,1,NODE1,10.6.6.101,255.255.255.0,10.6.6.1,,,,e4:1f:13:69:92:1e,Full,configured,100Mb/s,no,active
2,1,NODE1,,,,,,,e4:1f:13:69:92:1e,Full,configured,100Mb/s,yes,active
id,node_id,node_name,IP_address,mask,gateway,IP_address_6,prefix_6,gateway_6,MAC,duplex,state,spe
ed,failover,link_state
1,2,NODE2,10.6.5.102,255.255.255.0,10.6.5.1,,,,e4:1f:13:69:5e:34,Full,configured,1Gb/s,no,active
1,2,NODE2,,,,,,,e4:1f:13:69:5e:34,Full,configured,1Gb/s,yes,active
2,2,NODE2,10.6.6.103,255.255.255.0,10.6.6.1,,,,e4:1f:13:69:5e:36,Full,configured,100Mb/s,no,active
2,2,NODE2,,,,,,,e4:1f:13:69:5e:36,Full,configured,100Mb/s,yes,active
Figure 4-70. Command to set iSCSI IP for NODE1 port 1 SNV13.0
Notes:
The cfgportip command enables the three components of the IP address be set for node ID1
port 1.
The RED_SVC cluster contains two I/O groups or four nodes. Only io_grp0, comprising NODE1,
and NODE2 are being set up to support the iSCSI protocol. The following iSCSI addresses have
been assigned for the two Ethernet ports of each node:
• NODE1 port 1: 10.6.5.100
• NODE1 port 2: 10.6.6.101
• NODE2 port 1: 10.6.5.102
• NODE2 port 2: 10.6.6.103
The lsportip command is used to list the SVC node port addresses setup of iSCSI for NODE1
and NODE2.

V10.0
Student Notebook
Uempty
iSCSI initiator (host) and iSCSI target (NODE1)

iSCSI initiator (host)
10.6.6.52
10.6.5.51
IP
iSCSI target 10.6.6.101

10.6.5.100
IP address 10.6.5.102 10.6.6.103
iSCSI target IQNs
Figure 4-71. iSCSI initiator (host) and iSCSI target (NODE1) SNV13.0
Notes:
Each iSCSI initiator and target must have a worldwide unique name which is typically implemented
as an iSCSI qualified name (IQN). The Windows IQN is shown on the Configuration tab of the
iSCSI Initiator Properties notebook.
The SVC node IQN can be obtained from the iSCSI Configuration pane of the SVC GUI. The
verbose format of the lsnode command can also be used to obtain the SVC node IQN.
Student Notebook
iSCSI host discover target (NODE1) portal

1
2
3
Figure 4-72. iSCSI host discover target (NODE1) portal SNV13.0
Notes:
Define the SVC node as a SCSI target to the Windows SCSI initiator by using the Discovery tab
Discovery Portal button of the iSCSI Initiator Properties notebook.
The Discover Target Portal pop-up allows an SVC node iSCSI IP port address to be entered. Port
number 3260 is the default or official TPC/IP port for the iSCSI protocol. Click OK adds the SVC
node iSCSI IP port address as an eligible SCSI target portal.

V10.0
Student Notebook
Uempty
iSCSI host connect to target (NODE1) (1 of 2)

1
10.6.5.51
10.6.5.100
Figure 4-73. iSCSI host connect to target (NODE1) (1 of 2) SNV13.0
Notes:
In the Targets tab the SVC node IQN (for NODE1) has been discovered automatically by the
Windows iSCSI initiator. It has an initial status of inactive.
Click the Connect button to connect to the target (that is, the SVC node). The Connect to Target
pop-up box provides options to tailor the behavior of the connection, such as whether multipathing
is to be used. Click Advanced to pair the initiator to target ports in the same subnet to NODE1.
Student Notebook
iSCSI host connect to target (NODE1) (2 of 2)

1
5
4
10.6.6.52
10.6.6.101
Figure 4-74. iSCSI host connect to target (NODE1) (2 of 2) SNV13.0
Notes:
The initiator to the discovered target (NODE1) is now connected. Repeat the same steps to connect
the second pair of initiator to target addresses to complete the connection from the iSCSI host
initiator to NODE1’s second port.
At this point, the initiator’s connection to NODE1 include:
• Host port at 10.6.5.51 to NODE1 port 1 at 10.6.5.100

V10.0
Student Notebook
Uempty
Host to NODE1 connected with two sessions
Figure 4-75. Host to NODE1 connected with two sessions SNV13.0
Notes:
The connection from the host to SVC NODE1 has completed with two sessions enabled for
multipathing.
Instead of using the Discovery tab, the Target: box of the Targets tab allows for a Quick Connect
option. This option is a quicker setup option and establishes a single session between the host
initiator and the SVC node that owns the target address.
Student Notebook
Define iSCSI host object to assign SVC volumes
Define host IQN
From iSCSI host –

obtain IQN to define
SVC host object
Figure 4-76. Define iSCSI host object to assign SVC volumes SNV13.0
Notes:
Choose the iSCSI host option when defining the host object with the GUI. Define the iSCSI host
object by obtaining the IQN value found in the Windows iSCSI Initiator Properties notebook.
CHAP is an optional use of the Challenge Handshake Authentication Protocol where a passphrase
is used to authenticate the iSCSI user before the SVC will allow access to volumes.

V10.0
Student Notebook
Uempty
iSCSI host object created and volume assigned
iSCSI host object

REDWIN2 (ID 2)
created
Volume VW_iSCSI
mapped to REDWIN2
Figure 4-77. iSCSI host object created and volume assigned SNV13.0
Notes:
The visual shows the GUI generated mkhost command to create the iSCSI host object contains
the -iscsiname parameter.
Volume VC_iSCSI, which is owned by I/O group 0,has been assigned to this newly create iSCSI
host.
Student Notebook
iSCSI host to volume through NODE1’s ports
Host I/Os
Microsoft MPIO manages

one 2145 Multi-Path device
with 2 paths
based on 2 reported
Figure 4-78. iSCSI host to volume through NODE1’s ports SNV13.0
Notes:
Once device discovery has taken place on the host (rescan disks), the SVC volume appears as a
standard disk to Windows Disk Management. After the disk has been initialized and a partition
created then the drive is ready for I/O.
At this point, the volume is accessible from either of the two ports of SVC NODE1. Windows Device
Manager lists two 2145 SCSI disk devices reported by the two paths or sessions between the host
and NODE1. The MPIO support on Windows recognizes that these two instances of 2145 SCSI
disks actually represent one 2145 LUN and manages these as one 2145 multi-path device.

V10.0
Student Notebook
Uempty
iSCSI host connect to target (NODE2) portal
10.6.6.52
10.6.5.51
10.6.6.103
10.6.5.102
Figure 4-79. iSCSI host connect to target (NODE2) portal SNV13.0
Notes:
Repeat the same steps with target portal discovery and target connection using the configured
iSCSI addresses for NODE2 to setup connectivity between the iSCSI host and NODE2.
At this point, the initiator’s connections to both NODE1 and NODE2 include:
Student Notebook
iSCSI host to volume through both nodes

(four ports)
Host I/Os
Microsoft MPIO manages

one 2145 Multi-Path device
with 4 paths
based on 4 reported
Figure 4-80. iSCSI host to volume through both nodes (four ports) SNV13.0
Notes:
The configured four paths or sessions between the host and the two SVC nodes are reflected in the
Windows Device Manager for the device. Four instances of the SVC volume are reported to the
host through the four configured paths. Windows MPIO manages the reported instances as one
disk with four paths.

V10.0
Student Notebook
Uempty
Current cluster data with NODE1 as config node

IBM_2145:RED_SVC:admin> lsnode -delim , Current state 1
id,name,UPS_serial_number,WWNN,status,IO_group_id,IO_group_name,config_node,UPS_unique_id,
hardware,iscsi_name,iscsi_alias,panel_name,enclosure_id,canister_id,enclosure_serial_number
NODE1
1,NODE1,1000071223,500507680100B62A,online,0,io_grp0,yes,2040000007042083,CF8,iqn.1986-
03.com.ibm:2145.redsvc.node1,,155103,,, Config node
2,NODE2,1000071297,500507680100B605,online,0,io_grp0,no,2040000007042247,CF8,iqn.1986-
03.com.ibm:2145.redsvc.node2,,154968,,,

id,node_id,node_name,IP_address,mask,gateway,IP_address_6,prefix_6,gateway_6,MAC,duplex,state,
speed,failover,link_state
Figure 4-81. Current cluster data with NODE1 as config node SNV13.0
Notes:
The lsnode command output identifies NODE1 as the configuration node of the RED_SVC cluster.
The output of the lsportip commands lists the iSCSI IP addresses for each of the two ports of
NODE1 and NODE2.
Student Notebook
Node offline: Auto iSCSI IP addresses failover

1 Current state
10.6.5.100 10.6.5.60
NODE1
Config node 10.6.6.101 10.6.6.60
10.6.5.102
NODE2
SVC 2 NODE1 offline

c
10.6.5.100 10.6.5.60
NODE1
Config node 10.6.6.101
c 10.6.6.60
10.6.5.102
NODE2 10.6.5.100 10.6.5.60
Auto Config node failover Config node 10.6.6.103
from NODE1 to NODE2; 10.6.5.101 10.6.6.60
inherits mgmt IP SVC
Figure 4-82. Node offline: Auto iSCSI IP addresses failover SNV13.0
Notes:
If a node is no longer available (due to failure or code upgrade) then its partner node inherits the
iSCSI IP addresses of the departed node. The partner node port responds to the inherited iSCSI IP
address as well as its original iSCSI IP address.
If the departed node was the SVC cluster configuration node then the cluster designates another
node as the new configuration node. The cluster management IP addresses are moved
automatically to the new configuration node (or config node).

V10.0
Student Notebook
Uempty
IP addresses failover and config node failover

login as: admin
Authenticating with public key "rsa-key-20100111Teamadmin“
2 NODE1 offline
IBM_2145:RED_SVC:admin>lsnode -delim ,
NODE2
2,NODE2,1000071297,500507680100B605,online,0,io_grp0,yes,2040000007042247,CF8,iqn.1986-
IBM_2145:RED_SVC:admin>lsportip -delim , -filtervalue node_id=1
IBM_2145:RED_SVC:admin>lsportip -delim , -filtervalue node_id=2

1,2,NODE2,10.6.5.100,255.255.255.0,10.6.5.1,,,,e4:1f:13:69:5e:34,Full,configured,1Gb/s,yes,active
2,2,NODE2,10.6.6.101,255.255.255.0,10.6.6.1,,,,e4:1f:13:69:5e:36,Full,configured,100Mb/s,yes,active
IBM_2145:RED_SVC:admin> lsnodecandidate
id panel_name UPS_serial_number UPS_unique_id hardware
500507680100B62A 155103 1000071223 2040000007042083 CF8
Figure 4-83. IP addresses failover and config node failover SNV13.0
Notes:
Opened CLI sessions are lost when a config node switch occurs. Depending on timing, opened GUI
sessions might survive the switch.
Due to the departure of NODE1, NODE2 becomes the new config node for the RED_SVC cluster.
The output of the lsportip command for NODE2 confirms that the NODE1 iSCSI IP addresses
have been transferred to NODE2.
Nodes available to join the cluster can be listed with the lsnodecandidate command.
Student Notebook
iSCSI host access infrastructure unaffected
Host I/Os
One 2145 Multi-Path device

still with 4 paths
Figure 4-84. iSCSI host access infrastructure unaffected SNV13.0
Notes:
From the perspective of the iSCSI host, nothing has happened. The I/O operations proceed as
normal.
Furthermore the host access infrastructure isn’t affected. The SVC node failover activity is totally
transparent and nondisruptive to the attaching hosts.

V10.0
Student Notebook
Uempty
Node online: Auto iSCSI IP addresses failback

2 NODE1 offline iSCSI IP Management IP
addresses addresses
iSCSI targets
10.6.5.102
NODE2 10.6.5.100 10.6.5.60
Config node 10.6.6.103
10.6.5.101 10.6.6.60
SVC
3 NODE1 returns
addresses addresses
iSCSI targets
10.6.5.100
NODE1
10.6.5.102 10.6.5.60
NODE2
Config node Config node 10.6.6.103 10.6.6.60
does not move
SVC
Figure 4-85. Node online: Auto iSCSI IP addresses failback SNV13.0
Notes:
Once the departed node returns (the failed node has been repaired or code upgrade has
completed) it is brought back online and the iSCSI IP addresses automatically failback.
The SVC configuration node does not need to move. A config node switch occurs only if its hosting
node is no longer available.
Student Notebook
NODE1 online and iSCSI addresses failback

IBM_2145:RED_SVC:admin> addnode -iogrp 0 -panelname 155103 3 NODE1 returns
Node, id [5], successfully added
IBM_2145:RED_SVC:admin>lsnode -delim ,
5,NODE1,,,adding,0,io_grp0,no,,other,iqn.1986-03.com.ibm:2145.redsvc.node1,,,,,
2,NODE2,1000071297,500507680100B605,online,0,io_grp0,yes,2040000007042247,CF8,iqn.1986-
NODE2

Figure 4-86. NODE1 online and iSCSI addresses failback SNV13.0
Notes:
When a departed node rejoins the cluster, its attributes do not change (for example its object name
is the same). However a new node object ID is assigned. NODE1, whose object ID was 1, now is
assigned the next sequentially available object ID of 5.
The iSCSI IP addresses previously transferred to NODE2 are now returned to NODE1.

V10.0
Student Notebook
Uempty
IP connectivity failure protected by second IP port

iSCSI host
10.6.5.51 10.6.6.52
IP issues do not cause

SVC iSCSI IP addresses
iSCSI IP
to failover
iSCSI targets addresses
10.6.5.100
NODE1
Partner node 10.6.6.101 Configure port 2 for
iSCSI IP
10.6.5.102 10.6.5.60
NODE2
Config node 10.6.6.103 10.6.6.60 Configure port 2 for
management IP
SVC
Configure redundant
host IP ports
Figure 4-87. IP connectivity failure protected by second IP port SNV13.0
Notes:
Practice redundancy to protect against LAN failures, host port failures, or SVC node port failures.
Configure dual subnets, two host interface ports, and the second IP port on each node. Implied with
defining multiple iSCSI target addresses to the initiator is the need for host multipathing support.
It is also highly recommended that a second cluster management IP address is defined at port 2 so
that a LAN failure does not prevent management access to the SVC cluster.
Student Notebook
Host port1 failure: I/O protected by host port2
Host I/Os
One 2145 multipath device

with 2 paths
Figure 4-88. Host port1 failure: I/O protected by host port2 SNV13.0
Notes:
A host port failure reduces the number of paths between the host and the SVC cluster from four to
two. But host application I/O continues without issues due to host multipath support.

V10.0
Student Notebook
Uempty
Host port1 returned and paths returned
Host I/Os
One 2145 Multi-Path device

returned to 4 paths
Figure 4-89. Host port1 returned and paths returned SNV13.0
Notes:
When the failed host port returns then the original pathing infrastructure from the host to the SVC
volume is restored automatically.
Student Notebook
iSCSI connectivity best practice

iSCSI initiator
iSCSI
Admin
host
10.6.5.51 10.6.6.52
10.6.5.100 10.6.5.60
NODE1
Config node 10.6.6.101 10.6.6.60
10.6.5.x 10.6.5.1
10.6.5.102 Gateway
NODE2
Rest of IP
SVC network
10.6.6.1
10.6.6.x
Gateway
Redundancy enables a
robust LAN configuration iSCSI Email
iSNS
host gateway
Figure 4-90. iSCSI connectivity best practice SNV13.0
Notes:
Redundancy enables a robust LAN configuration both for iSCSI attached hosts as well as SVC
configuration management.

V10.0
Student Notebook
Uempty
SVC supported environments

Net SGI Citrix
Win AIX Linux Sun HP VMware Ware Blade VIOS IRIX Xen
Tru64 iSCSI hosts using
Apple
etc… SVC IP ports
Fabric 1 Fabric 2 Switches

BladeCenter
Brocade
Cisco
McDATA
QLogic
SVC Node 1 SVC Node 2
Juniper Networks
VendorX
DSxK Still growing
more over time
DS5000 Storwize DS8000
NetApp And so
DS4000 family DS6000 HDS HPQ EMC Sun
DS3000 XIV ESS
N series on...
FlashSystem
Figure 4-91. SVC supported environments SNV13.0
Notes:
Please consult the SVC product support website for current product support information,
including:
• Supported host platforms and additional solutions such as BladeCenter models and intercluster
distance extenders
• Supported host bus adapters (HBAs)
• Supported Fibre Channel switches
• Supported heterogeneous storage systems
• Supported software:
- SVC code level
- SDD/other multipath driver coexistence, native OS multipath drivers
- OS system levels including clustering support
Student Notebook
VMware vSphere APIs and vCenter plug-in

• Supports VMware vSphere APIs for Array Integration (VAAI)
– Enables VMware vSphere v4.1 functions to be offloaded from
vSphere ESX to SVC v6.2
• Hardware-accelerated Block Zero: Allows storage system to format fully
allocated VMDK file blocks
• Hardware assisted locking: Improves VMFS performance with fewer
reservation conflicts using fine-grained block-level locking
• Hardware-accelerated Full Copy: Reduces SAN traffic for performing
cloning and migration of virtual machines
• Provides SVC plug-in for VMware vCenter

– Enables VMware administrators to manage their storage from within
VMware management environment; functions include:
• Volume provisioning, resizing, and volume information display
• View general information about SVC clusters
• Receive events/alerts for SVC clusters attached to vSphere
Figure 4-92. VMware vSphere APIs and vCenter plug-in SNV13.0
Notes:
The VMware vSphere APIs for Array Integration (VAAI) enables VMware to offload operations that
should be handled at the storage systems level to the SVC.
Some number of common VMware functions such as provisioning virtual machines from templates,
extending Thin Provisioning virtual disks (VMDK), and storage vMotion were accomplished using
numerous inefficient and repetitive write operations to storage systems.
VAAI enables integration with storage systems (or in this case the SVC) to make use of higher
performance functionality such as the same SCSI write command to handle blocks of zeros or the
SCSI extended copy (XCOPY) command to minimize server I/O and reduce network bandwidth.


Ibm Bto SNV1 Student Guide Book 1 375 450 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ibm Bto SNV1 Student Guide Book 1 375 450 PDF

Uploaded by

Copyright:

Available Formats

V10.

Host object details and I/O group counts

Manage host object counts per I/O group

4-20 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

iSCSI initiator and target IQNs

Figure 4-19. iSCSI initiator and target IQNs SNV13.0

SVC 2145-CG8 and CF8 nodes: Ethernet ports for

IBM_2145:BLANC_SVC:admin>lsportip -delim , -filtervalue node_id=1

© Copyright IBM Corporation 2011, 2014

4-22 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Slot 2 and Slot 5

© Copyright IBM Corporation 2011, 2014

For access: Volumes must be assigned to a host

BLANCWIN1 is entitled to access volumes

© Copyright IBM Corporation 2011, 2014

Figure 4-22. For access: Volumes must be assigned to a host SNV13.0

4-24 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Host volume mapping and I/O group verification

Gee: What if io_grp1 volume

Phew: System is smart

© Copyright IBM Corporation 2011, 2014

Host objects, volume mappings, and I/O groups

Volume mappings Host objects Host objects

2145-DH8 2048 512 2048

• SVC v7 increased scalability for 2145-Cx8 and 2145-DH8 models

© Copyright IBM Corporation 2011, 2014

4-26 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

SVC host access topics (2 of 4)

• Fibre Channel host to SVC SAN fabric zoning

• Non Disruptive Volume Move (NDVM)

• iSCSI host to SVC IP connectivity

© Copyright IBM Corporation 2011, 2014

Figure 4-25. SVC host access topics (2 of 4) SNV13.0

Multipathing and host LUN access control

© Copyright IBM Corporation 2011, 2014

Figure 4-26. Multipathing and host LUN access control SNV13.0

4-28 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Host zone definition: AIX1 four-paths example

Figure 4-27. Host zone definition: AIX1 four-paths example SNV13.0

AIX1 volume1 preferred node and paths

Figure 4-28. AIX1 volume1 preferred node and paths SNV13.0

4-30 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

AIX1 volume2 preferred node and paths

Figure 4-29. AIX1 volume2 preferred node and paths SNV13.0

Host zone: W2K1 host exercise

Figure 4-30. Host zone: W2K1 host exercise SNV13.0

4-32 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Host zone: Linux1 host exercise

Figure 4-31. Host zone: Linux1 host exercise SNV13.0

Host ports zoned for four paths: GUI example

Each host WWPN is zoned with

© Copyright IBM Corporation 2011, 2014

4-34 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Host zoned with four paths and volume access

Host HBA to SVC ports: Zoning verification

Each host WWPN is zoned with

© Copyright IBM Corporation 2011, 2014

Figure 4-34. Host HBA to SVC ports: Zoning verification SNV13.0

4-36 SVC Implementation Workshop © Copyright IBM Corp. 2011, 2014

Host zoned for four paths: Host paths view

© Copyright IBM Corporation 2011, 2014

Host zoned for four paths: Host device view

© Copyright IBM Corporation 2011, 2014