A future proof way to determine we are inside bash on windows.

[vStone]

• Your Windows build number: Version 10.0.15063
• What you're doing and what's happening:

# get the puppetlabs repo
wget http:https://apt.puppetlabs.com/puppet5-release-xenial.deb && dpkg -i puppet5-release-xenial.deb`
apt-get update
apt-get install puppet-agent
facter is_virtual
# => false

• What's wrong / what should be happening instead:
  Facter should determine correctly we are running inside a vm of some sort.
  I'm looking for a future proof way to determine we are running inside a vm on windows so I can make the patch upstream to puppetlabs for fixing this.

This is the current implementation in facter:

root@aku:~# facter is_virtual --debug
2017-09-08 23:06:26.371976 INFO  puppetlabs.facter - executed with command line: is_virtual --debug.
2017-09-08 23:06:26.374603 INFO  leatherman.ruby:137 - ruby loaded from "/opt/puppetlabs/puppet/lib/libruby.so.2.4.1".
2017-09-08 23:06:26.375388 DEBUG leatherman.dynamic_library:77 - symbol rb_data_object_alloc not found in library /opt/puppetlabs/puppet/lib/libruby.so.2.4.1, trying alias rb_data_object_wrap.
2017-09-08 23:06:26.429033 INFO  leatherman.ruby:186 - using ruby version 2.4.1
2017-09-08 23:06:26.429488 INFO  puppetlabs.facter - requested queries: is_virtual.
2017-09-08 23:06:26.430259 DEBUG puppetlabs.facter - fact "facterversion" has resolved to "3.8.0".
2017-09-08 23:06:26.430993 DEBUG puppetlabs.facter - fact "aio_agent_version" has resolved to "5.1.0".
2017-09-08 23:06:26.431945 DEBUG leatherman.file_util:65 - Error reading file: No such file or directory
2017-09-08 23:06:26.433376 DEBUG puppetlabs.facter - loading all custom facts.
2017-09-08 23:06:26.433593 DEBUG puppetlabs.facter - loading custom fact directories from config file
2017-09-08 23:06:26.434252 DEBUG puppetlabs.facter - searching "/opt/puppetlabs/facter/facts.d" for external facts.
2017-09-08 23:06:26.435019 DEBUG puppetlabs.facter - skipping external facts for "/etc/facter/facts.d": No such file or directory
2017-09-08 23:06:26.435348 DEBUG puppetlabs.facter - skipping external facts for "/etc/puppetlabs/facter/facts.d": No such file or directory
2017-09-08 23:06:26.435823 DEBUG puppetlabs.facter - no external facts were found.
2017-09-08 23:06:26.436416 DEBUG puppetlabs.facter - resolving virtualization facts.
2017-09-08 23:06:26.437214 DEBUG puppetlabs.facter - resolving desktop management interface facts.
2017-09-08 23:06:26.441291 DEBUG puppetlabs.facter - /sys/class/dmi cannot be accessed: using dmidecode to query DMI information.
2017-09-08 23:06:26.443071 DEBUG leatherman.execution:92 - executing command: /opt/puppetlabs/puppet/bin/dmidecode
2017-09-08 23:06:26.453012 DEBUG !!! - /dev/mem: No such file or directory
2017-09-08 23:06:26.453385 DEBUG | - # dmidecode 2.12
2017-09-08 23:06:26.454585 DEBUG leatherman.execution:556 - process exited with status code 1.
2017-09-08 23:06:26.455122 DEBUG leatherman.execution:92 - executing command: /opt/puppetlabs/puppet/bin/virt-what
2017-09-08 23:06:26.565641 DEBUG leatherman.execution:556 - process exited with status code 0.
2017-09-08 23:06:26.566232 DEBUG leatherman.execution:92 - executing command: vmware -v
2017-09-08 23:06:26.566782 DEBUG leatherman.execution:409 - vmware was not found on the PATH.
2017-09-08 23:06:26.567892 DEBUG leatherman.execution:92 - executing command: /usr/bin/lspci
2017-09-08 23:06:26.579140 DEBUG !!! - pcilib: Cannot open /proc/bus/pci
2017-09-08 23:06:26.579423 DEBUG !!! - lspci: Cannot find any working access method.
2017-09-08 23:06:26.580223 DEBUG leatherman.execution:556 - process exited with status code 1.
2017-09-08 23:06:26.582368 DEBUG puppetlabs.facter - fact "is_virtual" has resolved to false.
2017-09-08 23:06:26.582725 DEBUG puppetlabs.facter - fact "virtual" has resolved to "physical".
false

Upstream ticket: https://tickets.puppetlabs.com/browse/FACT-1748

[therealkenc]

WSL isn't a VM. But you can check for whether you are running WSL with /proc/version. #423, #2299

[fpqc]

@vStone It's currently unknown what the end-state for hardware implementation will be. WSL may even end up with direct block-level access to unmounted Windows devices, or direct hardware access for graphics or CUDA for example, so it's not safe to just declare WSL as virtual. As Ken has mentioned before, it would be really helpful for the team to give us a roadmap, but at the moment, management has decided to to keep the roadmap private (and therefore flexible).

Certain workarounds for WSL bugs/unimplemented syscalls should not be candidates for addition to compatibility fixes in Linux projects. They should be reported on this github repo instead and considered temporary. If the problems are more fundamental (mainly revolving around missing kernel modules that the WSL team doesn't plan to replace with their own implementations), then designing around WSL limitations could make sense.

[benhillis]

Duplicate of #423.