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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list