On Tue, Oct 03, 2017 at 05:08:53PM +0200, Michal Privoznik wrote: > 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 <mpriv...@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.
Discontinuous aliases is a complete non-issue IMHO. The alias is an opaque string, so no one should care whether the last digit is a 0 or a 2. The scenario already happens if you hotplug/hotunplug a bunch of devices - the VM will have discontinuous aliases for as long as it carries on running. > 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. Apps would rely on fact that the devices appear in the XML they get back in the same order as they originally had in the input XML. The troublespoot is around devices which magically appear - <controller> elemenets essentially. > 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. Yes, if we generate aliases at define time we must honour those aliases for as long as that persistent config exists & never change them behind the apps back. This would imply we need to persist the aliases into /etc/libvirt/qemu/ so they're saved across restarts of libvirtd. Hmm, once we persist them in /etc/libvirt/qemu, we have effectively got the same scenario as if we just let applications define aliases upfront in the XML they give us, as its the same code paths. I wonder if we just have to give up & let apps define aliases themselves. The thing I disliked about that is that the permitted alias format is hypervisor specific, but perhaps we just have to document restrictions per hypervisor. > > 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 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
