There's a --type raw, right? Isn't that supposed to pass through the
SCSI
commands?
BTW, I tried to re-create the scenario with iscsitadm creating an
emulated tape target (in one vm under VirtualBox) and (in another vm on
my poor struggling Mac Mini, which can't really take enough RAM for
multiple
simultaneous guests to be very practical) an Ubuntu Studio Linux guest
with
open-iscsi initiator to access it. I couldn't get that to work
either. I gather
there's a "REPORT LUNs" command that goes out, but I didn't get the
details.
It had me wondering what that's supposed to look like if one of the
reported
devices is supposed to be a tape. I think I know what the SCSI inquiry
response ought to look like, but I have to read up more on REPORT LUNs
to
have any idea which end isn't making this work.
I also tried an initiator on the same system as the target; again, it
seemed to recognize it but not actually create a /dev/rmt (or even /
devices/iscsi/...) node with which the device could be accessed. By
contrast,
I've shared out a zvol as an iSCSI disk LUN from my snv_97 or so Sun
Blade
2000 to my Mac Mini (using the free GlobalSAN iSCSI initiator) and
it's seemed
to work pretty well, save only that my 100Mb/s LAN is clearly a
limitation.
So maybe there is a problem sharing out a (emulated) tape device...
On Apr 27, 2009, at 3:11 PM, Andrey Kuzmin wrote:
IIRC (it's over a years since I last looked at user-space iSCSI target
code), iscsit supports pass-through mode so that running local tape
target should not be a problem. Of course, whether such a mode was
envisaged/designed for is a totally different question.
Regards,
Andrey
On Mon, Apr 27, 2009 at 5:57 PM, Milos Muzik <[email protected]>
wrote:
The iSCSI target iscsitgtd does not support tape device as a
backing store.
Though iscsitadm has a parameter '--type tape', it is intended for
a tape
emulation (virtual tape). The only possible backing stores are
files and disk
devices.
Look at bug ID 6783745 for reference.
Regards,
Milos
Richard L. Hamilton wrote:
I don't even know if that _should_ work, and this probably won't
make it
work if it won't. But I think I'd prefer /dev/rmt/0n (non-rewind
on close),
so that any such special behavior would be left up to the client.
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
