Re: [libvirt] [PATCH alt] conf: Allow user define their own alias
On 10/03/2017 04:19 PM, 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'/>
> <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.
Can you elaborate on you mean by the cold plug problem here ?
Are you saying that if you cold plug a single device, we would regenerate
aliases on every single other device too ? I would surely think we can
avoid that kind of thing.
Not every other device, but lets consider interfaces for instance. Lets
say that a domain has two interfaces: vnet0 and vnet1. User detaches
vnet0. Should vnet1 be renamed to vnet1? Domain is not running, so it
can. But that puts a lot of burden on mgmt app to fix its internal state
as a result of the rename. Okay, so we don't rename it. The next
interface plugged is going to have name of vnet2. So in the end we will
have discontinuous aliases.
But from greater perspective, since users/mgmt app are not the one who
generate the alias, we would be just transforming problem to a different
one. I mean, even now can users uniquely identify devices - by addresses
(PCI, USB, ...) Having them to find alias we generated for the device
they are interested in is the same problem as finding its address.
Unless they can specify the ID (whether its attribute of <alias/> or
<metadata/> per device, or whatever), they will be chasing libvirt.
Worse, what if we need to change the scheme by which the aliases are
generated? We can't do that for persistent domains as we would be
breaking the link between what mgmt app expects to see and what it
actually sees. You know what I mean.
To make hotplug easier for applications we could add a V2 hotplug API
which *returns* the fully-expanded device XML.
That way applications would immediately learn the alias of the newly
hotplugged device in a simple manner.
While we were at it, this would give us opportunity to make the v2
hotplug API support hotplugging of multiple devices at once. This is
a feature we've needed for PCI assignment where some devices have to
be co-assigned at the same time.
Feels a bit out of scope of this feature. Definitely worth having such
API, just not quite sure it fits within this feature. I mean, that'd be
a lot of work.
Michal