vtl_switch_library Convenience Helper - did you see my commit?

[Tim Jones]

Hi Mark,

Since I need to test against real library configurations (8, 24, 48, 96, 40, 80, 160, 560 slots, and up to 16 drives), I created a script that manipulates the mhvtl configuration to switch between them.

I created a subfolder in the mhvtl parent named libswitch and committed it, but I don't know if you've seen it.

[Tim Jones]

I suspect that this functionality is tied to the 0403 error.

I've built preset definitions for mhvtl.conf, device.conf, and librarycontents.10.

Using the switch script, I do the following with no errors reported (example for a 1x8):

systemctl stop mhvtl.target
copy device.8 device.conf
copy mhvtl.8 mhvtl.conf
copy librarycontents.8 librarycontens.10
make_vtl_media -c -C /etc/mhvtl // each library definition has it's own media path
systemctl start mhvtl.target

Everything succeeds and lsscsi and mtx report properly:

root@linux64 mhvtl]# vtl_switch_library 8 y
Stopping the mhvtl target ... [DONE]
Change the config setting to 8 ... [DONE]
Creating the vtl media for configuration 8 ... [DONE]
Restarting the mhvtl target ... [DONE]
[3:0:0:0]    mediumx STK      L700             0106  /dev/sch0  /dev/sg3
[3:0:1:0]    tape    IBM      ULT3580-TD5      0106  /dev/st0   /dev/sg2

[root@linux64 mhvtl]# mtx -f /dev/sg3 status
  Storage Changer /dev/sg3:1 Drives, 8 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Full :VolumeTag=E01001L5                            
      Storage Element 2:Full :VolumeTag=E01002L5                            
      Storage Element 3:Full :VolumeTag=E01003L5                            
      Storage Element 4:Full :VolumeTag=E01004L5                            
      Storage Element 5:Full :VolumeTag=E01005L5                            
      Storage Element 6:Full :VolumeTag=E01006L5                            
      Storage Element 7:Full :VolumeTag=E01007L5                            
      Storage Element 8:Full :VolumeTag=E01008L5

The issue occurs only in media load attempts:

[root@linux64 mhvtl]# mtx -f /dev/sg3 load 1 0
Loading media from Storage Element 1 into drive 0...mtx: Request Sense: Long Report=yes
mtx: Request Sense: Valid Residual=yes
mtx: Request Sense: Error Code=70 (Current)
mtx: Request Sense: Sense Key=Hardware Error
mtx: Request Sense: FileMark=no
mtx: Request Sense: EOM=no
mtx: Request Sense: ILI=no
mtx: Request Sense: Residual = 00 00 00 00
mtx: Request Sense: Additional Sense Code = 04
mtx: Request Sense: Additional Sense Qualifier = 03
mtx: Request Sense: BPV=no
mtx: Request Sense: Error in CDB=no
mtx: Request Sense: SKSV=no
MOVE MEDIUM from Element Address 1000 to 500 Failed

Since the loads work from the default make install step, I've obviously I've missed a step in tying the new media to the new library, but I can't determine the missing step to save me.

[Mark Harvey]

The syslog (/var/log/messages) should throw some light on why the 04 03 ASC/ASCQ is being returned..

Can you try a ‘dump_tape -f E01001L5’ ?

Perhaps it’s *not* picking up the correct media path and trying to mount the wrong media ?

On 7 Apr 2019, at 12:21 pm, Tim Jones [via mhVTL - A Linux Virtual Tape Library] <[hidden email]> wrote:

I suspect that this functionality is tied to the 0403 error.

I've built preset definitions for mhvtl.conf, device.conf, and librarycontents.10.

Using the switch script, I do the following with no errors reported (example for a 1x8):

systemctl stop mhvtl.target
copy device.8 device.conf
copy mhvtl.8 mhvtl.conf
copy librarycontents.8 librarycontens.10
make_vtl_media -c -C /etc/mhvtl // each library definition has it's own media path
systemctl start mhvtl.target

Everything succeeds and lsscsi and mtx report properly:

root@linux64 mhvtl]# vtl_switch_library 8 y
Stopping the mhvtl target ... [DONE]
Change the config setting to 8 ... [DONE]
Creating the vtl media for configuration 8 ... [DONE]
Restarting the mhvtl target ... [DONE]
[3:0:0:0]    mediumx STK      L700             0106  /dev/sch0  /dev/sg3
[3:0:1:0]    tape    IBM      ULT3580-TD5      0106  /dev/st0   /dev/sg2

[root@linux64 mhvtl]# mtx -f /dev/sg3 status
  Storage Changer /dev/sg3:1 Drives, 8 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Full :VolumeTag=E01001L5                            
      Storage Element 2:Full :VolumeTag=E01002L5                            
      Storage Element 3:Full :VolumeTag=E01003L5                            
      Storage Element 4:Full :VolumeTag=E01004L5                            
      Storage Element 5:Full :VolumeTag=E01005L5                            
      Storage Element 6:Full :VolumeTag=E01006L5                            
      Storage Element 7:Full :VolumeTag=E01007L5                            
      Storage Element 8:Full :VolumeTag=E01008L5

The issue occurs only in media load attempts:

[root@linux64 mhvtl]# mtx -f /dev/sg3 load 1 0
Loading media from Storage Element 1 into drive 0...mtx: Request Sense: Long Report=yes
mtx: Request Sense: Valid Residual=yes
mtx: Request Sense: Error Code=70 (Current)
mtx: Request Sense: Sense Key=Hardware Error
mtx: Request Sense: FileMark=no
mtx: Request Sense: EOM=no
mtx: Request Sense: ILI=no
mtx: Request Sense: Residual = 00 00 00 00
mtx: Request Sense: Additional Sense Code = 04
mtx: Request Sense: Additional Sense Qualifier = 03
mtx: Request Sense: BPV=no
mtx: Request Sense: Error in CDB=no
mtx: Request Sense: SKSV=no
MOVE MEDIUM from Element Address 1000 to 500 Failed

Since the loads work from the default make install step, I've obviously I've missed a step in tying the new media to the new library, but I can't determine the missing step to save me.

---

If you reply to this email, your message will be added to the discussion below:

http://mhvtl-a-linux-virtual-tape-library.966029.n3.nabble.com/vtl-switch-library-Convenience-Helper-did-you-see-my-commit-tp4026240p4026241.html

To start a new topic under mhVTL - A Linux Virtual Tape Library, [hidden email]
To unsubscribe from mhVTL - A Linux Virtual Tape Library, click here.
NAML

[Tim Jones]

dump_tape -f E01001L5 returns:

PCL E01001L5 cannot be dumped, load_tape() returned 3

Seems to be the case.

If I move the tapes to the default of /opt/mhvtl, they are seen:

[root@linux64 tjones]# dump_tape -f E01001L5
Media density code: 0x58
Media type code   : 0x0b
Media description : Ultrium 5/16T
Tape Capacity     : 10485760000 (9 GBytes)
Media type        : Normal data
Media             : read-write
Remaining Tape Capacity : 10485760000 (9 GBytes)
Total num of filemarks: 0
Segmentation fault (core dumped)

Note the SEGFAULT at the close, though.

[Tim Jones]

And ... with the media folders in /opt/mhvtl instead of /opt/mhvtl_8 (in this case), the load of the originally created media works.

Defeinitly something getting mixed up in the setting of MHVTL_HOME_PATH.

[Tim Jones]

More on the steps -

When I set the MHVTL_HOME_PATH to a custom folder (/opt/mhtl_8 for example), the creation succeeds and places the media folders into /opt/mhvtl_8.  This means that mktape is picking up the proper path.

I'll strace a few of the other bits to see what the driver is seeing.

[Tim Jones]

For now, I'll change the vtl_switch_tape script to symlink /opt/mhvtl_XX to /opt/mhvtl.  This will solve the issue temporarily while allowing the existing media to remain persistent between swaps.