TryHackMe: Virtualisation Basics — Learning Notes

These are my personal learning notes as I work through TryHackMe — honest notes, not an authoritative guide. Corrections welcome.

On sources & TryHackMe’s material: These are independent learning notes in my own words. They describe my experience of the room and deliberately reproduce none of TryHackMe’s room text, task content, screenshots, flags, or answers — go do the room to get those. Room names and the linked URL are used for reference only. TryHackMe and its content are the property of TryHackMe Ltd; this post is not affiliated with, authorised by, or endorsed by them.

Overview

• Room: Virtualisation Basics — link
• Difficulty: Info / Easy
• What it teaches: What virtualisation is, the hypervisor / VM / container stack, the difference between Type 1 and Type 2 hypervisors, and how a virtual environment is managed — all through a building analogy, ending in a hands-on management panel.

The problem it solves is waste. The old rule was “one server = one application,” which left most machines idling at 5–20% of their capacity while a company paid for the hardware, power, cooling and floor space of each one. Virtualisation lets many virtual machines share a single physical box safely — and for me the interesting word there is “safely”, because that isolation is exactly why a VM is where you open something you don’t trust.

The building analogy

The room’s whole model is a block of flats, and it maps cleanly:

Building	Virtualisation
The building	The physical server
The building manager	The hypervisor (divides the building up safely)
An apartment	A virtual machine — its own door, walls, kitchen
A room inside an apartment	A container
A tenant	An application or operating system

The load-bearing idea: the apartments all share the building’s structure — electricity, water, lifts — the way VMs share the physical hardware underneath, yet each is walled off from the others. One tenant’s mess doesn’t reach the flat next door.

Type 1 vs Type 2 hypervisors

The hypervisor is the software that carves the physical machine into virtual ones, hands each a slice of CPU, memory and storage, keeps them isolated, and manages their lifecycle. It comes in two flavours:

• Type 1 (bare-metal) runs directly on the hardware, with no host OS beneath it. That makes it fast and efficient — it’s what runs production servers, databases and data centres.
• Type 2 (hosted) runs as an application inside an existing operating system. Easier to install, and the right fit for laptops, learning, software testing, running something like Kali, and detonating malicious files. VirtualBox and VMware Workstation are Type 2 — this is the kind you’d install on your own machine.

VMs vs containers

Both isolate, but they draw the boundary in very different places, and the difference is the most important thing in the room:

• A VM is a whole virtual computer with its own operating system, virtual CPU, RAM, storage and network. It can run any OS, and if one VM crashes the others carry on. Strong separation, but heavier.
• A container packages a single application with its dependencies and borrows the host’s kernel rather than shipping a whole OS. That makes it tiny and near-instant to start — but because it shares the host’s kernel, it must match the host’s OS type: you can’t run a Windows container on a Linux host. Docker is the usual way to run them.

So a VM has its own OS behind a hypervisor boundary; a container shares the host’s kernel. That thinner boundary is the whole reason the malware section below reaches for a VM and not a container.

Managing a virtual environment

The hands-on task drops you into a management panel with three views: a Summary, a Lab Machines list, and a Hosts view. A couple of things worth keeping:

• Lifecycle actions. A VM can be started, stopped, paused, cloned or deleted — and one sitting in an error state can simply be restarted back to health.
• Sizing. You create a VM by filling in a preset — a name, a number of CPU cores, an amount of memory, a disk size — and the hypervisor carves that slice out of the host.
• The Hosts view is the one I’d actually live in. Per physical host it shows how many VMs it carries and how loaded its CPU, memory and storage are — so at a glance you can see which hosts have headroom for another VM, which are near 100%, and which are disconnected and carrying nothing.

Connects to my bigger goal

The reason this room matters to me is malware: a VM is the standard place to run a suspicious file and watch what it does without risking your real machine. The room names two safeguards — run a guest OS different from the host, or isolate the guest so it can’t talk to the host — and my question was why the malware can’t just cross into the host anyway. Working it through:

• The real boundary is the hypervisor. The guest only ever touches virtual hardware — virtual CPU, RAM, disk, network — and the hypervisor sits in between and mediates every access. The malware can’t see the host’s memory, files or processes; by default it’s boxed inside the virtual machine.
• The “different OS” trick is a second layer, not the main one. Even if a malicious file did reach the host, a binary built for one OS won’t natively run on another — wrong format, wrong system calls — so a guest/host OS mismatch shrinks the blast radius. Useful, but it isn’t what holds the line.
• “No communication” is the practical safeguard. The ways malware actually reaches a host aren’t magic; they’re conveniences you switched on — shared folders, shared clipboard, drag-and-drop, and above all network access. Turn those off and there’s simply no channel to cross.
• Honest caveat: strong by default, not absolute. “VM escape” bugs — flaws in the hypervisor or its emulated devices — can in principle let code break out to the host. They’re rare and prized, but they exist, so “can’t cross” really means “is designed not to, and crossing needs either an open channel or a hypervisor exploit.”

Where I got stuck

In my own notes I described my malware sandbox as a container running a different OS from the host — a Windows guest on a Linux host, that kind of thing. That’s a VM’s trick, not a container’s, and catching the slip was the useful part. A container shares the host’s kernel — it borrows the running OS’s core instead of shipping its own — which is exactly why it can’t run a different OS type: no Windows container on a Linux host. I’d half-carried the VM’s “own OS” property across and pinned it on the wrong thing.

What made it click was seeing that the shared kernel explains two things at once. It’s why a container is so light and quick — there’s no second OS to boot — and why its isolation is thinner than a VM’s: the boundary is that shared kernel rather than a hypervisor, so there’s less standing between the workload and the host. Same fact, two consequences — and it’s the reason a malware sandbox has to be a VM, not a container. For something you’re deliberately trying to infect yourself with, you want the thicker wall.

Revisit

• The operational reflexes I want to be second nature: VMs get built per function (one for mail, one for development); you size each with a preset (CPU / RAM / disk); each can be started, stopped, paused, cloned or deleted; and the per-host view (VM count plus CPU / memory / storage load) is how you decide where a new VM will fit.
• To dig deeper: how the hypervisor actually enforces the boundary (hardware virtualisation — Intel VT-x / AMD-V), the classes of VM-escape exploit, and how container isolation works under the hood (shared kernel, namespaces and cgroups) compared with a VM’s.

Lessons Learned

• Virtualisation is about using one physical machine efficiently — instead of a box idling at 5–20% for a single app, many VMs share it.
• VM vs container is a trade-off: a VM brings its own OS and strong isolation but is heavier; a container is light and near-instant but shares the host’s kernel.
• Isolation is the security property. It’s what makes a VM a safe place to open something you don’t trust — and it’s the boundary, not the OS you happened to pick, that’s the thing to understand.

References

• Virtualisation Basics — TryHackMe
• Next in the path: Cloud Computing Fundamentals (which builds on virtualisation and containerisation).