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

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.

>> 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. >