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.