On 03/14/2014 07:59 AM, Richard W.M. Jones wrote: > On Fri, Mar 14, 2014 at 10:53:48AM +0000, Daniel P. Berrange wrote: >> 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. > > You either have to force the caller to provide an alias for each node, > or you have to auto-assign them. But if you auto-assign them (say > "node123"), what if the user provides a label for that node later on? > What if the user gives that label to a different node? Right now, we auto-assign. Another good reason to auto-assign is that the alias namespace is shared among ALL qemu objects - allowing the user to pick arbitrary names risks collisions not only with other disk objects, but with non-disk objects. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list