[PATCH] libxl: Turn on user aliases

[Laine Stump]

On 3/2/22 3:29 AM, Peter Krempa wrote:
> On Tue, Mar 01, 2022 at 09:40:30 -0700, Jim Fehlig wrote:
>> On 2/17/22 04:56, Michal Privoznik wrote:
>>> When I implemented user aliases I've invented this
>>> virDomainDefFeatures flag so that individual drivers can signal
>>> support for user provided aliases. The reasoning was that a
>>> device alias might be part of guest ABI, or used in a different
>>> way then in QEMU. Well, neither applies to the libxl driver, so
>>> it's safe to allow user aliases there.
>>
>> I suppose it is safe, but does it make sense since aliases are not used by
>> the driver in any way, and not supported by libxl?
> 
> In that case at least the libvirt side user-visible aspect of it does
> make sense. Users can pick a stable alias for their device if they care
> about that for any reason.

...for example, in the qemu driver, the alias can be used as an index to 
match when unplugging or updating a device; in the case of an 
<interface>, in the past you could match the device to unplug/update by 
looking at the MAC address or PCI address, but the MAC address isn't 
necessarily unique, and PCI address is usually determined by libvirt, so 
the management application may not know it. But the management 
application can just explicitly provide an alias in the <interface> XML 
when the domain is defined, and then later use that as the key when 
unplugging/updating.

Matching on alias when searching for an <interface> was added for use by 
the QEMU driver back in commit 114e3b4232, but fortunately this search 
is done by virDomainNetFindIdx(), which is also used by the libxl 
interface update and unplug functions, so libxl will get this 
functionality for free once Michal's patch is pushed.

(I haven't looked at whether or not other types of devices are using 
alias in this manner either in the qemu or libxl drivers, but I assume 
at least some of them are)

> 
> In the qemu impl we decided to propagate it to the hypervisor, but that
> should be considered an implementation detail as the IDs of objects
> (mostly) don't have guest visible meaning.
>