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

Eric Blake eblake at redhat.com
Fri Mar 14 14:07:21 UTC 2014


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140314/7ad0e6bc/attachment-0001.sig>


More information about the libvir-list mailing list