Creating a VM in Proxmox
Prerequisites
- A running Proxmox node or cluster — see Getting Started with Proxmox
- An ISO uploaded to Proxmox storage (Datacenter → Storage → ISO Images → Upload)
Creating the VM
In the Proxmox web UI, click Create VM in the top right corner.
General
| Field | Value |
|---|---|
| Name | A descriptive hostname (e.g. k8s-ctrl-03, nas) |
| VM ID | Leave as auto-assigned or pick a number in your scheme |
| Start at boot | Enable for production VMs |
OS
Select the uploaded ISO. Set the guest OS type to Linux for Debian-based VMs.
System
| Field | Value |
|---|---|
| Machine | q35 |
| BIOS | OVMF (UEFI) |
| EFI Storage | Select a storage pool — a small EFI disk will be created automatically |
| Qemu Agent | Enable |
q35 is the modern machine type with full PCIe support. OVMF (UEFI) is preferred over SeaBIOS for modern operating systems. The QEMU guest agent enables graceful shutdown, IP address reporting, and file system freeze during snapshots.
Disks
| Field | Value |
|---|---|
| Bus/Device | VirtIO Block |
| Storage | Select your storage pool |
| Size | Appropriate for the role (see the sizing table below) |
| Discard | Enable if the storage pool is on SSD or ZFS |
VirtIO is the paravirtualised driver — it has significantly lower overhead than emulated SATA or IDE.
CPU
| Field | Value |
|---|---|
| Cores | At least 2 for any workload running kubeadm or systemd services |
| Type | See below |
Memory
Enable Ballooning only if you want Proxmox to dynamically reclaim unused memory. For workloads with predictable memory needs (databases, Kubernetes nodes), set a fixed value and leave ballooning off.
Network
| Field | Value |
|---|---|
| Bridge | The bridge connected to your lab network |
| Model | VirtIO (paravirt) |
CPU Type — the Migration Trade-Off
CPU type is the most consequential setting for clusters where VMs may need to live-migrate between nodes.
| Type | Performance | Migration compatibility |
|---|---|---|
host | Best — exposes all host CPU flags | None — breaks migration to any different CPU model |
x86-64-v2-AES | Good — baseline with AES-NI | Migrates between any node that supports the baseline |
kvm64 | Basic | Widest compatibility, older instruction set |
host causes problems on mixed-CPU clusters. This homelab runs AMD Ryzen (5600G) and Intel N100 nodes — these CPUs have different instruction sets and different flags. A VM created with host on the 5600G exposes AMD-specific instructions; trying to live-migrate it to an N100 node will fail immediately because the target CPU cannot provide those instructions.
For any VM that may need to migrate — Kubernetes nodes, general-purpose VMs — use x86-64-v2-AES. It gives you AES-NI and a modern baseline without tying the VM to a specific CPU family.
VMs with PCI passthrough (such as the NAS with a passed-through SATA controller) cannot migrate regardless of CPU type. For those,
hostis acceptable since migration is already off the table.
VM Sizing Reference
| Role | CPUs | RAM | Disk |
|---|---|---|---|
| Kubernetes control plane | 2 | 2 GB | 20 GB |
| Kubernetes worker | 2 | 4 GB | 40 GB |
| General service / LXC equivalent | 1–2 | 512 MB–1 GB | 8–16 GB |
| VyOS router | 1–2 | 512 MB–1 GB | 4–8 GB |
After Creation
Start the VM and complete the OS installation from the ISO. Once the OS is running, install the QEMU guest agent inside the VM so Proxmox can interact with it properly:
| |
After this, Proxmox will display the VM’s IP address on the Summary tab and handle graceful shutdowns via the UI.
What’s Next
Where you go from here depends on the VM’s role:
- VyOS router — Setting Up VyOS as a Proxmox VM
- Kubernetes node — Setting Up a Kubernetes Cluster
- NAS — OpenMediaVault in a Proxmox VM with SATA Passthrough