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

[Daniel P. Berrange]

On Wed, Mar 12, 2014 at 05:34:17PM -0600, Eric Blake wrote:
> Hmm.  Another feature coming down the pipes in qemu 2.0 is the ability
> to give an alias to any portion of the backing chain.  Right now, we
> have an <alias> element tied to the <disk> as a whole (in qemu parlance,
> the device id), but some qemu operations will be easier if we also have
> a name tied to each file in the chain (in qemu parlance, a node id for
> the bd [block driver structure]).  Maybe we kill two birds with one
> stone, by having each <backingStore> track an <alias> sub-element with
> the name of the node, when communicating with qemu 2.0 and newer.

I like the idea of having a string-alias against each node to  allow
unambigously references to it. We could do an integer index, but a
string alias is a bit more flexible, allowing us to tie the alias value
to the QEMU name if desired.

> Right now, <alias> is currently a run-time and output-only parameter,
> but we someday want to support offline block-pull and friends, where
> we'd need the index to exist even when <alias> does not. 

Originally we only output <alias> when running because older QEMUs
did not allow us to choose aliases ourselves. We could only decide
what aliases to use when we decide what QEMU binary to invoke. As
long as we know that QEMU will honour our requested aliases, though
we could include that while shutoff too.

At some point we should also probably decide to ditch support for
some older QEMU versions. Backcompat is good....within reason. I
don't think we need to neccessarily support QEMU versions that are
7+ years old, not least because so few people use such old versions
that we're not getting any real testing so don't really know whether
they still even work.

> On snapshot, we are going from:
> 
> domainDiskDef (counter 1, alias "ide0-0-0")
>  + domainDiskSrcDef (node "ide0-0-0[0]", source "base")
> 
> to:
> 
> domainDiskDef (counter 2, alias "ide0-0-0")
>  + domainDiskSrcDef (node "ide0-0-0[1]", source "snap")
>    + domainDiskSrcDef (node "ide0-0-0[0]", source "base")
> 
> Note that the node names grow in order of creation, which is NOT the
> same as a top-down breadth-first numbering.  <alias> and nodeid would be
> output only (ignored on input); as long as qemu is running we cannot
> reuse old nodeids, but when qemu is offline, we could rename things to
> start back from 0; maybe only when passed a specific flag (similar to
> the update cpu flag forcing us to update portions of the xml that we
> otherwise leave unchanged).
> 
> Do we need both a node id and a <backingStore> index?  We already allow
> disk operations by <alias> name; so referring to the node id may be
> sufficient.  On the other hand, having index as an attribute might make
> it easier to write XPath queries that resolve to a numbered node
> regardless of depth (I'm a bit weak on XPath, but there's bound to be a
> way to lookup a <disk> element whose target is named "vda" and that has
> a "backingStore[index=4]" sub-element).

Node-id feels like a very QEMU specific concept that wouldn't map
nicely for other hypervisors. Index meanwhile is fairly generic,
as is a string-format alias. So I'd prefer either of the latter
over a QEMU specific 'node' attribute


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