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

[Daniel P. Berrange]

On Mon, Mar 04, 2013 at 03:04:53PM +0100, Kevin Wolf wrote:
> 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:

The issue is that QEMU is not the only thing that implements the qcow
format. There are a number of other impls out there, and we can't just
assume that they will all be providing a qcow2 driver that automagically
opens a qcow3 image format. Just in the same way we didn't assume that
a 'qcow' (version 1) driver would open a version 2 image.

It so happens that with QEMU if you specify format=qcow2 and give it
a qcow3 image, QEMU will open it, but libvirt can't assume that, since
this is a mere implementation detail. Hence libvirt must explicitly
refer to 'qcow3' in the XML and map it to qcow2 if applicable when
talking to QEMU.

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

Yes, but that is really a bug in our representation of vmdk.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|