[libvirt] RFC: Exposing backing chains in <domain> XML

[Daniel P. Berrange]

On Sat, Apr 12, 2014 at 08:49:50PM -0600, Eric Blake wrote:
> On 03/12/2014 02:21 PM, Eric Blake wrote:
> > tl;dr:
> > I am working on a series of patches to expose backing chain information
> > in <domain> XML.  Comments are welcome, to make sure my XML design is on
> > the right track.
> > 
> 
> > 
> > A backing chain of 3 files (base <- mid <- top) in the local file system:
> > 
> >     <disk type='file' device='disk'>
> >       <driver name='qemu' type='qcow2'/>
> >       <source file='/var/lib/libvirt/images/top.qcow2'/>
> >       <backingStore type='file'>
> >         <driver name='qemu' type='qcow2'/>
> >         <source file='/var/lib/libvirt/images/mid.qcow2'/>
> >         <backingStore type='file'>
> >           <driver name='qemu' type='qcow2'/>
> >           <source file='/var/lib/libvirt/images/base.qcow2'/>
> >           <backingStore/>
> >         </backingStore>
> >       </backingStore>
> >       <target dev='vda' bus='virtio'/>
> >     </disk>
> 
> Now that I've been working on virStorageSource for a while, I think I
> want to modify this slightly.  Most attributes of <driver> are
> per-device (things you only set once, such as cache='writethrough');
> furthermore, the <volume> XML for storage volumes uses a dedicated
> <format type='qcow2'/> rather than a <driver> element.  For back-compat,
> we can't drop the old spelling, but I'm thinking the backing chain
> should prefer <format>.  So if we use nested format, it would look
> something like:
> 
>     <disk type='file' device='disk'>
>       <format type='qcow2'/>
>       <source file='/var/lib/libvirt/images/top.qcow2'/>
>       <backingStore type='file'>
>         <format type='qcow2'/>
>         <source file='/var/lib/libvirt/images/mid.qcow2'/>
>         <backingStore type='file'>
>           <format type='qcow2'/>
>           <source file='/var/lib/libvirt/images/base.qcow2'/>
>           <backingStore/>
>         </backingStore>
>       </backingStore>
>       <driver name='qemu' type='qcow2' cache='writethrough'/>
>       <target dev='vda' bus='virtio'/>
>     </disk>
> 
> Or with Dan's proposal to prefer a flat listing, something like:
> 
>     <disk type='file' device='disk'>
>       <id index='1'/>
>       <format type='qcow2'/>
>       <source file='/var/lib/libvirt/images/top.qcow2'/>
>       <backingStore type='file'>
>         <id index='2' parent='1'/>
>         <format type='qcow2'/>
>         <source file='/var/lib/libvirt/images/mid.qcow2'/>
>       </backingStore>
>       <backingStore type='file'>
>         <id index='3' parent='2'/>
>         <format type='qcow2'/>
>         <source file='/var/lib/libvirt/images/base.qcow2'/>
>       </backingStore>
>       <backingStore/>
>       <driver name='qemu' type='qcow2' cache='writethrough'/>
>       <target dev='vda' bus='virtio'/>
>     </disk>
> 
> As I look at it, I'm also worried that a flat listing makes it hard to
> tell the difference between a partial chain (for example, we know 'top'
> has a backing of 'mid', but haven't followed the chain to see if 'mid'
> also has a backing file) vs. an explicit end of the chain.  At least
> with the nested listing, a <backingStore/> marker fits in better.

Ok, I won't object to using a nested listing, since that's what most
folks seem to prefer. Hopefully apps won't create chains that go
crazy deep :-)

Regards,
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 :|