Skip to main content

Creating a Virtual Machine in Proxmox VE: Complete Guide

Proxmox VE · 19.04.2026 · 6 min read
Illustration for “Creating a Virtual Machine in Proxmox VE: Complete Guide”

Creating a virtual machine (VM) in Proxmox VE is a fast process using the built-in wizard. In this guide we'll create a VM with Ubuntu Server 24.04, but the same steps apply to any OS.

Step 1: Upload the ISO to Storage

Before creating a VM, you need to upload an ISO image. In the web interface:

  1. Select local (pve) → ISO Images
  2. Click Upload or Download from URL

Or from the command line:

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

Step 2: Create the VM via the Web Interface

Click Create VM in the top-right corner. Go through the wizard tabs:

TabParameterRecommended Value
GeneralVM ID / Name100 / ubuntu-server
OSISO Imageubuntu-24.04-live-server.iso
OSGuest OS TypeLinux / 6.x-2.6 Kernel
SystemMachine / BIOSq35 / OVMF (UEFI)
SystemAdd EFI DiskEnable
DisksBus / StorageVirtIO SCSI / local-lvm
DisksDisk size32 GB+
CPUSockets / Cores1 / 2
CPUTypehost (for maximum performance)
MemoryRAM2048 MB+
NetworkBridge / Modelvmbr0 / VirtIO

Step 3: Create the VM via CLI (qm)

For automation, use the qm utility:

# Create VM with ID 100
qm create 100   --name ubuntu-server   --memory 2048   --cores 2   --net0 virtio,bridge=vmbr0   --cdrom local:iso/ubuntu-24.04-live-server-amd64.iso   --scsihw virtio-scsi-pci   --scsi0 local-lvm:32   --boot order=scsi0;ide2   --ostype l26

# Start the VM
qm start 100

# View status
qm status 100
VirtIO drivers: For Windows guests, install the virtio-win ISO as a second CD-ROM. This significantly improves disk and network performance.

Step 4: Configure the QEMU Guest Agent

The Guest Agent lets Proxmox properly shut down the VM and obtain the guest's IP address:

# Inside the Linux VM
apt install qemu-guest-agent -y
systemctl enable --now qemu-guest-agent

# In Proxmox: enable in the VM settings
qm set 100 --agent 1

Useful VM Management Commands

# List all VMs
qm list

# Stop a VM
qm stop 100

# Suspend
qm suspend 100

# Create a snapshot
qm snapshot 100 clean-install --description "Before updates"

# Roll back to a snapshot
qm rollback 100 clean-install

# Delete a VM with all its disks
qm destroy 100 --purge
CPU type: Using host gives maximum performance but ties the VM to a specific hardware generation. If you need live migration between different hosts, use x86-64-v2-AES.

Errors when creating and first-booting a VM

Three errors you are most likely to hit during creation and the first boot — all of them show up immediately in the command output or the VM console, with no need to dig through logs.

TASK ERROR: unable to create VM 100 - VM 100 already exists
kvm: -device virtio-net-pci,...: Bus 'pci.0' not found
No bootable device -- press key to retry boot
  • VM 100 already exists: the ID is already taken by another VM or LXC container — numbering is shared between qm and pct. Check qm list and pct list, and get a free ID with pvesh get /cluster/nextid.
  • Bus 'pci.0' not found: the VM configuration expects Machine Type q35, but i440fx is actually set (or vice versa) after manual editing. Fix the mismatch: qm set 100 --machine q35.
  • No bootable device: the ISO is detached from the drive, or the boot order does not include the disk with the image. Check qm config 100 | grep boot and make sure ide2 with the ISO is listed first during installation.

The first two errors most often follow copying a configuration between nodes or manually editing the VM file in /etc/pve/qemu-server/ — after edits like that, double-check the configuration with qm config before starting the VM.

When the standard VM creation wizard is not the right fit

The wizard is convenient for one or two machines, but not for every scenario.

  • Mass-deploying dozens of identical VMs — it is faster to clone a ready template with qm clone than to walk through the wizard for each machine separately.
  • Importing a ready disk from another platform (VMware, Hyper-V) — use qm importdisk instead of building from scratch with an installer ISO.
  • Automation through Infrastructure as Code — a Terraform provider or direct API calls (pvesh) fit better here than the manual wizard in the web interface.

Verifying the result

# VM status and IP address (requires the guest agent)
qm agent 100 network-get-interfaces

# Confirm the disk was created at the requested size
qm config 100 | grep scsi0

# Logs from the VM's latest startup
journalctl -u qmeventd -n 20

If the agent returns a current IP address and the disk size in the configuration matches what was requested at creation, the VM is set up correctly. For mass deployment via templates, see templates and Cloud-Init in Proxmox.

Frequently asked questions

Is installing the QEMU Guest Agent required for a virtual machine to boot and run normally?

Not required for the VM to boot or run — it is an optional component. Without it, Proxmox cannot shut the guest down gracefully from the host side and will not show the guest's IP address in the summary panel. Everyday use of the machine works fine without it; the agent only improves management and monitoring, not the guest OS.

Why does the guest's IP address still not show in the Proxmox summary panel after installing the agent package inside the VM?

Likely because the agent still needs to be switched on in the VM's own hardware settings, not only installed inside the guest. Installing the package alone is not enough — a matching option in the virtual machine configuration has to be enabled too, otherwise Proxmox never establishes the communication channel the agent relies on and the summary panel stays empty.

Can a VM's disk be resized after the virtual machine has already been created?

Yes, a disk attached to an existing virtual machine can be grown afterward from the hardware tab without reinstalling the guest — growing it does not erase existing data. The guest operating system still has to recognize and extend its own partition and filesystem afterward, since Proxmox only enlarges the underlying virtual disk, not what is inside it.

If a VM needs to migrate between different physical hosts later, does the CPU type chosen at creation matter?

Yes, picking the host CPU type ties the virtual machine to the exact feature set of that physical processor, which can prevent live migration to a host with a different generation of hardware. Choosing a more generic, compatible CPU type at creation time keeps migration options open later, at some cost to peak performance compared with the host type.

Was this article helpful?
← Back to Knowledge Base Ask Support