Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

11 Answers 11

Linux adds the hypervisor flag to /proc/cpuinfo if the kernel detects running on some sort of a hypervisor.

share|improve this answer
This is the most reliable way and should be the accepted answer IMHO. One can therefore use this command: grep -q ^flags.*\ hypervisor\ /proc/cpuinfo && echo "This machine is a VM" – dr01 Jan 7 at 9:33
@dr01 - This only worked for me in Ubuntu 14.04LTS if I removed the backslash after hypervisor. What is it supposed to do? – Martin Jan 23 at 13:47
You're right, there should be two spaces after that backslash. This also works: grep -q ^flags.*\ hypervisor /proc/cpuinfo && echo "This machine is a VM" This reads /proc/cpuinfo and checks if the flags: line contains the string hypervisor, as suggested by Jan. – dr01 Jan 23 at 14:49

On Linux you can use the command virt-what

[root@myhost]# virt-what
share|improve this answer
This did not work for me in an unprivileged docker container. It hits a permission denied error reading /proc/1/environ, as root! – Martin Jan 23 at 14:22
up vote 6 down vote accepted

Using dmidecode or lshw and greping seems to be to be the best way to find out.

share|improve this answer

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.


share|improve this answer

You could try Joanna Rutkowska's Red Pill This little program examines the IDTR (interrupt descriptor table register) using the SIDT instruction (x86 only), which apparently will be set differently by different VMMs.

share|improve this answer

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.

share|improve this answer
that will work if i'm only using virtual harddrives. – ulve Nov 2 '10 at 7:07
The Harddisk was just an example, check for other devices, maybe the harddisk controller or the graphics card (I don't have vmware here so I cannot check) – tante Nov 2 '10 at 8:25

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 .

share|improve this answer


$ dmesg |grep -i hypervisor
Hypervisor detected: KVM
share|improve this answer

well, the most intuitive way I always do is:

$ dmesg | grep -i vmware

share|improve this answer
nice - this works on virtual box: dmesg | grep -i vbox - ACPI: RSDP 000e0000 00024 (v02 VBOX ) – Danny Staple May 9 '13 at 14:40

I have done it:

hypervisor=`dmesg --notime | grep -i hypervisor | cut -d ':' -f2 | tr -d " \t\n\r"
echo "Hypervisor is $hypervisor"

It helps on scripts

share|improve this answer

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.

share|improve this answer
Docker is not a virtualization in the classical sense. It is a container, the processes still run inside the same kernel. Thus your answer, while it might be correct, is outside of the scope of the question. – Jan Henke Jan 24 at 18:56
There are a lot of half-truth and easy to misunderstand things written on wikipedia. Do not use it to prove a point and take everything written there with a grain of salt. Also not that "virtualization" is broader term then what we are discussing here. That is why I wrote "in the classical sense" above. Just accept that a docker container is pretty different from a virtual machine (which is the whole point of docker in the first place by the way). – Jan Henke Jan 25 at 7:45
" If I install Java in that machine it does not also get installed in the base OS" that has nothing to do with this discussion. Surely it is not installed in the base OS (as the container has a separate file system). But that does not make a Docker container the same as a virtual machine. I am trying to clarify your wrong assumptions right now, but you do not seem overly interested in listing and understand what I am telling you. – Jan Henke Jan 26 at 11:10
Also the title "create a Docker Machine" is misleading, you create a Docker container, not a Docker machine. The docker image has a separate file system, but processes you start run on the host kernel. You do not run a separate kernel, like a traditional virtual machine. That is why the hypervisor flag is not set, you are not running inside a hypervisor after all. Just do not call other people's answer "inadequate" if you confuse things and make false assumptions. – Jan Henke Jan 26 at 11:16
Your assumption is wrong. I never said it is bare metal. All I said is that containers like Docker are different from virtual machines. And my answer was fully correct, as it only applies to virtual machines. You extended the scope of the question yourself and then called my answer "inadequate", because it applied to the scope of the original question and not your extension. I just pointed out to you, that you have to treat containers like Docker differently from virtual machines, but calling my answer "inadequate" is wrong to begin with, since you base it on your subjective assumptions. – Jan Henke Jan 26 at 15:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.