Question
I added a new virtual target device to a vhost adapter that already had target devices on it, but the client cannot see the new virtual SCSI disk and a VSCSI_HOST error has been logged on the client. Why?
Answer
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
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 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:
To check the max_transfer size for hdisk1, run
$ lsdev -dev hdisk1 -attr
...
max_transfer 0x100000 Maximum TRANSFER Size True
...
To change the max_transfer value, run
$ chdev -dev hdisk# -attr max_transfer=
where
To find out what physical volume the logical volume, rootvg_lv resides on, run
$ lslv -pv rootvg_lv
rootvg_lv:N/A
PV COPIES IN BAND DISTRIBUTION
hdisk0 001:000:000 100% 000:001:000:000:000
Note: If your VIOS level is FP11.1, and you have ruled out the max_transfer size as previously discussed, it is possible you may be running into a known defect addressed with IZ29603, which is included in FP11.1 SP 1. Consequently, the recommendation is to update the VIOS to that SP level or higher.
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 disk during the Installation menu
No comments:
Post a Comment