Another problem with vmware and other environments is that if multipathing is used and a single connection of a multipathed device is dropped and re-established, if the disk disk serial numbers have changed during that time, then the system will see it as a new device with the same logical volume signatures causing all sorts of new problems, like rejecting the volume because of multiple volumes showing up with different underlying disk signatures.
I think there is a reference to the current case: http://comments.gmane.org/gmane.linux.iscsi.iscsi-target.devel/1649 and when I did HCT tests myself I encountered the same results.
I agree that it should be fixed with backwards compability in mind.

From: Ross S. W. Walker [mailto:RWalker@medallion.com]
Sent: Thursday, January 26, 2012 7:15 PM
To: Ross S. W. Walker
Cc: iscsitarget-devel@lists.sourceforge.net
Subject: Re: [Iscsitarget-devel] scsi_id/scsi_sn and vpd 83 type 8h

On Jan 26, 2012, at 6:43 PM, "Ross S. W. Walker" <RWalker@medallion.com> wrote:

On Jan 26, 2012, at 5:42 PM, "Oliver R." <iscsi-target@solar-imperium.com> wrote:

> Huuhhhhhhhh
> I can only support what Chris is saying. Please do not change the
> existing scsi_sn/scsi_id
> behaviour when these values are set manually. Not even in a 1.5 branch.
> I don't even want to imagine what happens to ESX/ESXi environments when
> they get
> new identifications for existing targets/LUNs. I think a total datastore
> mess would be the
> the case. Not something a vSphere admin would like to see in it's
> environment.

The SCSI ID and SN are read each time the ESX/Windows host starts and are only used during the lifetime of the volume connection. If you log off the target, remove the volume or shutdown the host, change the ID and/or SN and reconnect, re-add or startup the host the volume will still appear correctly.

The only stipulation is the the SN and ID be unique throughout the organization and that they aren't changed while the volume is connected.

Sorry I stand corrected having re-read the VMware doc on VMFS.

The SN is important for VMware as it's used in the disk signature and compared each time the volume is mounted.

Ok, how about this then, ignore scsi_id with a notice in the log, continue accepting scsi_sn and presenting as-is. If no scsi_sn is given then use the same MD5 auto-generated SN as we do now.

The SCSI ID will be as recommended in the spec which is the VENDOR_ID + PRODUCT_ID + PRODUCT_SN and the 8h version will the the 64-bit hex number of the 1h (VENDOR_ID + PRODUCT_ID + PRODUCT_SN).


This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.