707458cc8c
Change: Our handling of NetBSD virtualization facts led to facts that were just plain incorrect. One example is reporting Xen even when the system is running on something completely different (like KVM). As stated by the reporter of #69352, NetBSD has a better sysctl setting to use for this information, machdep.hypervisor. This PR does the following: - Try to use machdep.hypervisor sysctl value if the other sysctl values we check don't end up with enough information to be useful - Only look for /dev/xencons and assume Xen if nothing else works (Really this should probably return 'unknown' since the file exists on non-Xen systems and is not very useful). - Add a few more patterns (Xen matches and also Hyper-V) to VirtualSysctlDetectionMixin#detect_virt_product. This change is slightly breaking: - If the first two attempts at using sysctl worked before, (machdep.dmi.system-product and machdep.dmi.system-vendor), they will continue to work. - For cases when those values didn't work, previously the existence of /dev/xencons was checked, and if found, we reported 'xen' (even on non-Xen systems when the file existed). After this PR, we try the machdep.hypervisor sysctl key before still falling back to /dev/xencons. This means that in some cases, we might go from (wrongly) saying "xen" to giving a more accurate value such as "kvm" or "Hyper-V". Test Plan: - Tested with local NetBSD VM and got 'kvm' instead of 'xen' back. Tickets: - Fixes #69352 Signed-off-by: Rick Elrod <rick@elrod.me>
2 lines
430 B
YAML
2 lines
430 B
YAML
breaking_changes:
|
|
- NetBSD virtualization facts (specifically ``ansible_virtualization_type``) now returns a more accurate value by checking the value of the ``machdep.hypervisor`` ``sysctl`` key. This change is breaking because in some cases previously, we would erroneously report ``xen`` even when the target is not running on Xen. This prevents that behavior in most cases. (https://github.com/ansible/ansible/issues/69352)
|