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
Summary: Synchronizing a direct lun that is also a part of a storage domain causes its...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.1.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ovirt-4.1.5
: 4.1.5
Assignee: Idan Shaby
QA Contact: Elad
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-17 12:08 UTC by Idan Shaby
Modified: 2017-08-23 08:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-23 08:04:38 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-4.1+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 79480 0 master MERGED backend: don't remove VG ID of direct lun that is a part of a SD 2020-11-17 15:43:19 UTC
oVirt gerrit 79704 0 ovirt-engine-4.1 MERGED backend: don't remove VG ID of direct lun that is a part of a SD 2020-11-17 14:38:10 UTC

Description Idan Shaby 2017-07-17 12:08:45 UTC
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 14:20:10 UTC
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 16:17:40 UTC
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 13:17:00 UTC
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 13:38:04 UTC
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.