Tape Library with Changer where medium_transport_address!=0 not working

jdps

New Member
May 17, 2023
7
0
1
Hamburg, Germany
Hi!
I'm trying to use a tape library with a changer and two drives (dell tl4000 which is an IBM 3573-TL in disguise with two ULT3580-HH7 drives)
.
All is recognized pretty well by pbs, media in all slots shown correctly by GUI and pmtx
The problem is: loading and moving of tapes as well as labeling isn't working.
here is a sample output by pmtx:

root@pbs:~# pmtx load 2 --changer=tl4000 --drivenum=1
using device /dev/tape/by-id/scsi-00X4U78Y5511_LL0
Error: load drive failed - Illegal Request, Additional sense: Invalid message error

That led me to another post in this forum: https://forum.proxmox.com/threads/tape-libary-2-drives.87909/
although it's a similar problem, i found out that there seems to be a completely different cause.
The changer is working from that system though.
Had a simple test:
root@pbs:~# mtx -f /dev/tape/by-id/scsi-1IBM_3573-TL_00X4U78Y5511_LL0 load 2 1
Loading media from Storage Element 2 into drive 1...done

Our Library reports a medium transport address of "1" if the following output is not misinterpreted by me (bytes 8-9 of sub-header, first two bytes of the second line as referred on page 3-61 in https://www.ibm.com/support/pages/s...bf546185257b19007450cb/$FILE/GA32-0547-02.pdf):
root@pbs:~# sg_raw -r 16k /dev/tape/by-id/scsi-1IBM_3573-TL_00X4U78Y5511 B8 00 00 00 0F FF 01 00 FF FF 00 00
SCSI Status: Good

Received 868 bytes of data:
00 00 01 00 30 00 00 03 5c 01 00 00 10 00 00 00 10 ...0...\........
10 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20 04 00 00 32 00 00 00 64 01 00 01 00 00 00 00 00 ...2...d........
30 00 81 10 02 02 01 00 22 49 42 4d 20 20 20 20 20 ......."IBM
40 55 4c 54 33 35 38 30 2d 48 48 37 20 20 20 20 20 ULT3580-HH7
50 31 30 57 54 30 38 34 35 31 37 01 01 08 00 00 00 10WT084517......
60 00 00 00 00 00 00 02 01 00 22 49 42 4d 20 20 20 ........."IBM
70 20 20 55 4c 54 33 35 38 30 2d 48 48 37 20 20 20 ULT3580-HH7
80 20 20 31 30 57 54 30 38 36 30 38 39 02 00 00 10 10WT086089....
90 00 00 02 d0 10 00 09 00 54 33 35 38 30 a1 10 00 ........T3580...
a0 37 20 20 20 10 01 39 30 57 54 30 38 36 b1 10 01 7 ..90WT086...
b0 00 00 00 00 10 02 08 00 00 00 00 00 00 00 00 00 ................
c0 00 00 00 00 10 03 09 00 00 00 00 00 00 81 10 03 ................
d0 00 00 00 00 10 04 09 00 00 00 00 00 00 81 10 04 ................
e0 00 00 00 00 10 05 09 00 00 00 00 00 00 81 10 05 ................
f0 00 00 00 00 10 06 09 00 00 00 00 00 00 81 10 06 ................
100 00 00 00 00 10 07 09 00 00 00 00 00 00 81 10 07 ................
110 00 00 00 00 10 08 09 00 00 00 00 00 00 81 10 08 ................
120 00 00 00 00 10 09 09 00 00 00 00 00 00 81 10 09 ................
130 00 00 00 00 10 0a 09 00 00 00 00 00 00 81 10 0a ................
140 00 00 00 00 10 0b 09 00 00 00 00 00 00 81 10 0b ................
150 00 00 00 00 10 0c 09 00 00 00 00 00 00 81 10 0c ................
160 00 00 00 00 10 0d 09 00 00 00 00 00 00 81 10 0d ................
170 00 00 00 00 10 0e 09 00 00 00 00 00 00 81 10 0e ................
180 00 00 00 00 10 0f 09 00 00 00 00 00 00 81 10 0f ................
190 00 00 00 00 10 10 09 00 00 00 00 00 00 81 10 10 ................
1a0 00 00 00 00 10 11 09 00 00 00 00 00 00 81 10 11 ................
1b0 00 00 00 00 10 12 09 00 00 00 00 00 00 81 10 12 ................
1c0 00 00 00 00 10 13 09 00 00 00 00 00 00 81 10 13 ................
1d0 00 00 00 00 10 14 09 00 00 00 00 00 00 81 10 14 ................
1e0 00 00 00 00 10 15 09 00 00 00 00 00 00 81 10 15 ................
1f0 00 00 00 00 10 16 09 00 00 00 00 00 00 81 10 16 ................
200 00 00 00 00 10 17 09 00 00 00 00 00 00 81 10 17 ................
210 00 00 00 00 10 18 09 00 00 00 00 00 00 81 10 18 ................
220 00 00 00 00 10 19 09 00 00 00 00 00 00 81 10 19 ................
230 00 00 00 00 10 1a 09 00 00 00 00 00 00 81 10 1a ................
240 00 00 00 00 10 1b 09 00 00 00 00 00 00 81 10 1b ................
250 00 00 00 00 10 1c 09 00 00 00 00 00 00 81 10 1c ................
260 00 00 00 00 10 1d 09 00 00 00 00 00 00 81 10 1d ................
270 00 00 00 00 10 1e 09 00 00 00 00 00 00 81 10 1e ................
280 00 00 00 00 10 1f 09 00 00 00 00 00 00 81 10 1f ................
290 00 00 00 00 10 20 09 00 00 00 00 00 00 81 10 20 ..... .........
2a0 00 00 00 00 10 21 09 00 00 00 00 00 00 81 10 21 .....!.........!
2b0 00 00 00 00 10 22 09 00 00 00 00 00 00 81 10 22 ....."........."
2c0 00 00 00 00 10 23 09 00 00 00 00 00 00 81 10 23 .....#.........#
2d0 00 00 00 00 10 24 09 00 00 00 00 00 00 81 10 24 .....$.........$
2e0 00 00 00 00 10 25 09 00 00 00 00 00 00 81 10 25 .....%.........%
2f0 00 00 00 00 10 26 09 00 00 00 00 00 00 81 10 26 .....&.........&
300 00 00 00 00 10 27 09 00 00 00 00 00 00 81 10 27 .....'.........'
310 00 00 00 00 10 28 09 00 00 00 00 00 00 81 10 28 .....(.........(
320 00 00 00 00 10 29 09 00 00 00 00 00 00 81 10 29 .....).........)
330 00 00 00 00 10 2a 09 00 00 00 00 00 00 81 10 2a .....*.........*
340 00 00 00 00 10 2b 09 00 00 00 00 00 00 81 10 2b .....+.........+
350 00 00 00 00 10 2c 09 00 00 00 00 00 00 81 10 2c .....,.........,
360 00 00 00 00 ....

So what might be the problem?
I pulled the code from https://github.com/proxmox/proxmox-backup and think that regardless of the reported address, each time a 0 is passed.
What makes me think so?
In pbs-tape/src/sg_pt_changer.rs the use of this address is prepared and passed to the command but i found no appearance of setting it to other than 0.
...
medium_transport_address: u16,
...
cmd.extend(medium_transport_address.to_be_bytes());
...


I would be happy if a developer agrees to my conclusion and provides a fix.


Best regards,
Joerg
 
looking at the code, we decode the medium transport address from the read element status call, so that should be correct

what is the output of

Code:
pmtx status --changer <your-changer-id>
?

also 'proxmox-backup-manager versions --verbose' would be interesting
 
Hi!
Thanks for your reply.

Here are the results:

root@pbs:~# pmtx status --changer tl4000
using device /dev/tape/by-id/scsi-00X4U78Y5511_LL0
Transport Element (Griper) 0: Empty
Data Transfer Element (Drive) 0: VolumeTag("000003L7"), Source: 3, Serial: 10WT084517
Data Transfer Element (Drive) 1: Empty, Serial: 10WT086089
Storage Element 1: VolumeTag("000001L7")
Storage Element 2: VolumeTag("000002L7")
Storage Element 3: Empty
Storage Element 4: VolumeTag("000004L7")
Storage Element 5: VolumeTag("000005L7")
Storage Element 6: VolumeTag("000006L7")
Storage Element 7: VolumeTag("000007L7")
Storage Element 8: VolumeTag("000008L7")
Storage Element 9: VolumeTag("000009L7")
Storage Element 10: VolumeTag("000010L7")
Storage Element 11: VolumeTag("000011L7")
Storage Element 12: VolumeTag("000012L7")
Storage Element 13: VolumeTag("000013L7")
Storage Element 14: VolumeTag("000014L7")
Storage Element 15: VolumeTag("000015L7")
Storage Element 16: VolumeTag("000016L7")
Storage Element 17: VolumeTag("000017L7")
Storage Element 18: VolumeTag("000018L7")
Storage Element 19: VolumeTag("000019L7")
Storage Element 20: VolumeTag("000020L7")
Storage Element 21: VolumeTag("000021L7")
Storage Element 22: VolumeTag("000022L7")
Storage Element 23: VolumeTag("000023L7")
Storage Element 24: VolumeTag("000024L7")
Storage Element 25: VolumeTag("000025L7")
Storage Element 26: VolumeTag("000026L7")
Storage Element 27: VolumeTag("000027L7")
Storage Element 28: VolumeTag("000028L7")
Storage Element 29: VolumeTag("000029L7")
Storage Element 30: VolumeTag("000030L7")
Storage Element 31: VolumeTag("000031L7")
Storage Element 32: VolumeTag("000032L7")
Storage Element 33: VolumeTag("000033L7")
Storage Element 34: VolumeTag("000034L7")
Storage Element 35: VolumeTag("000035L7")
Storage Element 36: VolumeTag("000036L7")
Storage Element 37: VolumeTag("000037L7")
Storage Element 38: VolumeTag("000038L7")
Storage Element 39: VolumeTag("000039L7")
Storage Element 40: VolumeTag("000040L7")
Storage Element 41: VolumeTag("000041L7")
Storage Element 42: VolumeTag("000042L7")
Storage Element 43: VolumeTag("000043L7")
Storage Element 44: VolumeTag("000044L7")
Storage Element 45: VolumeTag("000045L7")
root@pbs:~# proxmox-backup-manager versions --verbose
proxmox-backup 2.4-1 running kernel: 5.15.107-2-pve
proxmox-backup-server 2.4.1-1 running version: 2.4.1
pve-kernel-5.15 7.4-3
pve-kernel-5.15.107-2-pve 5.15.107-2
pve-kernel-5.15.107-1-pve 5.15.107-1
pve-kernel-5.15.104-1-pve 5.15.104-2
pve-kernel-5.15.85-1-pve 5.15.85-1
pve-kernel-5.15.74-1-pve 5.15.74-1
ifupdown2 3.1.0-1+pmx3
libjs-extjs 7.0.0-1
proxmox-backup-docs 2.4.1-1
proxmox-backup-client 2.4.1-1
proxmox-mail-forward 0.1.1-1
proxmox-mini-journalreader 1.2-1
proxmox-offline-mirror-helper unknown
proxmox-widget-toolkit 3.6.5
pve-xtermjs 4.16.0-1
smartmontools 7.2-pve3
zfsutils-linux 2.1.11-pve1
 
thanks, looks normal so far.. i cannot really see what we would do wrong here, and AFAICS from the mtx source code, we even do the same here (aside from some eepos stuff that's not relevant here)

does it fail for every slot/drive? or just specific combinations?

also what is the error when you try to label one that's already loaded in the correct drive ?
 
Hi Dominik,
yes, pmtx fails for all combinations.

like this:
root@pbs:~# pmtx transfer 2 3 --changer=tl4000
using device /dev/tape/by-id/scsi-00X4U78Y5511_LL0
Error: transfer medium from slot 2 to slot 3 failed - Illegal Request, Additional sense: Invalid message error

for labelling:
root@pbs:~# proxmox-tape label --label-text 000003L7 --drive drive0
TASK ERROR: rewind failed - Illegal Request, Additional sense: Invalid message error


root@pbs:~# proxmox-tape barcode-label --drive drive0
checking/loading media '000001L7'
WARN: unable to load media '000001L7' - unload drive failed - Illegal Request, Additional sense: Invalid message error
checking/loading media '000002L7'
WARN: unable to load media '000002L7' - unload drive failed - Illegal Request, Additional sense: Invalid message error
checking/loading media '000003L7'
TASK ERROR: rewind failed - Illegal Request, Additional sense: Invalid message error

But mtx handles the lib just fine:
root@pbs:~# mtx -f /dev/tape/by-id/scsi-1IBM_3573-TL_00X4U78Y5511_LL0 transfer 2 3
root@pbs:~# pmtx status --changer=tl4000
using device /dev/tape/by-id/scsi-00X4U78Y5511_LL0
Transport Element (Griper) 0: Empty
Data Transfer Element (Drive) 0: VolumeTag("000003L7"), Serial: 10WT084517
Data Transfer Element (Drive) 1: Empty, Serial: 10WT086089
Storage Element 1: VolumeTag("000001L7")
Storage Element 2: Empty
Storage Element 3: VolumeTag("000002L7")
Storage Element 4: VolumeTag("000004L7")
....


But again, the "Transport Element (Griper)" in this output shows "0".

This here states it should be "1":

root@pbs:~# sg_raw -r 16k /dev/tape/by-id/scsi-1IBM_3573-TL_00X4U78Y5511 B8 00 00 00 0F FF 01 00 FF FF 00 00
SCSI Status: Good

Received 868 bytes of data:
00 00 01 00 30 00 00 03 5c 01 00 00 10 00 00 00 10 ...0...\........
10 00 01 <----

Best Regards,
Jörg
 
mhmm very weird,

can you post the output of
Code:
proxmox-tape changer list  --output-format json-pretty
proxmox-tape drive list  --output-format json-pretty
?

But again, the "Transport Element (Griper)" in this output shows "0".

This here states it should be "1":
the '0' here is not the index reported by the changer, but the index of our list, this is not what is sent as medium_transport_address

checking/loading media '000003L7'
TASK ERROR: rewind failed - Illegal Request, Additional sense: Invalid message error
this command does not even has anything to do with the changer, it's a command sent directly to the drive (and it's a very simple command...., basically '0x01 0x00 0x00 0x00 0x00 0x00')
how is your changer/drive connected to the server? via a raid card/hba ?
did you already check if there's a firmware update available for either?

honstly never saw that error pop up anywhere... do you have scsi docs for you tapelib/drives (aside from the ibm pdf you posted above?)
 
Here is the output:

root@pbs:~# proxmox-tape changer list --output-format json-pretty
[
{
"model": "3573-TL",
"name": "tl4000",
"path": "/dev/tape/by-id/scsi-00X4U78Y5511_LL0",
"serial": "00X4U78Y5511_LL0",
"vendor": "IBM"
}
]
root@pbs:~# proxmox-tape drive list --output-format json-pretty
[
{
"changer": "tl4000",
"changer-drivenum": 1,
"model": "ULT3580-HH7",
"name": "drive1",
"path": "/dev/tape/by-id/scsi-10WT086089-sg",
"serial": "10WT086089",
"vendor": "IBM"
},
{
"changer": "tl4000",
"changer-drivenum": 0,
"model": "ULT3580-HH7",
"name": "drive0",
"path": "/dev/tape/by-id/scsi-10WT084517-sg",
"serial": "10WT084517",
"vendor": "IBM"
}
]


I updated the firmware of the library to latest before i came up with my case here.
library and drives are connected to a hba and then presented via iscsi to the pbs.
I use SCST as described in this article: https://pve.proxmox.com/wiki/Tape_Drives

At first i had some doubts if i had done it wrong, but as mtx handles the changer and drives as expected i was looking for a reason why pmtx doesn't.

By now i don't have any other docs on the library but if needed will search for more :)
 
Before you have to ask:
the devices reported by 'scstadmin -list_device' on the target are:
Handler Device
--------------------------
dev_changer 11:0:0:1
dev_tape 0:0:0:0
11:0:0:0
dev_tape_perf -

initiator shows them as follows (lsscsi -g):
[3:0:0:0] tape IBM ULT3580-HH7 J4D1 /dev/st0 /dev/sg3
[3:0:0:1] tape IBM ULT3580-HH7 J4D1 /dev/st1 /dev/sg4
[3:0:0:2] mediumx IBM 3573-TL F.11 /dev/sch0 /dev/sg5
 
thanks for the info!

library and drives are connected to a hba and then presented via iscsi to the pbs.
I use SCST as described in this article: https://pve.proxmox.com/wiki/Tape_Drives

mhmm the article is rather old and not really intended for pbs

AFAIU the tape drive is not directly connected to the pbs? or is the pbs a virtual machine?
(just trying to understand all pieces here)

one thing i see here is that with mtx you use "/dev/tape/by-id/scsi-1IBM_3573-TL_00X4U78Y5511_LL0" but for pbs "/dev/tape/by-id/scsi-00X4U78Y5511_LL0" is configured, do they point to the same device (you can post the output of 'ls -lh /dev/tape/by-id' to verify)
 
Hi Dominik!

First, yes, the device names point to the same device (and mtx works with either name):
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-00X4U78Y5511_LL0 -> ../../sg5
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-10WT084517 -> ../../st1
lrwxrwxrwx 1 root root 10 May 17 11:40 scsi-10WT084517-nst -> ../../nst1
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-10WT084517-sg -> ../../sg4
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-10WT086089 -> ../../st0
lrwxrwxrwx 1 root root 10 May 17 11:40 scsi-10WT086089-nst -> ../../nst0
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-10WT086089-sg -> ../../sg3
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-1IBM_3573-TL_00X4U78Y5511_LL0 -> ../../sg5
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-32001000e1116d831 -> ../../st1
lrwxrwxrwx 1 root root 10 May 17 11:40 scsi-32001000e1116d831-nst -> ../../nst1
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-32001000e1116d831-sg -> ../../sg4
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-32004000e1116d831 -> ../../st0
lrwxrwxrwx 1 root root 10 May 17 11:40 scsi-32004000e1116d831-nst -> ../../nst0
lrwxrwxrwx 1 root root 9 May 17 11:40 scsi-32004000e1116d831-sg -> ../../sg3

Well, the article is old indeed.
I use the current version 3.8.0 of scst and yes, the library is bound to another machines hba and the pbs is a virtual machine.

nevertheless it runs with mtx and I don't see where the difference should be

some more info, /etc/proxmox-backup/tape.cfg :
changer: tl4000
path /dev/tape/by-id/scsi-00X4U78Y5511_LL0

lto: drive0
changer tl4000
path /dev/tape/by-id/scsi-10WT084517-sg

lto: drive1
changer tl4000
changer-drivenum 1
path /dev/tape/by-id/scsi-10WT086089-sg
 
nevertheless it runs with mtx and I don't see where the difference should be
no i don't know either why mtx should work but our tools not, AFAICT they're generally doing the same....
i'll think about how we can debug this and write again

one thing you could try is to execute the one rewind call from above with sg_raw manually and see if that works
Code:
sg_raw -r 1k /dev/tape/by-id/scsi-10WT084517-sg 01 00 00 00 00 00

also does the journal/dmesg show any errors/hints?
 
hey, any new info? did you try the sg_raw command?

besides trying that, there is not much in terms of debugging we can do from here (aside from checking the logs)...
that command failed for you, so it would be interesting if it fails when you manually execute it
 
Hi, for the record we have a Dell TL4000 tape library with three drives (internally IBM 3573-TL + 3 ULT3580-HH7 drives) and with PBS 3.1.2


Code:
root@r730xd:~# proxmox-backup-manager versions
proxmox-backup-server 3.1.2-1 running version: 3.1.2

Everything seem to work fine, PBS web UI and pmtx commands work as expected.

We were just careful to number the drives in proxmox in the same order as displayed by the web UI of the tape library itself which is not the same order as displayed by proxmox-tape drive scan (which seems to sort alphabetically).

"drive1" is proxmox drivenum 0, "drive2" 1, "drive3" 2.

Code:
root@r730xd:~# proxmox-tape drive scan
┌────────────────────────────────────┬────────┬─────────────┬────────────┐
│ path                               │ vendor │ model       │ serial     │
╞════════════════════════════════════╪════════╪═════════════╪════════════╡
│ /dev/tape/by-id/scsi-10WT023107-sg │ IBM    │ ULT3580-HH7 │ 10WT023107 │
├────────────────────────────────────┼────────┼─────────────┼────────────┤
│ /dev/tape/by-id/scsi-10WT023116-sg │ IBM    │ ULT3580-HH7 │ 10WT023116 │
├────────────────────────────────────┼────────┼─────────────┼────────────┤
│ /dev/tape/by-id/scsi-10WT023117-sg │ IBM    │ ULT3580-HH7 │ 10WT023117 │
└────────────────────────────────────┴────────┴─────────────┴────────────┘
root@r730xd:~# proxmox-tape drive list
┌────────┬────────────────────────────────────┬─────────────┬────────┬─────────────┬────────────┐
│ name   │ path                               │ changer     │ vendor │ model       │ serial     │
╞════════╪════════════════════════════════════╪═════════════╪════════╪═════════════╪════════════╡
│ drive1 │ /dev/tape/by-id/scsi-10WT023117-sg │ ibm-3573-tl │ IBM    │ ULT3580-HH7 │ 10WT023117 │
├────────┼────────────────────────────────────┼─────────────┼────────┼─────────────┼────────────┤
│ drive2 │ /dev/tape/by-id/scsi-10WT023107-sg │ ibm-3573-tl │ IBM    │ ULT3580-HH7 │ 10WT023107 │
├────────┼────────────────────────────────────┼─────────────┼────────┼─────────────┼────────────┤
│ drive3 │ /dev/tape/by-id/scsi-10WT023116-sg │ ibm-3573-tl │ IBM    │ ULT3580-HH7 │ 10WT023116 │
└────────┴────────────────────────────────────┴─────────────┴────────┴─────────────┴────────────┘
root@r730xd:~# ls -l /dev/tape/by-id/
total 0
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-00X4U78Y1247_LL0 -> ../../sg2
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-10WT023107 -> ../../st2
lrwxrwxrwx 1 root root 10 Jan  9 15:25 scsi-10WT023107-nst -> ../../nst2
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-10WT023107-sg -> ../../sg4
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-10WT023116 -> ../../st1
lrwxrwxrwx 1 root root 10 Jan  9 15:25 scsi-10WT023116-nst -> ../../nst1
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-10WT023116-sg -> ../../sg3
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-10WT023117 -> ../../st0
lrwxrwxrwx 1 root root 10 Jan  9 15:25 scsi-10WT023117-nst -> ../../nst0
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-10WT023117-sg -> ../../sg1
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-1IBM_3573-TL_00X4U78Y1247_LL0 -> ../../sg2
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-1IBM_3573-TL_00X4U78Y1247_LL0-changer -> ../../sg2
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-35000e1116b1b0001 -> ../../st0
lrwxrwxrwx 1 root root 10 Jan  9 15:25 scsi-35000e1116b1b0001-nst -> ../../nst0
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-35000e1116b1b0001-sg -> ../../sg1
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-35000e1116b1b0004 -> ../../st2
lrwxrwxrwx 1 root root 10 Jan  9 15:25 scsi-35000e1116b1b0004-nst -> ../../nst2
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-35000e1116b1b0004-sg -> ../../sg4
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-35000e1116b1b0007 -> ../../st1
lrwxrwxrwx 1 root root 10 Jan  9 15:25 scsi-35000e1116b1b0007-nst -> ../../nst1
lrwxrwxrwx 1 root root  9 Jan  9 15:25 scsi-35000e1116b1b0007-sg -> ../../sg3
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!