What Is a Virtual Machine?

Lab SetupLesson 1 of 220 minutesLessonNo lab next

Learning objectives

By the end of this lesson

• Explain the difference between a host computer and a guest virtual machine.
• Describe what the hypervisor does.
• Explain why snapshots are useful, and why they aren’t backups or perfect security boundaries.
• Explain why virtualization and emulation differ, and why the course targets x86-64 either way.
• Choose the right setup guide for your computer.

A computer inside your computer

Before we can go exploring in Linux, we need somewhere to explore it, and installing Linux directly onto the computer you use every day would mean rearranging its operating system and its storage. That’s a lot to ask of a machine that also holds your tax documents. So we’ll use a virtual machine instead, usually shortened to VM, which gives us a separate course environment we can reset after an experiment.

A virtual machine is a computer made out of software. It has virtual processors, memory, storage, networking, and the rest of the hardware you’d expect, and we can install an operating system inside it, start it, shut it down, and restore it after an experiment without reinstalling the host operating system.

The physical computer is the host, and the operating system running inside the VM is the guest. Software like VMware Workstation Pro, Hyper-V, or UTM sits between the two and hands the guest its virtual hardware, and that software is called a hypervisor.

You now have four terms: host, guest, hypervisor, and virtual hardware. Before you read on, make a prediction. When Ubuntu is running in the VM, which system owns each of these: the physical memory, the virtual disk file, the Ubuntu filesystem, and the Terminal process? Write your guess down so you can check it in a minute.

Key concept

The apartment-building model

Think of the host as an apartment building and each VM as an apartment inside it. The building supplies the shared plumbing and power, but each apartment has its own rooms and its own locks, and a tenant can make a serious mess without automatically redecorating everyone else’s place.

The analogy has a limit: VM isolation depends on software and configuration. A hypervisor can have bugs, and shared folders or networking connect the guest to resources outside it. Use the VM as a controlled workspace, not a guarantee that any experiment is harmless.

Virtual hardware still runs on real hardware

Giving a VM four processor cores and eight gigabytes of memory uses real host resources. The hypervisor schedules work on the host’s processor and allocates some of its memory, so the host needs enough left for its own applications.

Storage works the same way. A virtual disk is normally just one or more files sitting on the host, and the guest treats that file as though it were a physical drive. If the virtual disk grows to 40 GB, the host needs roughly 40 GB free to hold it.

So now go and check your prediction, because sorting out who owns what is the entire point of the exercise. The physical memory and the virtual disk file belong to the host, because the hypervisor lends the guest a slice of real memory and keeps the disk as an ordinary host file. The Ubuntu filesystem and the Terminal process belong to the guest, and they exist only inside that virtual disk and that running VM. The boundary you just drew is the host/guest line, and nearly every later lesson leans on it.

The guest is separated from the host by the hypervisor

The physical host provides real processor, memory, storage, and network resources. The hypervisor presents controlled virtual versions of those resources to the Ubuntu guest.

Host computerYour physical computer and its operating system

ProcessorMemoryStorageNetwork

HypervisorCreates and controls virtual hardware

Guest virtual machineUbuntu and the course files

vCPU8 GB RAM60 GB diskNAT

The physical host provides real processor, memory, storage, and network resources. The hypervisor presents controlled virtual versions of those resources to the Ubuntu guest.

For this course the comfortable target is a host with at least 16 GB of memory and 80 GB of free storage. We’ll normally give the course VM 8 GB of memory, four virtual processor cores, and a virtual disk with room to grow to 60 GB. A host with 8 GB of memory in total can still work, but you’ll want to assign the VM only 4 GB and close whatever else is running (browser tabs count, and a modern browser will happily eat several gigabytes on its own).

Why this course uses a VM

A consistent environment

Working from the same Linux distribution and architecture means your output matches the course examples closely. Commands, file locations, tools, and lab artifacts won’t depend on whatever happens to be installed on your host.

A disposable workspace

You’re going to install tools, change configurations, and run course-supplied programs that were built to fail in interesting ways. That work belongs on a machine made for experiments, and not next to your tax documents and your saved browser passwords.

Snapshots

A snapshot records enough of a VM’s current state that you can come back to it later. Take one before a risky experiment, and if the guest ends up unusable you restore it instead of losing an afternoon undoing changes that nobody wrote down at the time. I’d take a snapshot before every lab that touches system configuration. They’re cheap, and the alternative (an afternoon of guessing at what you changed) is not.

But a snapshot depends on the original VM files, so it is not a backup. If the host drive dies or the VM directory gets deleted, the snapshots usually go with it.

Controlled connections

The hypervisor decides how the guest reaches the host and the network. We’ll start with NAT networking, which lets the guest get to the internet through the host without normally exposing it as another directly reachable machine on your local network. Later labs may use tighter networks, for targets that have no business talking to the internet at all.

Safety note

Convenience creates openings

Shared folders, shared clipboards, USB passthrough, and networking all connect the guest to something outside it. They’re genuinely useful, and every one of them weakens the separation we built the VM to get. We’ll turn them on when a lesson needs them, and leave them off the rest of the time.

Virtualization and emulation

Virtualization runs guest code on a host processor of the same architecture, so an x86-64 Windows computer can virtualize an x86-64 Linux guest efficiently.

Emulation makes one processor architecture behave like another. Current Macs use Apple Silicon ARM processors, and the course targets are x86-64, which is the architecture Intel and AMD computers use. UTM can emulate x86-64 on Apple Silicon, but translating every instruction costs you real time (expect the VM to feel a lot slower than a native one).

On Apple Silicon, take the slower x86-64 emulation path anyway. An ARM Linux VM will feel faster, and it will also produce different machine code and won’t run every x86-64 artifact we hand you. That stops being an abstract concern the moment you start reading assembly.

The introduction to QEMU system emulation describes its machine models and acceleration choices. It helps distinguish an emulated CPU from hardware-assisted execution.

Choose your setup guide

Pick one guide, you don’t need all three.

• VMware Workstation Pro is what I’d recommend for Windows 10 or 11 Home, Pro, Enterprise, or Education on an Intel or AMD processor.
• Hyper-V is built into Windows 11 Pro, Enterprise, and Education. It isn’t included with Home editions, and the Hyper-V steps here target Windows 11, so on Windows 10 use VMware Workstation Pro.
• UTM is the macOS option, and its guide covers both Intel and Apple Silicon Macs.

There’s no reason to run both VMware Workstation and Hyper-V on the same host. They can coexist on current Windows systems, but the extra hypervisor layer can slow VMware down and makes troubleshooting a lot less pleasant (two hypervisors mean two plausible explanations for every problem). Pick one and move on.

Windows: VMware Workstation Pro Windows Pro or later: Hyper-V macOS: UTM

After Ubuntu is running, every installation guide sends you to Prepare Your Course Workspace. Do that lesson inside the VM.

Check that your chosen guide matches your host operating system and processor. If you can’t work out your host processor or your Windows edition, use the matching setup guide’s first verification step before you download anything.

Common failures and recovery

If the guide you picked doesn’t match your host operating system, processor architecture, or Windows edition, stop before you install a hypervisor. Go back to the host-information step and follow the path that matches what you have.

Check your understanding

Knowledge check

Question 1 of 2

The host disk containing a VM and its snapshots fails. Which recovery source is independent of that disk?

A snapshot on the same diskThe guest filesystem on that diskA backup on separate storage

Check answer