Bug 1173681

Summary: iSCSI authentication fails when attaching volume to VM that boots from ISO
Product: Red Hat OpenStack Reporter: Marius Cornea <mcornea>
Component: openstack-cinderAssignee: Eric Harney <eharney>
Status: CLOSED DUPLICATE QA Contact: nlevinki <nlevinki>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.0 (RHEL 7)CC: eharney, mcornea, scohen, sgotliv, yeylon
Target Milestone: ---   
Target Release: 6.0 (Juno)   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-08 14:23:15 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:
Description Flags
Nova and cinder logs none

Description Marius Cornea 2014-12-12 16:20:52 UTC
Created attachment 967717 [details]

Description of problem:

Volume cannot be attached to instance that's booted from an ISO image. CHAP credentials of the initiator do not match to the ones set on the target. 

Version-Release number of selected component (if applicable):
Openstack 5.0
Cinder 2014.1.3

How reproducible:
Upload a RHEL-7 Server ISO image, create an instance that boots from the ISO image, create a new volume and try to attach it to the instance. 

Steps to Reproduce:
1. Install Openstack with a packstack allinone deployment
2. Upload ISO image in the GUI
3. Launch instance that boots from the uploaded ISO image
4. Create an empty volume and attach it to the running instance

Actual results:
Message: Info Attaching volume testvol to instance test on /dev/hda.
The volume status hangs on 'Attaching' and changes to 'Available' after some time.

Expected results:
The volume should be attached to the instance.

Additional info:

/var/log/messages shows the following:

kernel: CHAP_N values do not match!
kernel: Security negotiation failed.
kernel: iSCSI Login negotiation failed.
kernel: connection3:0: detected conn error (1020)
iscsid: Kernel reported iSCSI connection 3:0 error (1020  - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (2)

The credentials on the iscsi target for the volume are the following:

/iscsi/iqn.20...:60a865d51724> get auth
The mutual_password auth parameter.

The mutual_userid auth parameter.

The password auth parameter.

The userid auth parameter.

The iscsi initiator is trying to access the target with other credentials:

root@rhos-test ~]# iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
Target: iqn.2010-10.org.openstack:volume-4ccb8f25-12a8-4152-8128-4037c4764f37 (non-flash)
    Current Portal:,0
    Persistent Portal:,0
        Iface Name: default
        Iface Transport: tcp
        Iface Initiatorname: iqn.1994-05.com.redhat:60a865d51724
        Iface IPaddress:
        Iface HWaddress: <empty>
        Iface Netdev: <empty>
        SID: 3
        iSCSI Connection State: IN LOGIN
        iSCSI Session State: FREE
        Internal iscsid Session State: NO CHANGE
        Recovery Timeout: 120
        Target Reset Timeout: 30
        LUN Reset Timeout: 30
        Abort Timeout: 15
        username: gT42LDg5kUf8kXsAWKkt
        password: ********
        username_in: <empty>
        password_in: ********
        Negotiated iSCSI params:
        HeaderDigest: None
        DataDigest: None
        MaxRecvDataSegmentLength: 8192
        MaxXmitDataSegmentLength: 0

Comment 2 Sergey Gotliv 2014-12-14 13:05:52 UTC

Which Cinder driver do you use? LVM? Which ISCSI helper - LIO? How about adding Cinder and Nova logs next time so I won't need to ask these questions.

Comment 3 Marius Cornea 2014-12-14 18:19:45 UTC
Created attachment 968569 [details]
Nova and cinder logs

Comment 4 Marius Cornea 2014-12-14 18:20:23 UTC
Hi Sergey,


I also attached the logs.

Comment 5 Sergey Gotliv 2015-01-06 12:37:09 UTC
It looks like a duplicate of BZ#1121702, different scenario but same piece of code and the same error.

Comment 6 Sergey Gotliv 2015-01-08 14:23:15 UTC

*** This bug has been marked as a duplicate of bug 1121702 ***