(FACT-1667) Add Hyper-V detector #16
Conversation
lib/src/detectors/hyperv_detector.cc
Outdated
|
|
||
| namespace whereami { namespace detectors { | ||
|
|
||
| result hyperv(const sources::cpuid_base& cpuid_source, sources::smbios_base& dmi_source) |
There was a problem hiding this comment.
Nit - did you also want to rename dmi_source to smbios_source?
There was a problem hiding this comment.
Yes! I forgot to change this name - thanks!
lib/src/detectors/hyperv_detector.cc
Outdated
| { | ||
| result res {vm::hyperv}; | ||
|
|
||
| if (cpuid_source.vendor() == "Microsoft Hv") { |
There was a problem hiding this comment.
Hah, also applies to Windows Virtual PC!
https://en.wikipedia.org/wiki/CPUID#EAX.3D0:_Get_vendor_ID_.28including_EAX.3D1:_Get_CPUID.29
There was a problem hiding this comment.
Oh, missed that - should I try to rule out Virtual PC before validating Hyper-V? Or do we care?
|
Some interesting notes about parts of CPUID behaving strangely for other things when checking from inside Hyper-V - https://software.intel.com/en-us/forums/virtualization-software-development/topic/701229 Don't know if any of that impacts us, but thought I'd mention it. |
|
Hmm, good find. In that thread, it looks like their issues revolve around Microsoft deliberately obscuring CPUID leaves that describe the capabilities of the physical processor within Hyper-V. I would hope that if MS is making adjustments like this, they'd leave the vendor leaf alone, since it's (supposed to be) reporting the presence of Hyper-V anyway (as opposed to physical information). That said, even if it reports the physical vendor or nothing, that seems okay to me, since the fallback SMBIOS vendor information comes from the hardware on a physical PC and (at least as far as I've seen) only reports "Microsoft" for Hyper-V. I have a few little cleanup tasks to do here - found a few misspellings, etc. Updating shortly. |
|
Yeah, I was less concerned about use of |
|
Oh, yeah - In this library we've only used leaves for the vendor and the "hypervisor present" bit (last one here), which seems safe (Facter currently relies on |
caseywilliams
force-pushed
the
hyperv-detector
branch
from
7768590 to
6c7aca4
Compare
Previously, the DMI data source collected data in its constructor, so even when DMI wouldn't have been used anyway, it would still try to collect its data from dmidecode and /sys on instantiation. This commit changes the DMI source so that it only collects data when one of data values is accessed. Also renames DMI to SMBIOS.
Adds a Windows WMI implementation of smbios_base
Adds a Hyper-V detector, which returns a valid result when: - the CPUID instruction's vendor string is "Microsoft Hv", or - the SMBIOS manufacturer contains "Microsoft"
caseywilliams
force-pushed
the
hyperv-detector
branch
from
6c7aca4 to
b8204ad
Compare
4 participants
Three commits:
Previously, the DMI data source collected data in its constructor, so even when DMI wouldn't have been used anyway, it would still try to collect on instantiation. The first commit here does the following:
dmi_basetosmbios_base, since DMI isn't an accurate name on windows or solarisThe second commit adds an implementation of the
smbios_baseusing WMI. This worked fine in manual tests, but there are no automated tests here (yet?).The third commit adds the Hyper-V detector. Checking the CPUID result for
Microsoft Hvseems to be a reliable way to do this, but SMBIOS is checked as a fallback.(Also, it occurred to me that this will have a few test fixture conflicts with the xen PR I have open now (#15) - I'll fix/rebase whichever as necessary)