Proxmox VE: a datacentre in a VM¶

Exercise Practical 2.8 PDF

You have three VMs on the class server, and so does everyone in your class. Netflix, your school's Moodle and your bank run thousands. So where is the person with the mouse, clicking New VM all day?

There is none. There is a room full of computers with no screen and no keyboard — and a web page. This page shows you that web page, Proxmox VE, first on a real server and then installed by you, inside a VM on the class server. A whole server room inside one file, with a snapshot in case you break it.

A hypervisor with no screen¶

You met the two types of hypervisor in Virtualisation. Picture them side by side:

On the server, the hypervisor is what was installed on the metal, and the machine does nothing else. That is the classic picture of a type 1, or bare-metal, hypervisor. The class server you use is already closer to the right-hand column: nobody sits in front of it, and you manage it from another computer.

Proxmox VE (Virtual Environment) is a type 1 hypervisor: a Debian system prepared to do only one job — run virtual machines and containers — managed from a web browser.

A little history¶

Proxmox Server Solutions was founded in Vienna in 2005 by Martin and Dietmar Maurer. The first public version of Proxmox VE came out on 15 April 2008. It is free software.

For years the best-known name in this field was VMware. On 22 November 2023 the company Broadcom finished buying VMware and changed its licences and prices. Since then many companies and schools have been moving to Proxmox. The current version is 9.2 (21 May 2026), built on Debian 13 — the same Debian as deb-lab.

A tour of the web interface¶

The address of a Proxmox server always ends in port 8006: https://ADDRESS:8006.

What a datacentre adds when it has many nodes, in one sentence each:

• A cluster is several nodes managed from one page.
• Live migration moves a running VM to another node without switching it off.
• High availability restarts a VM on another node when its node dies.

The hunt¶

The Exercise sheet sends you into a real Proxmox server with a read-only account: you can look at everything and touch nothing. Three things will surprise you on the way in:

• The browser warns you. The server signs its own certificate, so nobody outside vouches for it. On your own lab server that is expected; on your bank's website it would be an alarm. Choose Advanced → continue.
• The Realm field. The login box asks for a realm, the place where your user is defined. For the read-only account choose Proxmox VE authentication server.
• No valid subscription. Press OK. The software is complete; the company sells support subscriptions.

Try to press Start on a stopped VM. The button is grey, or the action is refused. That is least privilege: an intern, an auditor or a monitoring screen on the wall gets an account that can only look.

Russian dolls: nested virtualisation¶

Your turn to install one. Proxmox will run inside a VM on the class server, and then create guests inside itself:

flowchart TB
    PC["<b>Your PC</b><br>only shows the screens"]
    subgraph SRV["<b>Class server</b> · real hardware, KVM"]
        subgraph PVE["<b>VM pve</b> · Proxmox VE, also a hypervisor"]
            CT["<b>Container box1</b><br>Debian 13<br>borrows pve's kernel"]
            VM1["<b>VM vm1</b><br>Alpine Linux<br>brings its own kernel"]
        end
    end
    PC -->|"virt-manager and ssh,<br>over the internet"| SRV

Nested virtualisation is running a hypervisor inside a virtual machine: a VM in a VM.

To run the smallest doll, the middle doll must see the CPU's virtualisation instructions (VT-x on Intel, AMD-V on AMD). A normal VM gets a simplified, pretend CPU without them. So you tell virt-manager to hand over the real model: Copy host CPU configuration.

Nobody runs a production datacentre like this — there Proxmox is installed on the metal. But everybody learns like this.

Get ready¶

The host is the class server, so the checks run there. Open a terminal on your PC and log in with the user and password from your slip:

ssh <user>@<server>

The prompt changes to <user>@si: you are typing on the server. First, check that it allows nested virtualisation. One of these lines will say No such file or directory: that is normal.

cat /sys/module/kvm_intel/parameters/nested
cat /sys/module/kvm_amd/parameters/nested

The line that works must answer Y (Intel) or 1 (AMD). N or 0 means nested virtualisation is off: tell your teacher. It is one server, so the whole class gets the same answer.

Then verify the ISO, as you learned in Verify an ISO. It is already on the server, in /srv/isos:

cd /srv/isos
sha256sum proxmox-ve_9.2-1.iso

The 64 characters must match the value published on the Proxmox download page for proxmox-ve_9.2-1.iso:

4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6c

Finally, check there is room:

free -h
df -h ~/.local/share/libvirt/images
exit

free -h shows the server's RAM: tens of GiB, but shared by the whole class. Your pve needs 4 GB of it, and so does every classmate's: shut down your other VMs before you start it. df -h should show at least 35 GB free where your VM disks live.

Install Proxmox VE¶

Shut down every other VM of yours first — the server is shared. In virt-manager, on your connection to the class server: New VM → Local install media → type /srv/isos/proxmox-ve_9.2-1.iso (not Browse Local: that browses your PC). If it cannot detect the system, untick the detection and type Debian 13. Memory 4096, CPUs 2, disk 32 GB, name pve, network Bridge device virbr0. Tick Customize configuration before install → Finish. Then CPUs → tick Copy host CPU configuration (host-passthrough) → Apply → Begin Installation.

Choose Install Proxmox VE (Graphical) and go screen by screen: licence → target disk (the 32 GB one) → country Spain, time zone Europe/Madrid, keyboard Spanish → a password of your own and an e-mail → network (hostname pve.lab.internal, address as proposed) → summary → Install. The copy takes five to ten minutes: start your report.

After the restart, the black console shows the address of the web interface, like https://192.168.122.x:8006/.

That address 192.168.122.x lives in the private NAT network behind virbr0, on the class server. The server can reach it. Your PC cannot: NAT lets guests go out, but nobody outside can come in.

First login: through a tunnel¶

So you dig a tunnel. You already have a door into the server: your ssh login. ssh can carry a web page through that same door.

An ssh tunnel carries traffic from a port on your own PC, through your ssh login, to an address that only the server can reach.

Open a terminal on your PC and type, with your pve address from the black console:

ssh -L 8006:192.168.122.x:8006 <user>@<server>

Read it as: "whatever reaches port 8006 of my PC, carry it to the server, and from there to 192.168.122.x, port 8006". Type your password. The prompt changes to <user>@si. Leave that terminal open: closing it closes the tunnel.

flowchart LR
    FF["<b>Firefox on your PC</b><br>https://localhost:8006"] -->|"enters the tunnel"| SSH["<b>ssh</b><br>through the internet"]
    SSH -->|"comes out on"| SRV["<b>Class server</b>"]
    SRV -->|"NAT network virbr0"| PVE["<b>pve</b><br>192.168.122.x:8006"]

Now, in Firefox on your PC, open https://localhost:8006. localhost means "this same computer": the entrance of the tunnel. Accept the warning. User root, your own password, realm Linux PAM standard authentication this time — root is a user of the Linux system itself. Press OK on the subscription box.

Open the node pve → Shell:

cat /etc/os-release
uname -r

cat /etc/os-release says Debian GNU/Linux 13 (trixie): Proxmox VE is Debian underneath. uname -r prints the version of the running kernel — the core of the operating system. On the node it ends in -pve. Write it down; it is the key to the rest of the page.

Containers and VMs: who brings the kernel?¶

Back to the dolls. A VM is a complete doll: pretend hardware, and inside it a whole operating system with its own kernel.

A container is a closed room inside the node's own system: it has its own files, programs and users, but no kernel of its own — it uses the node's.

A template is a ready-made small system in one compressed file: no installer, no questions.

A container: box1¶

Left tree: local (pve) → CT Templates → Templates → the one that starts with debian-13-standard → Download. Then Create CT: hostname box1, a password, that template, disk 4 GB, 1 core, 512 MB, network IPv4: DHCP. Finish → select box1 → Start. Count the seconds: one or two.

box1 → Console → press Enter → log in as root:

cat /etc/os-release
uname -r

Debian 13 — and exactly the same kernel as the node, ending in -pve.

A VM inside the VM: vm1¶

local (pve) → ISO Images → Download from URL → the address of a very small Linux ISO given in class (Alpine Linux, virtual edition) → Query URL (it must show the file's size) → Download. Then Create VM: name vm1, that ISO, disk 1 GB, 1 core, 512 MB. Start it, open its console, type root at login: and run:

uname -r

This time the kernel ends in -virt: not the node's kernel. vm1 brought its own.

Count the kernels in your stack of dolls right now: the server's, pve's and vm1's — three. And one container riding on the second.

Shut down from the inside out¶

1. vm1 → Stop (a live system: nothing to save). box1 → Shutdown.
2. Node pve → Shutdown (top right).
3. Wait until virt-manager shows pve as Shutoff.
4. In virt-manager: pve → View → Snapshots → + → clean.

Key takeaways¶

• Proxmox VE is a type 1 hypervisor built on Debian, managed from a browser on port 8006; it runs the same KVM/QEMU engine as the class server.
• Its tree goes Datacenter → node → guests; a cluster joins nodes, live migration moves running VMs, high availability restarts them elsewhere.
• Nested virtualisation needs the host's real CPU model passed to the VM (host-passthrough).
• pve lives behind NAT on the server; an ssh tunnel brings its page to https://localhost:8006 on your PC.
• A VM brings its own kernel; a container (LXC, from a template) uses the node's — uname -r proves it.
• A read-only account is least privilege: look, never touch.
• Shut down from the inside out, then take the snapshot clean.

Quick check¶

Unit 2 ends here: you can install, update, recover and virtualise systems. Now it is time to really live inside them — the terminal and the directory tree: Terminal survival and the directory tree.