Picture a four-bedroom house with one person living in it. The lights are on everywhere, the heating runs for the whole building, and most rooms stay empty all day. That is exactly how companies used to run computers. One physical server, bought and powered and cooled, doing the work of a single application, sitting nearly idle. Studies of real data centers found those servers running at five to fifteen percent of what they could handle. Everyone was paying for a mansion to house one tenant.
Virtualization is the idea that fixed that waste, and it is the foundation everything else in this series stands on. Get this one clear and the rest will make sense.
Why one app per server wasted money
For years the rule in IT was one application, one server. The email system got its own box. The finance app got another. The company website got a third. Why so cautious? Because if two applications shared one machine and one of them crashed or hogged the memory, it could take the other down with it. Separate boxes meant separate blast radius. Safe, but absurdly wasteful. A modern server has dozens of CPU cores and hundreds of gigabytes of memory, and a single business app rarely needs more than a sliver of that. The rest of the hardware just burned electricity.
So what is virtualization?
Think of an apartment building. One physical structure with shared foundations, plumbing and electrical supply, divided into many separate flats. Each tenant has their own front door, their own locks, their own thermostat. They cannot wander into a neighbour flat, and a mess in one flat does not flood the others. The landlord decides how big each flat is and can resize or move tenants as needed.
Virtualization does the same thing to a server. The physical machine is the building. A virtual machine, or VM, is a flat. Each VM gets its own operating system, its own applications, its own settings, and believes it is a complete computer with the building all to itself. It has no idea it is sharing the hardware with twenty neighbours. The software acting as landlord, dividing the building and keeping tenants apart, is called the hypervisor.
A hypervisor is a thin layer of software that sits between the physical hardware and the virtual machines, slices the real CPU, memory, disk and network into virtual portions, and hands a portion to each VM while keeping them isolated. VMware calls its hypervisor ESXi, and it installs directly onto the bare server with no Windows or Linux underneath it. We give ESXi a full part of its own later in the series, so for now just hold the picture: hardware at the bottom, hypervisor in the middle, virtual machines on top.
ESXi, vCenter and vSphere
These three words get muddled constantly, including by people who have worked with them for years. Sort them out now and you will sound like you belong in your first week. ESXi is the hypervisor that runs on each physical server. vCenter is the control room that manages many ESXi hosts from one screen. vSphere is the name for the whole product family that bundles them together. ESXi and vCenter are things you install. vSphere is the umbrella term for the platform.
| Name | What it is | What it does for you |
|---|---|---|
| ESXi | The hypervisor, installed on each physical server | Runs and isolates the virtual machines on that one host |
| vCenter | A management server you connect to | Manages many ESXi hosts and all their VMs from one screen |
| vSphere | The product suite name | The umbrella term for ESXi plus vCenter plus the features around them |
Why every company made this switch
Two reasons, really: money and speed. Both are easy to feel with real numbers.
Every physical server costs money three times over. You buy it once. You power it every hour it runs. You cool the room it sits in. Cut the number of physical boxes and all three bills drop together. Industry figures from VMware put the typical utilization jump from the old eight-to-fifteen percent range up to seventy or eighty percent, with hardware and operating costs falling by as much as half and energy costs by as much as eighty percent. You will not always hit those exact numbers, but the direction is never in doubt: fewer boxes, lower bills.
Worked example
A small company runs 10 physical servers. Each one idles at roughly 12 percent CPU, so all 10 together are doing about the work of one and a quarter busy servers. They draw around 400 watts each, so 10 boxes pull about 4,000 watts around the clock.
Virtualize them onto 2 capable hosts. The real workload of all 10 spreads comfortably across the 2, leaving each host around 60 to 70 percent loaded with headroom to spare. Those 2 hosts draw maybe 500 watts each, so 1,000 watts total.
The result: 8 fewer servers to buy and maintain, and power draw cut from 4,000 to 1,000 watts. That is roughly a 75 percent drop in electricity for the same work, before you even count the cooling you no longer need.
Ordering a physical server used to take weeks. Approvals, a purchase order, shipping, racking, cabling, installing an operating system. With virtualization, a new server is a software object. Need a test machine? A few clicks and it exists in minutes. Done with it? Delete it and the resources go back into the pool. This is the quiet reason developers love virtualization: the wait between an idea and a running machine shrank from weeks to minutes.
| Question | Physical server | Virtual machine |
|---|---|---|
| Time to get one | Days to weeks | Minutes |
| Cost to add one | New hardware purchase | A slice of hardware you already own |
| Move it to another machine | Physically unrack and re-cable | Live migration while it keeps running |
| Make a copy | Buy and build another box | Clone the file in minutes |
| Hardware fails | That app is down until repaired | VMs restart automatically on another host |
A VM is really just files
This surprises most newcomers: a virtual machine is, when you get down to it, a set of files on disk. One file holds the virtual hard drive with the operating system and data inside it. A small text file describes the VM settings: how many virtual CPUs, how much memory, which network it connects to. Because a VM is just files, you can copy it, back it up, or move it the same way you move any file. That single fact is why so many of the clever features later in this series are even possible. Moving a running server to another machine sounds like magic until you remember it is mostly a matter of moving files and memory.
Three myths to bust on day one
First myth: a virtual machine is slower than a real one. In the early days there was a small tax, but modern CPUs have virtualization built into the silicon, and a well-sized VM runs at very close to bare-metal speed for the vast majority of workloads. Second myth: virtualization and cloud are the same thing. They overlap, but they are not equal. Virtualization is the technology that splits one machine into many. Cloud is a way of renting and self-serving those resources, often built on top of virtualization. We cover where the two meet in the companion Cloud for Beginners series. Third myth: a VM and a container are the same. A VM carries a full operating system and behaves like a complete computer. A container shares the host operating system and packages just an application. Different tools, different jobs. You will meet containers later once VMs feel natural.
Where you will actually work
Reading about virtualization is one thing. Knowing what your screen looks like on the job is another, and it removes a lot of first-week nerves. The tool you log into is the vSphere Client, a web page you open in a browser and sign into with your work account. On the left sits a tree, a bit like the folders on your own laptop. At the top of that tree is vCenter. Expand it and you find data centers, then clusters, which are groups of ESXi hosts pooled together, then the hosts themselves, and finally the virtual machines running on each host. Click any virtual machine and the main panel shows its health, how much CPU and memory it is using, and a console you can open to see its screen as if you were sitting in front of it.
That tree is the whole mental model in miniature. vCenter at the top managing everything, hosts in the middle running the workloads, virtual machines at the bottom doing the actual jobs. When a colleague says check host esx-03 or the database VM looks busy, you now know exactly where to click. None of the early tasks handed to a fresher require deep theory. They require you to find the right thing in that tree, read what it is telling you, and not panic. You already have the map.
Virtualization took the wasteful one-app-per-server world and turned it into something efficient and fast. One physical host, many isolated virtual machines, each thinking it owns the place, all managed from a single screen. That is the idea every job using VMware is built on, and it is why almost every company you apply to runs some form of it. You now know what a hypervisor is, what ESXi, vCenter and vSphere mean, and why a VM being just a file matters so much.
Next we go one level deeper and put a physical server and a virtual machine side by side, so you can see exactly what changed and why it matters for the work you will do. If you want the whole roadmap, the VMware for Beginners guide lists all 18 parts. When a topic later outgrows the basics, we will point you to the advanced VMware series on this site, such as the vSphere Kubernetes Service series, for when you are ready to go further.
References
vSphere vs ESXi vs vCenter, explained
VMware vSphere 9.0 documentation (Broadcom TechDocs)
About The Author
DrJha