Building a virtual machine that does not fight you

Why this matters

This is the most directly useful lesson in the course for a working technician. A virtual machine is a disposable computer: somewhere to test an upgrade, reproduce a user's fault, run the legacy application that only works on an old operating system, or open something you do not trust.

The exam asks about the settings, and the settings are where new users create their own problems — a disk that fills the host, a snapshot chain nobody cleaned up, a network mode that isolates the guest from the thing it needed to reach. All of those are avoidable at creation time and painful afterwards.

Everything here is doable on the machine you already have, which is why this is the applied lesson for the virtualisation objective.

The lesson

Sizing a machine for its job rather than accepting the defaults

The defaults are chosen to work everywhere, which means they are wrong almost everywhere. Four decisions:

• Processors. Two virtual processors for a desktop guest, one for a light server or a utility. More is rarely better on a bench machine, because a guest with many virtual processors waits for that many host cores to be free simultaneously.
• Memory. The guest operating system's realistic requirement, not its stated minimum — a modern desktop guest wants 4 GB to be pleasant. The constraint is the host: leave it enough, because a host that starts paging makes everything on the machine unusable.
• Disk. Generous on the maximum size and dynamic in allocation, which the next section explains.
• Firmware type. UEFI for modern guests, legacy BIOS for old ones. Changing it after installation means reinstalling, so this is worth getting right first.

Two settings that are easy to miss and save real time later: enable enough video memory for a comfortable desktop resolution, and enable nested virtualisation if the guest itself will run containers or a hypervisor.

Virtual disks: fixed against dynamic, and where each one hurts

A virtual disk is a file on the host, and it is created in one of two ways.

Fixed size allocates the whole file immediately. A 100 GB disk consumes 100 GB of host storage on day one.

• Slightly faster, because there is no expansion during writes.
• No risk of the host filling unexpectedly, because the space is already taken.
• Slow to create, and wasteful when the guest uses a fraction of it.

Dynamically allocated starts small and grows as the guest writes.

• Efficient: a 100 GB disk holding 12 GB of data occupies about 12 GB.
• Quick to create.
• The risk is the host filling up. Several dynamic disks, each permitted to grow to 100 GB, on a host with 200 GB free, will eventually collide — and when a host runs out of space, guests stop abruptly and can be damaged.
• Marginally slower during expansion, and the file becomes fragmented on mechanical storage.

The practical default is dynamic with a generous maximum, plus the discipline of watching host free space. The place it hurts is a laptop with a small drive running three guests, and the cure is to know the total potential size rather than the current one.

Two more disk facts worth knowing: a dynamic disk does not shrink when files are deleted inside the guest — reclaiming that space needs an explicit compact operation, usually after zeroing free space in the guest. And snapshots, below, consume space on top of all of this.

Guest additions and tools, and the features that do not work without them

Every hypervisor ships a package to install inside the guest — guest additions, guest tools, integration services, depending on the product. It provides paravirtualised drivers and host integration, and without it the guest runs on generic emulated hardware.

What it enables, which is the list of symptoms people report before installing it:

• Proper display drivers, so the guest can use arbitrary resolutions and resize with the window. Without them, a guest is stuck at a small fixed resolution.
• Smooth mouse integration, so the pointer moves in and out of the window without being captured and released.
• Shared clipboard and drag-and-drop, where enabled.
• Shared folders between host and guest.
• Time synchronisation with the host, which matters because guest clocks drift when the guest is paused or the host is loaded.
• Faster disk and network drivers.
• Graceful shutdown from the host.

The security note from lesson 29 applies directly: shared clipboard, shared folders and drag-and-drop are convenience features that punch a hole in the isolation. For a guest handling anything untrusted, install the tools for the drivers and turn those three off.

Snapshots: what they are for, what they are not, and how they consume a disk

A snapshot captures the guest's state at a moment, so it can be returned to exactly that state later. Optionally it includes memory, so a running machine resumes mid-task.

What they are for: taking one immediately before a risky change. An update, a driver installation, a configuration experiment, opening something suspicious. Revert takes seconds, and that is the whole value.

What they are not:

• Not a backup. The snapshot lives in the same files, on the same host, in the same place. Losing the host loses the snapshot with the machine.
• Not a long-term mechanism. They are meant to exist for minutes or hours.

How they consume disk: after a snapshot, the original disk is frozen and new writes go to a differencing file. Every subsequent snapshot adds another layer, and the guest reads down the chain. Consequences:

• Space grows without bound. A guest with a month-old snapshot has been writing into a differencing file that entire time, and it can exceed the original disk.
• Performance degrades with chain length, because each read may traverse several files.
• Deleting a snapshot merges it, which needs free space and time — sometimes a great deal of both. A host that is nearly full may be unable to delete a snapshot at all, which is an unpleasant corner to be in.

The discipline: take one before the change, delete it once the change is proven, and never leave one for more than a few days.

Networking modes, and choosing between isolated, shared and bridged

Hypervisors offer several networking modes, and picking the wrong one produces a guest that is either unreachable or more exposed than intended.

• NAT / shared. The guest sits behind the host, gets an address from the hypervisor, and reaches the outside world through the host's connection. Other machines on the network cannot reach it without a forwarding rule. The safe default, and right for most uses.
• Bridged. The guest appears on the physical network as a peer, with its own address from the network's DHCP server. Other machines can reach it directly. Right when the guest must be a server; wrong for anything untrusted, because it is now a full participant on the network.
• Host-only. The guest can reach the host and other guests on the same host-only network, and nothing else. No internet. Right for a multi-machine lab, and for isolating something that must be examined but not permitted out.
• Internal / isolated. Guests can reach each other and not even the host. The strongest isolation available without disconnecting entirely.
• Not connected. No adapter at all. The correct setting for opening something genuinely untrusted.

Choosing from a stated requirement:

• "The guest needs internet and nothing needs to reach it" → NAT.
• "The guest is a test web server other machines must reach" → bridged.
• "Two guests must talk to each other and not to the network" → host-only or internal.
• "I am opening a suspicious file" → not connected, and no shared folders.

The mode can be changed after creation, which makes the safe choice cheap: start isolated and open it up only when the guest has a reason to be reachable.