Virtualization Explained

One box, many computers

Walk into a cloud provider's data center and you will find rows of physical servers, but the number of physical machines is nowhere close to the number of customers using them. A single physical server can host dozens of completely separate virtual machines at once, each one running its own operating system, each one convinced it has the whole computer to itself, each one invisible to the others. That trick, one physical machine appearing to be many independent ones, is virtualization, and it is the technology that makes the cloud's shared resource pool physically possible.

The hypervisor: software that divides a computer

The software that makes this work is called a hypervisor. A hypervisor sits between the physical hardware, CPU, memory, storage, network, and the virtual machines (VMs) running on top of it, and its job is to divide that hardware up and hand each VM its own slice, some CPU cycles, some RAM, some disk space, on a schedule the hypervisor controls.

From inside a VM, everything looks normal. The guest operating system boots, sees what looks like real memory and a real disk, and runs applications exactly as it would on physical hardware. It has no way to tell that its "hardware" is actually a slice of a much larger machine being shared with several other VMs. That illusion is the entire point: isolation. If one VM crashes or gets compromised, the others keep running undisturbed, because the hypervisor keeps them separated at all times.

Two ways to run a hypervisor

Not all hypervisors sit in the same place. There are 2 types, and the difference matters for where each one gets used.

A Type 1 hypervisor, also called bare metal, installs directly on the physical hardware and takes the place of a traditional operating system. It talks to the CPU and memory directly, with nothing in between. Because there is no host operating system competing for resources, Type 1 hypervisors are fast and are the kind you find running production workloads in data centers and cloud platforms. VMware vSphere, Microsoft Hyper-V, and KVM are examples.

A Type 2 hypervisor, also called hosted, installs as an ordinary application on top of a regular operating system, the same way you would install a web browser. It has to ask that host operating system for CPU time and memory rather than talking to the hardware directly, which adds a layer of overhead. That overhead is a reasonable trade for convenience: Type 2 hypervisors are simple to install and use, which is why developers use them to test software across multiple operating systems on a single laptop. VMware Workstation and Oracle VirtualBox are examples.

Why this made the cloud's resource pool possible

Go back to the NIST definition from the last lesson: "a shared pool of configurable computing resources." Virtualization is the mechanism that makes that pool safely shareable. Without it, a provider would have to give each customer a dedicated physical machine, which is exactly the inefficient, one-customer-per-box model the cloud replaced. With it, a provider can carve one powerful physical server into dozens of VMs, sell each one to a different customer, and reclaim and reuse that capacity the moment a customer releases it. Rapid provisioning, spinning up a new VM in minutes, and resource pooling, many customers sharing hardware safely, both trace back to this one piece of software.

The boundary: virtualized is not the same as cloud

Here is where it is easy to overreach. A company that installs a Type 1 hypervisor on its own servers and runs 10 VMs in its own data center has virtualized its infrastructure, but it has not necessarily built a cloud. If a developer still has to file an IT ticket and wait 2 days for someone to manually create a new VM, that setup fails the "on-demand self-service" and "rapidly provisioned" parts of the definition you learned in the last lesson, even though the underlying technology is identical to what a cloud provider uses.

Virtualization is necessary for cloud computing at the scale you see today, but it is not sufficient by itself. The cloud adds self-service provisioning, metering, and elasticity on top of virtualized hardware. You will see this exact distinction again once you reach private cloud deployments later in this domain, since a private cloud is what you get when an organization adds those missing pieces to its own virtualized infrastructure.

What comes next

You now know the mechanism behind the shared pool: a hypervisor slicing physical hardware into isolated virtual machines. The next lesson names the 5 specific, testable traits, on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service, that separate a merely virtualized system from a true cloud.