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. 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
