This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1471759 - Synchronizing a direct lun that is also a part of a storage domain causes its virtual group ID to be removed from the DB
Synchronizing a direct lun that is also a part of a storage domain causes its...
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage (Show other bugs)
4.1.3
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ovirt-4.1.5
: 4.1.5
Assigned To: Idan Shaby
Elad
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-17 08:08 EDT by Idan Shaby
Modified: 2017-08-23 04:04 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-23 04:04:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.1+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 79480 master MERGED backend: don't remove VG ID of direct lun that is a part of a SD 2017-07-20 09:26 EDT
oVirt gerrit 79704 ovirt-engine-4.1 MERGED backend: don't remove VG ID of direct lun that is a part of a SD 2017-07-24 03:32 EDT

  None (edit)
Description Idan Shaby 2017-07-17 08:08:45 EDT
Description of problem:
When adding a direct lun with a lun that is also a part of a storage domain, that lun has already an entry in the DB ("luns" table) and it contains the VG ID.
Synchronizing this direct lun causes this VG ID to be changed to an empty string in the DB.

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

How reproducible:
100%

Steps to Reproduce:
1. Create a storage domain from one lun.
2. Create a direct lun from the same lun.
3. See that this lun has a VG ID in the "luns" table.
4. Synchronize the direct lun using the REST API:

POST http://<engine_address>:8080/ovirt-engine/api/disks/<direct_lun_id>/refreshlun
<action>
  <host id='<host_id>'/>
</action>

Actual results:
The lun's volume_group_id is an empty string instead the real one that it used to have.

Expected results:
The VG ID should not be changed.
Comment 1 Elad 2017-07-30 10:20:10 EDT
The LUN's 'volume_group_id' in 'luns' table value remains the actual VG ID of the storage domain it belongs to after adding a LUN, that is being used for a storage domain, as a direct LUN and refreshing the LUN via REST.


Request:
POST to https://jenkins-vm-19.qa.lab.tlv.redhat.com/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/refreshlun


<action>
  <host id='99282725-a5aa-4cb0-b5b6-9022bfcc5649'/>
</action>


Response:

<action>
<disk href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e" id="dd6b21fc-3d47-47fc-a664-d1b5b2afac6e">
<actions>
<link href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/sparsify" rel="sparsify"/>
<link href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/refreshlun" rel="refreshlun"/>
<link href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/export" rel="export"/>
<link href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/move" rel="move"/>
<link href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/copy" rel="copy"/>
</actions>
<link href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/permissions" rel="permissions"/>
<link href= "/ovirt-engine/api/disks/dd6b21fc-3d47-47fc-a664-d1b5b2afac6e/statistics" rel="statistics"/>
</disk>
<host id="99282725-a5aa-4cb0-b5b6-9022bfcc5649"/>
<status>complete</status>
</action>


LUN 3514f0c5a516008c8 record in 'luns' table after the refresh while the LUN exists as a direct LUN in the setup:

-[ RECORD 3 ]-------+---------------------------------------
physical_volume_id  | HR4qDA-pxiR-mZKC-ZoPE-3UWY-tMjp-2V2M9s
lun_id              | 3514f0c5a516008c8
volume_group_id     | 0G19NE-9oJH-4uUA-9vPC-21Dy-lZHZ-PKOKEs
serial              | SXtremIO_XtremApp_XIO00153500071
lun_mapping         | 1
vendor_id           | XtremIO
product_id          | XtremApp
device_size         | 150
discard_max_size    | 8388608
discard_zeroes_data | t


==============================================

Used:
ovirt-engine-4.2.0-0.0.master.20170728194615.gitec6aa15.el7.centos.noarch
vdsm-4.20.1-269.git4afc67d.el7.centos.x86_64
Comment 2 Sandro Bonazzola 2017-08-09 12:17:40 EDT
Elad, this bug is targeted 4.1.5, verification has been done on ovirt-engine-4.2.0-0.0.master. Moving back to QE
Comment 3 Idan Shaby 2017-08-14 09:17:00 EDT
For testing purposes:

In 4.1 it's not possible to synchronize a direct LUN via the REST API.
But it is possible to synchronize it by upgrading the dc.

So for 4.1 the steps to reproduce are:
1. Have a <= 4.0 dc.
2. Create a storage domain from one lun.
3. Create a direct lun from the same lun.
4. See that this lun has a VG ID in the "luns" table.
5. Create a VM in the dc from step 1 and attach it the direct lun from step 3.
6. Upgrade the dc to version 4.1.

Expected results: the VG ID should not be changed.

Thanks Elad for noticing and sorry for the missing details.
Comment 4 Elad 2017-08-14 09:38:04 EDT
Thanks Idan.

Tested according to the steps in the last comment.

LUN 3514f0c5a516008dd still has the same volume_group_id after upgrading the DC from 4.0 to 4.1 while the LUN is attached to a VM and is part of an iSCSI storage domain.

[root@storage-ge-03 ~]# su - postgres -c "psql -U postgres engine -c  'select lun_id,volume_group_id from luns;'"
      lun_id       |            volume_group_id             
-------------------+----------------------------------------
 3514f0c5a516008dc | l9aswX-elg2-bpVU-y7TW-TzVx-2Bsk-CZblrG
 3514f0c5a516008db | GuA242-Kp5k-pAGd-MIb8-bf4M-jeHe-gfvDPv
 3514f0c5a516008da | pQzCnl-rW1Z-rdtT-Lam0-RN9u-D8Jg-1RdfxK
 3514f0c5a516008dd | gQa2pK-VsJS-v2cO-CS9O-BFjW-QuH2-l82sUl
(4 rows)



Used:
rhevm-4.1.5.2-0.1.el7.noarch
vdsm-4.19.27-1.el7ev.x86_64

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