]> git.ipfire.org Git - thirdparty/libvirt.git/commit
storage: Fix regression cloning volume into a logical pool
authorJohn Ferlan <jferlan@redhat.com>
Fri, 29 Apr 2016 11:43:57 +0000 (07:43 -0400)
committerJohn Ferlan <jferlan@redhat.com>
Wed, 11 May 2016 13:06:26 +0000 (09:06 -0400)
commit2c52ec43aa283a1f3221e420f0c392706bdaedcc
tree95946999ed1bb5e7199d22457c241e65390bcf14
parent898c0bbea7ad3d8d9b8b978027762a9dd16ad691
storage: Fix regression cloning volume into a logical pool

https://bugzilla.redhat.com/show_bug.cgi?id=1318993

Commit id 'dd519a294' caused a regression cloning a volume into a
logical pool by removing just the 'allocation' adjustment during
storageVolCreateXMLFrom. Combined with the change to not require the
new volume input XML to have a capacity listed (commit id 'e3f1d2a8')
left the possibility that a zero allocation value (e.g., not provided)
would create a thin/sparse logical volume. When a thin lv becomes fully
populated, then LVM sets the partition 'inactive' and the subsequent
fdatasync() fails.

Add a new 'has_allocation' flag to be set at XML parse time to indicate
that allocation was provided. This is done so that if it's not provided
the create-from code uses the capacity value since we document that if
omitted, the volume will be fully allocated at time of creation.

For a logical backend, that creation time is 'createVol', while for a
file backend, creation doesn't set the size, but the 'createRaw' called
during buildVolFrom will decide whether the file is sparse or not based
on the provided capacity and allocation value.

For volume clones that provide different allocation and capacity values
to allow for sparse files, there is no change.
src/conf/storage_conf.c
src/storage/storage_driver.c
src/util/virstoragefile.c
src/util/virstoragefile.h