Bug 964768 - Add second LUN for already connected target need manually run multipath reload
Summary: Add second LUN for already connected target need manually run multipath reload
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.2.0
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: 3.3.0
Assignee: Yeela Kaplan
QA Contact: Katarzyna Jachim
URL:
Whiteboard: storage
: 967300 (view as bug list)
Depends On:
Blocks: 1019461
TreeView+ depends on / blocked
 
Reported: 2013-05-19 18:31 UTC by Meni Yakove
Modified: 2018-12-04 15:24 UTC (History)
12 users (show)

Fixed In Version: is9
Doc Type: Bug Fix
Doc Text:
VDSM now uses the reload option for multipath rescan in order to view a new LUN that was added to an already connected target.
Clone Of:
Environment:
Last Closed: 2014-01-21 16:07:30 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:
scohen: Triaged+


Attachments (Terms of Use)
vdsm.log (812.16 KB, application/x-zip-compressed)
2013-05-19 18:33 UTC, Meni Yakove
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0040 0 normal SHIPPED_LIVE vdsm bug fix and enhancement update 2014-01-21 20:26:21 UTC
oVirt gerrit 17263 0 None None None Never

Description Meni Yakove 2013-05-19 18:31:38 UTC
Description of problem:
For adding LUN when we have already connected target we need to run multipath -r in order to see the new LUN.

Version-Release number of selected component (if applicable):
vdsm-4.10.2-19.0.el6ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Create LUN on the storage server and add the storage to RHEVM.
2.On the same storage server create another LUN.
3.Try to add the new LUN to the same host.
  
Actual results:
Can't add the new LUN, only after run multipath -r on the VDSM the LUN can be added.

Expected results:
LUN should be added without run multipath -r.

Comment 1 Meni Yakove 2013-05-19 18:33:30 UTC
Created attachment 750179 [details]
vdsm.log

Comment 2 Haim 2013-05-20 11:20:28 UTC
problem with getDeviceList using multipath and not multipath -r

Comment 3 Yeela Kaplan 2013-07-23 16:11:04 UTC
There are two bugs here.

The first is vdsm not reloading multipath in multipath.rescan.

The second is engine sending 'getDeviceList' to all hosts and as you can see the device '3514f0c542a001658' is not returned:

Thread-28::INFO::2013-05-19 17:39:47,862::logUtils::42::dispatcher::(wrapper) Run and protect: getDeviceList, Return response: {'devList': [{'status': 'free', 'vendorID': 'XtremIO', 'capacity': '75161927680', 'fwrev': '1.05', 'vgUUID': '', 'pathlist': [{'initiatorname': 'default', 'connection': '10.35.160.7', 'iqn': 'iqn.2008-05.com.xtremio:001e675b8ee0', 'portal': '1', 'password': '******', 'port': '3260'}], 'logicalblocksize': '512', 'pathstatus': [{'physdev': 'sdb', 'type': 'iSCSI', 'state': 'active', 'lun': '0'}], 'devtype': 'iSCSI', 'physicalblocksize': '4096', 'pvUUID': '2fsovp-0Zqf-8JBP-cvKD-AM0i-Hwan-4GKCr0', 'serial': 'SXtremIO_XtremApp_027a351e8d85473a8e93750da19ad531', 'GUID': '3514f0c542a001657', 'productID': 'XtremApp'}, {'status': 'free', 'vendorID': 'XtremIO', 'capacity': '75161927680', 'fwrev': '1.05', 'vgUUID': '', 'pathlist': [{'initiatorname': 'default', 'connection': '10.35.160.7', 'iqn': 'iqn.2008-05.com.xtremio:001e675b8ee0', 'portal': '1', 'password': '******', 'port': '3260'}], 'logicalblocksize': '512', 'pathstatus': [{'physdev': 'sdc', 'type': 'iSCSI', 'state': 'active', 'lun': '1'}], 'devtype': 'iSCSI', 'physicalblocksize': '4096', 'pvUUID': '', 'serial': 'SXtremIO_XtremApp_10aa3b0e4fce451bb0995f90a13e8a95', 'GUID': '3514f0c542a00160e', 'productID': 'XtremApp'}]}


and then engine sends 'createVG' with a device that did not appear on the list returned '3514f0c542a001658' and fails because the device is not visible, which is an issue that we should deal with separately:

Thread-32::INFO::2013-05-19 17:39:48,190::logUtils::40::dispatcher::(wrapper) Run and protect: createVG(vgname='20b9db4d-68ac-4a77-bd0b-153385ba3bcc', devlist=['3514f0c542a001658'], force=False, options=None)
Thread-32::ERROR::2013-05-19 17:39:48,192::task::850::TaskManager.Task::(_setError) Task=`eeacb380-8aec-4c25-9f0f-5819b68ce965`::Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 857, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/logUtils.py", line 41, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/storage/hsm.py", line 1977, in createVG
    raise se.InvalidPhysDev(dev)
InvalidPhysDev: Invalid physical device: ('3514f0c542a001658',)

Comment 4 Katarzyna Jachim 2013-08-13 11:25:49 UTC
verified on is9.1

Comment 5 Sergey Gotliv 2013-11-10 13:39:23 UTC
*** Bug 967300 has been marked as a duplicate of this bug. ***

Comment 6 Charlie 2013-11-28 00:32:04 UTC
This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 7 errata-xmlrpc 2014-01-21 16:07:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0040.html


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