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.

Resolves: https://gitlab.com/libvirt/libvirt/-/issues/231
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 src/libxl/libxl_domain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index c91e531a9a..0816c5baa4 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -452,7 +452,8 @@ virDomainDefParserConfig libxlDomainDefParserConfig = {
     .domainPostParseCallback = libxlDomainDefPostParse,
     .domainValidateCallback = libxlDomainDefValidate,
 
-    .features = VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
+    .features = VIR_DOMAIN_DEF_FEATURE_USER_ALIAS |
+                VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
                 VIR_DOMAIN_DEF_FEATURE_NET_MODEL_STRING,
 };
 
-- 
2.34.1

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.
> 
> Resolves: https://gitlab.com/libvirt/libvirt/-/issues/231
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>   src/libxl/libxl_domain.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Jim Fehlig <jfehlig@suse.com>

Regards,
Jim

> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index c91e531a9a..0816c5baa4 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -452,7 +452,8 @@ virDomainDefParserConfig libxlDomainDefParserConfig = {
>       .domainPostParseCallback = libxlDomainDefPostParse,
>       .domainValidateCallback = libxlDomainDefValidate,
>   
> -    .features = VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
> +    .features = VIR_DOMAIN_DEF_FEATURE_USER_ALIAS |
> +                VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
>                   VIR_DOMAIN_DEF_FEATURE_NET_MODEL_STRING,
>   };
>

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?

Regards,
Jim

> Resolves: https://gitlab.com/libvirt/libvirt/-/issues/231
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>   src/libxl/libxl_domain.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index c91e531a9a..0816c5baa4 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -452,7 +452,8 @@ virDomainDefParserConfig libxlDomainDefParserConfig = {
>       .domainPostParseCallback = libxlDomainDefPostParse,
>       .domainValidateCallback = libxlDomainDefValidate,
>   
> -    .features = VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
> +    .features = VIR_DOMAIN_DEF_FEATURE_USER_ALIAS |
> +                VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
>                   VIR_DOMAIN_DEF_FEATURE_NET_MODEL_STRING,
>   };
>

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.

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.

On 3/2/22 01:29, 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.

Nod, agree it does make sense :-).

Regards,
Jim

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.
>