IBM 3584/TS3500 Support

RPTU · Jul 9, 2021

Hi,

ich teste aktuell PBS 1.1-10 mit einer IBM TS3500 bzw. IBM3584 Tape Library. Die Lib hat noch die erste Generation der Node-Cards und hat daher kein ALMS sonder nur die statische Partitionierung der Library in logische Libraries. Für PBS habe ich eine eigene logische Lib mit 4xLTO4 angelegt und über das 1. Drive wird der Changer zur Verfügung gestellt. Im Linux tauchen auch der Changer und die 4 Drives auf. proxmox-tape erkennt sowohl den Changer als auch die 4 Drives und kann alle Devices anlegen. Über die Weboberfläche der Lib kann ich auch Bänder in die Drives füttern und dann mit pbs-tape format oder label bearbeiten. Was nicht funktioniert sind alle Kommandos bei denen letztlich die Library die Arbeit erledigen muß (eject, volume move, barcode zurückliefern usw.). Tape klappt also, Changer-Device nicht. Gibt es irgendwo debug-output welcher hilfreich wäre um zu sehen wo es klemmt?

Inzwischen habe ich eine Fehlermeldung erhalten beim Versuch ein Backup in den angelegten Pool zu schreiben:
2021-07-09T19:08:29+02:00: TASK ERROR: error reading element status: read element status (B8h) failed: Unit Attention, Additional sense: Not ready to ready change, medium may have changed

Gruß,

Heiko.

RPTU · Jul 10, 2021

Habe noch ein wenig weiterprobiert, alles was mit dem Changer zu tun hat funktioniert nicht. Schon ein einfaches proxmox-tape changer status hängt einfach. In strace sehe ich mehrmals die Sekunde:
[pid 399] ioctl(13, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=12, cmdp="\xb8\x10\x00\x00\xff\xff\x01\x01\x00\x00\x00\x00", mx_sb_len=32, iovec_count=0, dxfer_len=65536, timeout=300000, flags=0, dxferp="", status=0x2, masked_status=0x1, msg_status=0, sb_len_wr=18, sbp="\x70\x00\x05\x00\x00\x00\x00\x0a\x00\x00\x00\x00\x24\x00\x00\xc8\x00\x06", host_status=0, driver_status=0x8, resid=65536, duration=20, info=SG_INFO_CHECK}) = 0
[pid 399] fstat(13, {st_mode=S_IFCHR|0660, st_rdev=makedev(0x15, 0xe), ...}) = 0

Es scheint einfach keine Kommunikation mit dem Changer zu geben. Wenn ich den Changer entferne und die Drives als Individual anlege, kann ich sauber ein Backup auf Tape durchführen. Die notwendigen Library-Kommandos muß ich dann aber von Hand über die Oberfläche der Library ausführen. Falls ihr bisher keine Gelegenheit hattet mit einer IBM TS3500 zu testen...ich hätte hier das passende Setup.

Gruß,
Heiko.

RPTU · Jul 10, 2021

Hi,

zwischenzeitlich habe ich mtx nachinstalliert. Dort funktioniert das Abfragen der Library:

mtx -f /dev/sg14 inquiry
Product Type: Medium Changer
Vendor ID: 'IBM '
Product ID: '03584L32 '
Revision: '7422'
Attached Changer API: No

mtx -f /dev/sg14 load 1
Loading media from Storage Element 1 into drive 0...done

mtx -f /dev/sg14 unload 1
Unloading drive 0 into Storage Element 1...done

Die Weboberfläche der Lib bestätigt das Load/Unload.

mtx -f /dev/sg14 status
Storage Changer /dev/sg14:4 Drives, 386 Slots ( 10 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Empty
Data Transfer Element 2:Empty
Data Transfer Element 3:Empty
Storage Element 1:Full :VolumeTag=PB1000L4
Storage Element 2:Full :VolumeTag=PB1001L4
Storage Element 3:Full :VolumeTag=PB1002L4
Storage Element 4:Full :VolumeTag=PB1003L4
Storage Element 5:Full :VolumeTag=PB1004L4
Storage Element 6:Full :VolumeTag=PB1005L4
Storage Element 7:Full :VolumeTag=PB1006L4
Storage Element 8:Full :VolumeTag=PB1007L4
Storage Element 9:Full :VolumeTag=PB1008L4
Storage Element 10:Full :VolumeTag=PB1009L4
Storage Element 11:Empty:VolumeTag=
...
Storage Element 376:Empty:VolumeTag=
Storage Element 377 IMPORT/EXPORT:Empty:VolumeTag=
...
Storage Element 386 IMPORT/EXPORT:Empty:VolumeTag=

Das Control-Device der Lib funktioniert also. Die TS3500 spricht dann wohl einen von eurem mtx-rust-rewrite nicht unterstützten Dialekt.

Gruß,
Heiko.

RPTU · Jul 11, 2021

Hallo,

noch eine Ergänzung. Habe mtx 1.3.12-12 aus den deb-sources mit Debug-Output gebaut und das Log in den Anhang des Posts gepackt. Evtl. hilft das.

Gruß,

Heiko.

dcsapak · Jul 12, 2021

hi,

tukl said:
2021-07-09T19:08:29+02:00: TASK ERROR: error reading element status: read element status (B8h) failed: Unit Attention, Additional sense: Not ready to ready change, medium may have changed

der fehler würde darauf hindeuten dass der changer nicht bereit war, nochmals probieren hilft hier meistens.

tukl said:
Habe noch ein wenig weiterprobiert, alles was mit dem Changer zu tun hat funktioniert nicht. Schon ein einfaches proxmox-tape changer status hängt einfach. In strace sehe ich mehrmals die Sekunde:

was genau sind sonst

tukl said:
zwischenzeitlich habe ich mtx nachinstalliert. Dort funktioniert das Abfragen der Library:

auch schon mal mit 'pmtx' unserem rust wrapper probiert? wie sieht hier die fehlermeldung aus?

als letztes noch bitte direkt mit 'sg_raw' probieren:

Code:

sg_raw -r 64k <pfad zum device> B8 10 00 00 FF FF 01 FF FF FF 00 00

wobei <pfad zum device> der changer pfad in /dev/tape/by-id/.... ist

RPTU · Jul 12, 2021

dcsapak said:
auch schon mal mit 'pmtx' unserem rust wrapper probiert? wie sieht hier die fehlermeldung aus?

root@pbs01:~# pmtx inquiry --changer ibm3584
using device /dev/tape/by-id/scsi-000007814651057A
Type: Medium Changer (8)
Vendor: IBM
Product: 03584L32
Revision: 7422
root@pbs01:~# pmtx status --changer ibm3584
using device /dev/tape/by-id/scsi-000007814651057A

Ab hier hängt pmtx nun einfach.
Mit strace sieht das dann so aus:
...
fstat(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(0x15, 0xe), ...}) = 0
ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=12, cmdp="\xb8\x10\x00\x00\xff\xff\x01\x01\x00\x00\x00\x00", mx_sb_len=32, iovec_count=0, dxfer_len=65536, timeout=300000, flags=0, dxferp="", status=0x2, masked_status=0x1, msg_status=0, sb_len_wr=18, sbp="\x70\x00\x05\x00\x00\x00\x00\x0a\x00\x00\x00\x00\x24\x00\x00\xc8\x00\x06", host_status=0, driver_status=0x8, resid=65536, duration=12, info=SG_INFO_CHECK}) = 0
fstat(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(0x15, 0xe), ...}) = 0
ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=12, cmdp="\xb8\x10\x00\x00\xff\xff\x01\x01\x00\x00\x00\x00", mx_sb_len=32, iovec_count=0, dxfer_len=65536, timeout=300000, flags=0, dxferp="", status=0x2, masked_status=0x1, msg_status=0, sb_len_wr=18, sbp="\x70\x00\x05\x00\x00\x00\x00\x0a\x00\x00\x00\x00\x24\x00\x00\xc8\x00\x06", host_status=0, driver_status=0x8, resid=65536, duration=12, info=SG_INFO_CHECK}) = 0
fstat(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(0x15, 0xe), ...}) = 0
ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=12, cmdp="\xb8\x10\x00\x00\xff\xff\x01\x01\x00\x00\x00\x00", mx_sb_len=32, iovec_count=0, dxfer_len=65536, timeout=300000, flags=0, dxferp="", status=0x2, masked_status=0x1, msg_status=0, sb_len_wr=18, sbp="\x70\x00\x05\x00\x00\x00\x00\x0a\x00\x00\x00\x00\x24\x00\x00\xc8\x00\x06", host_status=0, driver_status=0x8, resid=65536, duration=8, info=SG_INFO_CHECK}) = 0
...
Wiederholt sich halt endlos.

dcsapak said:
als letztes noch bitte direkt mit 'sg_raw' probieren:

Code:

sg_raw -r 64k <pfad zum device> B8 10 00 00 FF FF 01 FF FF FF 00 00

wobei <pfad zum device> der changer pfad in /dev/tape/by-id/.... ist

root@pbs01:~# sg_raw -r 64k /dev/tape/by-id/scsi-000007814651057A B8 10 00 00 FF FF 01 FF FF FF 00 00
SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
Sense Key Specific: Error in Command: byte 6 bit 0

Error 5 occurred, no data received

Ok, das scheint die Lib nicht zu mögen.

Danke schon mal für die Rückmeldung.

Gruß,
Heiko.

RPTU · Jul 12, 2021

Nachdem er sich ja über Byte 6 Bit 0 beschwert habe ich das bit mal auf 0 gesetzt und schon kommt was (ohne zu wissen was ich die Lib da gerade gefragt habe...):

root@pbs01:~# sg_raw -r 64k /dev/tape/by-id/scsi-000007814651057A B8 10 00 00 FF FF 00 FF FF FF 00 00
SCSI Status: Good

Received 20424 bytes of data:
00 00 01 01 88 00 00 4f c0 01 80 00 34 00 00 00 68 ......O....4...h
10 00 01 00 00 00 00 00 00 00 00 00 00 20 20 20 20 ............
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
...
4fa0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
4fb0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
4fc0 00 00 00 00 00 00 00 00 ........

Gruß,
Heiko.

RPTU · Jul 12, 2021

Hi,

https://www.ibm.com/docs/en/ts3500-tape-library?topic=commands-read-element-status-xb8

Gruß,
Heiko.

RPTU · Jul 12, 2021

Hi,

root@pbs01:~# sg_raw -r 64k /dev/tape/by-id/scsi-000007814651057A B8 04 00 00 FF FF 01 FF FF FF 00 00
SCSI Status: Good

Received 216 bytes of data:
00 01 0d 00 04 00 00 00 d0 04 00 00 32 00 00 00 c8 ...........2....
10 01 0d 04 00 81 00 00 00 00 00 00 00 02 01 00 22 ..............."
20 49 42 4d 20 20 20 20 20 55 4c 54 33 35 38 30 2d IBM ULT3580-
30 54 44 34 20 20 20 20 20 30 30 30 37 38 38 32 37 TD4 00078827
40 39 36 01 0e 04 00 81 00 00 00 00 00 00 00 02 01 96..............
50 00 22 49 42 4d 20 20 20 20 20 55 4c 54 33 35 38 ."IBM ULT358
60 30 2d 54 44 34 20 20 20 20 20 30 30 30 37 38 38 0-TD4 000788
70 35 31 33 31 01 0f 04 00 81 00 00 00 00 00 00 00 5131............
80 02 01 00 22 49 42 4d 20 20 20 20 20 55 4c 54 33 ..."IBM ULT3
90 35 38 30 2d 54 44 34 20 20 20 20 20 30 30 30 37 580-TD4 0007
a0 38 36 32 35 30 32 01 10 04 00 81 00 00 00 00 00 862502..........
b0 00 00 02 01 00 22 49 42 4d 20 20 20 20 20 55 4c ....."IBM UL
c0 54 33 35 38 30 2d 54 44 34 20 20 20 20 20 30 30 T3580-TD4 00
d0 30 37 38 35 31 36 38 30 07851680

Gruß,
Heiko.

dcsapak · Jul 12, 2021

ok danke für den link

interessant ist hier dieser teil wahrscheinlich:

For Element Type Code X'2', when the DVCID bit is set to B'1' and the VolTag bit is set to B'1', the maximum number of elements that can be requested is 5,376 (X'1500'). Any request over this amount returns Illegal Request with the ASC/ASCQ set to 24/00 (Invalid Field in CDB).

könntest du mal folgendes sg_raw probieren:

Code:

sg_raw -r 64k /dev/tape/by-id/scsi-000007814651057A B8 10 00 00 03 E8 01 FF FF FF 00 00

das fordert "nur" 1000 elemente an

RPTU · Jul 12, 2021

Hi,

leider nein.

root@pbs01:~# sg_raw -r 64k /dev/tape/by-id/scsi-000007814651057A B8 10 00 00 03 E8 01 FF FF FF 00 00
SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
Sense Key Specific: Error in Command: byte 6 bit 0

Error 5 occurred, no data received

Gruß,
Heiko.

dcsapak · Jul 12, 2021

mhm....

ok folgendes fällt mir noch ein:
gibts vielleicht ein firmware update für die library? (bei anderen usern hat es meistens geholfen die firmware von changer/drive upzudaten bei den meisten problemen)
alternativ die zahl noch weiter nach unten zu drehen:

Code:

sg_raw -r 64k /dev/tape/by-id/scsi-000007814651057A B8 10 00 00 00 64 01 FF FF FF 00 00

sind jetzt 100 statt 1000

RPTU · Jul 12, 2021

Ok, sobald ich die DVCID auf 1 setze, knallen alle Abfragen egal was die Anzahl der Elemente sagt. CURDATA 0 oder 1 ist egal.
Also nochmal mtx gegriffen und die CDB-Daten ausgeben lassen.
mtx macht erstmal ein inquiry
0000: 17 00 00 00 1D 12 00 01 00 02 05 7A 01 78 03 01 '...........z.x..'
0010: 00 0A 01 0D 00 04 00 00 20 20 20 20 20 20 '........ '
*sense_page=1d 1d
rawNumStorage= 1 120 rawNumImportExport= 0 10
rawNumTransport=0 2 rawNumDataTransfer=0 4
NumMediumTransport=2
NumStorage=386
NumImportExport=10
NumDataTransfer=4
MaxReadElementStatusData=32968
NumElements=392
Using original element status polling method (storage, import/export, drivers et
c independantly)
SCSI:ID=0 LUN=1

Danach schickt es einzelne Anfragen raus.
B8 32 (0b00110010) VolTag=1,Storage 05 7A (1402) 01 78 (376) 00 (0/0) 00 80 C8 (32968) 00 00
B8 33 (0b00110011) VolTag=1,Import/Export 03 01 ( 769) 00 0A ( 10) 00 (0/0) 00 80 C8 (32968) 00 00
B8 34 (0b00110100) VolTag=1,DataTransfer 01 0D ( 269) 00 04 ( 4) 00 (0/0) 00 80 C8 (32968) 00 00
B8 31 (0b00110001) VolTag=1,MediumTransport 00 01 ( 1) 00 01 ( 1) 00 (0/0) 00 80 C8 (32968) 00 00

DVCID ist immer auf 0, ansonsten passt es die Start/Num-Werte anhand des Inquiry an. Genau wie die LUN auch wenn die hier irrelevant ist.

Gruß,
Heiko.

RPTU · Jul 12, 2021

dcsapak said:
mhm....

ok folgendes fällt mir noch ein:
gibts vielleicht ein firmware update für die library? (bei anderen usern hat es meistens geholfen die firmware von changer/drive upzudaten bei den meisten problemen)
alternativ die zahl noch weiter nach unten zu drehen:

Code:

sg_raw -r 64k /dev/tape/by-id/scsi-000007814651057A B8 10 00 00 00 64 01 FF FF FF 00 00

sind jetzt 100 statt 1000

Keine Änderung, wie gesagt, die Lib mag DVCID=1 nicht. Auch wenn ich die MTX-Queries nehme und dort DVCID auf 1 setzte gibt es sofort wieder den bekannten Fehler.

Gruß,

Heiko.

RPTU · Jul 12, 2021

dcsapak said:
mhm....

ok folgendes fällt mir noch ein:
gibts vielleicht ein firmware update für die library? (bei anderen usern hat es meistens geholfen die firmware von changer/drive upzudaten bei den meisten problemen)

Tjo, an der Stelle habe ich leider verloren. Der letzte Release für die Hardware war 7422 Release Date: 10/09/09.

Gruß,
Heiko.

dcsapak · Jul 12, 2021

ok... mhmm.. sieht so aus als würden wir die abfrage so umstellen müssen, dass wir die einzelnen typen getrennt abfragen.. ist zwar nicht hübscher aber sollte funktionieren (mtx machts ja genau so)
das dvcid brauchen wir eig. eh nur bei den drives, und dort scheint es ja zu funktionieren
(wir verwenden die info um die konfigurierten drives mit den slots im changer zu matchen)

RPTU · Jul 12, 2021

Ok, exakt so sieht es aus. Bei den Drives tut es und beim Rest laufe ich in den Fehler. Die exakten Start/Anzahl der Elemente und die Size scheint egal zu sein. Die Lib liefert trotzdem die korrekten Daten aus. Nur sobald DVCID auf 1 sitzt gibt es den Fehler außer bei den Drives.

Ich hätte noch das Nachfolgemodell der Library mit ALMS und frischer Firmware im Zugriff. Mal temporär den PBS für eine der Libs freischalten und schauen ob es sich dort auch noch so verhält. Zum Testen wollte ich halt erstmal das Altsystem nehmen. Ich vermute aber das sich das Verhalten nicht ändern wird. Gebe aber nochmal bescheid sobald ich mehr weiß.

Gruß und Danke,

Heiko.

RPTU · Jul 12, 2021

So, auch mit den Nachfolgemodellen mit ALMS und aktueller Firmware verhält sich der Zugriff identisch. Bleibe daher erstmal bei der "alten" Lib für weitere Tests. Falls du noch weitere Daten benötigst, Test-Outputs usw., ich stehe gerne zur Verfügung.

Gruß,
Heiko.

dcsapak · Jul 12, 2021

danke fürs testen, hab mal einen patch geschickt, mit dem unsere tools die element types einzeln abfagen:
https://lists.proxmox.com/pipermail/pbs-devel/2021-July/003648.html

RPTU · Jul 12, 2021

Falls du ein frisches pmtx hast, kann ich gerne damit testen. Ansonsten warte ich auf frische Pakete.

Danke schonmal für die echt fixe Umsetzung,

Heiko.

IBM 3584/TS3500 Support

Member

Member

Member

Member

Attachments

Proxmox Staff Member

Member

Member

Member

Member

Proxmox Staff Member

Member

Proxmox Staff Member

Member

Member

Member

Proxmox Staff Member

Member

Member

Proxmox Staff Member

Member