Skip to content

systemd-detect-virt falsely detects "Microsoft" virtualisation #21468

Closed

Description

@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 ^

Activity

  1. added this to the v250 milestone on Nov 22, 2021
  2. bluca commented on Nov 22, 2021

    @bluca
    Member

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

  3. poettering commented on Nov 22, 2021

    @poettering
    Member

    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?

  4. bluca commented on Nov 22, 2021

    @bluca
    Member

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

  5. poettering commented on Nov 22, 2021

    @poettering
    Member

    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)

  6. bluca commented on Nov 22, 2021

    @bluca
    Member

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

  7. fbq commented on Nov 23, 2021

    @fbq
    Contributor

    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?

  8. poettering commented on Nov 23, 2021

    @poettering
    Member

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

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

  9. added a commit that references this issue on Nov 23, 2021
    d3288e2
  10. added a commit that references this issue on Nov 23, 2021
    76eec06
  11. added a commit that references this issue on Jan 15, 2022
    ba22ee4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug 🐛Programming errors, that need preferential fixingdetect-virt

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions