The first patch just changes 'building' into a bool as that's how I found it used when going to add a new bool for patch 2 Patch 2 addresses the following bz: https://bugzilla.redhat.com/show_bug.cgi?id=1091866 Essentially, wiping the lv caused it to disappear after a vol-refresh. This was because the lv that was created was a sparse (or thin or snapshot via --virtualsize of -V) logical volume. The multiple names are the ways I found the feature described. When the sparse volume was written to by the wipe algorithms it actually filled the volume beyond it's capacity rendering it INACTIVE which causes pool-refresh to ignore it. As it turns out a sparse lv created of size (for example) 4 MiB has metadata contained within the size created. While we could adjust the size of the metadata, control over it's location becomes the issue. It seems there is also some guard data at each end of the sparse lv as when the wipe was done lost I/O messages were sent to the system log. After much searching it just seems that writing a sparse lv with some sort of wipe algorithm will not work. Although if anyone has suggestions I'm willing to try. I have found writing '0x00''s, the scrub utility, and a "dd if=/dev/zero of=/dev/lv_pool/lv_test bs=4096 count=1024" doesn't work. It's also of interest to note that the 'scrub' utility doesn't seem to recognize the logical volume format properly as none of the nonzero algorithms are run - each fails to open the file - for example: $ /usr/sbin/lvcreate --name lv_test -L 4096K lv_pool $ /usr/bin/scrub -f -p bsi /dev/lv_pool/lv_test scrub: using BSI patterns scrub: warning: /dev/lv_pool/lv_test is zero length $ John Ferlan (2): storage: Convert 'building' into a bool storage: Disallow vol_wipe for sparse logical volumes src/conf/storage_conf.h | 2 +- src/storage/storage_backend_logical.c | 39 ++++++++++++++++++++++++++++++++++- src/storage/storage_driver.c | 8 +++---- src/util/virstoragefile.h | 1 + 4 files changed, 44 insertions(+), 6 deletions(-) -- 1.9.3 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list