Bug 1410182

Summary:	getVGInfo - report of free/used extents on each device
Product:	[oVirt] vdsm	Reporter:	Liron Aravot <laravot>
Component:	General	Assignee:	Liron Aravot <laravot>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Avihai <aefrat>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.19.11	CC:	bugs, gklein, ratamir
Target Milestone:	ovirt-4.1.0-rc	Flags:	rule-engine: ovirt-4.1+
Target Release:	4.19.2
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1410115	Environment:
Last Closed:	2017-02-01 14:49:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1410115

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******************************