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