Upon reading through the release notes for Fix Pack 22 for VIOS 2.1, I stumbled across a new command called chkdev. According to the notes, this command was added to help you check devices for virtual provisioning capability. This fired my curiosity and as soon as I had applied FP22 to one of my VIOS, I started using this command to see what it could do for me!
First, I checked the man page for chkdev. It stated that chkdev can determine whether or not a device can be used in physical to virtual (p2v) migration on a VIOS.
chkdev command
Purpose
Checks devices for virtual device provisioning capability in the Virtual I/O Server.
Syntax
chkdev [-dev Name] [-verbose] [-field FieldName ] [-fmt delimiter]
Description
The chkdev command determines whether a device can be used in physical to virtual transitions in the Virtual I/O Server. Devices include all physical volumes and multipath representations of logical units. If the -dev option is used, information is shown for the device specified. If the -verbose option is used, detailed information is shown. With the -field option, the user can specify which fields to display. With the -fmt option, the user can format the output to be separated by a given delimiter.
Capability in a virtual environment refers to the capability for a device to move between a physical environment to a virtual environment. The command displays these fields: Phys2Virt_Capable, Virt2NPIV_Capable, and Virt2Phys_Capable.
For a device to be capable of moving from a physical to a virtual environment, it must pass the address compatibility check. If the physical volume can be moved from a physical to a virtual environment, the Phys2Virt_Capable field has a value of YES. If the device is not capable of this move, the field has a value of NO. If the device is already in use by Virtual Small Computer System Interface (VSCSI), the field has a value of NA.
If a device is capable of moving from a VSCSI LUN environment to an N_Port ID Virtualization (NPIV) environment, it must pass the address-compatibility check. If this device can be moved, the Virt2NPIV_Capable field has a value of YES. If the device is not capable of this move, the field has a value of NO. If the device is not in use by the virtual target device (VTD), this field has a value of NA. This command is not sufficient to guarantee that the client can read the data after the VSCSI logical unit number (LUN) is removed. The storage area network (SAN) configuration must also be checked by the SAN administrator to ensure that it is mapped to a client NPIV.
Determination of whether a device is capable of moving from a virtual environment to a physical environment is applicable for devices that are mapped as VTDs. For devices to be capable of moving from a virtual environment to a physical environment, it must pass the address capability test.
If the physical volume is capable of being transferred from a virtual environment to a physical environment, the Virt2Phys_Capable field has a value of YES. If the device is not capable of this move, the field has a value of NO. If the device is not in use by VTD, the field has a value of NA.
..etc..
So, I ran this command on my VIOS and focused on the attributes of two different disk types. The first, hdisk1, was a (internal) SAS drive and the second was a FC attached SAN disk (IBM DS8100).
$ hostname
vio1
$ ioslevel
2.1.2.10-FP-22
$ lsdev -type disk
name status description
hdisk0 Available SAS Disk Drive
hdisk1 Available IBM MPIO FC 2107
hdisk2 Available IBM MPIO FC 2107
hdisk3 Available IBM MPIO FC 2107
hdisk4 Available IBM MPIO FC 2107
hdisk5 Available IBM MPIO FC 2107
hdisk6 Available IBM MPIO FC 2107
name status description
vtscsi0 Available Virtual Target Device - Disk
vtscsi1 Available Virtual Target Device - Disk
vtscsi2 Available Virtual Target Device Disk
$ lsmap -all
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost0 U7998.61X.10071FA-V1-C11 0x00000003
VTD vtscsi0
Status Available
LUN 0x8200000000000000
Backing device hdisk1
Physloc U78A5.001.WIH074C-P1-C6-T1-W500507630608059A-L4000402D00000000
..etc..
$ chkdev
NAME: hdisk0
IDENTIFIER: 2F1135000C500063973B70BST9146802SS08IBM-ESXSsas
PHYS2VIRT_CAPABLE: YES
VIRT2NPIV_CAPABLE: NA
VIRT2PHYS_CAPABLE: NA
NAME: hdisk1
IDENTIFIER: 200B75W2261002D07210790003IBMfcp
PHYS2VIRT_CAPABLE: NA
VIRT2NPIV_CAPABLE: YES
VIRT2PHYS_CAPABLE: YES
..etc..
From the chkdev output, I could determine that hdisk0 could be virtualised and presented to an LPAR (PHYS2VIRT_CAPABLE=YES). The VIRT2NPIV_CAPABLE and the VIRT2PHYS_CAPABLE attributes were both set to N/A, indicating that this device is not currently mapped to a VTD on the VIOS.
The attributes for hdisk1 showed that this disk had already been successfully mapped to an LPAR from the VIOS i.e. PHYS2VIRT_CAPABLE=N/A. The disk was also capable of moving from a VSCSI environment to an NPIV (N_Port ID Virtualisation) environment (VIRT2NPIV_CAPABLE=YES).
The -verbose flag provides additional attributes about a disk device. You can obtain the PVID, UDID, IEEE and VTD attributes, which may be useful in identifying and validating disks on a VIOS. For example looking at the output below, I can easily verify which VTD hdisk1 is currently mapped to on the VIOS. And I can quickly confirm that hdisk0 is not currently mapped to a VTD.
$ chkdev -dev hdisk0 -verbose
NAME: hdisk0
IDENTIFIER: 2F1135000C500063973B70BST9146802SS08IBM-ESXSsas
PHYS2VIRT_CAPABLE: YES
VIRT2NPIV_CAPABLE: NA
VIRT2PHYS_CAPABLE: NA
PVID: 000071facb8888a20000000000000000
UDID: 2F1135000C500063973B70BST9146802SS08IBM-ESXSsas
IEEE:
VTD:
$ chkdev -dev hdisk1 -verbose
NAME: hdisk1
IDENTIFIER: 200B75W2261002D07210790003IBMfcp
PHYS2VIRT_CAPABLE: NA
VIRT2NPIV_CAPABLE: YES
VIRT2PHYS_CAPABLE: YES
PVID: 000071fabe8efb250000000000000000
UDID: 200B75W2261002D07210790003IBMfcp
IEEE:
VTD: vtscsi0
This command is also mentioned in a new Redbook called PowerVM Migration from Physical to Virtual Storage. I recommend you take a look at it and so does Rob McNelly!