Question & Answer
Question
I added a new virtual target device to a vhost adapter that already had target devices on it, but the AIX client cannot see the new virtual SCSI disk and a VSCSI_HOST error has been logged on the client. Why?
This applies to VIOS 2.2.x
Cause
This is likely to be a problem with the max_transfer parameter. The maximum transfer parameter determines the size, in bytes, of the largest single data transfer request that can be handled by this adapter. As devices are added to a vhost adapter, the config method determines the maximum transfer each device is capable of by getting the maximum transfer size for that device and for the adapter to which that device is attached and using the smaller of those values. When the client adapter connects to the host adapter, the host reports to the client the smaller value of all the devices defined to that host. The client then reports that value to the disk head driver on the client. When the disk head driver on the client receives a request that is larger than the maximum transfer size, the disk head driver must break that request up into several smaller requests.
If a device is added to a host adapter after that host adapter has reported the maximum transfer size to the client, and the new device has a smaller transfer size than the value already reported, if the host showed that device to the client, the host could receive a request for that device that is larger than the device could handle. Therefore, the host does not show the device to the client and instead logs the informative error:
LABEL: VSCSI_HOST
IDENTIFIER: DF63A4FE
Date/Time: Mon Mar 5 11:47:21 2007
Sequence Number: 2205
Machine Id: 00C5763E4C00
Node Id: vios1
Class: S
Type: TEMP
Resource Name: vhost2
Description
Virtual SCSI Host Adapter detected an error
Probable Causes
Virtual SCSI Host Adapter Driver is an Undefined State
Failure Causes
Virtual SCSI Host Adapter Driver is an Undefined State
Recommended Actions
Remove Virtual SCSI Host Adapter Instance, then Configure the same instance
Detail Data
ADDITIONAL INFORMATION
module: target_report_luns rc: 00000000FFFFFFD8 location:00000001
data: 2 8F00000000000000
Note: In newer VIOS releases, mkvdev command will return a message stating the client needs to be rebooted for it to see the new VSCSI disk. i.e.
If a device is added to a host adapter after that host adapter has reported the maximum transfer size to the client, and the new device has a smaller transfer size than the value already reported, if the host showed that device to the client, the host could receive a request for that device that is larger than the device could handle. Therefore, the host does not show the device to the client and instead logs the informative error:
LABEL: VSCSI_HOST
IDENTIFIER: DF63A4FE
Date/Time: Mon Mar 5 11:47:21 2007
Sequence Number: 2205
Machine Id: 00C5763E4C00
Node Id: vios1
Class: S
Type: TEMP
Resource Name: vhost2
Description
Virtual SCSI Host Adapter detected an error
Probable Causes
Virtual SCSI Host Adapter Driver is an Undefined State
Failure Causes
Virtual SCSI Host Adapter Driver is an Undefined State
Recommended Actions
Remove Virtual SCSI Host Adapter Instance, then Configure the same instance
Detail Data
ADDITIONAL INFORMATION
module: target_report_luns rc: 00000000FFFFFFD8 location:00000001
data: 2 8F00000000000000
Note: In newer VIOS releases, mkvdev command will return a message stating the client needs to be rebooted for it to see the new VSCSI disk. i.e.
$ mkvdev -vdev hdiskN -vadapter vhost0 -dev MY_VTD_NAME MY_VTD_NAME Available Please reboot the client partition to see the newly added disk.
Answer
The best solution is to group devices according to maximum transfer sizes on host adapters. That is, if you know you will have devices with three different maximum transfer sizes in use by a single client, configure three host/client adapter pairs for that client and put the big transfer size devices on one, the medium size devices on the second, and the small devices on the third. That way, each device can run with the appropriate maximum transfer size and enjoy optimum throughput.
The second solution is to unconfigure the client adapter and all devices attached to it ("rmdev -l vscsiN -R") and reconfigure ("cfgmgr"), or reboot the client which does the same thing. However, the reconfigured client will now be using the smaller maximum transfer size so throughput will not be as good as it might be otherwise.
If a backing device (i.e. hdisk or logical volume) is exported through a vhost adapter, and its max_transfer size is greater than the max_transfer size of an already associated backing device of that vhost adapter, then the new virtual disk is not presented to the client partition. For example, suppose vhost1 has a backing device with a max_transfer size of 256K (0x40000), and you are trying to export a backing device whose max_transfer size is 1 MB (0x100000), when you run cfgmgr on the client, the client will not see the new virtual disk.
Therefore, a third alternative is to change the max_transfer size for the new device you are trying to export through that same vhost adapter to match the "largest" max_transfer size of the existing backing device(s). Then export that logical volume or disk as a backing device by running mkvdev command, and run cfgmgr on the client.
Note: The max_transfer size is a disk attribute. So, if you are exporting a logical volume (LV) as a backing device, you must check the max_transfer size of the underlying physical disk (i.e. if the logical volume, lv00, you are trying to export is on hdisk1, check the max_transfer size for hdisk1).
Example:
The second solution is to unconfigure the client adapter and all devices attached to it ("rmdev -l vscsiN -R") and reconfigure ("cfgmgr"), or reboot the client which does the same thing. However, the reconfigured client will now be using the smaller maximum transfer size so throughput will not be as good as it might be otherwise.
If a backing device (i.e. hdisk or logical volume) is exported through a vhost adapter, and its max_transfer size is greater than the max_transfer size of an already associated backing device of that vhost adapter, then the new virtual disk is not presented to the client partition. For example, suppose vhost1 has a backing device with a max_transfer size of 256K (0x40000), and you are trying to export a backing device whose max_transfer size is 1 MB (0x100000), when you run cfgmgr on the client, the client will not see the new virtual disk.
Therefore, a third alternative is to change the max_transfer size for the new device you are trying to export through that same vhost adapter to match the "largest" max_transfer size of the existing backing device(s). Then export that logical volume or disk as a backing device by running mkvdev command, and run cfgmgr on the client.
Note: The max_transfer size is a disk attribute. So, if you are exporting a logical volume (LV) as a backing device, you must check the max_transfer size of the underlying physical disk (i.e. if the logical volume, lv00, you are trying to export is on hdisk1, check the max_transfer size for hdisk1).
Example:
Use lsdev command to determine the max_transfer size for hdisk1:
$ lsdev -dev hdisk1 -attr max_transfer value 0x100000
Use chdev command to change the max_transfer value:
$ chdev -dev hdisk# -attr max_transfer=<New max_transfer>
where <New max_transfer> value is in hex (i.e. 0x40000)
To find out what physical volume (hdisk#) LV backing device name rootvg_lv resides on, run the following lslv command, and then determine the hdisk max_transfer value using lsdev command as previously noted:
$ lslv -pv rootvg_lv rootvg_lv:N/A PV COPIES IN BAND DISTRIBUTION hdisk0 001:000:000 100% 000:001:000:000:000
Sympthoms may include:
- Existing client unable to see new virtual disk on existing and new virtual SCSI adapter
- Existing VIO client may fail to see boot device
- New client unable to see virtual SCSI disk from the Installation menu
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSPHKW","label":"PowerVM Virtual I\/O Server"},"Component":"Not Applicable","Platform":[{"code":"PF002","label":"AIX"}],"Version":"VIOS 2.2","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]
Was this topic helpful?
Document Information
Modified date:
19 February 2022
UID
isg3T1010944