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

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(a)redhat.com&gt; >>> --- >>> >>> 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 -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list