VIO VSCSI

General Training
The initial management & setup will take place from the HMC. You will need to download and
use WebSM (current version) in order to access it and administer the P5s. For our portion of the
call handling (VSCSI) we assume that the following has been done already:
-

VIO Server partition/s already installed and configured

All physical adapters (ie.fcs# or scsi#) are assigned to partition
Client Lpars already configured through the HMC
Do not need an OS if you are setting VIO disk as boot device

Below are 2 Client lpars and 1 VIO Server lpar

In order to configure the virtual devices on a VIO server you will need to create a mapping from
the VIO Server VIO Client and one from the VIO Client VIO Server. That will result
in a vhost definition on the VIO Server. In an existing configuration you can use DLPAR to
dynamically make the updates, but you must remember to update the profile as well, otherwise
the change will not be there after the next reactivation of the partition. The following are screen
shots that you will see when you go to configure each of the mappings.
Note: This is specifically for a new configuration. When you perform these steps you will need both the I/O
Server and the VIO Client lpars to be inactive, otherwise after making the changes you will need to reactivate
both of them for the changes to be applied.

For the I/O Server_1 profile:

The Any remote partition and slot can connect option is not recommended. Also it very
important to recognize that the Slot number 20 does not correspond to a physical location but
to either the first available logical slot number on the I/O Server lpar, or a user specified number
(assuming that it is not already used).
The Remote partition is the client lpar that the mapping you are creating is going to. It is
critical that the Remote partition virtual slot number (3 in this case) is the same slot number
that you see in the 2nd profile that you will edit for the VIO Client lpar (below).

For the VIO Client profile:

Note that the Slot number (3) is the next available number on this client lpar. It is not a
physical mapping. You could just as easily edit this to the number 5, but the profile for the
VIO Server in the previous step would need to match.
The Remote partition in this step is the VIO Server I/O Server_1, and notice that
that Remote partition virtual slot number is 20 and matches that in the VIO Server profile (in
previous screen shot).
If these slot number are not properly configured you will be unable to see disks on the client
lpars. This is one of the most common areas to be mixed up.

On VIO Server (displaying what you have):

Once the mappings are performed on the HMC you can open up an shell on the VIO server.
Based on the mappings performed on the previous steps you will have a vhost definition on your
VIO Server.
# lsdev virtual
vhost0
Available

Virtual SCSI Server Adapter

#lsdev vpd | grep vhost

vhost0
U9111.520.10DDEEC-V2-C20

Virtual SCSI Server Adapter

*** Notice that the 20 represents the slot number on VIO Server mapping

#lsmap all
SVSA
vhost0

Physloc
U9111.520.10F9FDD-V2-C20

VTD

NO VIRTUAL TARGET DEVICE FOUND

Client Partition ID
0x0000000

*** Client partition ID will show all zeros if client is not up

# lsdev type adapter

sisscsia0
Available
vhost0
Available

PCI-X Dual Channel Ultra320 SCSI Adapter

Virtual SCSI Server Adapter

#lsdev type disk

hdisk0
Available
hdisk1
Available
hdisk2
Available
hdisk3
Available

16 Bit LVD SCSI Disk Drive

16 Bit LVD SCSI Disk Drive
16 Bit LVD SCSI Disk Drive
16 Bit LVD SCSI Disk Drive

#lspv
hdisk0
hdisk1
hdisk2
hdisk3

00cf9fdd22c5d965
none
none
none

rootvg
None
None
None

active

Mapping disks to client Lpars:

You now would have two choices.
1. Assign entire hdisk to a client lpar
2. Create a vg on that hdisk and assign lvs to a client lpar

I. Entire disk:
#mkvdev vdev hdisk3 vadapter vhost0 dev client_node2_rootvg
client_node2_rootvg

hdisk3 is one of the unused disks on VIO Server

vhost0 is Virtual SCSI Server Adapter that maps to client adapter
client_node2_rootvg is the name (label) of the Virtual Target Device

*** If this volume is assigned to another VIO Server you will need to set the reserve_policy on the
hdisk before running the mkvdev command covered in TeamRoom document.

#lsmap vadapter vhost0

SVSA
Physloc
vhost0
U9111.520.10F9FDD-V2-C20
VTD
LUN
Backing Device
Physloc

Client Partition ID
0x00000003

client_node2_rootvg
0x82000000000000
hdisk3
U787A.0011.DNZ09PC-P1-T10-L8-L0

II. Assign only lv:

# mkvg f vg rootvg_clients hdisk3
rootvg_clients

(created vg on VIO Server)

# mklv lv clientlpar_lv rootvg_clients 2G

clientlpar_lv

(created 2GB lv in that vg)

# mkvdev vdev clientlpar_lv vadapter vhost0 dev client_node2_rootvg

client_node2_rootvg
(created mapping and gave it name)
Note: You are not required to give it a name with the dev flag. If you do not use the flag the default name
of the Virtual Target Device will be vtscsi0 instead of client_node2_rootvg.

# lsdev virtual
vhost0
Available
client_node2_rootvg Available

Virtual SCSI Server Adapter

Virtual Target Device Logical Volume

#lsmap vadapter vhost0

SVSA
Physloc
vhost0
U9111.520.10F9FDD-V2-C20
VTD
LUN
Backing Device
Physloc

Client Partition ID
0x00000003

client_node2_rootvg
0x82000000000000
clientlpar_lv
U787A.0011.DNZ09PC-P1-T10-L8-L0

You can see above that the mapping is in place. On the VIO Client you should now
be able to utilize that disk to install an operating system. If the client lpar was already
configured and this was an additional hdisk, cfgmgr would have picked up new hdisk #
on client that would correspond to the lv on the VIO server.

Commands on Client:
#lspv
hdisk0

00cf9ffdd948b34da

rootvg

#lsdev Cc disk
hdisk0
Available

Virtual SCSI Disk Drive

#lsdev Cc adapter
vscsi0
Available

Virtual SCSI Client Adapter

active

Correlating a disk back to VIO Server:

#lscfg vl hdisk0
hdisk0 U9111.520.10F9FDD-V3-C4-T1-L820000000000 Virtual SCSI Disk Drive
*** Match the C4 to the client profile to see which vhost mapping it is, then match
lun ID.

On VIO Server:
#lsmap vadapter vhost0
SVSA
Physloc
vhost0
U9111.520.10F9FDD-V2-C20

Client Partition ID
0x00000003

VTD
LUN
Backing Device
Physloc

client_node2_rootvg
0x82000000000000
hdisk3
U787A.0011.DNZ09PC-P1-T10-L8-L0

VTD
LUN
Backing Device
Physloc

client_node2_datadisk
0x83000000000000
client1_datalv
U787A.0011.DNZ09PC-P1-T10-L8-L0

Unassigning a disk from VIO Client:

On VIO Server:
#rmdev dev VTD
* If the lun assigned to the client is an lv, this operation will get the lv to close. If it is a whole
disk mapping you will no longer be able to query the disk on the client. After the rmdev you will
no longer see the lun in the output of lsmap.
To not remove it entirely (put it into a defined state) do the following:
#rmdev ucfg VTD lun will not be accessible on client, but the definition does not go away
on the VIO server
#cfgdev dev VTD this will bring it back into an available state.

Reference:
VIO CLI Reference Guide
http://publib.boulder.ibm.com/infocenter/eserver/v1r2s/en_US/info/iphb1/commands/commands.pdf
Introduction & Basic Configuration
http://www.redbooks.ibm.com/redbooks/pdfs/sg247940.pdf
Team Room Document:
Sharing same disk between Multiple VIO Servers

*** Images & notes are partially from this Redbook