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

[Michal Privoznik]

On 10/20/2017 01:38 PM, Pavel Hrdina wrote:
> 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.

Yeah. Just don't forget the ancient QEMU part. So the whole story is
that if you're running QEMU that's lacking -netdev, and you want to
hotplug an interface with user supplied alias, we error out. Yeah, I'm
okay with that. We have to draw a line somewhere and say: yeah, it's
probably bad behaviour, be we don't care. Patches are welcome.

Michal