ansible/changelogs/fragments/69352-netbsd-virtual-facts.yml
Rick Elrod 707458cc8c
Make netbsd virtualization facts more specific ()
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 , 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 

Signed-off-by: Rick Elrod <rick@elrod.me>
2020-07-07 17:28:13 -05:00

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)