systemd-detect-virt falsely detects "Microsoft" virtualisation

[mbiebl]

Version: 249.7
Downstream bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000396

systemd-detect-virt checks /sys/class/dmi/id/sys_vendor as part of its
attempt to detect if the system is virtualised. I am using a Surface
Laptop so sys_vendor returns "Microsoft Corporation" which (as far as I
can tell) the program assumes indicates the presence of hyper-v rather
than Microsoft produced hardware. One of the consequences is that
systemd units that won't run in a VM fail, such as thermald.

Afaics, this is a result of PR #20998

506bbc8

@fbq ^

[bluca]

Yep that's not quite right. @fbq please reopen, I guess your first version that checked for /dev/vmbus is a better alternative?

[poettering]

I'd much prefer if we go by comparing strings, instead of relying on driver support. (i mean, it could be the kernel has vmbus support disabled, we still should be able to detect a microsoft virtualization)

Can't we make the strings check more precise? i.e. obviously "Microsoft" is very generic a check. But making the string check more precise should get us there, no? What are the strings reported by Surface and the VM environment?

[bluca]

I don't think vmbus can be disabled individually? It's enabled by building support for hyperv guest

[poettering]

still, checking for devices sucks, since they might come late, think udev and so on. Also it requires special code and stuff. I much prefer identifying by strings.

(And who knows, maybe some other VM env implements /dev/vmbus one day too? At least Synology NAS devices support "hyperv-enlightened" VMs that are actually backed by kvm)

[bluca]

Sure, if there's an alternative it would be much better

[fbq]

Yep that's not quite right. @fbq please reopen, I guess your first version that checked for /dev/vmbus is a better alternative?

Checking for /dev/vmbus can solve the problem that @mbiebl hit, however, I agree with @poettering, comparing strings is better. And in theory a Hyper-V VM can "run" without any VMbus (it can run, but cannot interact with the outside world).

I just checked other fields in DMI, it turned out that we have string "Hyper-V" in the following fields /sys/class/dmi/id/{product,sys,board,bios}_version, more precisely it's

Hyper-V UEFI Release v4.0

In my environment. We can detect whether it's a Hyper-V VM by checking whether /sys/class/dmi/id/product_version starts with "Hyper-V". Should I send another PR or should I change my previous PR?

[poettering]

Should I send another PR or should I change my previous PR?

Your PR already got merged. Please send a new follow-up PR!