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

[Daniel P. Berrange]

On Wed, Mar 12, 2014 at 02:21:46PM -0600, Eric Blake wrote:
> # virsh vol-dumpxml --pool gluster img3
> <volume type='network'>
>   <name>img3</name>
>   <key>vol1/img3</key>
> ...
>   <target>
>     <path>gluster://localhost/vol1/img3</path>

A shame we chose this representation instead of something that
matched the format used in the domain XML. At least we can add
the domain XML format here without breaking compat.

> Proposal
> ========
> For each <disk> of a domain, I will be adding a new <backingStore>
> element.  The element is optional on input, which allows libvirt to
> continue to understand input from older versions, but will always be
> present on output, to show what libvirt is tracking as the backing chain.
> 
> For a file with no backing store (including raw file format), the usage
> is simple:
> 
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='raw'/>
>       <source file='/path/to/somewhere'/>
>       <backingStore/>
>       <target dev='vda' bus='virtio'/>
>     </disk>
> 
> The new explicit <backingStore/> makes it clear that there is no backing
> chain.
> 
> 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>
> 
> Note that this is intentionally nested, so that for file formats that
> support more than one backing resource, it can list parallel
> <backingStore> as siblings to describe those related resources (thus
> leaving the door open to expose a qemu quorum as a <disk type='quorum'>
> with no direct <source> but instead with three <backingStore> sibling
> elements for each member of the quorum, and where each member of the
> quorum can further have its own backing chain).

I understand why you chose to use nesting, but I can't say I like
the appearance of nesting. I think that in the common case where
we have a single non-branching chain, the XML structure is kind of
unpleasant and would be nicer if just a flat list. Using nesting
makes it harder to extract info about backing files from the XML
structure with XPath because you can't simply ask for all <source>
elements at a given location.

If we're going to add <alias> I wonder if we should just use that
to express the nesting. eg have a flat list of <backingStore>
ordered by a depth first search, and then have <alias parent="foo" name="bar"/>
to express the nesting. That would allow nesting info to be extracted
for the few scenarios that actually need it, but keep the common case
simple.

> Implementation
> ==============
> The following APIs will be affected:
> 
> defining domain XML (whether via define for persistent domains, or
> create for transient domains): parse the new element.  If the element is
> already present, default to trusting the backing chain in that element
> instead of reading from the disk files.  If the element is absent, read
> the disk files and populate the element.  It is probably also worth
> adding a flag to trigger validation mode: read the disk files to ensure
> they match the xml, and refuse the operation if there is a mismatch (as
> for updating xml to match reality, the simplest is to edit the XML and
> delete the <backingStore> element then try the define again, so I don't
> see the need for a flag for that action).
> 
> I may also need to figure out if it is worth tainting a domain any time
> where libvirt detects that the XML backing chain vs. the disk file read
> backing chain have diverged.

I don't think we want todo that - there are genuine use cases where
that is a reasonable thing todo. eg you can provide a raw file to a
guest and that guest may genuinely want to format the virtual disk
it received with some other format. We don't want to taint such use
cases.

> dumping domain XML: always output the new element, by default without
> consulting disk files. By tracking the chain in memory ever since the
> guest is defined, it should already be available for output.  I'm
> debating whether we need a flag (similar to virsh dumpxml --update-cpu)
> that can force libvirt to re-read the disk files at the time of the dump
> and regenerate the chain to match reality of any changes made behind
> libvirt's back.

It feels like apps should just query the storage pool APIs if they
want to fetch refreshed notion of backing file formats.

> sVirt security labeling: right now, we are read the disk files to both
> label and remove labels on a backing chain - obviously, once the chain
> is tracked natively as part of the <disk>, we should be labeling without
> having to read disk files

We also likely want to be able to set labels in the XML against individual
backing files too, so we're not unconditionally using a read-only label
for backing files which may soon need write ability.


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