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. > but in snapshot XML we treat the driver type as the format: > > <disk name='/path/to/old'> > <driver type='qcow3'/> > <source file='/path/to/new'/> > <features> > <lazy_refcounts/> > </features> > </disk> > > So I think we should allow the qcow3 driver type as well and translate > it to qcow2 for QEMU. > > Jan > > [1] v2 here: > https://www.redhat.com/archives/libvir-list/2013-February/msg00212.html > 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 :|
