Bare-metal hypervisor
Runs directly on hardware and manages guest VMs. Data centres favour this design for control, predictable overhead and strong operational tooling.
Code
Bhavya
Understand how hypervisors virtualize hardware and how containers isolate processes while sharing one kernel. Compare performance, compatibility, density and security boundaries instead of treating either model as universally better.
Runs directly on hardware and manages guest VMs. Data centres favour this design for control, predictable overhead and strong operational tooling.
Runs above a host OS. It is convenient for desktop labs, but guest I/O passes through additional host layers.
Each VM owns a guest kernel, virtual CPUs, virtual memory and virtual devices. Different OS families can share one physical server.
| Mechanism | What is virtualized? | Key OS idea | Main cost |
|---|---|---|---|
| Trap and emulate | Privileged operations | Hypervisor handles sensitive instruction | Transitions |
| Hardware assist | CPU execution modes | Guest runs directly until a controlled exit | VM exits |
| Nested paging | Guest physical memory | Guest mapping plus host mapping reaches RAM | Translation/TLB pressure |
| Virtual device | Disk/network interface | Emulation or paravirtual driver performs I/O | Copying and exits |
PID, mount, network, IPC, UTS, user and cgroup namespaces create separate views of global kernel resources.
Account for and limit CPU, memory, I/O and process counts. A namespace changes visibility; a cgroup changes resource policy.
Read-only image layers are shared. Copy-on-write gives each running container a private writable layer; persistent data belongs in volumes.
container = processes + namespaces + cgroups + filesystem view
image ≠ running container
shared kernel ≠ no isolation
Pin dependencies, use a minimal trusted base and avoid embedding secrets.
The runtime prepares namespaces, cgroups, mounts, capabilities and security policy.
The application becomes the container's PID 1 and must handle signals and child reaping correctly.
Logs, metrics and health checks reveal state; deployments replace failed or outdated instances.
The recommendation will balance boundary strength, compatibility, startup time and density.
Run with the smallest identity and capability set, make filesystems read-only where practical and block privilege escalation.
Default-deny traffic, mount only necessary data and inject short-lived secrets rather than baking credentials into images.
Scan dependencies and images, update host kernels/runtimes and verify image origin. A stale base layer remains vulnerable.
| Dimension | Virtual machine | Container |
|---|---|---|
| Kernel | Separate guest kernel | Shares host kernel |
| Startup | Usually seconds or longer | Usually faster |
| Density | Lower due to guest OS overhead | Higher for similar services |
| OS compatibility | Can run a different guest OS | Must use compatible host kernel |
| Security boundary | Typically stronger kernel separation | Requires careful kernel/runtime hardening |
Mark complete after defending a VM/container choice from explicit requirements.
Saved in this browser.