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

[Daniel P. Berrange]

On Tue, Oct 31, 2017 at 07:04:35AM +0100, Michal Privoznik wrote:
> On 10/30/2017 11:12 PM, Jim Fehlig wrote:
> > On 10/30/2017 03:31 PM, Jim Fehlig wrote:
> >> 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
> > 
> > I should have read further ahead in my mail backlog, where I would have
> > discovered this has already be solved using <alias>. That's fine, but
> > I'm curious why the domain of permissible characters is restricted?
> > Could it include ():;/ ?
> 
> Currently, only: a-zA-Z0-9_- is allowed. This is because in qemu driver
> aliases are put onto qemu cmd line where only limited set of characters
> is allowed. However, the check for that could be moved to drivers so
> that each driver can define its own set of allowed characters.

That would not be particularly nice for an application that wants to set
aliases though. I think we should stick to a strict subset


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|