Bug 860719
Summary: | [vdsm] Same scsi id from different storages leads to fault tolerant multipath | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jakub Libosvar <jlibosva> | ||||
Component: | device-mapper-multipath | Assignee: | Ben Marzinski <bmarzins> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.3 | CC: | abaron, agk, bazulay, bmarzins, dwysocha, dyasny, heinzm, iheim, lpeer, lzoubek, msnitzer, prajnoha, prockai, ykaul, zkabelac | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | storage | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-10-01 15:42:44 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
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. |
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