Re: SCSI ID uniqueness: VMware initiator

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

 



Hi Yaron.

I belive VMWare vSphere uses the special SCSI opcode COMPARE_AND_WRITE.

I sent a patch to the list the other day to activate this opcode and
fix it so it should work according to the standard.

Would it be possible for you to try TGTD with the COMPARE_AND_WRITE
patch and see if VMWare vSphere is happy ?
If it is not happy it should fail almost immediately.

That would be great since I dont have access to vSphere myself.


regards
ronnie sahlberg



On Mon, Oct 15, 2012 at 10:25 AM, Yaron Sheffer <yaronf@xxxxxxxxxxxx> wrote:
> Hi,
>
> We are using tgt with VMware vSphere as the initiator. We run tgt on Ubuntu
> Lucid, and everything works fine until there are several of our target
> machines with one initiator. Then the initiator starts ignoring some of the
> targets. It turns out that vSphere requires a value called "t10 ID" to be
> unique for each LUN, even across multiple hosts. This value appears to be
> identical to the "SCSI ID" parameter displayed by tgtadm.
>
> * Is this a legitimate requirement? I have always thought that only the
> target name needs to be globally unique.
>
> Trying to work around the issue, we attempted to set the SCSI ID parameter
> for the LUN using this command: tgtadm --mode logicalunit --op update --tid
> $tid --lun $lun --params scsi_id="my id"
>
>
> * This syntax is undocumented. Can you please add it to the man page? Or can
> I provide such a patch?
>
> * More important: although the parameter was set correctly according to
> tgtadm, vSphere reported the same "IET___..." value as before. This could be
> a problem in tgtadm or a problem on the initiator's side. Or else a
> misunderstanding on our part...
>
>
> Finally we just randomized the target ID value, which causes tgtadm to
> generate a somewhat randomized SCSI ID, and makes VMware happy. We also
> patched tgt-admin to dump the tid value and accept it back in its "execute"
> mode. I will gladly share this patch, but I suspect that it is the wrong
> thing to do from an architectural POV. Any opinions?
>
>
> Thanks,
>
>     Yaron
>
>
> --
>
> *Yaron Sheffer*|Co-Founder and CTO, *Porticor Cloud Security*| T:+972 73
> 7294673 <tel:+972-73-7294673> | M:+972 52 8698984 <tel:+972-52-8698984> |
> yaronf@xxxxxxxxxxxx <mailto:yaronf@xxxxxxxxxxxx> |www.porticor.com
> <http://www.porticor.com/>
>
>
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux