Bug 1348225

Summary: hosted-engine --deploy sorts iscsi luns incorrectly
Product: [oVirt] ovirt-hosted-engine-setup Reporter: Jiri Belka <jbelka>
Component: GeneralAssignee: Ido Rosenzwig <irosenzw>
Status: CLOSED CURRENTRELEASE QA Contact: Nikolai Sednev <nsednev>
Severity: low Docs Contact:
Priority: low    
Version: 1.3.7.2CC: bugs, stirabos, ylavi
Target Milestone: ovirt-4.2.2Keywords: Triaged
Target Release: ---Flags: rule-engine: ovirt-4.2+
ylavi: exception+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-29 11:04:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Belka 2016-06-20 13:39:25 UTC
Description of problem:

it seems iscsi luns are sorted incorrectly by hosted-engine --deploy:

~~~
          The following luns have been found on the requested target:
                [1]     1IET_000c0002   110GiB  IET     VIRTUAL-DISK
                        status: free, paths: 1 active
         
                [2]     1IET_000c0001   60GiB   IET     VIRTUAL-DISK
                        status: free, paths: 1 active
         
                [3]     1IET_000c0003   60GiB   IET     VIRTUAL-DISK
                        status: free, paths: 1 active
         
          Please select the destination LUN (1, 2, 3) [1]:
~~~

The order is not correct, valid order on target is:

~~~
Target 12: iqn.2016-06-14.brq-str-02:jbelka
        LUN: 0
            SCSI ID: IET     000c0000
            SCSI SN: beaf120
            Size: 0 MB, Block size: 1
            Backing store path: None
        LUN: 1
            SCSI ID: IET     000c0001
            SCSI SN: beaf121
            Size: 64425 MB, Block size: 512
            Backing store path: /dev/druha_vg/jbelka-he1
        LUN: 2
            SCSI ID: IET     000c0002
            SCSI SN: beaf122
            Size: 118112 MB, Block size: 512
            Backing store path: /dev/druha_vg/jbelka-he2
        LUN: 3
            SCSI ID: IET     000c0003
            SCSI SN: beaf123
            Size: 64425 MB, Block size: 512
            Backing store path: /dev/druha_vg/jbelka-he2-data
~~~

Version-Release number of selected component (if applicable):
ovirt-hosted-engine-setup-1.3.7.2-1.el7ev.noarch

How reproducible:
100%

Steps to Reproduce:
1. have iscsi target and luns as above
2. hosted-engine --deploy with iscsi storage for HE VM
3.

Actual results:
check how are luns sorted

Expected results:
should be sorted in the same way as defined on target

Additional info:

Comment 2 Nikolai Sednev 2017-09-26 18:15:08 UTC
Moving back to assigned as SHE deployment over iSCSI with ovirt-engine-appliance-4.2-20170925.1.el7.centos.noarch and ovirt-hosted-engine-setup-2.2.0-0.0.master.20170919052946.git896e399.el7.centos.noarch, shown:

Please specify the target name (iqn.2005-10.org.freenas.ctl:lun0, iqn.2005-10.org.freenas.ctl:lun1, iqn.2005-10.org.freenas.ctl:lun2, iqn.2005-10.org.freenas.ctl:lun3) [iqn.2005-10.org.freenas.ctl:lun0]: 
The following luns have been found on the requested target:

                [1]     36589cfc0000000f45f24ee6e1b47101e       80GiB   FreeNAS iSCSI Disk
                        status: free, paths: 1 active
         
                [2]     36589cfc000000152f51d5ffb3e91ea03       50GiB   FreeNAS iSCSI Disk
                        status: free, paths: 1 active
         
                [3]     36589cfc00000055ee2d9d0ed8a90e439       60GiB   FreeNAS iSCSI Disk
                        status: free, paths: 1 active
         
                [4]     36589cfc00000060a526da3e25bf359e4       70GiB   FreeNAS iSCSI Disk
                        status: free, paths: 1 active
         
          Please select the destination LUN (1, 2, 3, 4) [1]: 
--------------------------------------------------------------------------------

While on iSCSI target I've configured as follows:

LUN0 serial 00163e7bb85400 size 70GB
LUN1 serial 00163e7bb85401 size 60GB
LUN2 serial 00163e7bb85402 size 80GB
LUN3 serial 00163e7bb85403 size 50GB

Comment 3 Red Hat Bugzilla Rules Engine 2017-09-26 18:15:13 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 4 Nikolai Sednev 2018-02-18 15:10:53 UTC
I've created LUNs on target by this order:
80GB, 81GB, 82GB, 83GB.
I've received this order during deployment:
[ INFO  ] Connecting to the storage server
          The following luns have been found on the requested target:
                [1]     LUN1    3514f0c5a516015ce       80GiB   XtremIO XtremApp
                        status: free, paths: 1 active
         
                [2]     LUN2    3514f0c5a516015cf       81GiB   XtremIO XtremApp
                        status: free, paths: 1 active
         
                [3]     LUN3    3514f0c5a516015cd       82GiB   XtremIO XtremApp
                        status: free, paths: 1 active
         
                [4]     LUN4    3514f0c5a516015cc       83GiB   XtremIO XtremApp
                        status: free, paths: 1 active
         
          Please select the destination LUN (1, 2, 3, 4) [1]: 

Moving to verified, as the order appears as expected.
Works for me on these components:
ovirt-hosted-engine-ha-2.2.5-1.el7ev.noarch
ovirt-hosted-engine-setup-2.2.10-1.el7ev.noarch
rhvm-appliance-4.2-20180202.0.el7.noarch
Linux 3.10.0-693.19.1.el7.x86_64 #1 SMP Thu Feb 1 12:34:44 EST 2018 x86_64 x86_64 x86_64 GNU/Linux

Comment 5 Sandro Bonazzola 2018-03-29 11:04:49 UTC
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 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.