Bug 1353713 - [RFE] - Hosted Engine: iSCSI Setup Should use different User/Password For Discovery and Portal
Summary: [RFE] - Hosted Engine: iSCSI Setup Should use different User/Password For Dis...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: Plugins.Block
Version: 2.0.0.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ovirt-4.2.1
: 2.2.6
Assignee: Simone Tiraboschi
QA Contact: Nikolai Sednev
URL:
Whiteboard:
: 1532864 (view as bug list)
Depends On: 1455169
Blocks: 1458709 1474209
TreeView+ depends on / blocked
 
Reported: 2016-07-07 19:30 UTC by Ariel
Modified: 2018-05-17 13:09 UTC (History)
10 users (show)

Fixed In Version: ovirt-hosted-engine-setup-2.2.6
Clone Of:
Environment:
Last Closed: 2018-02-12 11:54:50 UTC
oVirt Team: Integration
Embargoed:
rule-engine: ovirt-4.2?
nsednev: testing_plan_complete+
rule-engine: planning_ack?
sbonazzo: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 86262 0 master MERGED ansible: use different password for iscsi discovery and portal 2020-12-18 09:20:41 UTC
oVirt gerrit 86358 0 ovirt-4.2 MERGED wizard: Add iSCSI discovery username/pwd fields 2020-12-18 09:21:11 UTC

Description Ariel 2016-07-07 19:30:37 UTC
Description of problem:
I cannot install oVirt 4.0 hosted engine on iSCSI where the target server does
not require discovery user/password or its user/password is different than the
session's.

I have a storage server where I don't need to specify user and password for
discovery, basically this would work right away:

	# iscsiadm -m discovery --type sendtargets --portal 192.168.49.4:3260

And then I can mount my block device normally:

	# iscsiadm -m node --targetname "iqn.2015-10.kebonjati.procyon:san.ovirthesan1" --portal 192.168.49.4:3260 --op update --name node.session.auth.authmethod --value CHAP
	# iscsiadm -m node --targetname "iqn.2015-10.kebonjati.procyon:san.ovirthesan1" --portal 192.168.49.4:3260 --op update --name node.session.auth.username --value ovirtheuser
	# iscsiadm -m node --targetname "iqn.2015-10.kebonjati.procyon:san.ovirthesan1" --portal 192.168.49.4:3260 --op update --name node.session.auth.password --value ovirthepassword
	# iscsiadm -m node --targetname "iqn.2015-10.kebonjati.procyon:san.ovirthesan1" --portal 192.168.49.4:3260 --login
	Logging in to [iface: default, target: iqn.2015-10.kebonjati.procyon:san.ovirthesan1, portal: 192.168.49.4,3260] (multiple)
	Login to [iface: default, target: iqn.2015-10.kebonjati.procyon:san.ovirthesan1, portal: 192.168.49.4,3260] successful.
	
	# lsblk
	NAME                                MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
	sda                                   8:0    0 74.5G  0 disk
	+-sda1                                8:1    0  200M  0 part  /boot/efi
	+-sda2                                8:2    0  500M  0 part  /boot
	+-sda3                                8:3    0   52G  0 part
	  +-vgvmhost1-lvsystem              253:0    0   48G  0 lvm   /
	  +-vgvmhost1-lvswap                253:1    0    4G  0 lvm   [SWAP]
	sdb                                   8:16   0   20G  0 disk
	+-36001405505f200138f248c1a9682fcec 253:2    0   20G  0 mpath


But when I run oVirt's "hosted-engine --deploy", I get this error:

    ..

	[ ERROR ] Failed discovery of iSCSI targets: "portal=IscsiPortal(hostname=u'192.168.49.4', port=3260), err=(24, [], ['iscsiadm: Login failed to authenticate with target ', 'iscsiadm: discovery login to 192.168.49.4 rejected: initiator failed authorization', '', 'iscsiadm: Could not perform SendTargets discovery: iSCSI login failed due to authorization failure'])"

It seems according to the source code:

	ovirt-hosted-engine-setup-79f4cbf/src/plugins/gr-he-setup/storage/blockd.py:586
	https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-setup.git;a=blob;f=src/plugins/gr-he-setup/storage/blockd.py;h=f5b50b1172c908f8303c6859d76e0187fab2b0a2;hb=79f4cbfe7ca64f56afac536812d6ea9241a0ab46#l586

it uses discovery credential that queried (to the user) as portal's user &
password. This causes problem because the two credentials is different and
should be treated as such.

While vdsm does allow user not to provide credential:

	vdsm-98fb604/vdsm/storage/hsm.py:2924
	https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/storage/hsm.py;h=359b2b3380a4ff63d0a47ebf3950e1261b28bac5;hb=98fb6046ceb8e018a3e8937b902a83f4e36629fb#l2924

but this also means that there is no session password. Which is in my setup is
problematic because while I do not have discovery user/password but I do have
session password:

	  o- iscsi .............................................................................[Targets: 2]
	  | o- iqn.2015-10.kebonjati.procyon:san.ovirthesan1 ......................................[TPGs: 1]
	  | | o- tpg1 ...........................................................[no-gen-acls, auth per-acl]
	  | |   o- acls ...........................................................................[ACLs: 2]
	  | |   | o- iqn.1991-05.com.microsoft:locke.ariel.kebonjati ...........[1-way auth, Mapped LUNs: 1]
	  | |   | | o- mapped_lun0 ...............................................[lun0 block/dev-dm-3 (rw)]
	  | |   | o- iqn.1994-05.com.redhat:cde9733b4660 .......................[1-way auth, Mapped LUNs: 1]
	  | |   |   o- mapped_lun0 ...............................................[lun0 block/dev-dm-3 (rw)]
	  | |   o- luns ...........................................................................[LUNs: 1]
	  | |   | o- lun0 ......................................................[block/dev-dm-3 (/dev/dm-3)]
	  | |   o- portals .....................................................................[Portals: 6]
	  | |     o- 192.168.49.4:3260 .................................................................[OK]


My search on problem like this on oVirt gives me this bug report:

	https://bugzilla.redhat.com/show_bug.cgi?id=1256024


Version-Release number of selected component (if applicable):

	# yum list installed | grep ovirt-hosted
	ovirt-hosted-engine-ha.noarch      2.0.0-1.el7.centos       @ovirt-4.0
	ovirt-hosted-engine-setup.noarch   2.0.0.2-1.el7.centos     @ovirt-4.0

	# yum list installed | grep vdsm
	vdsm.x86_64                        4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-api.noarch                    4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-cli.noarch                    4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-hook-vmfex-dev.noarch         4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-infra.noarch                  4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-jsonrpc.noarch                4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-python.noarch                 4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-xmlrpc.noarch                 4.18.4.1-0.el7.centos    @ovirt-4.0
	vdsm-yajsonrpc.noarch              4.18.4.1-0.el7.centos    @ovirt-4.0

	# uname -a
	Linux ovirthost1.ovirtlab.kebonjati 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

	# cat /etc/redhat-release
	CentOS Linux release 7.2.1511 (Core)

How reproducible:
	100%

Steps to Reproduce:
	1. On target server run "/iscsi set discovery_auth enable=False" while set
	   password on target/portal using targetcli.
	2. install CentOS 7.2.1511 on hypervisor host
	3. yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm
	4. yum -y install ovirt-hosted-engine-setup
	5. hosted-engine --deploy
	6. use iscsi storage


Actual results:

	[ ERROR ] Failed discovery of iSCSI targets: "portal=IscsiPortal(hostname=u'192.168.49.4', port=3260), err=(24, [], ['iscsiadm: Login failed to authenticate with target ', 'iscsiadm: discovery login to 192.168.49.4 rejected: initiator failed authorization', '', 'iscsiadm: Could not perform SendTargets discovery: iSCSI login failed due to authorization failure'])"

Expected results:
	No error, and I can install hosted engine.

Additional info:
	As a workaround, for now I enable authentication on discovery with also the
	exact user and password for *all* targets.

Comment 1 Nir Soffer 2016-07-07 19:53:55 UTC
Simone, in engine, you can use separate password for discovery and for login. The 
ui is clumsy, but you set a password for discovery, discover the targets, and
then change the password before clicking login.

hosted engine setup should provide both discovery password and login password.
each can be missing.

Comment 2 Simone Tiraboschi 2016-07-07 20:37:40 UTC
Ok, thanks.
We have to fix where we ask it, where we save in hosted-engine.conf and where we consume it from the agent and check also the auto-import procedure from the engine.

Comment 3 Коренберг Марк 2017-03-10 18:42:41 UTC
In order to workaround, you should type the following commands in targetcli:

/iscsi> set discovery_auth enable=1
/iscsi> set discovery_auth userid=<.....>
/iscsi> set discovery_auth password=<.....>

Comment 4 Simone Tiraboschi 2018-01-11 22:57:16 UTC
*** Bug 1532864 has been marked as a duplicate of this bug. ***

Comment 5 Nikolai Sednev 2018-01-22 16:04:42 UTC
Works for me just fine on these components:
ovirt-hosted-engine-setup-2.2.7-0.0.master.20180119084226.git3799ea2.el7.centos.noarch
ovirt-hosted-engine-ha-2.2.5-0.0.master.20180117160214.20180117160210.gitd5b58a8.el7.centos.noarch
ovirt-engine-appliance-4.2-20180121.1.el7.centos.noarch

Moving to verified.

[ INFO  ] changed: [localhost]
          Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs)[nfs]: iscsi
          Please specify the iSCSI portal IP address: <IP address here>
          Please specify the iSCSI portal port [3260]: 
          Please specify the iSCSI discover user: 
          Please specify the iSCSI discover password: 
          Please specify the iSCSI portal login user: 
          Please specify the iSCSI portal login password: 
[ INFO  ] Discovering iSCSI targets

Comment 6 Sandro Bonazzola 2018-02-12 11:54:50 UTC
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE.

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


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