Posted inVirtualization

Creating and Managing Virtual Machines with Proxmox VE: From Installation to Real-World Monitoring

Virtualization tutorial - IT technology blog
Virtualization tutorial - IT technology blog

Why Choose Proxmox Over Managing KVM Manually?

If you’ve ever set up KVM using virsh or libvirt, you know what it’s like to sit there typing commands to create VMs, configure networking, and attach disks — having to memorize every bit of syntax. Proxmox VE solves that by wrapping KVM (and LXC containers) in a fully-featured web interface, complete with built-in cluster management, snapshots, and backups.

I run a homelab with Proxmox VE managing 12 VMs and containers — a playground for testing everything before pushing to production. I moved away from bare KVM for a simple reason: once you go past 5-6 VMs, managing them via command line starts eating up real time. With Proxmox, spinning up a new VM takes about 2 minutes through the web UI, while SSH access to the node for running commands is always available when you need it.

What I find most convenient compared to manual KVM management: all VM configs are stored as plain text files at /etc/pve/qemu-server/<vmid>.conf, making them easy to back up and version control. Every change made through the web UI is logged — when debugging later, a quick log filter tells you exactly who changed what and when.

Installing Proxmox VE

Practical Hardware Requirements

Proxmox VE requires a CPU with virtualization support (Intel VT-x or AMD-V). Check before installing:

egrep -c '(vmx|svm)' /proc/cpuinfo
# Result > 0 means the CPU supports virtualization — if you get 0, enable Intel Virtualization Technology in BIOS

Minimum configuration to get it running:

  • CPU: 4 cores (8 cores if running many VMs simultaneously)
  • RAM: 8GB (I recommend 32GB+ for a serious homelab)
  • Storage: 128GB+ SSD — HDDs will create serious bottlenecks when multiple VMs write to disk simultaneously
  • NIC: 1 Gigabit port (2 ports if you want to separate management network from VM traffic)

Installation Process

Download the ISO from the Proxmox website and create a bootable USB:

dd if=proxmox-ve_8.x.iso of=/dev/sdX bs=1M status=progress
# Replace /dev/sdX with your USB device (use lsblk to check)

The installer is pretty straightforward — a wizard walks you through disk selection, timezone, and root password. The network section requires a bit more care:

  • Management IP: Static IP for the Proxmox web UI (e.g., 192.168.1.10/24)
  • Gateway: Your router (192.168.1.1)
  • Hostname: FQDN, e.g., pve.homelab.local

Once installed, access the web UI at https://192.168.1.10:8006 (HTTPS, port 8006). Log in with root and the password you just set. The browser will warn about the SSL certificate — this is Proxmox’s self-signed cert, just click “Advanced → Proceed” to continue.

Detailed Configuration — Creating and Managing VMs

Uploading an ISO to Proxmox

Before creating a VM, you need an OS ISO. The fastest way is to download it directly to the node via SSH:

wget -P /var/lib/vz/template/iso/ \
  https://releases.ubuntu.com/22.04/ubuntu-22.04.3-live-server-amd64.iso

# Verify checksum
sha256sum /var/lib/vz/template/iso/ubuntu-22.04.3-live-server-amd64.iso

Or upload from your local machine through the web UI: Datacenter → pve → local (pve) → ISO Images → Upload.

Creating a VM via the Web UI

Click Create VM in the top-right corner. The wizard goes through 7 tabs — I’ll highlight the points that are often overlooked:

  1. General: VM ID auto-increments; use a clear naming pattern like ubuntu-prod-01, debian-test-02.
  2. OS: Select the ISO you just uploaded, along with the OS type and version (this affects which drivers are loaded by default).
  3. System: Keep the defaults for Linux. For Windows, enable OVMF (UEFI) and add a TPM 2.0 for Windows 11.
  4. Disks: Select VirtIO Block as the bus type for the best I/O performance. Enable Discard if your storage is an SSD (supports TRIM).
  5. CPU: Set the number of cores. Don’t assign too many — overcommitting is allowed, but when all VMs are under load simultaneously, CPU contention kicks in immediately.
  6. Memory: Enable the Ballooning Device so VMs return RAM to the host when idle — significant savings when running many VMs.
  7. Network: Bridge vmbr0 is the default. The VirtIO model gives the highest throughput; use E1000 if an older OS lacks VirtIO drivers.

Creating a VM via CLI (qm command)

When you need to create multiple VMs at once or write automation scripts, use qm:

# Create VM with ID 200
qm create 200 --name ubuntu-test \
  --memory 2048 \
  --cores 2 \
  --net0 virtio,bridge=vmbr0 \
  --scsihw virtio-scsi-pci \
  --scsi0 local-lvm:32 \
  --ide2 local:iso/ubuntu-22.04.3-live-server-amd64.iso,media=cdrom \
  --boot c --bootdisk scsi0 \
  --ostype l26

# Start VM
qm start 200

# Check status
qm status 200

# Graceful shutdown (sends ACPI signal)
qm shutdown 200

# Immediate stop (equivalent to pulling the power plug)
qm stop 200

VM Snapshots and Cloning

These are the features I use most — snapshot before testing something risky, clone to create new VMs from a template:

# Create a snapshot
qm snapshot 200 snap-before-upgrade --description "Before Ubuntu dist-upgrade"

# List all snapshots for the VM
qm listsnapshot 200

# Roll back to a snapshot (VM must be stopped, or use a live snapshot)
qm rollback 200 snap-before-upgrade

# Delete a snapshot you no longer need
qm delsnapshot 200 snap-before-upgrade

My go-to golden image workflow for the homelab: prepare a VM with the OS pre-installed, SSH keys, and commonly used packages. Convert it to a template. Then clone it whenever you need a new VM — much faster than installing from scratch:

# Convert VM to template (cannot be started after conversion)
qm template 200

# Full clone from template (independent VM, uses its own disk space)
qm clone 200 301 --name web-server-01 --full

# Linked clone (saves disk space, but depends on the template)
qm clone 200 302 --name web-server-02

# Start the newly cloned VM
qm start 301

Monitoring and Verification

Monitoring Resources via the Web UI

You don’t need to set up Grafana right away — Proxmox’s built-in monitoring is sufficient for a homelab. Open the summary of any node or VM and you’ll see real-time graphs immediately: CPU, memory, disk I/O, and network traffic.

Metrics history is retained across multiple timeframes: hour, day, week, month, and year. When a VM suddenly slows down, checking the 24-hour CPU/disk I/O graphs usually pinpoints the cause within minutes — no need to dig through logs manually.

Monitoring via CLI

# List all VMs and their status
qm list

# View detailed VM configuration
qm config 200

# Real-time VM status (CPU, memory, uptime)
pvesh get /nodes/pve/qemu/200/status/current

# List all VMs as JSON, filter by name
pvesh get /nodes/pve/qemu --output-format json | jq '.[].name'

# Check disk usage of storage
pvesh get /nodes/pve/storage --output-format table

# View all tasks (including failed ones)
pvesh get /nodes/pve/tasks --output-format table | head -20

Alert Script for VM Downtime

Proxmox 8.x already has built-in Notifications (go to Datacenter → Notifications). If you want simple Telegram alerts, this script does the job:

#!/bin/bash
# /root/check-vms.sh — runs every 5 minutes via cron
TELEGRAM_BOT_TOKEN="your_bot_token"
CHAT_ID="your_chat_id"

for vmid in $(qm list | awk 'NR>1 {print $1}'); do
  status=$(qm status $vmid | awk '{print $2}')
  name=$(qm config $vmid | grep '^name:' | awk '{print $2}')
  
  if [ "$status" != "running" ]; then
    curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
      -d "chat_id=${CHAT_ID}&text=⚠️ VM ${name} (ID: ${vmid}) status: ${status}"
  fi
done
# Add to crontab
*/5 * * * * /root/check-vms.sh

Backing Up VMs with vzdump

Scheduled backups through the web UI at Datacenter → Backup is the easiest approach. Use the CLI when you need an ad-hoc backup:

# Back up VM 200 with zstd compression (fast, good compression ratio)
vzdump 200 --storage local --compress zstd --mode snapshot

# Back up all VMs
vzdump --all --storage local --compress zstd --mode snapshot

# Restore from a backup file
qmrestore /var/lib/vz/dump/vzdump-qemu-200-2024_01_15-10_30_00.vma.zst 300
# 300 is the new VM ID after restore

Pro tip: using snapshot mode means you don’t need to shut down the VM during the backup. Proxmox creates a KVM snapshot, backs up from it, then cleans up automatically — the VM keeps running throughout without any interruption.

Share:
Tags: