[libvirt-users] Problem about Disk Dize of Destination and Source File after Do Blockcopy

[shyu]

On 07/27/2014 10:28 AM, shyu wrote:
> Hi Eric,
>
> On 07/22/2014 08:52 PM, Eric Blake wrote:
>> On 07/21/2014 10:01 PM, shyu wrote:
>>
>>> # rpm -q libvirt qemu-kvm-rhev
>>> libvirt-1.1.1-29.el7.x86_64
>>> qemu-kvm-rhev-1.5.3-60.el7ev_0.2.x86_64
>> These are downstream builds.  Can you reproduce your situation with
>> upstream libvirt 1.2.6 and qemu 2.1-rc2?  It may be that you are hitting
>> behavior that was introduced by downstream backports.
> I tried with qemu-kvm-2.1.0-0.5.rc3.fc20.x86_64 and libvirt built from 
> latest libvirt.git, I am able to reproduce that.
>

Oops, I am unable to reproduce that. :)

>>> 1. Check source file
>>> # qemu-img info /var/lib/libvirt/images/rhel6.img
>>> image: /var/lib/libvirt/images/rhel6.img
>>> file format: qcow2
>>> virtual size: 5.0G (5368709120 bytes)
>>> disk size: 1.2G
>> Disk size tracks how much of the qcow2 file has been allocated, NOT how
>> much guest data has been allocated.
>>
>>> 3. Check destination file's disk size
>>>
>>> # qemu-img info /var/lib/libvirt/images/copy.img
>>> image: /var/lib/libvirt/images/copy.img
>>> file format: qcow2
>>> virtual size: 5.0G (5368709120 bytes)
>>> disk size: 2.0G
> Thanks very much for your explanation
>> The thing to remember here is that blockcopy defaults to doing a cluster
>> at a time, even if the guest has not yet touched every sector within the
>> cluster.  It may be that you are hitting cases where the copy operation
>> ends up writing an entire cluster in the destination where only a
>> partial cluster had been allocated in the source.  But that does not
>> necessarily mean the copy is flawed, only that the default granularity
>> was large enough to inflate the destination with redundant all-zero
>> sectors in the interest of speeding up the operation, or that the
>> destination is not as sparse as the source.  Qemu offers the
>> 'granularity' parameter to the 'drive-mirror' command to alter the
>> granularity, but libvirt is not (currently) exposing this knob to the
>> user so for now libvirt is just relying on qemu defaults.
>>
>> It may also be a factor of how much copy-on-write dirtying is happening.
>>   If the guest is actively hammering on the disk during the copy
>> operation, the same cluster may be marked dirty multiple times; if qemu
>> allocates a new destination cluster for each pass through the dirty
>> bitmap, it may result in some inflation in size due to clusters that are
>> written early then discarded as they are later rewritten in a new
>> allocation.  I'm not familiar enough with qemu block handling to know if
>> this is happening, or even whether qemu could be patched to do better
>> garbage collection of clusters left unused if it is happening.
>>
>> There is nothing that libvirt can do about this.  I don't think it is a
>> bug, but you may want to ask on the qemu list, since it is up to qemu
>> whether or not the copy will be inflated in host size.  But inflation is
>> not a bad thing in itself - the real question is whether the copy
>> contains the same guest contents as the original at the time the copy
>> completed - as long as that is the case, even if the host sizes are
>> different, then the copy is reliable.
>>
>

-- 
Regards
shyu