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

[Eric Blake <eblake@redhat.com>]

On 06/06/2018 09:57 AM, Eric Blake wrote:
> 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.

On a completely different front, 'qcow2' as a file format comes with 
some psychological baggage.  If someone was using it 8 years ago, before 
we did coroutine optimizations, it was noticeably slower than raw, and 
relatively easier to get into a corrupted image condition that resulted 
in data loss.  Just one VM lost, and it leaves a sour taste in your 
mouth, where you are unwilling to trust that file format (even though 
the file format was not necessarily the cause of the corruption). 
Marketing-wise, we failed with our improvements ('qcow2v3' is so much 
more of a mouthful than 'qcow3'), and it took years to flip the defaults 
from v2 as the default to v3 as the default (moreso in downstream 
distros than upstream), in part because we couldn't convince people of 
the improvements they would be gaining by moving to v3.  Historically, 
there's also 'qed' which was promised as a way to fix some of the poor 
performance of qcow2, but which ended up not being any better than our 
actual qcow2v3 improvements, so no one ended up switching to that. So, 
to some extent, various high-level consumers still have the notion that 
'raw' files are better/safer/faster than 'qcow2' files because of an 
anecdote from years ago, even if we have since fixed the speed parity 
and added locking to eliminate careless data loss.

If we DO add a new tar-file block driver to qemu, that could serve as a 
marketing opportunity to convince people that the new format has all of 
the features that you can't get from just a raw file, and does not 
suffer from the slowness or data corruption they were worried about in 
qcow2.  Thus, even if our new format is just a thin wrapper around a 
config file plus the existing qcow2v3 we already know and love, the mere 
fact that it is a new format may get people to move away from raw images 
in situations where just the name 'qcow2' is unable to do so, at which 
point we can help them take advantage of the features made possible by 
qcow2.

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