The Friday 16 May 2014 à 08:20:22 (-0600), Eric Blake wrote :
On 05/16/2014 08:07 AM, Peter Krempa wrote:
It feels rather odd to have <backingStore> elements but no top level disk images. Really these are all top level images
It reflect the ways QEMU does it. A single BlockDriverState holding n quorum BlockDriverState children. There is a 1-1 mapping.
How would you see it ?
We'd rather see multiple source elements for the top level disk. Backing store is the property of the source image, thus every single of those sources should have it's own list. (or perhaps a tree?)
I don't see how you can possibly have multiple source elements. Remember, part of the determination of what forms a valid <source> element is the type='...' attribute tied to the <disk> parent element - but you can't have duplicate attributes. As I see it, a quorum HAS to be a special chain element with 0 sources and multiple backingStore children, where each backingStore then includes the type='...' attribute for how to interpret the <source> element of that child.
Additionally quorum support taking snapshots so we need one entity to bind them together. Best regards Benoît
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list