Bug 860719

This is default multipath behaviour and has nothing to do with vdsm.
In addition, I don't think it's a bug, but I'll leave that up to the multipath team.

Multipath uses a callout program, getuid_callout, to figure you which paths belong to which multipath devices.  All paths with the same response from getuid_callout will be part of the same multipath device. For scsi devices, this defaults to

"/lib/udev/scsi_id --whitelisted --device=/dev/%n"

Is there a reason that you switched to the deprecated RHEL 5 scsi_id options?

Two seperate LUNs should never have the same scsi_id.  This has the potential to cause problems beyond multipath.  You could change your getuid callout to
something else to make multipath build the devices differently.  The getuid_callout program just needs to return a string to be used as the WWID.  But
like I said, even if you do make this work for multipath, this may still cause problems for other programs that expect the scsi_ids to be unique.

(In reply to comment #2)
> This is default multipath behaviour and has nothing to do with vdsm.
> In addition, I don't think it's a bug, but I'll leave that up to the
> multipath team.

From the code I would say vdsm configures /etc/multipath.conf

/usr/lib64/python2.6/site-packages/vdsm/constants.py:
STRG_MPATH_CONF = """

defaults {
    polling_interval        5
    getuid_callout          "/sbin/scsi_id -g -u -d /dev/%n"
    no_path_retry           fail
    user_friendly_names     no
    flush_on_last_del       yes
    fast_io_fail_tmo        5
    dev_loss_tmo            30
    max_fds                 4096
}
"""

/usr/share/vdsm/storage/multipath.py:
MPATH_CONF = "/etc/multipath.conf"
MPATH_CONF_PRIVATE_TAG = "# RHEV PRIVATE"
MPATH_CONF_TEMPLATE = MPATH_CONF_TAG + constants.STRG_MPATH_CONF

def setupMultipath():
    """
    Set up the multipath daemon configuration to the known and
    supported state. The original configuration, if any, is saved
    """
    if os.path.exists(MPATH_CONF):
        misc.rotateFiles(os.path.dirname(MPATH_CONF), os.path.basename(MPATH_CONF), MAX_CONF_COPIES, cp=True, persist=True)
    f = tempfile.NamedTemporaryFile()
    f.write(MPATH_CONF_TEMPLATE)
    f.flush()
    cmd = [constants.EXT_CP, f.name, MPATH_CONF]
    ...

Based on code above vdsm is the one who defines getuid_callout for determining paths for multipath devices.

Ayal, could you confirm that vdsm cannot change STRG_MPATH_CONF to obtain uniquer name (based on more info than just scsi_id) for getuid_callout?

(In reply to comment #4)
> (In reply to comment #2)
> > This is default multipath behaviour and has nothing to do with vdsm.
> > In addition, I don't think it's a bug, but I'll leave that up to the
> > multipath team.
> 
> From the code I would say vdsm configures /etc/multipath.conf
> 
> /usr/lib64/python2.6/site-packages/vdsm/constants.py:
> STRG_MPATH_CONF = """
> 
> defaults {
>     polling_interval        5
>     getuid_callout          "/sbin/scsi_id -g -u -d /dev/%n"
>     no_path_retry           fail
>     user_friendly_names     no
>     flush_on_last_del       yes
>     fast_io_fail_tmo        5
>     dev_loss_tmo            30
>     max_fds                 4096
> }
> """
> 
> /usr/share/vdsm/storage/multipath.py:
> MPATH_CONF = "/etc/multipath.conf"
> MPATH_CONF_PRIVATE_TAG = "# RHEV PRIVATE"
> MPATH_CONF_TEMPLATE = MPATH_CONF_TAG + constants.STRG_MPATH_CONF
> 
> def setupMultipath():
>     """
>     Set up the multipath daemon configuration to the known and
>     supported state. The original configuration, if any, is saved
>     """
>     if os.path.exists(MPATH_CONF):
>         misc.rotateFiles(os.path.dirname(MPATH_CONF),
> os.path.basename(MPATH_CONF), MAX_CONF_COPIES, cp=True, persist=True)
>     f = tempfile.NamedTemporaryFile()
>     f.write(MPATH_CONF_TEMPLATE)
>     f.flush()
>     cmd = [constants.EXT_CP, f.name, MPATH_CONF]
>     ...
> 
> Based on code above vdsm is the one who defines getuid_callout for
> determining paths for multipath devices.
> 
> Ayal, could you confirm that vdsm cannot change STRG_MPATH_CONF to obtain
> uniquer name (based on more info than just scsi_id) for getuid_callout?

if we can define something that is generally unique and works for most types of storage arrays etc then we probably could (although this would be seriously problematic with backward compatibility), but that is the purpose of the default callout.