[fedora-virt] /var/lib/libvirt/images on BTRFS (it works!) message 10 of 20)

[fedora.bobd at dfgh.net]

On 11/18/2013 03:05 PM, Gene Czarcinski - gene at czarc.net wrote:
> On 11/18/2013 01:27 PM, James A. Peltier wrote:
>> ----- Original Message -----
>> | Some of you may be interested in running your qemu-kvm (or other)
>> | disk
>> | image files on BTRFS.  After some fumbling around, I have found out
>> | how
>> | to do it so it works and works very well (especially if it is on an
>> | SSD).
>> |
>> | Anyone investigating running on BTRFS immediately finds out that
>> | there
>> | is a fragmentation problem (just putting image files on btrfs can
>> | result
>> | in them having between 50,000 and 100,000 extents).  Some may have
>> | seen
>> | that adding nodatacow to the mount option is a solution ... it is
>> | not.
>> | So what is the solution?
>> |
>> | 1.  execute:  chattr  +C  /var/lib/libvirt/images
>> | or wherever your image files are.  This needs to be done on the
>> | directory whether you have a separate subvol or not.
>> |
>> | 2.  This ONLY works for new files and ONLY works for "raw" storage
>> | format files.  Pretty much by definition, qcow2 files are sparse
>> | format
>> | files and that is the primary problem on btrfs.
>> |
>> | So that the vm creation wizard will create a new disk using the raw
>> | storage format, you need to select:
>> |     Edit->Preferences->VM Details->Default Storage Format->Raw
>> | After then, an created virtual will have the correct disk format.
>> |
>> | You can use "filefrag" to verify that things are working.
>> |
>> | Gene
>> | _______________________________________________
>> | virt mailing list
>> | virt at lists.fedoraproject.org
>> | https://admin.fedoraproject.org/mailman/listinfo/virt
>>
>> So in effect, nothing has been solved for using qcow2 images which is
>> what the majority of people are interested in using.
>>
>> We understand that the problem with BTRFS is when dealing with sparse
>> files and this problem needs to be addressed for it to be "production
>> ready" for VM infrastructure.  There hasn't really been a problem
>> when dealing with files of the raw image format other than your
>> standard file system optimization problems associated with a new file
>> system.  Until you are able to create sparse files with performance
>> on par or better than EXT{3,4} or XFS, BTRFS is still not ready.
>>
> I am not sure the problem is solvable but, then, I am not a btrfs
> internals expert either.  I do not know how it would be if you had a
> qcow2 file in a "+C" directory.  On the other hand, I know that btrfs
> fi defrag does work and can trim files with a huge number of extents
> to large but more reasonable values.
>
> That said, give a SSD hardware platform, I am not sure what the impact
> of a large number of extents is.
>
> Also, except for a little time for initialization, is there a
> performance penalty for using raw versus qcow2 disk file images? At
> first I thought that one advantage of qcow2 and the sparse file was
> that it let you over-commit storage (allocate more virtual disk space
> that you really had) but virt-manager will not let you do that.  There
> must be at least as much free space available for qcow2 as if you were
> fully allocating the disk image.

Yes that's a bug IMO. If I have 40GB free, I can create a machine with a 
thin-provisioned 30GB disk. Then I can create a second one, also with 
30GB. So you can clearly over-commit. But I can't create a single 
thin-provisioned disk with 60GB disk.

-Bob