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

Kevin Wolf kwolf at redhat.com
Wed Aug 15 10:44:44 UTC 2018


Am 15.08.2018 um 12:26 hat Richard W.M. Jones geschrieben:
> On Tue, Aug 14, 2018 at 09:31:06PM +0300, Nir Soffer wrote:
> > On Tue, Aug 14, 2018 at 8:29 PM Richard W.M. Jones <rjones at redhat.com>
> > wrote:
> > 
> > > This option prints the estimated size of the data that will be copied
> > > from the source disk.
> > >
> > > For interest, the test prints:
> > >
> > > 3747840 ../test-data/phony-guests/windows.img
> > > Estimate: 3710976
> > >
> > 
> > Why not use qemu-img measure on the overlay?
> 
> Yes this would be better, but oddly it doesn't work properly when
> the output format is set to 'raw':
> 
>   /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'raw' '--output=human' '/home/rjones/d/libguestfs/tmp/v2vovl62b7c2.qcow2'
>   required size: 6442450944
>   fully allocated size: 6442450944
> 
> However it's OK if the output format is set to 'qcow2':
> 
>   /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'qcow2' '--output=human' '/home/rjones/d/libguestfs/tmp/v2vovla53d7c.qcow2'
>   required size: 1047986176
>   fully allocated size: 6443696128
> 
> I guess it ignores sparseness of raw images, but I can't see a way to
> specify that on the command line.
> 
> OTOH the qcow2 figure is probably a good enough guess for our purposes
> (ie. estimating how much data will be copied).

'qemu-img measure' calculates the resulting file size, not the number of
used blocks. I think this is because its main purpose is to create block
devices (like LVs) of the right size, so sparseness on a filesystem
level doesn't buy you anything.

Kevin




More information about the Libguestfs mailing list