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@xxxxxxxxxx> > >>>>> --- > >>>>> > >>>>> 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
