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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list