Mkvdev problems

From AIXWiki

Contents 1 The problem 2 The best solution 3 The second solution 4 The alternative solution 5 Example

[edit] The problem

This page will describe the following problem:

$ mkvdev -vdev hdiskpower01 -vadapter vhost0 -dev vrootvg
vrootvg Available
To see the newly added disk, client partition needs reboot.

On the VIO server this mkvdev command will create an 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: vhost0

The cause of this problem is that the newly added vdev has a higher max_transfer speed then the already assigned vdev's. The possible soultions for this issue are:

[edit] The best solution

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.

[edit] The second solution

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.

[edit] The alternative solution

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).

[edit] 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=<New max_transfer>
where <New max_transfer> value is in hex (i.e. 0x40000)

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 

Source Unable to See New VSCSI Disk on Existing vhost @ IBM.com