LVM thin provisioning and virt-manager

[Pádraig Brady]

On 10/17/2013 07:09 PM, Chris Murphy wrote:
> 
> On Oct 17, 2013, at 10:22 AM, Chris Murphy <lists at colorremedies.com> wrote:
> 
>>
>> So whatever options virt-manager is using to create qcow2 files, is either the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any difference in options isn't making a difference in performance. The 37 second performance difference is probably due to less disk contention from the source ISO being on a separate drive this time around. And if I'm right about all of that, then the overwhelming gain is coming from unsafe cache.
> 
> My original 1h41s result I reported was based on a qcow2 file that I made using qemu-img without metadata preallocation, not the virt-manager UI. So the above assertion that most gain is coming from unsafe cache was premature.
> 
> Here's the retesting:
> 
> btrfs partitions default guided to qcow2 (libvirt unsafe cache, virt-manager default qcow2 creation)
> anaconda.log "Running Thread: AnaInstallThread" = 15:56:02
> anaconda.log "Thread Done: AnaConfigurationThread" = 16:12:46
> 00:16:44
> 
> btrfs partitions default guided to qcow2 (libvirt unsafe cache, qemu-img qcow2 creation with no options)
> anaconda.log "Running Thread: AnaInstallThread" = 17:18:10
> anaconda.log "Thread Done: AnaConfigurationThread" = 17:35:23
> 00:17:13
> 
> That's significantly more justification to suggest most of the gain over the first 1h41m case was overwhelming due to the use of the 'none' cache setting; and qcow2 metadata preallocation is not nearly as significant a factor.

Yes preallocation=metadata makes a huge difference.
I've testing benchmarks here:
https://blueprints.launchpad.net/nova/+spec/preallocated-images
Note the caveats with backing disk though.

thanks,
Pádraig.