You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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)
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?
Activity
bluca commentedon Nov 22, 2021
Yep that's not quite right. @fbq please reopen, I guess your first version that checked for /dev/vmbus is a better alternative?
poettering commentedon Nov 22, 2021
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 commentedon Nov 22, 2021
I don't think vmbus can be disabled individually? It's enabled by building support for hyperv guest
poettering commentedon Nov 22, 2021
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 commentedon Nov 22, 2021
Sure, if there's an alternative it would be much better
fbq commentedon Nov 23, 2021
Checking for
/dev/vmbuscan 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'sIn my environment. We can detect whether it's a Hyper-V VM by checking whether
/sys/class/dmi/id/product_versionstarts with "Hyper-V". Should I send another PR or should I change my previous PR?poettering commentedon Nov 23, 2021
Your PR already got merged. Please send a new follow-up PR!
virt: Fix the detection for Hyper-V VMs
virt: Fix the detection for Hyper-V VMs
virt: Fix the detection for Hyper-V VMs
Fixed false detect virt as microsoft by systemd-detect-virt