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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list