Picture a street of independent houses. Each house has its own plot of land, its own water tank, its own electricity meter, and exactly one family living in it. If that family goes on holiday for a month, the house sits empty. The land, the water, the power line, all of it, just waiting. That is a room full of physical servers. Now picture one large apartment building on the same plot. Same land, same water main, same electrical supply, but now thirty families live there, each behind their own locked door, each unaware of the others. The building manager quietly makes sure nobody hogs the lift or the hot water. That building is a virtualization host, and each apartment is a virtual machine.
That single image carries most of what you need. The rest of this part fills in the engineering detail behind it, and shows you the one number that trips up almost every fresher in their first month.
What a physical server actually is
A physical server, often called bare metal, is real hardware: a metal chassis holding CPUs, memory sticks, disks, and network cards. You install one operating system directly onto it, say Windows Server or Linux, and that operating system talks straight to the hardware. One box, one OS, usually one main job. A finance application here, a database there, an email system on a third box.
This was how data centres ran for decades, and it has real strengths. Nothing sits between the application and the hardware, so performance is predictable. The machine is isolated, which some security and compliance teams still insist on. And for a genuinely huge workload that needs every drop of the hardware, dedicating a whole box to it makes sense.
The problem is waste. Most applications do not need a whole server. Studies of pre-virtualization data centres routinely found physical servers running at 5 to 15 percent of their capacity, day in and day out. You bought a powerful machine, paid to power and cool it around the clock, and used a sliver of it. Multiply that across hundreds of boxes and you have an expensive room full of idle metal. That waste is the entire reason virtualization exists.
What a virtual machine actually is
A virtual machine is a complete computer built entirely out of software. It has a CPU, memory, a hard disk, and a network card, but every one of those is virtual: a software stand-in that behaves exactly like the real thing as far as the operating system inside can tell. You install Windows or Linux inside a VM the same way you would on a physical box, and that guest operating system has no idea it is not running on real hardware.
Here is the part that surprises newcomers: a virtual machine is, on disk, just a set of files. A configuration file that lists how many virtual CPUs and how much memory it has, and one or more virtual disk files that hold everything inside, the operating system, the applications, the data. On VMware that virtual disk is a .vmdk file and the configuration is a .vmx file. Because a whole running computer is just files, you can copy it, move it to another host, or restore it from a backup. Try copying a physical server to another building in five minutes. You cannot. You can do exactly that with a VM.
Between them sits the hypervisor
So how do three operating systems run on one box without fighting? That is the job of the hypervisor, the building manager from our apartment analogy. It is a thin piece of software that sits directly on the hardware, takes ownership of the real CPUs, memory, disks, and network, and hands out controlled slices to each VM. When a VM asks for processor time, the hypervisor schedules it. When two VMs want memory at once, the hypervisor decides who gets what.
VMware calls its hypervisor ESXi. It is a Type 1, or bare-metal, hypervisor, meaning it installs straight onto the server with no Windows or Linux underneath it. That is different from running VMware Workstation on your laptop, where the hypervisor sits on top of your existing operating system. We give ESXi a full part of its own next, Part 3, so for now just hold the idea: hardware at the bottom, hypervisor on top of it, VMs on top of that.
Physical versus virtual, side by side
| Trait | Physical server | Virtual machine |
|---|---|---|
| Hardware | Owns the whole box | Shares a box with other VMs |
| What it is made of | Metal, chips, cables | Files (.vmx and .vmdk) |
| Provisioning time | Days to weeks (order, rack, cable) | Minutes from a template |
| Move to another machine | Physical relocation | Live, with vMotion, no downtime |
| Typical utilization | Often 5 to 15 percent | Pooled, much higher overall |
| Recovery after failure | Rebuild, can take days | Restart on another host in minutes |
| Best when | One massive, latency-sensitive workload | Almost everything else |
Why companies made the switch
The headline reason is consolidation: packing many under-used physical servers onto a few well-used hosts. Fewer boxes means less hardware to buy, less rack space, less power, less cooling, and fewer things to break. But the benefits people fall in love with come later. A VM can be cloned in minutes, snapshotted before a risky change, backed up as a file, and moved off a failing host while it keeps running. None of that is possible with bare metal.
Worked example
Say you have 10 old physical servers. Each has 8 CPU cores and 64 GB of memory, so on paper that is 80 cores and 640 GB across the room. But monitoring shows each one really uses about 10 percent: roughly 1 core and 8 GB in daily use. Real demand is therefore close to 10 cores and 80 GB.
Now buy 2 modern hosts, each with 32 cores and 256 GB. That is 64 cores and 512 GB of capacity for the pair. Your real demand of 10 cores and 80 GB fits comfortably, with generous room for spikes and for one host to fail while the other carries everything. You went from 10 boxes to 2, cut power and cooling by roughly the same proportion, and gained the ability to lose a host without losing service.
That is the pitch in one paragraph. It is also exactly the kind of estimate a junior engineer is asked to sanity-check in their first months.
Oversubscription: what nobody tells freshers
Here is where virtualization stops being magic. Because most workloads are idle most of the time, the hypervisor lets you hand out more virtual CPUs than you have physical cores. This is oversubscription, and it is the whole trick behind those savings. A host with 32 cores might run VMs that add up to 80 or 100 virtual CPUs, because they are never all busy at once. Just like an apartment building has one lift for thirty families and it works fine, until everyone leaves for work at 9am.
When too many VMs want CPU at the same moment, they wait in line. In VMware that waiting shows up as a metric called CPU Ready, the time a VM was ready to run but had to wait for a physical core to free up. A new engineer sees a VM that is slow, checks its CPU usage, sees it is low, and is baffled. The VM is not short of work, it is short of a seat. High CPU Ready, not high CPU usage, is the real fingerprint of an overloaded host. Learning to look at that one metric will make you useful faster than almost anything else.
Forget the magic ratio
For years, freshers were taught a rule of thumb: keep virtual CPUs to physical CPUs at 4 to 1, and never go past it. You will still hear this in interviews and old blog posts. I think chasing a fixed ratio is the wrong habit, and so does VMware. In a June 2025 post, VMware performance lead Mark Achtemichuk wrote plainly that there is no common ratio, and that the static-ratio mindset causes operational problems. The honest answer is to watch for contention, the CPU Ready and memory pressure on a host, and grow capacity when you see it. If you want a safe starting point with no monitoring in place, begin at 1 to 1 and loosen it as you learn the workload. A spreadsheet of ratios feels precise. It is precisely wrong for workloads you have never measured.
Real interview question
If a virtual machine and a physical machine have identical specs, which is faster, and why?
Answer honestly: the physical machine, slightly, because the hypervisor adds a small amount of overhead and the VM may share hardware with neighbours. But then make the real point: for the vast majority of workloads that gap is tiny and irrelevant, and the flexibility you gain, snapshots, live migration, fast recovery, fast provisioning, is worth far more than a few percent of raw speed. Interviewers want to see that you know the trade-off exists and that you can reason about when raw performance actually matters and when it does not. That balanced answer beats both naive cheerleading and naive doubt.
Try it yourself
Install the free VMware Workstation Player on your own laptop, or use the free ESXi hypervisor in a nested lab. Create one virtual machine, give it 2 virtual CPUs and 4 GB of memory, and install a small Linux distribution inside it. Then, with the VM shut down, open the folder where it lives and look at the files. You will see the .vmx configuration file and the .vmdk virtual disk.
How to check you got it right: copy that whole folder to a USB drive or another location, then open the copied .vmx in Workstation and boot it. If the copy starts up as a working computer, you have just proved the central idea of this part, that a VM is portable files, with your own hands.
Where this fits in 2026
The platform you will meet at work is VMware vSphere 8, with ESXi 8 as the hypervisor and vCenter Server 8 as the management console, now sold by Broadcom. The free ESXi hypervisor returned with ESXi 8.0 Update 3e, which is genuinely useful for building a home lab without a licence. Everything in this part, physical versus virtual, files on disk, the hypervisor, oversubscription, is just as true on the newest release as it was a decade ago. The names and the tooling around the edges change. The core idea does not. When you are ready to go further than the fundamentals, the advanced VMware Cloud Foundation, NSX, and Private AI material picks up where this beginner series stops.
FAQ
Is a virtual machine the same thing as a container, like Docker?
No. A VM carries a full guest operating system and behaves like a complete computer. A container shares the host operating system and packages just an application and its dependencies, so it is much lighter but less isolated. They solve overlapping problems in different ways, and many companies run containers inside VMs.
Does running as a VM slow my application down?
Usually by a small, often unnoticeable amount. Modern CPUs have hardware features built specifically to make virtualization fast. Real slowness almost always comes from a host being oversubscribed or a VM being wrongly sized, not from virtualization itself.
Can I turn an existing physical server into a VM?
Yes. The process is called P2V, physical to virtual, and tools exist to copy a running physical machine into a VM. It is a common task during data centre migrations, though for clean modern builds many teams now prefer to rebuild fresh inside a VM instead.
If many VMs share one server, do they slow each other down?
They can, if the host is overloaded. That is exactly the contention problem above. A well-sized host with healthy CPU Ready and free memory keeps VMs comfortably isolated. The hypervisor enforces fair sharing, and tools like resource shares and limits, covered later in this series, give you fine control.
Do I still need to learn physical servers at all?
Yes, a little. Someone has to rack, cable, and power the hosts your VMs run on, and understanding the hardware underneath helps you reason about performance and failures. You do not need to be a hardware specialist, but knowing what a core, a memory channel, and a NIC are will serve you well.
Your move
You now know the single idea the rest of VMware is built on: a VM is software pretending to be hardware, sharing a real box through a hypervisor. Do the Try It Yourself task this week. Copying a running computer as if it were a photo album is the moment virtualization stops being abstract. Next we open up that hypervisor itself and meet ESXi properly.
References
About The Author
DrJha