Re: [Qemu-devel] [RFC] qcow3 format in libvirt

[Kevin Wolf <kwolf@redhat.com>]

Am 04.03.2013 um 14:09 hat Daniel P. Berrange geschrieben:
> On Mon, Mar 04, 2013 at 01:58:12PM +0100, Ján Tomko wrote:
> > Before posting another version of my patches [1], attempting to add
> > support for the new qcow format to libvirt, I would like to know if this
> > sounds reasonable:
> > 
> > A new format named 'qcow3' would be added, along with a <features>
> > sub-element for target.
> > 
> > <volume>
> >   <name>qcow3test</name>
> >   <source>
> >   </source>
> >   <capacity unit='GiB'>8</capacity>
> >   <target>
> >     <path>/var/lib/libvirt/images/qcow3test</path>
> >     <format type='qcow3'/>
> >     <features>
> >       <lazy_refcounts/>
> >     </features>
> >   </target>
> > </volume>
> > 
> > I think that libvirt shouldn't care if the features are compatible or
> > incompatible, as we don't know what features are supported by the
> > hypervisor. Would the features be any good as tri-state (on, off, default?).
> > 
> > While the qcow3 format is handled by the qcow2 driver in QEMU,
> > <driver name='qemu' type='qcow2'/> should be enough for domains,
> 
> We should use qcow3 everywhere IMHO, regardless of whether qcow2
> technically works in this context.

I think it makes much more sense to deal with it the way qemu does
instead of inventing new names. This has much more of an (incompatible)
feature flag than of a different image format. So to fit it in your
proposed syntax:

<target>
  <path>/var/lib/libvirt/images/qcow3test</path>
  <format type='qcow2'/>
  <features>
    <compat version="1.1" />
    <lazy_refcounts/>
  </features>
</target>

Or if you really think that you should refer to the inner workings of
qcow2, you can make it <version>3</version>.

But I guess you call all VMDKs just "vmdk", despite the fact that they
are really just a collection of different subformats. Right?

Kevin