Description of problem:
Attempting to thin provision when images_type=lvm results in a broken volume chain and disk read errors in the Instances.
applicable configs from nova.conf
volume_clear=none #this should bypass the heavy dd on a instance delete
sparse_logical_volumes=true #created disk errors
force_raw_images=false #avoids the heavy qemu convert
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure images_type=lvm and sparse_logical_volumes=true
2. Boot a VM using a flavor with 10GB and the RHEL 7.3 KVM guest
Fails to boot
This is easily reproducable and if this feature is not supported, perhaps it should be removed from OpenStack at all.
There are some additional checks that could be done for config testing when sparse=true.
One key issue I found was in the OSP9 RHEV install lvm.conf had thin_pool_autoextend_threshold set to 100 so the initial sized thinpool lv would max out, but the qemu-img convert call would still return a 0.
I also found that on delete the thinlv would be removed (eg uuid_disk), but the autogenerated thinpool (datalv and metalv) would be left so you would collect the lvol### instances within lvm and I found no garbage collection routine.
The autoextend (I tested w 70 w a 20% increase) seemingly is not quick enough to match either qemu-img or a dd sourced data addition routine. I would see a variety of sizes in LSize for the thinpool after a copy complete. It seems like the writes are being ACK'd, but not being written back correctly.
As a note using lvm sparse or thick vols I don't see an alternative to the raw conversion so that is an expected overhead for using lvm. I do find it a bit curious why lvm snaps of a thick or thin hosted _base image don't seem to be used when cow is true.
For reference: not reproducible on devstack. Will try with packstack RHOS 9 and LVM.
In case I can't reproduce, could you please share a sosreport from an affected machine with a failure in the logs?