Re: [Qemu-devel] The image size of instance VM keeps growing

[Stefan Hajnoczi]

On Fri, May 25, 2012 at 10:20 AM, Charles.Tsai-蔡清海-研究發展部
<address@hidden> wrote:
> Stefan,
>
>        I made two test cases here.
>
>        1) case one:
>                A 32-bit Windows 7 VM with 8G virtual disk size.
>                In this test, the virtual disk is almost full.
>                Like what you said, the instance VM size only increased 2% 
> initially and only a little when virtual disk size is almost                  
>        full.
>
>        2) case two: (we think it is a bug)
>
>                A 64-bit Windows 7 VM with 64G virtual disk size.
>                Base image size: 19G
>
>                Here is what I found
>
>                The increase size of instance VM is significantly different 
> from the decrease size of virtual disk.
>                The decrease size of virtual disk stands for the new data 
> written into the disk by the OS.
>
>                Here are the readings I collected at differ time slot.
>
>                1)
>                Instance VM size: 1.6G
>                Virtual disk free space: 45792534528 (read from guest OS)
>
>                2)
>                Instance VM size: 2.1 G
>                Virtual disk free space: 45786300416 (read from guest OS)
>
>                You can find that the instance VM increase 0.5G but virtual 
> disk space only reduces around 6MB.
>                This process will continue as long as the VM is running.

This seems normal.  The relationship between free space inside the
guest and qcow2 image file size is not 1:1 - in fact it's arbitrary
and depends completely on your file system, partitioning, etc.

But let's assume for a second that free space inside the guest
indicates the amount of data written into the image file:

free space consumed = 45792534528 - 45786300416 = 6234112 = ~6 MB

In the worst case each 512-byte sector of those 6 MB is in a separate
64 KB cluster region.  In other words:

for (i = 0; i < 6234112 / 512; i++) {
    offset = i * 65536;
    pwrite(disk, buf, 512, offset);
}

Let's calculate how much allocation this causes in the qcow2 image file:

(6234112 / 512) * 65536 = 797966336 = 761 MB

This is the worst case.  In practice the I/O pattern will probably not
touch a new cluster every time and the qcow2 file will grow a lot
less.

So we have estimated the worst case qcow2 image file growth for 6 MB
of writes.  The result is 761 MB.  It is larger than what you observed
so your results can be explained as expected behavior.

Stefan