Bug 1072999

This is somewhat related to bug #1021505.

I have a volume group on top of MD RAID, with 7 logical volumes

$ vgdisplay 
  --- Volume group ---
  VG Name               test
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                7
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               184.00 MiB
  PE Size               4.00 MiB
  Total PE              46
  Alloc PE / Size       14 / 56.00 MiB
  Free  PE / Size       32 / 128.00 MiB
  VG UUID               R0vZWK-DH6U-F9KN-B5i7-6sGt-QHu8-sdZpE

$ lvs
LV   VG   Attr       LSize Pool Origin Data%  Move Log Cpy%Sync Convert
  1    test -wi-a----- 8.00m                                             
  2    test -wi-a----- 8.00m                                             
  3    test -wi-a----- 8.00m                                             
  4    test -wi-a----- 8.00m                                             
  5    test -wi-a----- 8.00m                                             
  6    test -wi-a----- 8.00m                                             
  7    test -wi-a----- 8.00m                                             

(you can see the RAID is quite small).

Creating new 8MB logical volume using blivet throws:

  File "/usr/lib/python2.7/site-packages/lmi/storage/LMI_StorageConfigurationService.py", line 212, in _create_lv
    lv = self.storage.newLV(**args)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1145, in newLV
    return device_class(name, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 2595, in __init__
    self.parents[0]._addLogVol(self)
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 2314, in _addLogVol
DeviceError: ('new lv is too large to fit in free space', 'test')


The reason is wrong LVMVolumeGroupDevice.freeSpace and freeExtents:
>>> vg = blivet.vgs[0]
>>> print repr(vg)

LVMVolumeGroupDevice instance (0x20dc810) --
  name = test  status = True  kids = 7 id = 21
  parents = ['existing 188MB mdarray 1 (6) with existing lvmpv']
  uuid = R0vZWK-DH6U-F9KN-B5i7-6sGt-QHu8-sdZpEW  size = 184
  format = existing None
  major = 0  minor = 0  exists = True  protected = False
  sysfs path =   partedDevice = None
  target size = 0  path = /dev/mapper/test
  format args = []  originalFormat = None  target = None  dmUuid = None  free = 128.0  PE Size = 4.0  PE Count = 46
  PE Free = 32  PV Count = 1
  LV Names = ['1', '2', '3', '4', '5', '6', '7']  modified = False
  extents = 46.0  free space = -12.0
  free extents = -3.0  reserved percent = 0  reserved space = 0
  PVs = ['existing 188MB mdarray 1 (6) with existing lvmpv']
  LVs = ['existing 8MB lvmlv test-1 (22)',
 'existing 8MB lvmlv test-2 (23)',
 'existing 8MB lvmlv test-3 (24)',
 'existing 8MB lvmlv test-4 (25)',
 'existing 8MB lvmlv test-5 (26)',
 'existing 8MB lvmlv test-6 (27)',
 'existing 8MB lvmlv test-7 (28)']

Notice free space = -12.0 and free extents = -3.0 -> _addLogVol() check for free space fails.

Version-Release number of selected component (if applicable):
python-blivet-0.18.28-1.el7.noarch

python-blivet-0.18.27-1.el7.noarch was working, I suspect commit b82b638aa53fbaa375e6e038c2b2251a8e145c52 did something wrong.

How reproducible:
always

Steps to Reproduce:
1. get two 100MB devices (partitions)
2. create raid0 of them: mdadm -C -l 0 -n 2 /dev/md1 /dev/sdc{1,2}
3. create VG on top of them: vgcreate test /dev/md1
4. create 7 LVs: for i in `seq 7`;do lvcreate -l 2 -n $i test; done
5. initialize blivet and look at LVMVolumeGroupDevice (see attachment)

Actual results:
blivet prints: free space = -12.0 free extents = -3.0

Expected results:
blivet prints something positive, indicating that it has plenty of free space in the VG. Bug 1021505 indicates that it may not be pixel-perfect, but missing 128MB is IMO too much.