On Fri, Sep 29, 2017 at 03:56:53PM +0200, Michal Privoznik wrote: > On 09/29/2017 01:52 PM, Daniel P. Berrange wrote: > > On Fri, Sep 29, 2017 at 12:09:52PM +0100, Daniel P. Berrange wrote: > >> On Fri, Sep 29, 2017 at 01:04:34PM +0200, Michal Privoznik wrote: > >>> On 09/29/2017 10:49 AM, Daniel P. Berrange wrote: > >>>> On Fri, Sep 29, 2017 at 09:06:01AM +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 > >>>>> tag 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'/> > >>>>> <alias user='myDisk0'/> > >>>> > >>>> I really do not like this - having two arbitrary string alias names is > >>>> just crazy. > >>> > >>> Why is that? We have plenty of elements that do not match to anything at > >>> hypervisor level. Firstly, there's metadata. Secondly, aliases in lxc > >>> driver don't match anything either. And one can argue that the link in > >>> qemu can be broken too. I mean, it's just for now that the aliases we > >>> report happen to be device IDs we put onto the qemu's cmd line. Not to > >>> mention devices that we put there and not report in the domain XML => no > >>> IDs visible there. > >> > >>>> If we want to add a second attribute to uniquely identify > >>>> devices, then it should be a UUID IMHO, so it at least has some tangible > >>>> benefit instead of just duplicating the existing id format > >>> > >>> I'm failing to see why UUID is better than any arbitrary string. You > >>> mean we would generate the UUIDs if not supplied by user? > >> > >> Some hypervisors could map UUIDs to individual devices, so it is a more > >> generally useful concept. > > > > Also if we have APIs that accept an 'alias' string, we cannot extend them > > to support the user's own 'alias' unless we guarantee the user supplied > > alias is different from the alias we give to QEMU. > > We can if we document that libvirt generated aliases take precedence > over user ones. That way we can keep the backward compatibility. No, that's fragile. If libvirt were ever to change its alias name for something there is a risk it might clash with an app name, which previously did not clash. > > If we used UUID format, > > however, we don't have any ambiguity between a string that's an alias and > > a string that's a UUID. > > So IIUC users would be able to specify UUID for devices they want and > for the rest libvirt will generate new one? That'll make XMLs a lot > bigger. If we will not generate UUIDs, but just store ones provided by > user this also makes sense then. Although, dealing with UUIDs is very > user unfriendly, but that ship sailed a long time ago :-P I would not generate UUIDs - only have them if the app asked for them, or if the hypervisor we're using has assigned them itself. 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
