On recent amd64 hardware (I haven't tested on ARM), and if the "virt-what" package is installed, "facter virtual is_virtual" in a Xen dom0 returns "virtual => xenhvm" and "is_virtual => true". On some older hardware it returns "virtual => xen0" and "is_virtual => false". If I uninstall the "virt-what" package it returns "virtual => xen0" and "is_virtual => false" on both old and new hardware. Is this a bug in facter or in virt-what? Formally, a Xen dom0 is indeed a virtual machine, albeit a rather special one, and virt-what only reports (faithfully, as far as I could see) what it gets from the cpuid instruction; so the problem, in my view, is rather how facter makes use of the information from virt-what. In practice, I prefer for the dom0 to have is_virtual => false since I use is_virtual to decide on such things as whether to install intel-microcode (which doesn't really make sense in a guest domain). I could live with "virtual => xen0, is_virtual => true" since that also lets me single out the dom0. "virtual => xenhvm" for the dom0, on the other hand, doesn't give me enough information. There are also differences in behavior with and without virt-what in a PVH domU. With virt-what I get "virtual => xen" instead of "virtual => xenu". (The underlying hardware doesn't seem to play a role here.)
systemd has a similar issue, tracked in #1038901. (Maybe one should ask the virt-what maintainers whether they agree with https://github.com/systemd/systemd/issues/28113#issuecomment-1621986461, in which case this bug can be reassigned to virt-what.)
Actually the origin of the bug could indeed be facter. If you look at the virt-what resolver [0], it's just matching for strings in the output. If the output of virt-what contains both 'xen-hvm' and 'xen-dom0' then 'xenhvm' is going to be used because 'xen-hvm' will match first. It's possible we might want to actually match for 'xen-dom0' *first*, but this all depends on virt-what's full output. Would it be possible to share here what virt-what is outputting both on dom0 and domU? Thanks,
-------------------------------------------------- # virt-what --version 1.25 # virt-what xen xen-hvm # facter virtual xenhvm # apt-get purge virt-what Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: virt-what* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 50.2 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 87238 files and directories currently installed.) Removing virt-what (1.25-1) ... Processing triggers for man-db (2.11.2-2) ... # facter virtual xen0 ------------------------------------------------- So no, the output of virt-what does not contain "xen-dom0" at all. In a (PVH) bookworm domU: ------------------------------------------------- # virt-what --version 1.25 # virt-what xen xen-domU # facter virtual xen # apt-get purge virt-what Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: virt-what* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 50.2 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 84955 files and directories currently installed.) Removing virt-what (1.25-1) ... Processing triggers for man-db (2.11.2-2) ... # facter virtual xenu -------------------------------------------------------- I also think it's wrong for the fact value to depend on whether virt-what is installed. (In a guest, I get "xenu" if virt-what is absent, "xen" if it is present. This adds unnecessary complexity to Puppet manifests.) As far as I'm concerned facter should not use virt-what. I achieve this on my systems by removing virt-what (I had to re-add it manually in order to produce the test output above).
Le 2024-09-02 à 05 h 34, Sergio.Gelato@astro.su.se a écrit : According to this output, it definitely looks like virt-what is at fault here. Reassigning. At best, facter and virt-what should agree on about the virtualisation environment, otherwise virt-what should more precise than facter by itself.