Re: [Qemu-devel] storing machine data in qcow images?

[Eric Blake]

On 06/06/2018 11:11 AM, Michal Suchánek wrote:

> The reason why storing the config inside the qcow2 file is you have one
> self-contained file that can be updated by qemu itself.
>
> So you take an image file, point your management console to it, boot
> it, change something on it, shut it down, and publish the image as the
> new revision of the VM.
>
> With the tar file the management console needs to chew the tar file,
> save a copy of the config file and the disk image somewhere, and when
> you update the image you have to re-export the tar file.

That's not necessarily true.  We're arguing that as long as the qcow2 
image is last in the tar file, it should still be relatively easy to 
write a qemu block driver that manages tar files for in-place qcow2 
editing.  GNU tar can also do --append or --update to modify the config 
file; although we may have to be careful if that starts to make the 
qcow2 image not the last member in the tar file.  On the other hand, if 
updating the config file is a common enough operation, I would not be 
surprised if we end up teaching the qemu tar driver how to resize images 
even when the qcow2 portion of the tar file is not last, or adding 
qemu-img commands that wrap typical tar file manipulations.

> This is a lot of lengthy copying. The upside is that the console can
> check that the machine you are exporting is not running an you are not
> prone to publishing images in inconsistent state.

Read-only qcow2 within a tar does NOT require lengthy copying.  Updating 
qcow2 within tar might, but then again, we are arguing that with a sane 
layout, copying the ENTIRE qcow2 portion is NOT always going to be 
necessary.  For example, modern Linux has things like 
fallocate(FALLOC_FL_INSERT_RANGE) (on file systems that are capable) for 
enlarging the head of a tar file enough to stick in a larger config file 
at the front, with a LOT less data movement effort when compared to 
moving the qcow2 tail of that same tar file.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org