VTL "tape" adding to vpar

[Greg Geyer]

Was able to add physical tape to a vpar like so:

hpvmmodify -P avtbak1 -a tape:avio_stor::attach_path:0/0/0/7/0/0/1.0x500104f0008a4f15.0x0

but the VTL 'tape drives' have a longer path like so:

tape 88 64000/0xfa00/0x122 estape CLAIMED DEVICE online IBM
ULTRIUM-TD3
1/0/0/5/0/0/1.0x21000024ff31db20.0x1000000000000
/dev/rtape/tape88_BEST /dev/rtape/tape88_BESTn
/dev/rtape/tape88_BESTb /dev/rtape/tape88_BESTnb
tape 89 64000/0xfa00/0x123 estape CLAIMED DEVICE online IBM

Not sure if this is the cause of the problem but it doesn't seem to like the path:

root@avtbak1:/# hpvmmodify -P host -a tape:avio_stor::attach_path:1/0/0/5/0/0/1.0x21000024ff31db20.0x1000000000000
hpvmmodify: ERROR (avtbak1): Invalid device path '1/0/0/5/0/0/1.0x21000024ff31db20.0x1000000000000' specified for backing store.
hpvmmodify: Unable to create device tape:avio_stor::attach_path:1/0/0/5/0/0/1.0x21000024ff31db20.0x1000000000000.
hpvmmodify: Unable to modify the guest.
root@avtbak1:/#

Anyone use hpvmmodify with attach_path that has the extra length, or a work-around?  I tried dropping the remaining zeros but then it is device not found.

[Ken Grabowski]

What is the output from ioscan -m lun /dev/TAPEPATH?

[Greg Geyer · Accepted solution]

Problem solved by deleting existing /dev/pt/pt_tapeX device files.  Then hpvmmodify works and re-creates this device file.

A solution provided by doc emr_na-c02863278-1 though they're describing fixing a device that existed on the client but had been replaced.  Worked for my new device issue.