Bug 860719 - [vdsm] Same scsi id from different storages leads to fault tolerant multipath
[vdsm] Same scsi id from different storages leads to fault tolerant multipath
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
6.3
x86_64 Linux
unspecified Severity urgent
: rc
: ---
Assigned To: Ben Marzinski
Red Hat Kernel QE team
storage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-26 10:49 EDT by Jakub Libosvar
Modified: 2012-10-03 09:40 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-01 11:42:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vdsm.log (85.14 KB, text/x-log)
2012-09-26 10:49 EDT, Jakub Libosvar
no flags Details

  None (edit)
Description Jakub Libosvar 2012-09-26 10:49:44 EDT
Created attachment 617594 [details]
vdsm.log

Description of problem:
There are two storage servers, configured different iqn, vendor, scsi sn but with same scsi id. When host logs into targets on both hosts, connected lun is in fault tolerant multipath.

multipath:
1pstehlik dm-12 RH-str01,VIRTUAL-DISK
size=20G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 5:0:0:3  sdk 8:160 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 6:0:0:1  sdl 8:176 active ready running

iscsi sessions:
[sid: 3, target: iqn.2011-01.brq.str-01:pstehlik, portal: 10.34.63.202,3260]
[sid: 4, target: iqn.2011-01.brq.str-02:pstehlik, portal: 10.34.63.204,3260]

multipath.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
}

[root@slot-5 ~]# /sbin/scsi_id -g -u -d /dev/sdd
1pstehlik
[root@slot-5 ~]# /sbin/scsi_id -g -u -d /dev/sde
1pstehlik


Version-Release number of selected component (if applicable):
vdsm-4.9.6-34.0.el6_3.x86_64
device-mapper-1.02.74-10.el6.x86_64
device-mapper-multipath-0.4.9-56.el6.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Have two storage servers
2. On each server configure lun with the same scsi id
3. Connect host to both targets
  
Actual results:
Fault tolerant multipath

Expected results:
Two different paths to destination luns
Comment 2 Ayal Baron 2012-09-26 17:25:26 EDT
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.
Comment 3 Ben Marzinski 2012-10-01 11:42:44 EDT
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.
Comment 4 Jakub Libosvar 2012-10-03 06:37:41 EDT
(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?
Comment 5 Ayal Baron 2012-10-03 09:40:51 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.