1.8 Virtualization Fundamentals
Key Takeaways
- A hypervisor partitions one physical server into many isolated virtual machines, each running a full guest OS.
- Type 1 (bare-metal) hypervisors run directly on hardware; Type 2 hypervisors run on top of a host OS.
- Containers share the host OS kernel, so they are far lighter and start faster than full VMs.
- A virtual switch (vSwitch) inside the hypervisor connects VMs to each other and to physical NICs.
- Virtualization raises hardware utilization, speeds provisioning, and enables snapshots, migration, and high availability.
What virtualization is
Virtualization creates software-based versions of physical resources, servers, networks, and storage, decoupling the operating system from the underlying hardware. One powerful physical server can then host many isolated virtual machines (VMs) simultaneously, dramatically improving utilization that would otherwise sit idle.
The hypervisor
A hypervisor (also called a virtual machine monitor) creates, runs, and isolates VMs, allocating slices of CPU, memory, disk, and network to each. There are two types, a favorite exam distinction:
| Type | Runs on | Examples | Use case |
|---|---|---|---|
| Type 1 (bare-metal) | Directly on hardware, no host OS | VMware ESXi, Microsoft Hyper-V, KVM | Production data centers |
| Type 2 (hosted) | On top of a host OS | VMware Workstation, VirtualBox | Desktops, labs, testing |
Type 1 is more efficient and secure because there is no intervening operating system between the hypervisor and hardware, so it is what enterprises run in production. Type 2 is convenient for running a VM on your laptop.
Virtual machines
Each VM includes a full guest operating system, virtual CPU, virtual RAM, virtual disk, and one or more virtual NICs (vNICs). VMs are strongly isolated: a crash or compromise in one VM does not affect its neighbors. VMs can be snapshotted, cloned, and live-migrated between physical hosts with no downtime, which underpins high availability.
Containers vs VMs
Containers package an application with its dependencies but share the host OS kernel instead of bundling a full guest OS. The difference matters:
| Property | Virtual machine | Container |
|---|---|---|
| Includes full OS? | Yes, a complete guest OS | No, shares host kernel |
| Size | Gigabytes | Megabytes |
| Boot time | Seconds to minutes | Milliseconds to seconds |
| Isolation | Strong (separate kernels) | Lighter (shared kernel) |
| Density per host | Lower | Much higher |
Because containers are lightweight and fast to start, they are favored for microservices, while VMs remain ideal when full OS isolation or a different guest OS is required.
Virtual networking
Inside the hypervisor a virtual switch (vSwitch) connects vNICs to each other and uplinks to the physical NICs, so VMs on the same host can talk without leaving the server. VLANs and trunking extend onto the vSwitch, meaning the network team must coordinate VLAN tags down to the hypervisor. This is why the CCNA cares: virtualization pushes Layer 2 boundaries into the server.
Worked example
A company replaces ten aging physical servers, each 10% utilized, with two Type 1 hypervisor hosts running all ten workloads as VMs. Utilization rises, power and rack space drop, and a failed host's VMs live-migrate to the surviving host, providing resilience that bare-metal servers could not.
Virtual NICs, vSwitches, and uplinks
Inside a hypervisor host, each VM has one or more virtual NICs that plug into a virtual switch. The vSwitch behaves much like a physical Layer 2 switch: it forwards frames between VMs by MAC and tags frames with VLAN IDs. The vSwitch then connects to the host's physical NICs (the uplinks), often bundled for redundancy and bandwidth, which carry traffic out to the physical access switch. The physical switch port facing the host is therefore usually a trunk carrying every VLAN the VMs use, a key integration point between server and network teams.
Why virtualization changes network design
- VM mobility: live migration can move a running VM to another host or even another data center, so its VLAN/subnet may need to exist in multiple places, this is a driver behind overlay technologies like VXLAN.
- East-west traffic growth: consolidating many servers onto few hosts and clustering them multiplies server-to-server traffic, favoring spine-leaf fabrics.
- Network functions as VMs: routers, firewalls, and load balancers can themselves run as virtual appliances (NFV, network functions virtualization), blurring the line between server and network gear.
Benefits and tradeoffs
| Benefit | Why it matters |
|---|---|
| Higher utilization | Many VMs share idle CPU/RAM/disk |
| Faster provisioning | Spin up a server in minutes from a template |
| Isolation | A crash in one VM does not affect others |
| Snapshots/rollback | Capture and restore a VM's exact state |
| High availability | Restart or migrate VMs off a failed host |
The tradeoffs are the hypervisor as a single point of failure (mitigated by clustering) and contention when too many VMs oversubscribe one host's resources.
Worked comparison
A microservices app with twenty small, stateless services starts fastest and packs densest as containers sharing one host kernel. A legacy application that requires a specific full operating system and strong isolation runs better in its own VM. Choosing the wrong abstraction wastes resources, which is exactly the judgment the exam probes.
Common traps
- Type 1 runs on bare metal; do not confuse it with Type 2's host-OS requirement.
- Containers do not each carry a full OS, they share the host kernel, which is why they are smaller and faster.
- A vSwitch is software inside the hypervisor, not a physical device, yet it still does Layer 2 forwarding and VLAN tagging.
- The physical port toward a hypervisor is typically a trunk, not an access port, because it carries multiple VLANs.
Which type of hypervisor runs directly on the physical hardware without a host operating system?
What is the primary difference between virtual machines and containers?