[libvirt] [PATCH v2 3/3] conf: Allow users to define UUID for devices

[Jim Fehlig]

On 10/03/2017 07:53 AM, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 02:11:44PM +0200, Martin Kletzander wrote:
>> On Tue, Oct 03, 2017 at 12:58:59PM +0200, Michal Privoznik wrote:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1434451
>>>
>>> It comes handy for management application to be able to have a
>>> per-device label so that it can uniquely identify devices it
>>> cares about. The advantage of this approach is that we don't have
>>> to generate aliases at define time (non trivial amount of work
>>> and problems). The only thing we do is parse the user supplied
>>> UUID and format it back. For instance:
>>>
>>>     <disk type='block' device='disk'>
>>>       <driver name='qemu' type='raw'/>
>>>       <source dev='/dev/HostVG/QEMUGuest1'/>
>>>       <target dev='hda' bus='ide'/>
>>>       <uuid>1efaf08b-9317-4b0f-b227-912e4bd9f483</uuid>
>>>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>>>     </disk>
>>>
>>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>>> ---
>>>
>>> This is just a very basic implementation. If I get a green light on this, I can
>>> implement the feature further, i.e. allow device lookup on the UUID. For
>>> instance:
>>>
>>> virsh domiftune fedora $UUID $bandwidth
> 
> <snip>
> 
> I'm thinking that part of the problem we're having with agreeing how to
> deal with this RFE is that we're over-analysing semantics, by wondering
> whether its a unique name or UUID, its relation to alias, whether it has
> bearing on APIs.
> 
> How about we change tack, and do what we did when we needed application
> specific information at the top level - just declare a general purpose
> <metadata> element and say it is a completely opaque blob. Libvirt will
> *never* do anything with it, other than to preserve it exactly as is.
> No API will ever use the metadata in any way. Libvirt will never try to
> guarantee uniqueness of metadata for each device. It can be JSON or a
> gziped microsoft word document for all we care. Entirely upto the app
> developer to decide what metadata is saved and guarantee uniqueness if
> they so desired.

I vote for the opaque blob since it would be helpful for my use case described here

https://www.redhat.com/archives/libvir-list/2017-October/msg01329.html

The <metadata> element could contain the 'some-dev-config' from my example and 
alleviate the need to modify XML. <metadata> at the device level is a bit 
cleaner for hot (un)plug IMO. E.g.

virsh attach-device foo << 'EOF'
   <disk type='block' device='disk'>
     <metadata>some-dev-config</metadata>
     <driver name='qemu' type='raw'/>
     <source dev='/dev/vg1/lv1'/>
     <target dev='vdb' bus='virtio'/>
   </disk>
EOF

Regards,
Jim