Write problem to the media

[sita]

Hi,

I have setup the 0.18 version on OEL and tested from Solaris client. When using tar or dd command to write some files to media in MHVTL, I have got error like "Read Only Filesystem" or "I/O error". I thought I have wrong setup on LTO drive and media but it doesn't look from config file - device.conf below.

Any idea I should start with?.

Thanks,
Sita.

Library: 10 CHANNEL: 00 TARGET: 00 LUN: 00
 Vendor identification: STK
 Product identification: L700
 Product revision level: 550V
 Unit serial number: XYZZY_A
 NAA: 10:22:33:44:ab:00:00:00

Drive: 11 CHANNEL: 00 TARGET: 01 LUN: 00
 Library ID: 10 Slot: 01
 Vendor identification: IBM
 Product identification: ULT3580-TD4
 Product revision level: 550V
 Unit serial number: XYZZY_A1
 NAA: 10:22:33:44:ab:00:01:00
 Compression: factor 1 enabled 1
 READ_ONLY: LTO1
 READ_ONLY: LTO2
 READ_WRITE: LTO3
 READ_WRITE: LTO4
 WORM: LTO3
 WORM: LTO4
 ENCRYPTION: LTO4

Drive: 12 CHANNEL: 00 TARGET: 02 LUN: 00
 Library ID: 10 Slot: 02
 Vendor identification: IBM
 Product identification: ULT3580-TD4
 Product revision level: 550V
 Unit serial number: XYZZY_A2
 NAA: 10:22:33:44:ab:00:02:00
 Compression: factor 1 enabled 1
 READ_ONLY: LTO1
 READ_ONLY: LTO2
 READ_WRITE: LTO3
 READ_WRITE: LTO4
 WORM: LTO3
 WORM: LTO4
 ENCRYPTION: LTO4

Drive: 13 CHANNEL: 00 TARGET: 03 LUN: 00
 Library ID: 10 Slot: 03
 Vendor identification: IBM
 Product identification: ULT3580-TD4
 Product revision level: 550V
 Unit serial number: XYZZY_A3
 NAA: 10:22:33:44:ab:00:03:00
 Compression: factor 1 enabled 1
 READ_ONLY: LTO1
 READ_ONLY: LTO2
 READ_WRITE: LTO3
 READ_WRITE: LTO4
 WORM: LTO3
 WORM: LTO4
 ENCRYPTION: LTO4

Drive: 14 CHANNEL: 00 TARGET: 04 LUN: 00
 Library ID: 10 Slot: 04
 Vendor identification: IBM
 Product identification: ULT3580-TD4
 Product revision level: 550V
 Unit serial number: XYZZY_A4
 NAA: 10:22:33:44:ab:00:04:00
 Compression: factor 1 enabled 1
 READ_ONLY: LTO1
 READ_ONLY: LTO2
 READ_WRITE: LTO3
 READ_WRITE: LTO4
 WORM: LTO3
 WORM: LTO4
 ENCRYPTION: LTO4

[nia]

Any chance you are attempting to load /write e.g. LTO-1 or 2 tape in  LTO-4 drive ?

[Mark Harvey]

To 'prove' nia suggestion easily, remove all the load 'rules'

e.g. Remove all entries like:
 READ_ONLY: LTO1
 READ_ONLY: LTO2
 READ_WRITE: LTO3
 READ_WRITE: LTO4
 WORM: LTO3
 WORM: LTO4
 ENCRYPTION: LTO4

Re-start the vtl once the changes are in place.

Failing that, confirm VERBOSE 3 in the /etc/mhvtl/mhvtl.conf, re-create the error and forward the syslog (typically /var/log/messages) for analysis.

Cheers
Mark

[sita]

Hi Nia,

My media are all set to LTO4.

Sita.

[sita]

Hi Mark,

I have modified device.conf and restart but the problem is still.

The /var/log/messages is zipped in attached file.

Thanks,
Sita.messages.mhvtl.gz

Mark Harvey wrote

To 'prove' nia suggestion easily, remove all the load 'rules'

e.g. Remove all entries like:
 READ_ONLY: LTO1
 READ_ONLY: LTO2
 READ_WRITE: LTO3
 READ_WRITE: LTO4
 WORM: LTO3
 WORM: LTO4
 ENCRYPTION: LTO4

Re-start the vtl once the changes are in place.

Failing that, confirm VERBOSE 3 in the /etc/mhvtl/mhvtl.conf, re-create the error and forward the syslog (typically /var/log/messages) for analysis.

Cheers
Mark

[citronik]

Just a quick suggestions:
are your /opt/mhvtl/* directories+files readable+writable at the time of failure?
They should be accessible in you system for vtl:vtl regardless of mhvtl running or not, all the time.
Is it true in you case?

:j

[sita]

Hi,

Yes, I did enable read/write access to file in /opt/mhvtl with vtl:vtl.

Sita.

citronik wrote

Just a quick suggestions:
are your /opt/mhvtl/* directories+files readable+writable at the time of failure?
They should be accessible in you system for vtl:vtl regardless of mhvtl running or not, all the time.
Is it true in you case?

:j

[Mark Harvey]

syslog shows wrote

Jun  8 17:32:57 VTL vtltape[3155]: completeSCSICommand: OP s/n: (1216), sz: 14, sam_status: 0
Jun  8 17:32:57 VTL vtltape[3155]: CDB (1217) 12 01 83 00 fe 00
Jun  8 17:32:57 VTL vtltape[3155]: spc_inquiry: INQUIRY ** (1217)
Jun  8 17:32:57 VTL vtltape[3155]: spc_inquiry: Page code 0x83
Jun  8 17:32:57 VTL vtltape[3155]: spc_inquiry: Found page 0x83
Jun  8 17:32:57 VTL vtltape[3155]: completeSCSICommand: OP s/n: (1217), sz: 54, sam_status: 0
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 11 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 14 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 13 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 12 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 11 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 14 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 13 read failed, errno: 19

I can see no queries to the mhvtl daemons (except for startup messages).
However, I do see lots of messages from tgtd.

I would have to assume you are attempting to 'communicate' to the mhvtl via iSCSI and it is this that is failing.

Your sg/st paths to the devices are:

syslog shows wrote

Jun  8 17:32:57 VTL kernel: st 3:0:1:0: Attached scsi tape st0
Jun  8 17:32:57 VTL kernel: st 3:0:1:0: Attached scsi generic sg1 type 1
Jun  8 17:32:57 VTL kernel: st 3:0:2:0: Attached scsi tape st1
Jun  8 17:32:57 VTL kernel: st 3:0:2:0: Attached scsi generic sg6 type 1
Jun  8 17:32:57 VTL kernel: st 3:0:3:0: Attached scsi tape st2
Jun  8 17:32:57 VTL kernel: st 3:0:3:0: Attached scsi generic sg7 type 1
Jun  8 17:32:57 VTL kernel: st 3:0:4:0: Attached scsi tape st3
Jun  8 17:32:57 VTL kernel: st 3:0:4:0: Attached scsi generic sg8 type 1
Jun  8 17:32:58 VTL kernel: ch 3:0:0:0: Attached scsi changer ch0
Jun  8 17:32:58 VTL kernel: ch 3:0:0:0: Attached scsi generic sg9 type 8

Can you please supply the commands you used to:
- configure the SCSI Target (tgtd)
Supply the output of :
# tgtadm --mode target --op show

Also as a test, on this linux box (VTL):
# mtx -f /dev/sg9 load 1 0
# mt -f /dev/st0 status
# sg_turs -v /dev/sg1

Forward the syslog for the time frame you ran these commands along with the output.

Cheers
Mark

[sita]

Hi Mark,

Please see below for the result.

Attached is /var/log/messagesmessages.gz

Thanks,
Sita.

Here the result tgtadm --mode target --op show

Target 1: iqn.tgt-1016.org.mhvtl.server.target1
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 3
            Initiator: iqn.1986-03.com.sun:01:ea8ef0f5ffff.4deba8b1
            Connection: 0
                IP Address: 192.168.56.70
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: passthrough
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: sg
            Backing store path: /dev/sg2
            Backing store flags:
        LUN: 2
            Type: passthrough
            SCSI ID: IET     00010002
            SCSI SN: beaf12
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: sg
            Backing store path: /dev/sg3
            Backing store flags:
        LUN: 3
            Type: passthrough
            SCSI ID: IET     00010003
            SCSI SN: beaf13
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: sg
            Backing store path: /dev/sg4
            Backing store flags:
        LUN: 4
            Type: passthrough
            SCSI ID: IET     00010004
            SCSI SN: beaf14
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: sg
            Backing store path: /dev/sg5
            Backing store flags:
    Account information:
    ACL information:
        ALL

AND

[root@VTL /]# mtx -f /dev/sg9 load 1 0
Drive 0 Full (Storage Element 1 loaded)

[root@VTL /]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Mark Harvey wrote

syslog shows wrote

Jun  8 17:32:57 VTL vtltape[3155]: completeSCSICommand: OP s/n: (1216), sz: 14, sam_status: 0
Jun  8 17:32:57 VTL vtltape[3155]: CDB (1217) 12 01 83 00 fe 00
Jun  8 17:32:57 VTL vtltape[3155]: spc_inquiry: INQUIRY ** (1217)
Jun  8 17:32:57 VTL vtltape[3155]: spc_inquiry: Page code 0x83
Jun  8 17:32:57 VTL vtltape[3155]: spc_inquiry: Found page 0x83
Jun  8 17:32:57 VTL vtltape[3155]: completeSCSICommand: OP s/n: (1217), sz: 54, sam_status: 0
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 11 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 14 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 13 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 12 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 11 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 14 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 13 read failed, errno: 19

I can see no queries to the mhvtl daemons (except for startup messages).
However, I do see lots of messages from tgtd.

I would have to assume you are attempting to 'communicate' to the mhvtl via iSCSI and it is this that is failing.

Your sg/st paths to the devices are:

syslog shows wrote

Jun  8 17:32:57 VTL kernel: st 3:0:1:0: Attached scsi tape st0
Jun  8 17:32:57 VTL kernel: st 3:0:1:0: Attached scsi generic sg1 type 1
Jun  8 17:32:57 VTL kernel: st 3:0:2:0: Attached scsi tape st1
Jun  8 17:32:57 VTL kernel: st 3:0:2:0: Attached scsi generic sg6 type 1
Jun  8 17:32:57 VTL kernel: st 3:0:3:0: Attached scsi tape st2
Jun  8 17:32:57 VTL kernel: st 3:0:3:0: Attached scsi generic sg7 type 1
Jun  8 17:32:57 VTL kernel: st 3:0:4:0: Attached scsi tape st3
Jun  8 17:32:57 VTL kernel: st 3:0:4:0: Attached scsi generic sg8 type 1
Jun  8 17:32:58 VTL kernel: ch 3:0:0:0: Attached scsi changer ch0
Jun  8 17:32:58 VTL kernel: ch 3:0:0:0: Attached scsi generic sg9 type 8

Can you please supply the commands you used to:
- configure the SCSI Target (tgtd)
Supply the output of :
# tgtadm --mode target --op show

Also as a test, on this linux box (VTL):
# mtx -f /dev/sg9 load 1 0
# mt -f /dev/st0 status
# sg_turs -v /dev/sg1

Forward the syslog for the time frame you ran these commands along with the output.

Cheers
Mark

[Mark Harvey]

syslog wrote

Jun  9 09:31:02 VTL vtltape[3551]: CDB (1293) 00 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_tur: Test Unit Ready (1293) ** : Yes
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1293), sz: 0, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1294) 05 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_read_block_limits: Read block limits (1294) **
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1294), sz: 6, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1295) 1a 00 00 00 0c 00
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense: MODE SENSE (1295) **
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Mode Sense 6 byte version
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Page Control  : Current configuration(0x0)
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Page Code     : 0x0
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Disable Block Descriptor => No
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Allocation len: 12
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense: pcode: 0x00
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1295), sz: 12, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1296) 01 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_rewind: Rewinding (1296) **
Jun  9 09:31:02 VTL vtltape[3551]: read_header: Reading header 0 at offset 0, type: END OF DATA, size: 0
Jun  9 09:31:02 VTL vtltape[3551]: rewind_tape: Media is writable
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1296), sz: 0, sam_status: 0

So from that, we can see the media is 'writable'
Jun  9 09:31:02 VTL vtltape[3551]: rewind_tape: Media is writable

The 'tgtadm --op show' looks OK.

What version of tgt are you using ?

Also looking thru the syslog, I see the daemon was started a couple of days ago.
Jun  7 23:03:48 VTL tgtd: tgtd daemon started, pid:2195
Jun  7 23:03:48 VTL tgtd: tgtd logger started, pid:2197 debug:0

I would recommend the start / stop sequence of:

mhvtl start
tgt start
tgt configure

tgt stop
mhvtl stop

i.e.
- stop tgt before mhvtl
- start mhvtl before starting tgt

As tgt performs a open() of the /dev/sg path, and stopping mhvtl results in the /dev/sg path being removed, tgtd may fail to communicate correctly and hence the source of your problems..

Cheers
Mark

[sita]

Hi,

Perhaps my Solaris client can be wrong. What's step on Solaris client to check?.

Thanks.

Sita.

Mark Harvey wrote

syslog wrote

Jun  9 09:31:02 VTL vtltape[3551]: CDB (1293) 00 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_tur: Test Unit Ready (1293) ** : Yes
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1293), sz: 0, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1294) 05 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_read_block_limits: Read block limits (1294) **
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1294), sz: 6, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1295) 1a 00 00 00 0c 00
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense: MODE SENSE (1295) **
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Mode Sense 6 byte version
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Page Control  : Current configuration(0x0)
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Page Code     : 0x0
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Disable Block Descriptor => No
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Allocation len: 12
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense: pcode: 0x00
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1295), sz: 12, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1296) 01 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_rewind: Rewinding (1296) **
Jun  9 09:31:02 VTL vtltape[3551]: read_header: Reading header 0 at offset 0, type: END OF DATA, size: 0
Jun  9 09:31:02 VTL vtltape[3551]: rewind_tape: Media is writable
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1296), sz: 0, sam_status: 0

So from that, we can see the media is 'writable'
Jun  9 09:31:02 VTL vtltape[3551]: rewind_tape: Media is writable

The 'tgtadm --op show' looks OK.

What version of tgt are you using ?

Also looking thru the syslog, I see the daemon was started a couple of days ago.
Jun  7 23:03:48 VTL tgtd: tgtd daemon started, pid:2195
Jun  7 23:03:48 VTL tgtd: tgtd logger started, pid:2197 debug:0

I would recommend the start / stop sequence of:

mhvtl start
tgt start
tgt configure

tgt stop
mhvtl stop

i.e.
- stop tgt before mhvtl
- start mhvtl before starting tgt

As tgt performs a open() of the /dev/sg path, and stopping mhvtl results in the /dev/sg path being removed, tgtd may fail to communicate correctly and hence the source of your problems..

Cheers
Mark

[Mark Harvey]

Oh no. The problem is at the Linux host..

i.e.
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 11 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 14 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 13 read failed, errno: 19
Jun  8 17:32:58 VTL tgtd: graceful_read(65) sg device 12 read failed, errno: 19

tgtd can't communicate via/to the sg device..

Have you stopped and re-started tgtd and re-configured since starting mhvtl daemons ?

[sita]

Hi,

How to configure tgt?. My tgt package is installed under /opt/tgt..... I seem I can not find the option "configure". Just start/stop/reload/forcestop....

Sita.

sita wrote

Hi,

Perhaps my Solaris client can be wrong. What's step on Solaris client to check?.

Thanks.

Sita.

Mark Harvey wrote

syslog wrote

Jun  9 09:31:02 VTL vtltape[3551]: CDB (1293) 00 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_tur: Test Unit Ready (1293) ** : Yes
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1293), sz: 0, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1294) 05 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_read_block_limits: Read block limits (1294) **
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1294), sz: 6, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1295) 1a 00 00 00 0c 00
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense: MODE SENSE (1295) **
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Mode Sense 6 byte version
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Page Control  : Current configuration(0x0)
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Page Code     : 0x0
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Disable Block Descriptor => No
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense:  Allocation len: 12
Jun  9 09:31:02 VTL vtltape[3551]: spc_mode_sense: pcode: 0x00
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1295), sz: 12, sam_status: 0
Jun  9 09:31:02 VTL vtltape[3551]: CDB (1296) 01 00 00 00 00 00
Jun  9 09:31:02 VTL vtltape[3551]: ssc_rewind: Rewinding (1296) **
Jun  9 09:31:02 VTL vtltape[3551]: read_header: Reading header 0 at offset 0, type: END OF DATA, size: 0
Jun  9 09:31:02 VTL vtltape[3551]: rewind_tape: Media is writable
Jun  9 09:31:02 VTL vtltape[3551]: completeSCSICommand: OP s/n: (1296), sz: 0, sam_status: 0

So from that, we can see the media is 'writable'
Jun  9 09:31:02 VTL vtltape[3551]: rewind_tape: Media is writable

The 'tgtadm --op show' looks OK.

What version of tgt are you using ?

Also looking thru the syslog, I see the daemon was started a couple of days ago.
Jun  7 23:03:48 VTL tgtd: tgtd daemon started, pid:2195
Jun  7 23:03:48 VTL tgtd: tgtd logger started, pid:2197 debug:0

I would recommend the start / stop sequence of:

mhvtl start
tgt start
tgt configure

tgt stop
mhvtl stop

i.e.
- stop tgt before mhvtl
- start mhvtl before starting tgt

As tgt performs a open() of the /dev/sg path, and stopping mhvtl results in the /dev/sg path being removed, tgtd may fail to communicate correctly and hence the source of your problems..

Cheers
Mark

[Mark Harvey]

Now we're getting somewhere...

Can you pls supply the output of
# rpm -qf `which tgtadm`

Then:
# rpm -qi <package name from above cmd>

[sita]

Quite strange. I have installed it already but the result below showed different. I have checked and there is /usr/sbin/tgtadm there. Am I missing anything?.

[root@VTL scripts]# rpm -qf `which tgtadm`
file /usr/sbin/tgtadm is not owned by any package
[root@VTL scripts]# rpm -qi tgtadm
package tgtadm is not installed

Mark Harvey wrote

Now we're getting somewhere...

Can you pls supply the output of
# rpm -qf `which tgtadm`

Then:
# rpm -qi <package name from above cmd>

[Mark Harvey]

OK, Looks like I assumed wrong here.

As you indicated you didn't manually setup/configure stgt, I assumed you had installed from a package supplied with Oracle Linux. RPM queries reflect otherwise.

Therefore, did you download latest stgt source and compile ?
If so, what version ?

Where/what rc script are you using to start stgt ?
Have you re-started tgtd since latest start of mhvtl ?

Cheers
Mark

[sita]

Hi Mark,

I did setup for tgt. It's tgt1.0.16. Whenever I want to start/stop/restart, I use their script, that's initd.sample under installed directory. And I checked whether tgtd is up and running.

Probably, my step is not complete correct. Do you have step start from the beginning then I can check?.

Thanks,
Sita.

Mark Harvey wrote

OK, Looks like I assumed wrong here.

As you indicated you didn't manually setup/configure stgt, I assumed you had installed from a package supplied with Oracle Linux. RPM queries reflect otherwise.

Therefore, did you download latest stgt source and compile ?
If so, what version ?

Where/what rc script are you using to start stgt ?
Have you re-started tgtd since latest start of mhvtl ?

Cheers
Mark

[nia]

This one is an old one but should still work :

http://mhvtl-linux-virtual-tape-library-community-forums.966029.n3.nabble.com/MHVTL-0-18-10-tgt-iSCSI-target-tp1684577p1684577.html


You basically need to start mhvtl, compile stgt, start tgtd, create iscsi targets in stgt and export ( in this order)

nia

[Mark Harvey]

Perfect answer !

Obviously just the target bit is needed. You don't need to do the initiator bits (from iscsiadm --discovery) down.

Thanks NIA

Mark

[sita]

Thanks NIA and Mark for all the help. Appreciate.

Sita.

Mark Harvey wrote

Perfect answer !

Obviously just the target bit is needed. You don't need to do the initiator bits (from iscsiadm --discovery) down.

Thanks NIA

Mark