Your first VM with virt-manager¶

Practical 2.2 first-vm-virt-manager-annex.pdf · PDF

To try a new operating system on a real PC you need a spare PC, a USB stick, an hour, and the courage to wipe a disk. You have none of those. You have a window.

On the Virtualisation page you checked that the class server can run virtual machines. Now you build one. In about 25 minutes there will be a second computer inside your computer — and you will catch it believing things about itself that are not quite true.

A computer made of settings and files¶

Picture an empty PC case. Before it can start, you must put parts inside — you know the list from Unit 1. A virtual machine needs the same list, except every part is a setting or a file:

An ISO image is a single file holding an exact copy of a CD, DVD or USB installer. The VM "inserts" it and boots from it, as a real PC would boot from a disc.

A live system is a complete operating system that starts straight from the disc, without installing anything. It runs in RAM.

Live systems are great for trying a system, for rescuing a broken PC — and for today. Before you start, think about one question: if it runs in RAM, what happens to your files when you switch off? Task 5 answers it.

Where is today's host?¶

On the Virtualisation page the host was your PC. Today it is not. Picture three boxes:

flowchart LR
    PC["<b>Your PC</b><br>the remote control:<br>shows the VM's screen"] -->|"mouse, keyboard"| NET(["Internet"])
    NET --> G
    subgraph SRV ["Class server: the host, in a data centre"]
        G["<b>Your guest</b><br>live-test"]
    end
    G -.->|"its screen"| PC

The VM runs on the class server, a real machine in a data centre. Your PC only shows the VM's screen and sends it your mouse and keyboard, like a remote control. The host is the computer that lends its hardware — today that is the server, not the PC in front of you.

Every student is a Linux user on the server, with their own libvirt, and only sees their own VMs. Your teacher gives you a slip with three things: the server address, your user name and your password.

A remote connection is virt-manager talking to libvirt on another machine instead of on your own PC. The road it travels is SSH, a secure way to log in to a computer from another one (you will meet it properly with Ubuntu Server).

Build it: connect, then the five steps of the wizard¶

First, one line that saves you a lot of typing. virt-manager opens a separate SSH road for every part of the VM's window — picture, keyboard, mouse, sound — and each one would ask for your password. This line tells SSH to open one road and let the others share it, so you type the password once. Open a terminal on your PC (Ctrl+Alt+T), paste it, press Enter. You only do it once: it stays in your account.

mkdir -p ~/.ssh && printf 'Host *\n  ControlMaster auto\n  ControlPath ~/.ssh/cm-%%C\n  ControlPersist 10m\n' >> ~/.ssh/config

Now the connection. Open Virtual Machine Manager:

1. File → Add Connection. Hypervisor: Custom URI... and type qemu+ssh://<user>@<server>/session (your user and the server address from the slip) → Connect.
2. Type the password from the slip. Wait: connecting takes up to a minute. The new connection appears in the list: select it. It is empty — you have no VMs there yet.

Now the wizard. Click File → New Virtual Machine and check that Connection shows the server:

1. Choose Local install media (ISO image or CDROM) → Forward.
2. Type the path /srv/isos/debian-live-13.7.0-amd64-gnome.iso in the box → Forward. Do not use Browse Local: it browses your PC, and the ISO is on the server. Leave Automatically detect ticked. If it finds nothing, or something that is not Debian, untick it and type Debian 13 (or Debian 12 if the list has no 13).
3. Memory 4096, CPUs 2 → Forward.
4. Create a disk image for the virtual machine: 10 GiB → Forward.
5. Name: live-test. Network selection: Bridge device..., Device name: virbr0 → Finish.

A new window opens with the Debian boot menu. Click inside it, choose Live system (amd64) and press Enter. In about a minute the GNOME desktop appears, logged in as the user user (password live, if it ever asks).

flowchart LR
    ISO["<b>ISO image</b><br>the installer disc,<br>read-only"] -->|"boots"| VM["<b>VM live-test</b><br>2 vCPU · 4096 MiB"]
    VM -->|"runs in"| RAM["<b>RAM</b><br>the live system<br>lives here"]
    VM -.->|"not used today"| DISK["<b>qcow2 disk</b><br>10 GiB, empty"]

When it goes wrong¶

Inside the guest: what does it believe?¶

In the guest, press the Super key (the one with the logo), type terminal and press Enter. Every command is given whole; type it and write the answer on the Practical sheet.

nproc                  # how many CPUs do I have?
free -h                # how much RAM? (column "total", line "Mem:")
lsblk                  # which disks?
ip -br a               # my network addresses
systemd-detect-virt    # am I a virtual machine?
ping -c 3 debian.org   # can I reach the internet? (3 packets, then it stops)

What you should see:

The guest says it has a 10 GB disk. Does it know that disk is a file? No. That is the trick: the guest cannot tell.

What you just built: qcow2 and NAT¶

The disk that grows¶

qcow2 (QEMU Copy-On-Write, version 2) is the disk-file format used by QEMU. The file starts tiny and grows only as the guest writes data.

The guest sees a full 10 GB disk. The host only stores the parts the guest has actually written. This is called thin provisioning. Since the live system runs in RAM and writes nothing to the disk, the file right now is almost empty.

The network: NAT¶

Inside the host — the class server — there is a small virtual router. It gives the guest a private address (192.168.122.x) and has the address 192.168.122.1 itself. On the host it shows up as a network interface called virbr0.

When the guest talks to the internet, the host replaces the guest's address with its own. That is NAT (Network Address Translation) — the same trick the router at home does for your phone.

And you are not alone in there: every classmate's VM hangs from the same virtual router, each with its own 192.168.122.x.

flowchart LR
    subgraph HOST ["Host: the class server"]
        G["<b>Your guest</b><br>live-test<br>192.168.122.x"] --> VR["<b>Virtual router</b><br>virbr0<br>192.168.122.1"]
        G2["<b>Your neighbour's guest</b><br>192.168.122.y"] --> VR
        VR -->|"NAT: swaps the guest's<br>address for the host's"| NIC["<b>Real network card</b><br>the server's public address"]
    end
    NIC --> NET(["Internet"])

The consequence: the guest can go out; nobody outside can come in. Addresses and NAT are studied properly in Unit 3 — for now, the drawing is enough.

On the host: the truth¶

Today the host is the class server, so that is where the truth lives. Open a terminal on your PC, not in the VM (Ctrl+Alt+T), and log in to the server with the same user and password as in virt-manager. Then run the same commands, plus one question for libvirt about the disk file:

ssh <user>@<server>    # the same login as virt-manager
nproc
free -h
ip -br a
virsh -c qemu:///session vol-info --pool default live-test.qcow2
exit                   # back to your PC

After ssh, the prompt changes to <user>@si: you are typing on the server now. Read the virsh answer carefully:

• Capacity: 10.00 GiB is what the guest sees.
• Allocation: is what the file really takes on the host — a couple of MiB, because the live system wrote nothing.

Fill in the comparison on the Practical sheet. It will look something like this:

Find the line virbr0 in the server's ip -br a: that is the virtual router from the drawing. Why does the server have so many more CPUs and so much more RAM than your PC? Because the whole class's guests live on it at once.

If virsh answers "Storage volume not found", refresh the list of disk files first: virsh -c qemu:///session pool-refresh default.

Change the hardware¶

On a real PC, adding RAM means a screwdriver. On a VM it means two clicks — but only while it is shut down.

1. In the guest, open Text Editor, write your name and save the file in Documents.
2. Menu Virtual Machine → Shut Down → Shut Down. A black screen is not enough — that may be the screensaver. If after 30 seconds the VM is still running, use Virtual Machine → Shut Down → Force Off: a live system has nothing to lose.
3. View → Details (the light-bulb button). After the first boot virt-manager ejected the ISO and set the VM to start from its disk — which is empty. Put the disc back: SATA CDROM 1 → Source path /srv/isos/debian-live-13.7.0-amd64-gnome.iso → Apply. Then Boot Options → tick SATA CDROM 1 and move it to the top → Apply.
4. Memory: 2048 → Apply. CPUs: 1 → Apply.
5. View → Console, press ▶, boot the live system again and open the terminal.
6. Run nproc and free -h again, and look for your file in Documents.

nproc now says 1, free -h about 1.9Gi — and your file is gone. The live system lives in RAM, RAM is volatile (Unit 1), and the 10 GB disk was never used. Installing — next week — is exactly the step that copies the system onto that disk.

When you finish, shut the VM down again. Do not delete it: you will use it again.

The report¶

Write practical-2.2-surname.md with the lab report template: the VM's specification as a table, the guest/host comparison, the hardware change, and your answers, in your own words, to three questions:

1. What is the ISO file for?
2. The guest sees a 10 GB disk. Why does the file take so little space on the host?
3. Why did your file disappear after the restart?

Hand it in on Google Classroom before the deadline on the Practical sheet. The sheet shows how it is marked.

Key takeaways¶

• Today the host is the class server: virt-manager reaches it through a remote connection over SSH, and your PC only shows the VM's screen.
• A VM is a shopping list of settings and files: vCPUs, a slice of RAM, a qcow2 disk file, an ISO image and a NAT network.
• A live system boots from the ISO and runs in RAM: nothing you do survives a restart, because nothing was installed.
• The guest believes its hardware is real; commands on the host show the truth. systemd-detect-virt answers kvm inside.
• A qcow2 disk uses thin provisioning: capacity 10 GiB, allocation only what the guest has written.
• With NAT, the guest gets a private 192.168.122.x address from a virtual router (virbr0, 192.168.122.1): it can go out, nobody can come in.
• Change a VM's hardware only when it is shut down, in View → Details.

Quick check¶

Next: today the VM's numbers were given to you. Next time you decide them yourself — Planning an installation.