[Libguestfs] [Qemu-block] [PATCH] v2v: Add --print-estimate option to print source size estimate.

[Eric Blake]

On 08/15/2018 07:53 AM, Kevin Wolf wrote:

>> But if I run ‘qemu-img convert ... -O raw output.raw’ then output.raw
>> will be a sparse file, and that's the file size I'd expect measure to
>> give us for "required size" (of course "fully allocated size" would be
>> the virtual size, and that is correct).
>>
>> It does look as if the block/raw-format.c:raw_measure function is wrong.
> 
> No, it is correct. Its output is what the file size will be. For raw
> images, that is the same as the virtual disk size.
> 
> Not all blocks in the file will be actually allocated, but the file size
> is what 'ls -l' prints, not what 'du' prints (for regular files).
> 
> It becomes even clearer when you create LVs as the target. If you have a
> 10 GB image in which only the last 1 MB actually contains data, you
> still need a 10 GB volume. You can't create a 1 MB volume and then store
> data at an offset 10 GB - 1 MB, that would be way after the end of the
> block device.
> 
>> In any case we can use the qcow2 estimate for our purposes as it will
>> be near enough what we need (a rough estimate of the size of the copy).
> 
> I don't know what the exact purpose is, and it feels a bit hacky, but it
> might be good enough.
> 
> I suppose what you really want is that 'qemu-img measure' provides
> another number for the space taken by allocated blocks. (Probably
> excluding metadata for non-raw formats? Might depend on the actual
> purpose.)

Adding a third metric to 'qemu-img measure' makes more sense than 
changing the meaning of either of the two existing metrics.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org