[PATCH] libxl: Turn on user aliases
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.
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 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.
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 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, };
participants (4)
-
Jim Fehlig -
Laine Stump -
Michal Privoznik -
Peter Krempa