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