Proxmox for Beginners: Your First VM in 30 Minutes

Proxmox VE has earned its reputation as a down-to-earth open source alternative to VMware ESXi and Microsoft Hyper-V — and it is a fair entry point into professional virtualization, especially for small IT teams. Anyone planning the switch or setting up their own hypervisor for the first time quickly gets overwhelmed by menu trees, KVM options and ZFS jargon. This guide walks you from the ISO to a running VM with no prior knowledge — realistically in about 30 minutes of actual working time.

What You Need for a Proxmox Start

Before you begin, gather your gear. This is deliberately not about enterprise hardware but about a clean test or pilot setup.

• A machine with at least 8 GB of RAM, ideally 16 GB. For a first test even an office PC or a small tower server will do.
• Two drives are nice but not required. One SSD as the system disk and a second one for VM data make life easier.
• A USB stick with at least 4 GB for the installer.
• A wired network connection — Wi-Fi at the hypervisor is a bad idea.
• Half an hour without interruptions.

If you plan to run Proxmox in production later, take a look at our article on planning Proxmox architecture or head straight to our Proxmox service. For this getting-started run, any reasonably modern x86 machine with virtualization extensions (VT-x on Intel, AMD-V on AMD) is enough.

Step 1: Download the ISO and Prepare the USB Stick

You will find the current Proxmox VE ISO on the official project site. Make sure you actually download Proxmox VE and not Proxmox Backup Server or Proxmox Mail Gateway — those are separate products.

To write the USB stick, use Rufus on Windows, dd or Etcher on Linux. Important: not a regular copy but a real image write. A classic beginner mistake is dragging the ISO onto the stick like a file — that never boots.

Once the stick is ready, plug it into the target machine, enable virtualization extensions in the BIOS and set the boot order to USB first.

Step 2: Install Proxmox VE — the Important Choices

The Proxmox installer is refreshingly straightforward. You click through in a few minutes but there are three points where you should stop and think.

Target drive and filesystem: For the first setup, ext4 on a single SSD is fine. If you have two or more drives, choose ZFS RAID1 (mirror). ZFS brings snapshots, checksums and easy replication with it — it is the standard in the Datazone daily routine. Read up later with our overview of ZFS RAID levels.

Locale: Time zone Europe/Berlin, keyboard de if that is your layout. Otherwise stay with the defaults.

Networking: Assign a static IP in the same subnet as your workstation. A sensible hostname is something descriptive like pve01.lan — note the domain suffix is mandatory, otherwise the installer complains. Write down IP, gateway and root password. Whoever loses the password later stares at a friendly login prompt for a long time.

After installation the server reboots. On the console a URL like https://<your-ip>:8006 appears. Open that in your workstation browser. The certificate warning on first launch is normal — Proxmox uses a self-signed cert that you can later replace with Let’s Encrypt.

Step 3: First Login and Basic Configuration

Log in with user root, realm Linux PAM and your root password. You land in the datacenter overview — resource tree on the left, tabs in the middle, actions in the top right.

Two quick tasks pay off right away:

Switch repositories: By default Proxmox points to the Enterprise repository, which returns 401 without a subscription. For test and pilot use, switch to the free No-Subscription repository under Node > Updates > Repositories. Then run apt update && apt dist-upgrade -y in the shell — the server is now current.

Subscription popup: The friendly reminder that no valid subscription is registered can be hidden with a small script tweak. For production systems, however, we recommend at least the Community or Basic subscription — the more stable Enterprise repository can be worth its weight in gold in an emergency.

Step 4: Set Up the Network Bridge — Understanding vmbr0

Without a bridge there are no useful VMs. After installation a bridge called vmbr0 already exists with the physical NIC attached. Every VM you later place on vmbr0 appears in the same network as the Proxmox host — so they get IPs from your office or server room network.

Worth understanding:

• A bridge is a virtual switch. VMs virtually plug a cable into it.
• The host itself also uses the bridge for its own IP.
• If you use VLANs, enable VLAN aware in the bridge editor.
• For isolated test networks, create additional bridges without a physical interface — for example vmbr1 for an internal lab.

Details on VLANs are in our post on network segmentation with VLAN and OPNsense. For getting started, vmbr0 with DHCP or a static IP is enough.

Step 5: Create the First VM — Debian 12 as an Example

Now for the part you have been waiting for. First upload an ISO image — click local (pve01) in the left tree, then ISO Images > Upload. Debian 12 Netinstall is under 500 MB and uploads in a minute.

In the top right click Create VM. The wizard walks you through seven tabs:

1. General: Name debian-01, VM ID 100 — Proxmox will not let you reuse an ID.
2. OS: pick the ISO, type Linux, version 6.x - 2.6 Kernel.
3. System: BIOS OVMF (UEFI), Machine q35, enable EFI disk. For older systems, SeaBIOS with i440fx is fine.
4. Disks: storage local-lvm or local-zfs, size 20 GB, enable Discard for SSDs.
5. CPU: 2 cores, type host — this avoids compatibility headaches during live migration.
6. Memory: 2048 MB to start. Ballooning enabled.
7. Network: bridge vmbr0, model VirtIO (paravirtualized).

After Finish the VM appears in the tree. Click Start, then Console, and you see the Debian installer. Twenty minutes later you have a working Linux — the only way to spend longer is to get lost in the partitioner.

Step 6: Use Cloud-Init — Deploy VMs in Under a Minute

Anyone who regularly creates new VMs will grow tired of manual installation after the third round. Proxmox supports Cloud-Init natively. You create a template VM, clone it and pass hostname, user, SSH key and IP at clone time — the new VM is fully configured on first boot.

The workflow in short:

• Download a cloud image of your distribution (Debian, Ubuntu, Rocky Linux all offer ready-made .qcow2 images).
• Import it as a VM and add a Cloud-Init drive.
• Convert the VM into a template.
• Clone as needed and parametrize via the web UI or CLI.

The full step-by-step is in a dedicated article: Proxmox Cloud-Init: provision VMs automatically. For now it is enough to know that you can retrofit this automation at any time — it is not an enterprise feature.

Step 7: Plan the First Backup — Not Optional

A VM without a backup is a VM on borrowed time. Proxmox ships with a backup scheduler in the web UI that writes to local storages or to a Proxmox Backup Server. For a beginner setup, a backup job to an external drive or a NAS share is enough.

Create a job under Datacenter > Backup > Add:

• Storage: your backup target — ideally not the same SSD as the VM data.
• Schedule: daily at 22:00 as a starting point.
• Mode: Snapshot for running VMs.
• Compression: ZSTD — faster and more efficient than GZIP.
• Retention: keep at least 7 daily, 4 weekly and 3 monthly backups.

If you take it seriously, combine this with the 3-2-1 backup rule and a clean offsite copy. For TrueNAS storage as a ZFS backup target, you will find suitable systems for SMB use in the TrueNAS configurator.

What You Have After 30 Minutes — and What Comes Next

At the end of this half hour, a Proxmox host is running that you operate through the browser. On that host you have a first Debian VM. A backup job takes regular snapshots offsite. That is a solid entry.

To stay honest: production use adds topics that would blow up a beginner guide. Clusters with at least three nodes for real high availability, shared storage via ZFS replication or Ceph, proper monitoring, an update strategy and patch management. For the full overview, our article on Proxmox high availability and clustering is the logical next step.

For production environments at small and medium-sized companies, Datazone accompanies you from planning to daily operation — from a single host to a three-node cluster with TrueNAS storage. Details on our Proxmox service and a no-strings quote are only a phone call away.

FAQ on Proxmox for Beginners

Do I need a paid subscription for Proxmox?

No. Proxmox VE is fully open source and can be run for free indefinitely with the No-Subscription repository. For production, we still recommend at least a Community subscription because the Enterprise repository is more thoroughly tested and grants you support access.

Can I try Proxmox on an old office PC?

For first tests, yes. What matters is that the CPU supports virtualization extensions (VT-x or AMD-V), that they are enabled in BIOS and that the machine has 8 GB of RAM or more. For production, however, server hardware, ECC RAM and redundant power supplies are much preferred.

What is the difference between a VM and an LXC container in Proxmox?

A VM is a fully virtualized machine with its own kernel. An LXC container shares the host kernel, starts in seconds and needs significantly fewer resources. For a deeper comparison see our article on Docker, LXC and VMs as well as the post on LXC container virtualization.

How do I migrate my VMs from VMware or Hyper-V to Proxmox?

Since version 8, Proxmox includes an integrated import assistant for VMware VMs. For Hyper-V you export the virtual disks and convert them to qcow2 with qemu-img. The details and pitfalls are covered in our article From VMware to Proxmox — planned migration.

Is a single Proxmox host enough or do I need a cluster?

For test, development and small branch environments a single host with clean backups is entirely fine. As soon as you need high availability — automatic failover on hardware loss — three nodes are the minimum. Two-node setups are possible but awkward and unpleasant in split-brain scenarios.

How do I secure Proxmox itself against attacks?

Standard hardening consists of a few steps: allow SSH only with keys, put the web interface behind an OPNsense firewall, keep regular updates, enable multi-factor authentication for the web login and separate management from VM networks. A practical template: our post on Linux server hardening and the overview on SSH hardening.