Lesson 2: Hypervisors, VDI, Containers, and VM Requirements

"It runs virtually" is not enough information to troubleshoot anything.

You need to know where the virtualization boundary lives.

A Type 1 hypervisor, a Type 2 hypervisor, VDI, and a container can all deliver isolated computing environments, but their dependency chains are different.

Different chain, different failure path.

Type 1: the hypervisor sits directly on the platform

hardware
  ↓
hypervisor
  ↓
guest VMs

The hypervisor owns the virtualization layer directly over the physical platform.

If several guests fail together, shared boundaries include physical host hardware, hypervisor state, shared storage, and shared virtual networking.

The guests may be separate systems logically while still sharing real infrastructure.

Visual reference

See the system before you troubleshoot it

illustrationHost, Hypervisor, VM, Container, Cloud

Type 2: a host OS sits underneath the virtualization application

hardware
  ↓
host operating system
  ↓
hypervisor application
  ↓
guest VM

That extra host-OS layer matters.

If the host OS loses network access, the guest may lose its path too. If the host OS crashes, every Type 2 guest on that host stops regardless of how healthy each guest was moments earlier.

The guest is independent enough to be useful.

It is not independent enough to ignore the host.

Virtual hardware maps onto real resources

A guest may see:

• virtual CPU;
• virtual RAM;
• virtual disk;
• virtual NIC;
• virtual optical media;
• supported virtual USB or other devices.

Those are abstractions presented by the platform.

The host still provides the capacity underneath them.

A virtual disk can fill. A virtual NIC can be disconnected. A virtual CPU can be starved by an overloaded host.

The interface looks virtual. The failure is still real.

Virtual networking decides what the guest can reach

Platform names vary, but common concepts include:

Bridged or external

The guest connects more directly to the external network through the host's physical path.

NAT or shared

The guest reaches outward through a translated or shared host-side boundary.

Host-only

The guest can communicate within a host-local virtual network without normal external access.

Internal or private

Guests communicate through an isolated virtual network according to the platform design.

If a VM is attached to host-only networking while the user expects internet access, the virtual network may be working exactly as configured.

The symptom is a design mismatch, not necessarily a broken NIC.

Robotnix container simulation
Ghostty renders the terminal. No Docker daemon, image pull, registry, or host container runtime is connected.

$ docker images
REPOSITORY   TAG      IMAGE ID       SIZE
nginx        alpine   4f67c83422ec   52MB

$ docker ps
CONTAINER ID   IMAGE   STATUS   NAMES

$ docker run --name web-demo nginx:alpine
a13f7c2b8d11 (simulated container started)

$ docker ps
CONTAINER ID   IMAGE          STATUS        NAMES
a13f7c2b8d11   nginx:alpine   Up 8 seconds   web-demo

$ docker stop web-demo
web-demo

$ docker ps -a
CONTAINER ID   IMAGE          STATUS                     NAMES
a13f7c2b8d11   nginx:alpine   Exited (0)                 web-demo

Worked case: one VM has no network

Evidence:

host network: healthy
VM A: healthy
VM B: healthy
VM C: no connectivity
VM C virtual NIC: disconnected

The first failed boundary is the affected VM's virtual device configuration.

Do not reset the physical router because other guests and the host are working.

VDI moves the desktop away from the endpoint

Virtual Desktop Infrastructure delivers desktop sessions from centralized infrastructure.

endpoint
   ↓
local network / internet
   ↓
identity / authentication
   ↓
VDI broker or access service
   ↓
virtual desktop / session
   ↓
applications / data

The local endpoint can be healthy while the VDI desktop is unavailable.

A user may say:

"My computer is broken because my desktop won't load."

Maybe.

Or the endpoint is fine and the centralized desktop service failed.

The architecture tells you where to look.

Containers isolate applications differently from full VMs

A full VM normally includes a complete guest operating-system environment.

A container typically isolates an application and dependencies while sharing more of the host operating-system kernel and platform.

VM:
hardware → host/hypervisor → guest OS → application

container:
hardware → host OS → container runtime → isolated application

A container is not simply "a tiny VM."

That difference affects startup, resource use, isolation, host dependency, and troubleshooting.

Storage is another shared boundary

Virtualization often uses files or storage objects for virtual disks, snapshots, VM configuration, templates, and images.

Technician concerns include:

• free capacity;
• performance;
• permissions;
• snapshot growth;
• backup and export;
• host-storage health.

If host storage fills, one or many guests can fail even when their virtual filesystems look logically separate.

Security follows the layers

Ask:

• Who can create or modify VMs?
• Is the hypervisor supported and updated?
• Is the host secure?
• Which networks can the guest reach?
• Are legacy guests isolated appropriately?
• Are virtual disks and snapshots protected?
• Does shared-folder or device access cross an intended boundary?

Virtualization creates isolation opportunities.

It also creates new administrative surfaces.

Compare the models

For Type 1, Type 2, VDI, and containers, document:

where the boundary lives
what the user sees
major shared dependency
network dependency
storage dependency
one failure outside the guest/application
one security question

Before you move on

The useful troubleshooting question is:

Which layer owns the resource or decision that failed?

Host, hypervisor, virtual device, guest, broker, container runtime, application, or external service?

Next we add cloud computing, where that same question becomes a responsibility map between customer and provider.