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

[Michal Privoznik]

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.

Michal