On 09/29/2017 09:52 AM, Peter Krempa wrote:
On Fri, Sep 29, 2017 at 09:06:01 +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'/>
> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
> </disk>
>
> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> ---
>
> An alternative approach to:
>
>
https://www.redhat.com/archives/libvir-list/2017-September/msg00765.html
>
> Honestly, I prefer this one as it's simpler and we don't have to care about
> devices changing their aliases on cold plug. I mean, on cold (un-)plug we'd
> have to regenerate the aliases so it might be hard to track certain device.
> But with this approach, it's no problem.
>
> Also, I'm not completely convinced about the name of @user attribute. So I'm
> open for suggestions.
With this proposed design you need to make sure to document that the
user alias is _not_ guaranteed to be unique and also that it can't be
used to match the device in any way.
Sure. I'll just add it at the end of the paragraph that describes
<alias/>. Err, hold on. There's none! But okay, I think I can find a
place to add it there.
Even though my patch doesn't implement it (simply because I wanted to
have ACK on the design so I've saved it for follow up patches), I don't
quite see why we can't match user supplied aliases?
virsh domif-setlink fedora myNet down
This has the great advantage of being ordering agnostic. You don't have
to check for the alias of the device you want to modify (as aliases can
change across different startups, right?). True, for that we would have
to make sure that the supplied aliases are unique per domain (which is
trivial to achieve). But apart from that I don't quite see why we
shouldn't/can't do it.
I think that users which know semantics of the current alias may be
very
confused by putting user data with different semantics into the same
field.
Yep. As I say, I'm not happy with the name either. Any suggestion is
welcome. So a separate element then? Naming is hard.
Michal