Bug 851050 - [vdsm] Failure in iscsiadm update node command during discoverSendTargets on attempt to modify node.startup
Summary: [vdsm] Failure in iscsiadm update node command during discoverSendTargets on ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.2.0
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
: 3.3.0
Assignee: Sergey Gotliv
QA Contact: Aharon Canan
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-23 07:22 UTC by Gadi Ickowicz
Modified: 2016-02-10 19:18 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-07 07:34:35 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:
scohen: Triaged+


Attachments (Terms of Use)
vdsm logs (1.71 MB, application/x-bzip)
2012-08-23 07:22 UTC, Gadi Ickowicz
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 17212 0 None None None Never

Description Gadi Ickowicz 2012-08-23 07:22:58 UTC
Created attachment 606463 [details]
vdsm logs

Description of problem:
When requesting discoverSendTargets, vdsm performs 
/usr/bin/sudo -n /sbin/iscsiadm -m discoverydb -t sendtargets -I default -p 10.35.16.27:3260 -n node.startup -v manual --op=update

this fails every time with: FAILED: <err> = 'iscsiadm: Cannot modify node.startup. Invalid param name.\n'; <rc> = 7

This does not interrupt the process, and it continues on to discover.

manually running the command also produces the same result:
[root@cougar04 ~]# /usr/bin/sudo -n /sbin/iscsiadm -m discoverydb -t sendtargets -I default -p 10.35.16.27:3260 --op=new
New discovery record for [10.35.16.27,3260] added.
[root@cougar04 ~]# /usr/bin/sudo -n /sbin/iscsiadm -m discoverydb -t sendtargets -I default -p 10.35.16.27:3260 -n node.startup -v manual --op=update
iscsiadm: Cannot modify node.startup. Invalid param name.
[root@cougar04 ~]# echo $?
7
[root@cougar04 ~]# ls -ltr /var/lib/iscsi/nodes/
total 12
drw-------. 2 root root 4096 Aug 21 14:00 iqn.2008-05.com.xtremio:001b21b545c0
drw-------. 2 root root 4096 Aug 22 14:38 iqn.1986-03.com.sun:02:gadi-rhevm2012081395810878617
drw-------. 2 root root 4096 Aug 22 14:41 iqn.1986-03.com.sun:02:gadi-rhevm201208139582110787

contents of /var/lib/iscsi/send_targets:
[root@cougar04 10.35.16.27,3260]# for i in `ls /var/lib/iscsi/send_targets/`; do cat /var/lib/iscsi/send_targets/$i/*; done
# BEGIN RECORD 2.0-872.41.el6
discovery.startup = manual
discovery.type = sendtargets
discovery.sendtargets.address = 10.35.16.27
discovery.sendtargets.port = 3260
discovery.sendtargets.auth.authmethod = None
discovery.sendtargets.timeo.login_timeout = 15
discovery.sendtargets.use_discoveryd = No
discovery.sendtargets.discoveryd_poll_inval = 30
discovery.sendtargets.reopen_max = 5
discovery.sendtargets.timeo.auth_timeout = 45
discovery.sendtargets.timeo.active_timeout = 30
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768
# END RECORD





Version-Release number of selected component (if applicable):
vdsm-4.9.6-29.0.el6_3.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Perform discoverSendTargets on a host. check logs

Comment 2 Ayal Baron 2012-08-26 08:13:20 UTC
This is mostly a logging issue as we ignore the error and the default value is manual anyway, but fix seems very simple.
Need to change iscsi.py line 158 to:
iscsiadm.node_update(iface.name, portalStr, targetName, "node.startup", "manual")

Comment 3 RHEL Program Management 2012-12-14 06:47:13 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 4 Petr Spacek 2013-06-13 11:01:11 UTC
The problem is still present in vdsm-4.10.2-22.0.el6ev.x86_64 , RHEL 6.4 hypervisor with latest updates (2013-06-13).

Comment 5 Sergey Gotliv 2013-07-22 13:29:53 UTC
Iscsiadm operational mode must be 'node' while updating 'node.startup'
setting and not 'discoverydb' as it is today.


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