Hello Nab,
> > | | o- lun1 ......................................... [/dev/md126 (1.8TiB) write-thru activated]
> > o- qla2xxx ........................................................................ [Targets: 2]
> > | o- naa.210000e08b885aa6 ........................................................... [gen-acls]
> > | | o- acls .......................................................................... [ACLs: 1]
> > | | | o- naa.2100001b322f021a ................................................. [Mapped LUNs: 1]
> > | | | o- mapped_lun0 .................................................. [lun0 block/lun1 (rw)]
> > | | o- luns .......................................................................... [LUNs: 1]
> > | | o- lun0 ........................................................ [block/lun1 (/dev/md126)]
> > | o- naa.210100e08ba85aa6 ........................................................... [gen-acls]
> > | o- acls .......................................................................... [ACLs: 1]
> > | | o- naa.2100001b320f021a ................................................. [Mapped LUNs: 1]
> > | | o- mapped_lun0 .................................................. [lun0 block/lun1 (rw)]
> > | o- luns .......................................................................... [LUNs: 1]
> > | o- lun0 ........................................................ [block/lun1 (/dev/md126)]
looking at the configuration it looks like that the same LUN is exported
using _two_ different naa. The problem here is that VMware stores a
checksum of the inquiry data on the VMFS and ignores a path to a volume
if the SCSI inquiry data do _not_ match. Why? Because it could be a two
week old snapshot and using it a as a multipathing target would be
fatal.
I assume that is the problem.
Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
