Previously, creation of iSCSI storage domains caused VDSM to throw an error during the login to target command. This was because the Red Hat Enterprise Virtualization Manager REST API set the portal field to the wrong value. This issue presented only in VDSM-4.9.6-17.0.el6.x86_64. A patch to VDSM removes a conversion to int of the iSCSI portal parameter for two reasons: the parameter is not used in VDSM, and removing this avoids regressions. In new versions, the engine sends 0.
Creating iSCSI storage domains no longer causes VDSM to throw errors during the login to target command.
Description of problem:
When I'm trying to create ISCSI storage domain on rhevm3.0 with vdsm-4.9.6-17.0.el6.x86_64 I'm encountering an error during login to target command . When I'm looking at vdsm logs i see the following error: "ValueError: invalid literal for int() with base 10: 'shafan.eng.lab.tlv.redhat.com' "
Apparently RHEVM Rest API set wrong value to portal field ( same value as storage server )
After downgrading vdsm version on the hosts from vdsm-4.9.6-17.0.el6.x86_64 to vdsm-4.9-113.1.el6.x86_64 the problem disappear.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Thread-40::INFO::2012-07-05 00:43:54,964::logUtils::37::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=3, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'shafan.eng.lab.tlv.redhat.com', 'iqn': 'iqn.2011-10.com.redhat:iscsi-test6', 'portal': 'shafan.eng.lab.tlv.redhat.com', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': '3260'}], options=None)
Thread-40::ERROR::2012-07-05 00:43:54,964::task::853::TaskManager.Task::(_setError) Task=`b6154a2d-beaa-45be-8415-934d7c6c9cdc`::Unexpected error
Traceback (most recent call last):
File "/usr/share/vdsm/storage/task.py", line 861, in _run
return fn(*args, **kargs)
File "/usr/share/vdsm/logUtils.py", line 38, in wrapper
res = f(*args, **kwargs)
File "/usr/share/vdsm/storage/hsm.py", line 1899, in connectStorageServer
conInfo = _connectionDict2ConnectionInfo(domType, conDef)
File "/usr/share/vdsm/storage/hsm.py", line 166, in _connectionDict2ConnectionInfo
tpgt = int(tpgt)
ValueError: invalid literal for int() with base 10: 'shafan.eng.lab.tlv.redhat.com'
# login command from Rest API:
2012-07-04 16:27:25,115 - MainThread - storagedomains - DEBUG - Response code is valid: [200, 201]
2012-07-04 16:27:25,120 - MainThread - storagedomains - DEBUG - Action request content is -- url:http://localhost:8080/api/hosts/fc8d56fa-c5da-11e1-a5b2-001a4a231251/iscsilogin body:<action><async>false</async><grace_period><expiry>10</expiry><absolute>false</absolute></grace_period><iscsi><address>shafan</address><target>iqn.2011-06.com.redhat:ci-iscsi-test</target></iscsi></action>
2012-07-04 16:27:25,290 - MainThread - storagedomains - DEBUG - Response body for action request is: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<action>
<async>false</async>
<grace_period>
<expiry>10</expiry>
</grace_period>
<iscsi>
<address>shafan</address>
<target>iqn.2011-06.com.redhat:ci-iscsi-test</target>
</iscsi>
<status>
<state>failed</state>
</status>
<fault>
<reason>Operation Failed</reason>
<detail>[]</detail>
</fault>
</action>
This is not a but, someone sent a string in the portal field (which is actually tpgt)
Engine internally never does this and sending this is wrong anyway.
The real issue is that the parameter name has been confusing all this time until I decided to fix it.
This is not a bug, the bug was that it worked in the first place.
Verified as working with this xml request:
<test_case>
<test_name>Create Data Storage Domain iSCSI</test_name>
<test_action>addStorageDomain</test_action> <parameters>name='ISCSIDataDomain',type='e{storage_dom_type_data}',storage_type='e{storage_type_iscsi}',host='{vds[0]}',lun='{lun}',lun_address='{lun_address}',lun_target='{lun_target}',lun_port=3260,portal="some_portal"</parameters>
<positive>TRUE</positive>
</test_case>
using:
rhevm-3.0.7_0001-2.el6_3.x86_64
vdsm-4.9.6-29.0.el6_3.x86_64
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/RHSA-2012-1508.html