What is Virtualization?

Virtualization is the trick that lets a single physical computer pretend to be many separate computers at once. Each of those pretend computers, called a virtual machine (a VM is a software-based computer that runs its own operating system as if it were real hardware), thinks it has its own CPU, memory, and disk. This one idea is the foundation of nearly all modern cloud computing, and understanding it makes everything else about “the cloud” click into place.

Why virtualization exists

A real server is expensive and usually wasted. A physical box might have 64 CPU cores and 256 GB of RAM, but a single small website only uses a tiny slice of that. Leaving the rest idle is throwing money away.

Virtualization solves this by slicing one powerful physical machine into many smaller virtual machines. Each VM is fully isolated: a crash, a security breach, or a reboot in one VM does not touch the others. This is exactly what lets a cloud provider buy huge servers and rent them out to thousands of customers as small, separate machines.

Isolation is the whole point. If two customers shared the same operating system, one could read the other’s files. A hypervisor gives each VM its own kernel and its own walls.

The hypervisor

The piece of software that creates and runs VMs is called a hypervisor (a layer that sits between the physical hardware and the virtual machines, handing out slices of CPU, memory, and disk to each one). The hypervisor is the referee: it decides which VM gets to use the real CPU at any given moment and stops VMs from stepping on each other.

There are two kinds.

Type 1 — bare-metal hypervisors

A Type 1 hypervisor runs directly on the physical hardware, with no normal operating system underneath it. The hypervisor itself is the operating system. Because there is nothing in the way, it is fast and efficient, which is why every serious cloud provider uses this type.

Examples: KVM (built into the Linux kernel), VMware ESXi, Microsoft Hyper-V, and Xen.

Type 2 — hosted hypervisors

A Type 2 hypervisor runs as a normal application on top of an existing operating system like Windows or macOS. You open it like any other program. It is slower because requests pass through the host OS first, but it is perfect for testing on your own laptop.

Examples: VirtualBox, VMware Workstation, and Parallels.

Type 1 vs Type 2 — when to use which

Aspect	Type 1 (bare-metal)	Type 2 (hosted)
Runs on	Hardware directly	An existing OS
Speed	Near-native	Slower (extra layer)
Typical use	Cloud, data centres, production	Laptops, learning, local testing
Examples	KVM, ESXi, Hyper-V	VirtualBox, VMware Workstation
When NOT to use	On your own laptop for quick tests	For production cloud workloads

When you rent a server from AWS, Google Cloud, or DigitalOcean, you are getting a VM running on a Type 1 hypervisor in their data centre. You almost never see or touch the hypervisor itself — you just get a clean Linux machine.

Seeing virtualization on Ubuntu

Ubuntu ships with KVM (Kernel-based Virtual Machine), a Type 1 hypervisor built straight into the Linux kernel. First, check that your CPU supports hardware virtualization.

egrep -c '(vmx|svm)' /proc/cpuinfo

Output:

8

Any number greater than 0 means your CPU supports virtualization (vmx is Intel’s feature, svm is AMD’s). A 0 means it is disabled in the BIOS or unsupported.

Now install the KVM tools on Ubuntu 22.04 or 24.04:

sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system virtinst

Add yourself to the groups so you can manage VMs without sudo every time, then confirm the service is running:

sudo usermod -aG kvm,libvirt $USER
sudo systemctl enable --now libvirtd
sudo systemctl status libvirtd

Output:

● libvirtd.service - Virtualization daemon
     Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled)
     Active: active (running) since Mon 2026-06-15 10:02:11 UTC

Log out and back in for the group change to take effect, then list your VMs:

virsh list --all

Output:

 Id   Name   State
--------------------

The empty list is correct — you have not created a VM yet, but the hypervisor is ready.

How virtualization underpins the cloud

Every cloud “instance” or “droplet” or “VM” you rent is the same idea repeated at massive scale:

1. The provider racks thousands of physical servers in a data centre.
2. Each server runs a Type 1 hypervisor (often KVM).
3. When you click “create server,” the hypervisor carves out a slice — say 2 CPUs and 4 GB RAM — and boots a fresh Ubuntu VM on it.
4. You get SSH (Secure Shell, a way to log into a remote machine over an encrypted connection) access and it feels like a brand-new computer.

Because VMs are just files and configuration, the provider can create one in seconds, destroy it, move it to another physical host, or snapshot it. That flexibility is what we call “elasticity,” and it is why you can rent a server for an hour and pay pennies.

Virtualization vs containers

People often confuse virtual machines with containers (a lighter way to isolate an app that shares the host’s kernel instead of running its own). The difference comes down to what gets virtualized.

	Virtual machine	Container
Virtualizes	Whole hardware + OS	Just the application + its files
Has its own kernel?	Yes	No (shares the host’s)
Boot time	Seconds to minutes	Milliseconds
Size	Gigabytes	Megabytes
Isolation strength	Stronger	Lighter
Tooling	KVM, VMware	Docker, Podman

A VM gives you a whole machine; a container gives you a wrapped-up app. In practice they work together: cloud providers run VMs, and inside those VMs you run containers. Use a VM when you need a full, strongly-isolated operating system. Use a container when you just need to ship and scale one application quickly.

Best practices

• Use a Type 1 hypervisor (KVM) for anything in production, and a Type 2 (VirtualBox) only for local testing on your laptop.
• Always check /proc/cpuinfo for vmx/svm before installing KVM — without hardware support, VMs run painfully slowly.
• Keep the host’s hypervisor patched (sudo apt update && sudo apt upgrade); a vulnerability there can affect every VM on the machine.
• Snapshot a VM before risky changes so you can roll back instantly.
• Right-size your VMs — give each one only the CPU and RAM it needs so the physical host can pack in more.
• Treat VMs as disposable: store config and data outside the VM so you can rebuild it from scratch at any time.

Related Topics

• Virtual Machines
• What is Cloud Computing?
• Cloud Providers
• Renting a VPS
• IaaS, PaaS, and SaaS