On Fri, Mar 03, 2017 at 09:51:46PM +0800, Stefan Hajnoczi wrote: > RFCv1: > * Publishing patch series with just raw support, no qcow2 yet. Please review > the command-line interface and let me know if you are happy with this > approach. > > Users and management tools sometimes need to know the size required for a new > disk image so that an LVM volume, SAN LUN, etc can be allocated ahead of time. > Image formats like qcow2 have non-trivial metadata that makes it hard to > estimate the exact size without knowledge of file format internals. > > This patch series introduces a new qemu-img subcommand that calculates the > required size for both image creation and conversion scenarios. > > The conversion scenario is: > > $ qemu-img max-size -f raw -O qcow2 input.img > 107374184448 > > Here an existing image file is taken and the output includes the space > required > for data from the input image file. > > The creation scenario is: > > $ qemu-img max-size -O qcow2 --size 5G > 196688
Hmm, so that appears to be indicating the amount of physical space that a qcow2 image would take up before any data has been written to it. That's not actually what I was thinking. I would like to know the maximum possible physical space that a 5G qcow2 image would take up once data is written to every sector. Obviously this is impossible to say if you allow for internal snapshots, but I think it is fine to say that we ignore internal snapshots for purposes of this command. IOW, I would expect something like: $ qemu-img max-size -O qcow2 --size 5G 5905580032 (I just blindly assumed qcow2 metadata is a 10% overhead for sake of illustrating the number here) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|