Learn Proxmox VE - Creating & Managing Virtual Machines (KVM)

#Introduction

This is the moment you've been waiting for: creating your first Virtual Machine. Proxmox uses KVM as its primary virtualization engine, and episode 3 will guide you from the basic concepts to a running VM with the right configuration. The decisions you make on the wizard page — CPU type, RAM, disk, and network — determine your VM's performance for the long term.

We'll cover how KVM works, uploading an ISO to storage, filling in the VM creation wizard with the right choices, and then running the full lifecycle operations: start, stop, shutdown, reset, pause, suspend, all the way to migrate. After this episode, you'll be able to create VMs with confidence.

#The KVM Concept (Kernel-based Virtual Machine)

#A Type-1 Hypervisor Inside the Kernel

KVM is a virtualization module integrated directly into the Linux kernel. With Intel VT-x or AMD-V hardware virtualization support, KVM turns Linux into a type-1 hypervisor — running directly on the hardware, without an additional operating system layer. QEMU provides device emulation, while KVM handles instruction execution natively.

Because KVM lives in the same kernel as the Proxmox system, the virtualization overhead is very low — VMs run with near bare-metal performance.

#Uploading an ISO to Local Storage

Before creating a VM, you need an operating system image. Download the Ubuntu or Debian ISO from the official site, then upload it to Proxmox via local -> ISO Images -> Upload. Alternatively, upload it through the CLI with scp:

scp ubuntu-24.04.iso root@<IP-PROXMOX>:/var/lib/vz/template/iso/

Files in the /var/lib/vz/template/iso/ folder automatically appear in the web UI as ISOs available for use.

#Creating a New VM via the Web UI

#CPU Configuration

Click Create VM, fill in the VM ID and name. In the OS section, select the ISO you uploaded and the guest type. The next important section is CPU:

Sockets : 1
Cores   : 2
Type    : host (recommended) or x86-64-v2-AES

CPU Type host passes all the physical CPU's features through to the VM — best performance, ideal for heavy workloads and instruction-sensitive applications. kvm64 and x86-64-v2-AES are more portable across nodes with different CPUs, useful if you want to migrate VMs between non-identical hardware.

#RAM and Ballooning

Set the RAM according to the guest's needs. Enable ballooning so the RAM the VM isn't using can be returned to the host and used by other VMs when needed. On the host, you can see this dynamic allocation with qm set 100 -balloon 2048.

#Machine Type: q35 vs i440fx

Proxmox offers two chipsets: the modern q35, which supports UEFI, PCIe, and other modern devices, and i440fx, which is compatible with older operating systems. For all new VMs, choose q35 — unless you have a clear compatibility reason.

#Virtual Disk Configuration

#VirtIO SCSI for Best Performance

For the disk, choose VirtIO SCSI as the bus — this paravirtualized driver gives the best performance compared to SATA or IDE emulation. Set the disk size to your needs and choose the storage where the disk will live.

ls -lh /var/lib/vz/images/100/

The vm-100-disk-0.qcow2 or .raw file is the virtual disk representation in storage.

#Cache Mode, Discard and SSD Emulation

Other important settings: Cache mode none with discard enabled is recommended for modern disks and supports TRIM. Enable SSD emulation if the host storage is SSD-based so the guest performs the right optimizations. This combination yields more efficient I/O without hiding power failures.

#Network Configuration and VM Lifecycle

#VirtIO NIC and Bridge

For networking, use a VirtIO NIC — again, because it gives the best performance. Choose the available bridge, usually vmbr0, which connects VMs to the physical network. If you already have several bridges, pick the one matching the network segment you want.

Bridge  : vmbr0
VLAN Tag: (leave empty for untagged access)
Model   : VirtIO

#VM Lifecycle Operations

Once the VM is created and the operating system is installed, you control it from the lifecycle buttons:

• Start: powers on the VM.
• Shutdown: sends an ACPI signal to the guest so the OS shuts down cleanly.
• Stop: force-powers off — equivalent to pulling the power plug.
• Reset: force-reboots the guest.
• Pause: suspends the VM without releasing resources.
• Suspend to Disk: saves the VM's entire state to disk and powers it off.
• Migrate: moves the VM to another node (covered in episode 12).

qm start 100
qm shutdown 100
qm stop 100
qm list

qm list shows the list of all VMs on the node along with their status. A good habit: always use shutdown first, and only use stop if there's no response.

#Closing

Episode 3 put you in the driver's seat: understanding KVM as a type-1 hypervisor, uploading ISOs, configuring VMs with the right CPU type, RAM ballooning, the q35 chipset, VirtIO SCSI disks, and VirtIO NICs, as well as mastering the full VM lifecycle operations.

The key takeaways:

• KVM runs inside the Linux kernel: high-performance virtualization.
• Upload ISOs to /var/lib/vz/template/iso/ before creating a VM.
• Use the host CPU type for performance, kvm64 for portability.
• Choose the q35 chipset and VirtIO SCSI disk bus for modern VMs.
• Cache mode none with discard is safer than writeback.
• Lifecycle: start, shutdown, stop, reset, pause, suspend, migrate.

In the next episode, episode 4, we will cover Cloud-Init, VM Templates, and Rapid Provisioning — why manual OS installation is inefficient at scale, how to auto-configure VMs at first boot, creating templates with qemu-guest-agent and cloud-init, and the difference between full clones and linked clones for spinning up VMs in seconds. Prepare an Ubuntu VM as your experiment subject!