[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [dm-devel] open-iscsi + dm-multipath



 

-----Original Message-----
From: dm-devel-bounces redhat com [mailto:dm-devel-bounces redhat com]
On Behalf Of Patrick Mansfield
Sent: Tuesday, March 15, 2005 5:38 PM
To: device-mapper development
Cc: open-iscsi googlegroups com
Subject: Re: [dm-devel] open-iscsi + dm-multipath

On Tue, Mar 15, 2005 at 04:40:01PM -0800, Caushik, Ramesh wrote:
> BTW I have seen in the case of atleast 2 different iSCSI target
> implementations (unh-iscsi and iscsi-enterprise target), the target
does
> not return the physical disk id for the scsi_id callout, but returns
> manufactured values (like LINUX ISCSI for vendor, etc). Given that,
how

Is that only when used on top of block devices or file systems? That
makes
sense, but not if they are just passing commands through to the LUN.

   >>> By default they are mostly used on top of block devices or
filesystems. 

> can multipath-tools create multipaths for different iscsi disks ? I am
> thinking of the case 2 iscsi servers running iscsi target software and
> talking to the same FC disk at the back-end. By running
multipath-tools
> I would expect the 2 different iSCSI logical devices to be part of the
> same multipath group. But if the target software on both the servers
> returns made-up values then this scheme would break, right ? Any

What is the scsi_id output for those cases?

If the made up values are unique there is not a problem. The target
could
(should?) return a vendor specific value for VPD page 0x83. Then scsi_id
prepends the vendor + model in front of that.

If the value returned is unique across all possible LUNs with the same
vendor and model, it would work OK even across different targets (i.e.
targets on different hosts or such, I don't know what iSCSI calls them).

There should be methods to make sure you always get something unique
from
the target, like include the underlying LUN's VPD page 0x83, or include
the MAC address of as part of the generated id.

	>>> The problem is they are not unique. 

> comments on this one ?

Fix the targets to always return unique values.

If there is a special scsi command or such that can be sent to get a
unique value from these targets, special code could be added to scsi_id,
but it is best if VPD page 0x83 can be used.

If it is still an issue, use some other method to identify the LUNs, or
don't use multipathing with those targets.

		>>> Thanks. I think it is best fixed in the target, or
find another way to identify multiple paths to the same iscsi volume.

-- Patrick Mansfield

--
dm-devel mailing list
dm-devel redhat com
https://www.redhat.com/mailman/listinfo/dm-devel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]