<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 15, 2018 at 1:55 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Adding Stefan who implemented the subcommand)<br>
<br>
On Wed, Aug 15, 2018 at 12:44:44PM +0200, Kevin Wolf wrote:<br>
> Am 15.08.2018 um 12:26 hat Richard W.M. Jones geschrieben:<br>
> > On Tue, Aug 14, 2018 at 09:31:06PM +0300, Nir Soffer wrote:<br>
> > > On Tue, Aug 14, 2018 at 8:29 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>><br>
> > > wrote:<br>
> > > <br>
> > > > This option prints the estimated size of the data that will be copied<br>
> > > > from the source disk.<br>
> > > ><br>
> > > > For interest, the test prints:<br>
> > > ><br>
> > > > 3747840 ../test-data/phony-guests/windows.img<br>
> > > > Estimate: 3710976<br>
> > > ><br>
> > > <br>
> > > Why not use qemu-img measure on the overlay?<br>
> > <br>
> > Yes this would be better, but oddly it doesn't work properly when<br>
> > the output format is set to 'raw':<br>
> > <br>
> >   /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'raw' '--output=human' '/home/rjones/d/libguestfs/tmp/v2vovl62b7c2.qcow2'<br>
> >   required size: 6442450944<br>
> >   fully allocated size: 6442450944<br>
> > <br>
> > However it's OK if the output format is set to 'qcow2':<br>
> > <br>
> >   /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'qcow2' '--output=human' '/home/rjones/d/libguestfs/tmp/v2vovla53d7c.qcow2'<br>
> >   required size: 1047986176<br>
> >   fully allocated size: 6443696128<br>
> > <br>
> > I guess it ignores sparseness of raw images, but I can't see a way to<br>
> > specify that on the command line.<br>
> > <br>
> > OTOH the qcow2 figure is probably a good enough guess for our purposes<br>
> > (ie. estimating how much data will be copied).<br>
> <br>
> 'qemu-img measure' calculates the resulting file size, not the number of<br>
> used blocks. I think this is because its main purpose is to create block<br>
> devices (like LVs) of the right size, so sparseness on a filesystem<br>
> level doesn't buy you anything.<br>
<br>
But if I run ‘qemu-img convert ... -O raw output.raw’ then output.raw<br>
will be a sparse file, and that's the file size I'd expect measure to<br>
give us for "required size" (of course "fully allocated size" would be<br>
the virtual size, and that is correct).<br>
<br>
It does look as if the block/raw-format.c:raw_measure function is wrong.<br></blockquote><div><br></div><div><div><div>Yes, it looks like the "required-size" value for raw output format is not</div></div></div><div>very helpful. We could report there the number of bytes that would be</div><div>allocated after the image is copied.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In any case we can use the qcow2 estimate for our purposes as it will<br>
be near enough what we need (a rough estimate of the size of the copy).<br>
<br>
Rich.<br>
<br>
-- <br>
Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones</a><br>
Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
virt-p2v converts physical machines to virtual machines.  Boot with a<br>
live CD or over the network (PXE) and turn machines into KVM guests.<br>
<a href="http://libguestfs.org/virt-v2v" rel="noreferrer" target="_blank">http://libguestfs.org/virt-v2v</a><br>
</blockquote></div></div>