Re: [libvirt] [PATCH v1 00/14] Never ending story of user supplied aliases

On Fri, Oct 20, 2017 at 01:20:20PM +0200, Michal Privoznik wrote: > On 10/19/2017 03:33 PM, Pavel Hrdina wrote: >> On Thu, Oct 19, 2017 at 10:10:55AM +0200, Michal Privoznik wrote: >>> As discussed earlier [1], we should allow users to set device >>> aliases at the define time. While the discussed approach calls >>> for generating missing aliases too, I'm saving that for another >>> patch set. There are couple of reasons for that: >>> >>> a) I don't think it's really necessary (if users are interested >>> in a device they can just set the alias). >>> >>> b) This patch set is already big enough as is. >>> >>> c) Generating aliases is going to have its own problems. >>> >>> Therefore, for now I'm only proposing parsing user supplied >>> aliases. The idea is that it's not enabled by default for all >>> drivers. Any driver that want to/can provide this feature has to >>> set VIR_DOMAIN_DEF_FEATURE_USER_ALIAS. Note that we have some >>> drivers that don't have notion of device aliases. But the code is >>> generic enough so that it should be easy to use in the drivers >>> that do know what aliases are. >> >> This patch series missed some of the important parts of code >> that relies on our generated aliases: >> >> 1. qemuGetNextChrDevIndex() ... this will fail while attaching new >> chardev device without an alias if there is one already provided >> by user and doesn't match the one that we generate. >> >> 2. qemuAssignDeviceRedirdevAlias() ... same as 1) >> >> 3. qemuAssignDeviceShmemAlias() ... same as 1) > > Okay, these are easy to resolve. > >> >> 4. qemuDomainNetVLAN() ... similar to the previous ones, hot-plugging >> network interface with user alias will fail because the alias is used >> to figure out VLAN of the interface. > > This one. Well, this function is called only for ancient QEMUs (those > which lack QMP, and even not for all of them). So do we care? Sure, I > can cripple my code and allow user aliases only if running sufficiently > new QEMU. Or just shrug and walk away. In that case just ignore it, it will print an error message and since this will affect only hot-plug of network devices with user alias specified we can claim that this operation is unsupported.