Bug 1410182 - getVGInfo - report of free/used extents on each device
Summary: getVGInfo - report of free/used extents on each device
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: General
Version: 4.19.11
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.1.0-rc
: 4.19.2
Assignee: Liron Aravot
QA Contact: Avihai
URL:
Whiteboard:
Depends On:
Blocks: 1410115
TreeView+ depends on / blocked
 
Reported: 2017-01-04 16:50 UTC by Liron Aravot
Modified: 2017-02-01 14:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1410115
Environment:
Last Closed: 2017-02-01 14:49:43 UTC
oVirt Team: Storage
rule-engine: ovirt-4.1+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 69133 0 None None None 2017-01-04 16:50:16 UTC
oVirt gerrit 69631 0 ovirt-4.1 MERGED hsm: adding pe_alloc_count/pe_count to getVgInfo 2017-01-05 12:23:10 UTC

Description Liron Aravot 2017-01-04 16:50:16 UTC
This patch is about adding report of the free/used extends of each of the vg devices in order to solve BZ 1410115


+++ This bug was initially created as a clone of Bug #1410115 +++

Description of problem:
A user can attempt to remove multiple devices from a block storage domain.
For each of the devices, the data is first moved from the
device to other devices of the domain and then the device is removed from the domain.
The data is moved using the lvm command pvmove, if there's not enough
free space the operation will fail.

When attempting to reduce multiple devices, we can't rely on the lvm
verification for free space (as lvm isn't aware that the user we are going to remove more devices from the domain). regardless - validating it instead of failing on the lvm command execution is more user friendly.

How reproducible:
Always - complicated reproduction

Steps to Reproduce:
1. Create a block domain with 1 devices
2. create a preallocated disk in a size close to the device size.
3. extend the domain with another device with size similar to the first device (let's call that device A)
4. create a preallocated disk in size close to the device size.
5. extend the domain with another device with size similar to the first device (yes, again - let's call that device B).
6. create a preallocated disk in size close to the device size.
7. delete the disk residing on device A.
8. send a request to remove devices A and B from the domain (A should appear first).


Actual results:
The first device is removed from the domain successfully, the second device removal fails because of lack of free space.

Expected results:
The engine should determine the free space needed to reduce all the devices passed by the user and validate that there is enough free space prior to removing any of the devices from the domain.

Additional info:

Comment 1 Red Hat Bugzilla Rules Engine 2017-01-04 16:51:00 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 2 Avihai 2017-01-19 13:58:41 UTC
verified on:
Engine: 
ovirt-engine-4.1.0.1-0.4.master.20170118134729.gitf34da1f.el7.centos.noarch

VDSM:
4.19.2-1.el7.centos.noarch

Also as requested by @laravot , 
I also checked vgs info from hosts Vs vdsclient info after deleting a disk .

results looks good meaning that indeed vgsize & vgfree looks the same as vgs results , see below .

vdsClient results :
vdsClient -s 0 getVGInfo cW4x8D-S5D8-JPOY-zhWH-Mx7V-CyJu-3zwBRi > vgsclient_info.txt

[root@storage-ge4-vdsm1 ~]# less vgsclient_info.txt | egrep -i "free|size"
vgsize = 159853314048 
vgfree = 54492397568 

VGS results :
[root@storage-ge4-vdsm1 ~]# vgs
  VG                                   #PV #LV #SN Attr   VSize   VFree  
   2b1c5922-dc2f-4d98-9f15-724db78580ad   3  11   0 wz--n- 148.88g  50.75g

Comment 3 Avihai 2017-01-19 14:27:12 UTC
Adding corresondance with @laravot showing further verification on vdsm extent count vs linux pvs after disk removal from one of the 3 luns .

*****************************START OF CORRESPONDENCE****************************
<aefrat>  pe_alloc_count = 388  devtype = iSCSI  discard_zeroes_data = 1  pvUUID = Q0uQHZ-nj2s-xusC-VO4E-KTF1-DeQY-qz04d0 
<aefrat> pe_alloc_count = 0  devtype = iSCSI  discard_zeroes_data = 1  pvUUID = Yef3k3-CqIJ-795t-K9jC-Khtl-lSoe-QeQx6B 
<aefrat> pe_alloc_count = 397  devtype = iSCSI  discard_zeroes_data = 1  pvUUID = zVH8mu-DYSN-wapi-1TkY-oiZg-dhix-kBYWg3
<aefrat> 3 devices 
<laravot> ok
<aefrat> pvs
<aefrat>   PV                            VG                                   Fmt  Attr PSize   PFree  
<aefrat>   /dev/mapper/3514f0c5a51600265 f48a30ab-b0a5-40b2-a0f6-d844847dbee1 lvm2 a--  149.62g 137.50g
<aefrat>   /dev/mapper/3514f0c5a51600266 cdc2ce81-3354-4c6f-b7de-cc9a8a5f4464 lvm2 a--  149.62g 139.50g
<aefrat>   /dev/mapper/3514f0c5a51600267 203a9aae-c79a-41b9-b36c-d6baa6f0b3b1 lvm2 a--  149.62g 139.50g
<aefrat>   /dev/mapper/3514f0c5a51600268 2b1c5922-dc2f-4d98-9f15-724db78580ad lvm2 a--   49.62g      0 
<aefrat>   /dev/mapper/3514f0c5a51600269 2b1c5922-dc2f-4d98-9f15-724db78580ad lvm2 a--   49.62g  49.62g
<aefrat>   /dev/mapper/3514f0c5a5160026a 2b1c5922-dc2f-4d98-9f15-724db78580ad lvm2 a--   49.62g   1.12g
<aefrat>   /dev/vda3                     VolGroup01                           lvm2 a--   17.31g      0 
<laravot> you need to execute it with pe_count as well
<aefrat> relevant vg is 2b1c5922-dc2f-4d98-9f15-724db78580ad
<aefrat> oh
<laravot> i'll add steps
<laravot> 1. run pvs -o pv_name,pv_size,pv_free,pv_used,pv_pe_count,pv_pe_alloc_count
<laravot> and compare it to the result of getVgInfo
<laravot> for the vg pvs
<laravot> (pe_count/pe_alloc_count)
<aefrat> vdsClient pvs -o pv_name,pv_size,pv_free,pv_used,pv_pe_count,pv_pe_alloc_count^C
<aefrat> [root@storage-ge4-vdsm1 ~]#  pvs -o pv_name,pv_size,pv_free,pv_used,pv_pe_count,pv_pe_alloc_count
<aefrat>   PV                            PSize   PFree   Used   PE   Alloc
<aefrat>   /dev/mapper/3514f0c5a51600265 149.62g 137.50g 12.12g 1197    97
<aefrat>   /dev/mapper/3514f0c5a51600266 149.62g 139.50g 10.12g 1197    81
<aefrat>   /dev/mapper/3514f0c5a51600267 149.62g 139.50g 10.12g 1197    81
<aefrat>   /dev/mapper/3514f0c5a51600268  49.62g      0  49.62g  397   397
<aefrat>   /dev/mapper/3514f0c5a51600269  49.62g  49.62g     0   397     0
<aefrat>   /dev/mapper/3514f0c5a5160026a  49.62g   1.12g 48.50g  397   388
<aefrat>   /dev/vda3                      17.31g      0  17.31g 4432  4432
<aefrat> [root@storage-ge4-vdsm1 ~]# 
<aefrat> looks good
<laravot> and now compare it to getVgINfo :)
<laravot> the pe_alloc_count pe_count
<aefrat>   /dev/mapper/3514f0c5a51600268  49.62g      0  49.62g  397   397
<aefrat> <aefrat>   /dev/mapper/3514f0c5a51600269  49.62g  49.62g     0   397     0
<aefrat> <aefrat>   /dev/mapper/3514f0c5a5160026a  49.62g   1.12g 48.50g  397   388
<laravot>  pe_alloc_count/pe_count
<aefrat> VS : pe_alloc_count = 388  devtype = iSCSI  discard_zeroes_data = 1  pvUUID = Q0uQHZ-nj2s-xusC-VO4E-KTF1-DeQY-qz04d0 
<aefrat> <aefrat> pe_alloc_count = 0  devtype = iSCSI  discard_zeroes_data = 1  pvUUID = Yef3k3-CqIJ-795t-K9jC-Khtl-lSoe-QeQx6B 
<aefrat> <aefrat> pe_alloc_count = 397  devtype = iSCSI  discard_zeroes_data = 1  pvUUID = zVH8mu-DYSN-wapi-1TkY-oiZg-dhix-kBYWg3
<laravot> and pe_count is the same as well?
<aefrat> checking
<aefrat> via vgs client in all 3 devices  pe_count = 397  
<aefrat> Also with pvs 
*****************************END OF CORRESPONDENCE******************************


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