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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list