Build a Proxmox VE home lab: from bare metal to your first restored backup

Proxmox VE is a free, open-source platform that turns one ordinary computer into a host for virtual machines and Linux containers, managed from a web browser. This tutorial is for people who have never run a hypervisor before: you take one spare PC or mini server and finish with a working lab, including a backup you have actually restored.

The steps follow the official Proxmox VE admin guide. Screens and package versions change between releases, so where a menu label or file name might differ on your version, the tutorial says how to check.

What you will build

• A Proxmox VE host called pve1.example.com with a static address, reachable in your browser on port 8006.
• Updates coming from the free no-subscription repository, with the paid enterprise repository disabled so apt update runs cleanly.
• A Linux bridge (vmbr0) that puts guests on the same network as the host.
• One virtual machine (VM 100) installed from an uploaded ISO image.
• One unprivileged LXC container (CT 200) created from a downloaded template.
• A nightly backup job, plus a test restore of both guests under new IDs.

Before you start

• Hardware: one 64-bit x86 machine whose CPU and firmware support Intel VT or AMD-V. The docs list 1 GB RAM as the bare minimum for evaluation and recommend at least 2 GB for the host plus the memory you want to give guests; 16 GB makes a comfortable lab. One disk of 128 GB or more and one wired network card.
• Warning: the installer erases the disk you select. Use a machine whose data you do not need, or remove other disks before installing.
• A USB stick (larger than the ISO) and another computer to write the installer image and to open the web interface.
• Network details: a free static IP address on your LAN, the gateway and a DNS server. This tutorial uses 192.0.2.10/24, gateway 192.0.2.1; replace them with your own.
• Time: about 2 to 3 hours, most of it waiting for installs and downloads.
• Knowledge: basic Linux shell use (moving around, editing a file with nano), what an IP address and gateway are, and the idea of a virtual machine versus a container.

Step 1: Install Proxmox VE on the machine

Why: Proxmox VE ships as its own installer ISO with a Debian base, the hypervisor and the web interface already integrated. Installing it on bare metal is the supported path.

1. Download the current installer ISO from the official download page and check its SHA256 checksum against the value published there.
2. Write it to the USB stick. On Linux or macOS you can use dd (see below); on Windows the docs suggest tools such as Etcher or Rufus in DD mode.
3. In the target machine’s firmware setup, enable Intel VT or AMD-V (sometimes called SVM), then boot from the USB stick.
4. Choose the graphical install, accept the license, pick the target disk, set country and time zone, and choose a strong root password and an email address for notifications.
5. On the network screen set the hostname as a fully qualified name (pve1.example.com), the static address 192.0.2.10/24, gateway and DNS server.
6. Confirm the summary, let the installer finish and reboot. Remove the USB stick.

# Replace /dev/sdX with the USB stick. Check with lsblk first: dd overwrites the whole device.
lsblk
sudo dd bs=1M conv=fdatasync if=./proxmox-ve_*.iso of=/dev/sdX

Check: after reboot the console shows a welcome message with the web address. Open https://192.0.2.10:8006 from another computer, accept the self-signed certificate warning, and log in as root with realm Linux PAM standard authentication. If the installer fails, the docs suggest checking the second console (Ctrl+Alt+F2) for the error.

Step 2: Switch to the no-subscription repository and update

Why: a fresh install has the enterprise repository enabled. It needs a paid subscription key, so without one apt update reports errors. The no-subscription repository is free and intended for testing and non-production use, which fits a home lab.

Open a shell on the host: in the web UI select the node pve1 and click Shell, or SSH in as root. Look at what is configured first:

ls /etc/apt/sources.list.d/
cat /etc/apt/sources.list.d/pve-enterprise.sources

On Proxmox VE 9 (based on Debian 13 trixie) repositories use the deb822 .sources format. Disable the enterprise entry by adding Enabled: no to it, then create the no-subscription file. If a ceph.sources file also points at enterprise.proxmox.com, add Enabled: no there as well.

echo 'Enabled: no' >> /etc/apt/sources.list.d/pve-enterprise.sources

cat > /etc/apt/sources.list.d/proxmox.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

On Proxmox VE 8 (Debian 12 bookworm) the files use the older one-line format instead. Comment out the line in /etc/apt/sources.list.d/pve-enterprise.list and add this line to /etc/apt/sources.list:

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

You can do the same in the web UI under pve1 > Updates > Repositories, which shows warnings when something is off. Now install updates. Always use full-upgrade on Proxmox VE: the docs warn that plain apt upgrade can leave packages partly upgraded.

apt update
apt full-upgrade

Check: apt update finishes without any error lines for enterprise.proxmox.com. If the kernel was updated, reboot with reboot before continuing.

Step 3: Check the bridge network

Why: guests need a network. The installer already creates a Linux bridge called vmbr0 that holds the host’s IP address and is attached to the physical network card. Every VM or container you plug into vmbr0 appears on your LAN like another physical machine and can get an address from your router.

cat /etc/network/interfaces
ip -br addr show vmbr0

The file should contain a stanza similar to this one (the physical card name, here eno1, differs per machine):

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.10/24
        gateway 192.0.2.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

If you edit this file by hand (for example to change the address), apply it with ifreload -a. Changes made in pve1 > System > Network are staged first and take effect when you click Apply Configuration. A typo here can cut you off from the web UI, so keep a monitor and keyboard attached while you experiment.

ifreload -a
ping -c 3 192.0.2.1

Check: ip -br addr show vmbr0 shows UP and your address, and the gateway answers pings.

Step 4: Upload an ISO image

Why: a VM installs its operating system from an ISO image, just like a physical PC. The default storage called local (the directory /var/lib/vz) accepts ISO images, container templates and backups. VM and container disks go to local-lvm on a default LVM install (on a ZFS install the disk storage is called local-zfs instead).

In the web UI open Datacenter > pve1 > local (pve1) > ISO Images. Click Upload and pick the ISO file on your computer. Alternatively, copy it with scp into /var/lib/vz/template/iso/ on the host. Use a small server installer such as the Debian netinst image.

Check from the shell:

pvesm status
pvesm list local --content iso

The ISO appears as a volume ID like local:iso/debian-13-amd64-netinst.iso. Your file name will be different; use the exact name shown in the next step.

Step 5: Create and install a virtual machine

Why: a VM has its own kernel and virtual hardware, so it can run any operating system. The wizard under Create VM (top right) asks for the same settings as the command below; doing it once on the command line shows what each setting means. The docs recommend the VirtIO SCSI single controller and a VirtIO network card for Linux guests for best performance.

qm create 100 \
  --name debian-vm \
  --memory 2048 \
  --cores 2 \
  --ostype l26 \
  --scsihw virtio-scsi-single \
  --scsi0 local-lvm:32 \
  --net0 virtio,bridge=vmbr0 \
  --cdrom local:iso/debian-13-amd64-netinst.iso \
  --agent enabled=1

qm start 100

• 100 is the VM ID. IDs are unique across VMs and containers on the host.
• --scsi0 local-lvm:32 allocates a new 32 GiB disk on local-lvm.
• --net0 virtio,bridge=vmbr0 plugs a VirtIO network card into the bridge from Step 3.
• --agent enabled=1 prepares the VM for the QEMU guest agent, which lets the host shut the guest down cleanly and read its IP address.

Select VM 100 in the tree and open Console. Go through the Debian installer as usual; it gets its address from your router’s DHCP through vmbr0. After the first boot, log in to the VM and install the guest agent:

apt install qemu-guest-agent
systemctl start qemu-guest-agent

Check: on the host, qm list shows VM 100 as running, and the VM’s Summary page shows its IP addresses once the agent runs. In Hardware, set the CD/DVD drive to Do not use any media so the VM no longer boots the installer.

qm list
qm agent 100 ping && echo agent ok

Step 6: Create an LXC container

Why: a container shares the host’s kernel, so it starts in seconds and uses much less memory than a VM. It can only run Linux. Unprivileged containers map the container’s root user to an unprivileged user on the host, which is the safer default.

First refresh the template list and download a current Debian system template to the local storage:

pveam update
pveam available --section system | grep debian
# copy one name from the output, for example:
TEMPLATE=debian-13-standard_13.6-1_amd64.tar.zst
pveam download local "$TEMPLATE"
pveam list local

The exact template file name changes with each release; use a name from your own pveam available output. Then create container 200. Copy your SSH public key to the host first (for example scp ~/.ssh/id_ed25519.pub [email protected]:/root/admin.pub from your computer) so you can log in to the container with it.

pct create 200 local:vztmpl/"$TEMPLATE" \
  --hostname ct200 \
  --memory 512 \
  --cores 1 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=dhcp \
  --unprivileged 1 \
  --ssh-public-keys /root/admin.pub

pct start 200
pct enter 200

pct enter gives you a root shell inside the container without any password. If you also want a root password for console logins, run passwd there. Check the address and connectivity, then leave with exit:

ip -br addr show eth0
ping -c 3 192.0.2.1
exit

Check: pct list shows container 200 as running. To start both guests automatically when the host boots, set onboot:

pct list
qm set 100 --onboot 1
pct set 200 --onboot 1

Step 7: Run a manual backup

Why: before you automate anything, run one backup by hand and look at the file it produces. vzdump is the backup tool behind both the GUI and scheduled jobs. Snapshot mode, the default, backs up a running guest with minimal downtime; zstd compression is the fastest of the available options according to the docs.

vzdump 100 200 --storage local --mode snapshot --compress zstd
pvesm list local --content backup
ls -lh /var/lib/vz/dump/

Check: the task ends with a line saying the backup job finished successfully, and the storage now lists files named like vzdump-qemu-100-<date>_<time>.vma.zst and vzdump-lxc-200-<date>_<time>.tar.zst.

Keep in mind that local sits on the same disk as the guests. It is fine for learning, but a real backup must live on another device: an NFS share, a USB disk added as storage, or a Proxmox Backup Server.

Step 8: Schedule a backup job

Why: backups only help if they run without you. Scheduled jobs are stored in /etc/pve/jobs.cfg and run by the pvescheduler daemon.

1. Go to Datacenter > Backup and click Add.
2. Node: pve1. Storage: local (or your external storage).
3. Schedule: type 21:00 for every day at 9 PM, or pick an example from the drop-down. The format is similar to systemd calendar events, for example mon..fri 21:00.
4. Selection mode: All, or tick VM 100 and CT 200.
5. Compression: ZSTD. Mode: Snapshot.
6. On the Retention tab set for example Keep Last 3 and Keep Daily 7 so old backups are pruned automatically.
7. Click Create.

cat /etc/pve/jobs.cfg

Check: the file contains a vzdump: entry with your schedule. Select the job and click Run now to test it immediately; the task log at the bottom of the screen shows the result.

Step 9: Test a restore

Why: a backup you have never restored is only a hope. Restore each guest under a new ID so the originals stay untouched. --unique 1 gives the copy a new random MAC address, so it does not clash with the running original on your network.

ls /var/lib/vz/dump/

qmrestore /var/lib/vz/dump/vzdump-qemu-100-<date>_<time>.vma.zst 900 --storage local-lvm --unique 1
pct restore 901 /var/lib/vz/dump/vzdump-lxc-200-<date>_<time>.tar.zst --storage local-lvm --unique 1

Replace <date>_<time> with the real file names from ls. In the GUI the same thing is local > Backups > select a file > Restore, where you can type a new VM ID.

The restored container has the same hostname and, with DHCP, gets a new address. The restored VM is a full copy, so before starting it, either stop the original or detach the copy’s network so two machines with the same hostname are not on the LAN at once:

qm set 900 --net0 virtio,bridge=vmbr0,link_down=1
qm start 900
pct start 901
pct exec 901 -- ls /root

Check: VM 900 boots to a login prompt in its console, and container 901 starts and shows the same files as container 200.

Check that it works

• apt update on the host completes without repository errors.
• qm list and pct list show VM 100 and CT 200 running, plus the restored copies 900 and 901.
• From another computer you can SSH into the container, for example ssh root@<address of ct200>.
• pvesm list local --content backup shows backups from the scheduled job after it has run once.
• After reboot of the host, VM 100 and CT 200 come back up by themselves.

If something goes wrong

• apt update shows errors for enterprise.proxmox.com: the enterprise repository is still enabled. Check every file in /etc/apt/sources.list.d/, including ceph.sources, and add Enabled: no (or comment out the line in older .list files).
• A VM will not start and mentions KVM virtualization: hardware virtualization is off in the firmware. Reboot into the BIOS/UEFI setup and enable Intel VT or AMD-V/SVM.
• Guests get no IP address: make sure their network card uses bridge=vmbr0, that vmbr0 lists the correct physical port in bridge-ports, and that your router hands out DHCP leases. In a container, ip=dhcp must be set on net0.
• The web UI is unreachable after a network change: log in at the physical console, fix /etc/network/interfaces, and run ifreload -a.
• A backup job fails with a storage error: the target storage must allow backup content (Datacenter > Storage > Edit > Content) and have enough free space; check with pvesm status.

Clean up

Warning: the commands below permanently delete guests and their disks. First run qm list and pct list and make sure the IDs are the test copies, not guests you want to keep.

qm list
pct list

qm stop 900
qm destroy 900 --purge
pct stop 901
pct destroy 901 --purge

--purge also removes the guest from backup jobs and other job configurations. To remove the test backup files, use local > Backups > Remove in the GUI, which shows exactly which file you are deleting. To stop scheduled backups, remove the job under Datacenter > Backup. To return the whole machine to another use, simply reinstall a different operating system over it.

Next steps

• Add a separate backup target: an NFS share, a second disk, or a Proxmox Backup Server for deduplicated, incremental backups.
• Turn VM 100 into a template and create new VMs as linked clones, or use cloud-init images to skip the installer entirely.
• Enable the Proxmox VE firewall at datacenter, host and guest level.
• Replace the self-signed certificate with one from Let’s Encrypt (pve1 > System > Certificates).
• Add a second node and learn clustering, storage replication and live migration.

Official documentation

• Proxmox VE Administration Guide
• Proxmox VE wiki: Package Repositories
• Proxmox VE wiki: Backup and Restore