On 05 Jul 2023 17:51, George Dunlap wrote:
Hey all,
The following systemd issue was brought to my attention:
https://github.com/systemd/systemd/issues/28113
I think basically, they want `systemd-detect-virt` return the following
values:
Xen on hardware, from a dom0: `none`
Xen on hardware, from a domU: `xen`
Xen in a VM, from a dom0: (ideally the virtualization type, or `vm-other`
if not)
Xen in a VM, from a domU: `xen`
Is there a reliable set of tests which would work across all dom0 guest
types / architectures? If not, can we expose the information somehow?
-George
Small follow-up, I did some more tests (AMD platforms).
systemd-detect-virt (sdv) is using "/sys/class/dmi/id/sys_vendor".
On both "baremetal" dom0s, sdv is reporting the platform manufacturer
("MSI" or "Micro-Star International Co., Ltd." on my systems).
On a nested dom0, sdv is reporting "xen" :
root@xen-nested:~# SYSTEMD_LOG_LEVEL=debug systemd-detect-virt
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
Virtualization Xen found in DMI (/sys/class/dmi/id/sys_vendor)
Found VM virtualization xen
xen
PS: my host "xen-nested" is not masking CPUID leaves in cfg file.
So I'm wondering, isn't that path enough for correct detection ?
I mean, if "/sys/class/dmi/id/sys_vendor" reports Xen (or KVM, or any
other known hypervisor), it's nested, otherwise it's on hardware ?
Is that really mandatory to use CPUID leaves ?
