SVC SCSI id assignement

Current way of SVC SCSI id handling in case of multiple I/O groups could cause problem with Clustered Hosts (like VMware)

The problem is that an SVC with multiple IO Groups could present a LUN with different SCSI id to the members of an ESX cluster. This could cause problem because for example...

example 1.
The change on the SCSI ID should matter, as long as the same storage disk_UID (naa, eui, vml) are presented to the ESXi hosts with all the same SCSI ID.
For example naa.600123000000015 LUN are presented to all ESXi hosts as SCSI id 1, then this should be consistent. if this is not consistent for example if its presented to host1 as SCSI id 1 but on host2 its SCSI id 2, then this will break vMotion. vMotion requires all the host to mount the same LUN, by the same manner.

example 2.
In case of Non Disruptive Volume, Move may leave the same Volume mapped to different hosts in the same host cluster using different
SCSI IDs. From a GUI initiated I/O Group change VMware drops the VMFS datastore because of SCSI id. change                                

This a vmware publication about SCSI id regulation:
http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-storage-guide.pdf on page 52

As a workaround there are methods to solve this issue, but there are cases when these can't be used. For example:

Mapping a LUN to all iogroups could easily hit the path limits of VMware. The creation of single host object will not help, as mappings are enumerated based on the following format host:iogroup:ID.