On 06/06/2018 09:43 AM, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
Yeah, but why make qcow2 that format? That's what I completely fail to
understand.
Because why not? It's cheap to add it there and is much easier
than teaching people about a new container format.
tar is not a new container format, but it is a new format to various
toolchains - that said, if we popularize tar as the format for including
a config file alongside a qcow2 image, it's not that hard to fix the
stack to start passing that file around as the new preferred file type.
Eric Blake put it very well I think. There are several things that
several people would like to see addressed:
(1) A sensible list of guest visible aspects of the VM
preserving which across VM restarts we deem critical enough to support
starting guests.
At this point this includes at least architecture and machine type.
This part is true no matter where we store it. So as I see it, the
question is now whether to store it in qcow2, or whether to store qcow2
+ config in a tar file.
(2) A compact file format for serializing list (1)
tar files already serve this purpose (even if we don't like the current
OVA specification for the config side, it at least proves that tar files
are usable in this manner)
(3) Ability to store file (2) in a qcow2 image
As Dan pointed out, if we can FIRST popularize storing a config file +
qcow2 in a tar file, THEN we can (for convenience) let qcow2 directly
store the same config file, if it helps things (although if popularizing
tar files works, we wouldn't need it in qcow2).
Maybe the step we want to take now is to add a new block driver to qemu
that supports tar files including resize. That is, where we currently do:
qcow2 -> posix file
we would instead popularize:
qcow2 -> tar driver -> posix file
where the tar driver takes care of finding the right subset within the
overall tar file, AND makes it easy to resize (by updating tar metadata
any time qcow2 wants to resize larger, and assuming qcow2 is the last
member of the tar archive)
Perhaps we can even automate it so that the tar driver is automatically
inserted even when not explicitly specified (after all, you can already
start qemu by giving just the file name holding a qcow2 image, and qemu
can figure out to use the qcow2 driver) - although we DO have to be
careful of avoiding CVEs (probing image formats MUST NOT allow a guest
to convert a raw image into something that qemu would treat as a tar,
any more than it would misinterpret raw as qcow2)
You are asking why store (2) in qcow2 image specifically. The answer is
it's just one place where we can store it. The answer is we don't need
to involve qemu-block at all for storing it in other places.
Then why start with qcow2? Let's start with tar files, and enhance
qemu-block to make tar files containing qcow2 easier to use in qemu (and
NOT with making qcow2 larger just to bypass tar files).
But for many people it will be handy to have it in the same file, and
qcow2 is popular enough that many people will be well served if it's
there.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org