[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Libguestfs] [PATCH] v2v: Add --print-estimate option t
Re: [Qemu-block] [Libguestfs] [PATCH] v2v: Add --print-estimate option to print source size estimate.
Wed, 15 Aug 2018 07:57:33 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
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
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
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