Re: [libvirt] RFC: Exposing backing chains in <domain> XML
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 :|