We are aware of this issue and are moving as fast as possible to correct it. Please be patient. Also can you test when creating a target to set the LUN's to 1 or 2 or 3.... but not to LUN 0. Concerning the FC we are working on this as well. On next release we are racing to have both of these issues resolved, it may be earlier if we complete the tests fast enough with confirmation with some of our dedicated customers.
There is a thread going on the VMware forums where someone else is running into having to keep the LUN numbers globally unique with Open-E. There are a few responses there pointing back to the iSCSI Enterprise Target mailing list
which points towards a possible config in iSCSI Enterprise Target (which I believe is the base open source package for Open-E) where the SCSI_SN needs to be unique per target/volume or else the LUN# itself needs to be kept globally unique. So a question would be is in Open-E iSCSI are all the SCSI_SNs set to the same value (or not set at all) or are they unique per target/volume (i.e. the "equivalent" of a SCSI disk once presented to the OS)?
ESX recognizes newly created disks after writing a disk signature
Hello Craig
I had the same problem and tried the work-around with the LUN ID, but with no success. Then I mapped the target with the newly created columes to a windows machine (instead of ESX) and opened the disk management for writing a disk signature.
After the disk signature was written, ESX was able to map the drives. Don't ask my why ESX cannot read new volumes, but it works...
Administrator
ESX recognizes newly created disks after writing a disk signature
Posting Permissions
Reply With Quote