Is there any way to find out if the OS I'm running (actually installing) is running in a VMWare machine. I need to disable
ntp settings if the automated install is done on a virtual machine but keep them enabled if installing on bare metal.
This worked better for me as it gives me specific information about the manufacturer and the product name.
dmidecode -t system|grep 'Manufacturer\|Product'
Output on Dell server:
Manufacturer: Dell Inc. Product Name: PowerEdge C5220
Output on Virtualbox VM:
Manufacturer: innotek GmbH Product Name: VirtualBox
Output on KVM/QEMU:
Manufacturer: QEMU Product Name: Standard PC (i440FX + PIIX, 1996)
This is great for scripts that can parse these out for better identification of servers... but if you use Chef in your infrastructure, you can check the node attribute
Virtualization -> system in the chef server .
If all you need is a way to tell whether the OS/host is a virtualized host or not, just you have a perl module Sys::Detect::Virtualization and the script with it
virtdetect. It does all the possible heuristics/guess detections and reports the detected OS environment. Give it a try.
The best idea would probably to look at the hardware. At least with VirtualBox you can easily determine that you are on a virtual machine, due to the names of some of the hardware devices (for example
/sys/block/sda/device/model will say "VBOX HARDDISK").
Since all your machines are VMware, just pick one of those things and check that.
All of these answers work in some cases but not others.
For example, you can depend on
dmesg while boot-up log details are still in the ring buffer, but it will likely fail on a machine that has been running for any length of time. Worse, a message might be logged by the bare metal OS concerning a running hypervisor, in which case a naive test like
dmesg | grep -i vmware will return a false positive.
Testing under Docker is quite different. Docker has no
/proc/cpuinfo of its own; instead it passes on the host machine's info. Meanwhile,
dmidecode fails trying to read a directory
/dev/mem not seen by Docker.
virt-what has detection for Docker containers, but needs to be patched to cope with a recent change in container privileges. It crashes trying to access
/proc/1/environ before it reaches the tests for Docker.
It is important to pay attention to the
virt-what caveat emptor :
Most of the time, using this program is the wrong thing to do. Instead you should detect the specific features you actually want to use.
In my case, publishing a tutorial that installs a ton of crap users may not want after all, I refuse to let it run on bare metal, with this test :
[[ 0 < $(grep -c docker /proc/1/cgroup) ]] || [[ "X$(sudo virt-what)X" != "XX" ]] && export VIRTUALIZED=true;
Note : I realize the OP asks specifically about VMWare in the body of the question, but the title of the question will attract many readers (like me) looking for the more general case.