Mental model
Cisco objective 4.3 says “Describe the attributes of these application deployment types: virtual machines, bare metal, containers”.
Three layers of how far you are from the physical hardware:
┌──────────────────────────────────────────┐
│ Containers (sharing one kernel) │ milliseconds, MB
├──────────────────────────────────────────┤
│ VMs (full OS per workload) │ seconds-minutes, GB
├──────────────────────────────────────────┤
│ Bare metal (one OS, raw hardware) │ minutes-hours, physical
└──────────────────────────────────────────┘
Bare metal
Install an OS directly on physical hardware. One OS per server. No virtualization.
- Pros: no overhead; full access to specialised hardware (GPU, FPGA, special NICs); predictable performance.
- Cons: rigid (one workload per machine); slow to provision (install OS + apps); poor hardware utilisation (CPU idle most of the time).
- When: latency-critical databases, HPC, dedicated appliance workloads.
Virtual machines (VMs)
A hypervisor (VMware ESXi, KVM, Hyper-V) runs on the hardware. On top of the hypervisor you run many VMs, each with its own kernel and OS.
- Pros: strong isolation (a crashed VM does not touch others); any OS can be a VM; mature management (vCenter, OpenStack); live-migration between hosts.
- Cons: each VM carries its own OS (GB of RAM, minutes to boot); hypervisor overhead; density capped by RAM.
- When: mixed-OS environments, hard tenant isolation, legacy apps that must have “a server”.
Containers
Processes share the host’s kernel but see an isolated filesystem, network, process list, user namespace. Package: an image (nginx:latest) with the exact code and dependencies.
- Pros: very fast start (ms); very small footprint (MB); image is immutable (same thing dev / test / prod); huge ecosystem (Docker, Kubernetes).
- Cons: weaker isolation than VMs (kernel bugs can escape); not every workload containerises (needs the right OS kernel features); networking + storage take time to learn.
- When: modern web apps, microservices, CI/CD build agents, Kubernetes everywhere.
Side-by-side
| Attribute | Bare metal | VM | Container |
|---|---|---|---|
| Boot time | Minutes-hours | Seconds-minutes | Milliseconds |
| Overhead per workload | None | GB RAM + full OS | MB RAM, no extra kernel |
| Isolation strength | Physical | Hypervisor (strong) | Namespace (weaker) |
| Density on a 128 GB server | ~1 OS | ~30 VMs | 100s-1000s of containers |
| OS flexibility | Any OS | Any OS | Must share host kernel |
| Portability of workload | Image on install media | VM image (OVA / VMDK) | Container image (OCI / Docker) |
| Common manager | None | vCenter, Nutanix, OpenStack | Docker Engine, Kubernetes |
Where network engineers see each
- Bare metal: DC switch fabric, latency-critical routers, firewall appliances, GPU training rigs.
- VMs: controller VMs (vManage, APIC), virtual firewalls (FTDv, Fortigate VM), lab topology (CML, GNS3).
- Containers: CI pipeline agents, custom Catalyst Center or NSO extensions, apps running on Catalyst 8300 IOx, API gateways, telemetry collectors.
FAQ
Can I run VMs inside a container? Technically yes (nested virt with KVM-in-Docker), but unusual. Normally the stack is Bare metal → Hypervisor → VMs → Containers inside the VMs.
Why do containers need a hypervisor on macOS and Windows? Containers need a Linux kernel. On non-Linux hosts, Docker Desktop runs a tiny Linux VM and launches containers inside it.
Is a container “lightweight VM”? Marketing version, yes. Technically no — a VM virtualises hardware; a container isolates processes. They solve different problems.
Is bare metal going away? No. Workloads that need direct hardware (GPU training, HPC, high-frequency trading) always come back to bare metal. The share has shrunk but the use cases remain.