CCNA Hypervisors, Virtual Machines and Containers Explained

A hypervisor is the software layer that abstracts a physical host's CPU, memory, storage and network interfaces, hands each virtual machine (VM) its own share of them, and keeps the VMs isolated from one another. Each VM believes it owns a complete computer; in reality the hypervisor schedules it onto the shared hardware.

Its jobs, in the order you meet them on a host:

• Abstraction: it presents virtual hardware (vCPUs, virtual RAM, virtual disks, virtual NICs) to each guest operating system.
• Resource scheduling: it decides which vCPU runs on which physical core and when, and how physical memory is shared out.
• Isolation: a crash, a reboot or a kernel fault inside one VM stays inside that VM; the others keep running.
• Virtual networking: it provides a virtual switch that connects VMs to each other and to the physical NICs (covered below).
• Lifecycle features: because a VM is just a set of files, the hypervisor can snapshot, clone and move it.

This is what makes server consolidation work: a dozen lightly used physical servers can become a dozen VMs on two hosts, each still running its own operating system, without one workload's failure taking down its neighbours.

A Type 1 (bare-metal) hypervisor is installed directly on the server hardware and owns it; there is no general-purpose operating system underneath. A Type 2 (hosted) hypervisor is an application that runs on top of an existing desktop or server operating system and borrows that OS's drivers and scheduler.

Two practical consequences. First, a laptop that must keep running Windows for everyday work while also running lab router images needs a Type 2 hypervisor; installing ESXi would replace Windows, and dual-booting means only one of them runs at a time. Second, Type 2 VMs live and die with the host OS: when Windows installs updates and restarts, the lab VMs stop, while VMs on an ESXi server carry on because nothing sits underneath the hypervisor to be patched and rebooted.

KVM is a Linux kernel module that turns Linux itself into the hypervisor, and Hyper-V slides beneath Windows once enabled, so both are usually classed as Type 1 even though an OS is involved.

A virtual machine is a complete, isolated computer built from virtual hardware (vCPU, vRAM, one or more vNICs and a virtual disk) on which its own guest operating system is installed. The guest OS does not have to match the host: a Linux host running KVM can run Windows Server guests, and twenty VMs on one ESXi host can run a mix of Linux, Windows and network operating systems.

A new VM is an empty computer. Before any application can run in it, you install a guest OS on its virtual disk, exactly as you would on a bare server; an application cannot simply be dropped into a VM without one.

Drivers still matter. The hypervisor presents virtual devices, and the guest needs drivers for them. Paravirtualized devices such as KVM's virtio NIC are fast but Windows has no built-in virtio driver, so a Windows guest given a virtio NIC shows no network adapter at all until the virtio drivers are installed (or the VM is given an emulated NIC model it does recognise). A missing adapter is a driver problem; an adapter that is present but cannot pass traffic points to the network.

A VM is a set of files (configuration, virtual disk, memory state) on a datastore, which enables:

A snapshot is not a backup: it lives on the same datastore as the VM and depends on the base disk. Snapshots left in place for weeks fill the datastore and slow disk performance, so delete them once the change has succeeded.

The hypervisor shares physical CPUs by scheduling vCPUs onto physical cores in turns, giving each a time slice. Because a vCPU is not a reserved slice of silicon, the total vCPUs assigned to VMs may exceed the host's cores; this is CPU overcommitment, and the hypervisor does not refuse to power on VMs because of it. Memory can be overcommitted too: VMs are assigned more RAM in total than the host has, on the bet that they will not all use it at once.

Overcommitment saves hardware until many VMs get busy together. Then:

• CPU contention: a VM's vCPUs are ready to run but must wait for a free physical core. The guest's own CPU counters do not show the time it spent waiting (at most a steal-time figure on some hypervisors), so the hypervisor's view of CPU ready time is the reliable measure.
• Memory pressure: when demand exceeds physical RAM the hypervisor must reclaim memory (ballooning, compression, swapping to disk), and guests slow down. No VM ever gets more usable memory than it was assigned.

For a network engineer this matters because a virtual appliance's performance depends on the whole host, not only on its own configuration. Latency, jitter or throughput that rises and falls with the load of other workloads on the same host is a sign of resource contention. The fixes are on the hypervisor side: fewer vCPUs assigned overall, CPU and memory reservations for latency-sensitive network VMs, or placing them on a less loaded host.

VMs connect through a virtual switch inside the hypervisor. Each VM's vNIC plugs into a virtual switch port; the host's physical NICs are the virtual switch's uplinks to the physical access switch. The path is: vNIC → virtual switch → physical NIC → physical switch port.

Same host, same VLAN stays inside. The virtual switch forwards frames between vNICs on the same host and the same VLAN itself, so that traffic never appears on the physical uplink or in a capture taken on the physical switch port. A standard virtual switch is a Layer 2 device, though: it does not route. Traffic between two VMs on the same host but in different VLANs goes out the uplink to the gateway (for example an SVI on a distribution switch), is routed there, and comes back down the same uplink. Heavy inter-VLAN traffic between VMs on one host can therefore congest that host's uplink.

Port groups and VLANs. On a VMware standard vSwitch, VMs attach to a port group, and the port group's VLAN ID decides how their traffic is tagged:

Because a host normally carries VMs in several VLANs over one uplink, the physical switch port facing it must be an 802.1Q trunk that allows every VLAN the port groups use, with a native VLAN that matches the port groups that send untagged frames. An access port carries only one VLAN, so tagged port groups behind it fail. Trunk configuration itself belongs to the switching domain; here, remember why the host needs one.

What the physical switch sees. Each vNIC has its own MAC address (VMware vNIC MACs usually start 00:50:56 when vCenter assigns them, or 00:0C:29 when a standalone host generates them), so the switch learns many MAC addresses, in several VLANs, on one port. That pattern in show mac address-table is the signature of a hypervisor host. Containers behave differently: on Docker's default bridge they share the host's own MAC and IP address towards the LAN, so a container host on its own looks like a single station. Port-security limits on a port facing a host must allow for every vNIC behind it.

Live migration (VMware vMotion, Hyper-V Live Migration, KVM live migration) moves a running VM from one host to another without rebooting it. Its memory is copied across while it runs, then execution switches to the destination host in a pause too short for users to notice. The VM keeps its MAC address and IP address; the destination host announces the MAC so physical switches update their tables at once.

Two things must therefore be true on the destination host:

• Storage: it can reach the VM's disk (shared storage), or the disk is copied as part of the move (storage migration).
• Network: the VM's VLAN is carried on the destination host's uplinks, with a matching port group. The VM's IP address never changes, so its subnet has to exist there.

The hypervisor checks that the destination has a suitable port group, but it cannot see the physical switch configuration. If the port group exists but the physical port facing the destination host does not carry the VLAN, the move completes and the VM then loses reachability until the VLAN is added to that trunk or the VM is moved back. The design rule follows: carry every VM VLAN to every host a VM can move to. What moves with the VM is its own identity (vNIC MAC, IP address, running state); the hosts' physical uplinks are only the path, so the requirement is that the path carries the VM's VLAN.

A container is an isolated set of processes that shares the host's operating system kernel, packaged with the application's own libraries and dependencies. There is no guest OS to boot, which is why a container starts in about a second and uses far less memory than a VM. The price is that a container must match the host kernel's OS family: Linux containers need a Linux kernel and Windows containers need a Windows kernel. (Docker Desktop runs Linux containers on Windows and macOS by running a small Linux VM underneath.)

Because there is only one kernel, anything that asks the kernel about itself from inside a container gets the host's answer: the reported kernel release is the host's, whichever distribution the image's user space comes from. Kernel features work the same way. A kernel module, such as a file-system or tunnelling driver, is part of the host's kernel; an image carries user-space files only, so a container can use a module only when it is loaded into the host's kernel, where every container on the host shares it.

Two Linux kernel features provide the isolation:

Other building blocks have different jobs: seccomp profiles restrict which system calls a container may make, and a union file system such as overlay2 stacks the image layers. Resource limits are the job of cgroups alone. Because every container uses the one host kernel, a flaw in that kernel can affect every container on the host. A VM's isolation boundary is the hypervisor, and each VM has its own kernel, which is why VMs give stronger separation between tenants who do not trust each other.

A container is started from a read-only image, writes to a disposable layer of its own, and on Docker's default network sits behind the host's address. Each of those three behaviours is tested.

Images and registries

An image is a read-only, layered template containing an application and its dependencies, identified by a name and tag such as webportal:3.4. Images are stored and shared through a registry (Docker Hub, a cloud provider's registry, or a private one such as Harbor). A container is a running instance created from an image, and one image can start any number of identical containers side by side.

Container data

Each container gets a thin writable layer on top of the read-only image. Its lifecycle is the trap:

• Stop and start: the writable layer is kept on the host's disk, so files written inside the container survive.
• Remove (docker rm) and run a new container from a newer image: the writable layer is deleted with the old container, and the new one starts clean. Writes never go back into the image.

Data that must outlive a container, such as a database or log files, belongs outside the writable layer: in a named volume managed by Docker, or a bind mount of a host directory, mounted at the application's data path. The rule is to keep the application in the image and the state in storage that Docker manages separately, so containers can be replaced freely.

Container networking

On Docker's default bridge network, each container gets a private address from the bridge's subnet (172.17.0.0/16 by default) behind a virtual bridge on the host. That address is reachable from the host itself, not from the LAN.

• Outbound: the host source-NATs (masquerades) container traffic to its own IP address. A router or ACL further along sees the host's address, never 172.17.x.x, and replies come back through the host.
• Inbound: a container is reachable from outside only through a published port. -p 8443:443 means host port 8443 → container port 443: the first number is on the host, the second inside the container. A LAN client opens https://<host-IP>:8443; the container's 172.17.x.x address and its internal port 443 are not reachable from the LAN.

docker ps shows the mapping, for example 0.0.0.0:8443->443/tcp: host port on the left, container port on the right.

A container orchestrator such as Kubernetes manages containers across many hosts: it places new containers on nodes with spare capacity, restarts or recreates failed ones, and scales the number of instances up and down with load. Three roles are easy to confuse:

The difference shows when a host fails. A Docker restart policy (--restart) restarts a crashed container on the same host, so it does nothing when the host itself is down. In Kubernetes, an application run as a Deployment declares a desired number of replicas; when a node becomes unavailable, Kubernetes recreates its pods on healthy nodes. A container someone started by hand on a node with the runtime's own CLI is outside Kubernetes' control, so it dies with that node and is not recreated anywhere.

Use a VM when you need a different OS or kernel from the host, or strong isolation between tenants; use containers for many small same-OS apps that must start fast and use little memory; and use virtual network functions to run network appliances as software. The deciding constraint usually picks the answer:

The two are often combined on one host: Linux microservices as containers for density, plus a VM for the one workload that needs a different OS. Running every small service in its own VM works but wastes a guest OS per service; a Windows-only app cannot run in a Linux container, and a Windows container still needs a Windows kernel.

Network functions virtualization (NFV) applies the same idea to the network: routers, firewalls and other appliances run as software, as virtual network functions (VNFs), on standard x86 servers instead of dedicated hardware. The Cisco Catalyst 8000V virtual router is an example. A VNF is an ordinary VM, so its GigabitEthernet interfaces are vNICs attached to port groups: one vNIC per port group places one interface in each VLAN. To route several VLANs over a single vNIC, attach it to a port group that passes tags to the guest (VLAN ID 4095 on a VMware standard vSwitch) and configure 802.1Q subinterfaces on the router, as a router-on-a-stick would on a physical trunk. A port group with one VLAN ID strips the tag, so subinterfaces for other VLANs would see nothing.