Virtualization7 min read

VM Lifecycle & Networking

Creating, migrating, and connecting VMs in Proxmox

VM Lifecycle

Create

Three Ways to Create a VM

From ISO

Upload ISO to storage, create VM, attach ISO as CD-ROM, boot and install manually. Slowest method but maximum control.

From Template

Install a VM once, configure it, convert to template (qm template <vmid>). Clone from template for instant provisioning.

Cloud-Init Template

Download a cloud image (Ubuntu, Debian, etc.), attach cloud-init drive. Set hostname, SSH keys, network via Proxmox UI or API. Fastest path to automation.

console


    # Create a cloud-init template from a downloaded image
    qm create 9000 --name ubuntu-template --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0
qm importdisk 9000 jammy-server-cloudimg-amd64.img local-lvm
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
qm template 9000
    # Clone from template
    qm clone 9000 100 --name webserver-01 --full
qm set 100 --ciuser admin --sshkeys ~/.ssh/id_ed25519.pub --ipconfig0 ip=dhcp
qm start 100

Start — What Actually Happens

Proxmox reads /etc/pve/qemu-server/<vmid>.conf

Build QEMU Command
qemu-server translates config into qemu-system-x86_64 args
Launch Process
QEMU process starts, opens /dev/kvm ioctl
VMCS Setup
KVM allocates VMCS, configures EPT, sets entry point
VM Entry
VMLAUNCH → CPU enters VMX non-root mode → guest boots

Shutdown

Graceful Shutdown (ACPI)

qm shutdown <vmid>
Proxmox sends ACPI power button event to QEMU
Guest OS receives the signal and initiates normal shutdown
Flushes buffers, stops services, unmounts filesystems
Requires qemu-guest-agent for best results
Timeout: default 60s, then optionally force-stop

Hard Stop (SIGKILL)

qm stop <vmid>
Proxmox sends SIGKILL to the QEMU process
Equivalent to pulling the power cord
No graceful shutdown — risk of data corruption
Disk write cache may not be flushed
Use only when guest is unresponsive

Live Migration

Pre-Copy Live Migration

Move a running VM from one node to another with minimal downtime.

Pre-Copy
Entire RAM copied to destination while VM keeps running on source
Iterative Rounds
Re-copy only dirty pages (pages written since last round)
Stop-and-Copy
Pause VM, copy remaining dirty pages + CPU state
Resume on Destination
VM resumes on target node. Downtime typically <100ms

Warning

Requirements for live migration:

Shared storage — both nodes must see the same disk (Ceph, NFS, iSCSI). Without shared storage, disk must be copied too (slower, uses --with-local-disks).
Same or compatible CPU family — use a common CPU type or named model, not cpu: host.
Same Proxmox version recommended.
Network connectivity — dedicated migration network recommended for large VMs.

console


    # Live migrate VM 100 to node pve2
    qm migrate 100 pve2 --online
    # With local disk (copies disk over network)
    qm migrate 100 pve2 --online --with-local-disks

Snapshots

Snapshot Mechanics

Captures disk state and optionally RAM state at a point in time
Disk snapshots use qcow2 backing files — original becomes read-only, writes go to a new overlay
Live snapshot (with --vmstate) saves RAM contents — rollback resumes exactly where you left off
Multiple snapshots form a chain — each overlay references the previous as its backing file
Deleting a snapshot merges the overlay into the base (called "commit")

console


    # Take a live snapshot (includes RAM)
    qm snapshot 100 before-upgrade --vmstate
    # List snapshots
    qm listsnapshot 100
    # Rollback (VM must be stopped for disk-only snapshots)
    qm rollback 100 before-upgrade
    # Delete a snapshot (merges overlay)
    qm delsnapshot 100 before-upgrade

Clone

Full Clone

Complete independent copy of all disks
No dependency on source VM
Takes more time and storage space
Source can be deleted safely
qm clone 100 200 --full --name clone-full

Linked Clone

Uses source snapshot as backing file
Only stores differences — very fast, saves space
Depends on source — cannot delete the base snapshot
Great for dev/test environments
qm clone 100 201 --name clone-linked

Networking

vmbr Bridges — The Foundation

Proxmox uses Linux bridges (named vmbr0, vmbr1, etc.) as virtual switches. Each VM NIC connects to a bridge via a tap interface.

Physical Server

Proxmox Host (Linux Kernel)

vmbr0 (Linux Bridge)

Connected to eth0 (physical NIC)

tap100i0

VM 100 eth0

tap101i0

VM 101 eth0

veth200i0

CT 200 eth0

VM Network Stack — Packet Path

VM Guest OS
Application sends packet via guest eth0
virtio-net
Paravirtual NIC driver — shared ring buffer with host
tap interface
tap100i0 — kernel network device on host
vmbr0 bridge
Linux bridge — L2 switching, MAC learning
Physical NIC
eth0/eno1 — out to physical network

console


    # Show bridge members
    $ bridge link show
3: eth0: <BROADCAST,MULTICAST,UP> master vmbr0
7: tap100i0: <BROADCAST,MULTICAST,UP> master vmbr0
8: tap101i0: <BROADCAST,MULTICAST,UP> master vmbr0
    # Show bridge MAC table
    $ bridge fdb show br vmbr0 | head -5

VLAN-Aware Bridges

Configuration

A single bridge can carry multiple VLANs when VLAN-aware mode is enabled. Each VM NIC specifies its VLAN tag in the config.

console


    # /etc/network/interfaces — VLAN-aware bridge
    auto vmbr0
iface vmbr0 inet static
    address 10.0.0.1/24
    gateway 10.0.0.254
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094
    # VM config — assign VLAN tag 100 to VM NIC
    net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0,tag=100
    # VM config — VLAN trunk (multiple VLANs)
    net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0,trunks=100;200;300

Tip

With VLAN-aware bridges, you do not need to create separate vmbr bridges per VLAN. One bridge handles all VLANs — much simpler to manage.

Open vSwitch (OVS)

OVS as an Alternative to Linux Bridges

OVS bridges replace Linux bridges with more advanced features
Port mirroring, sFlow/NetFlow monitoring, OpenFlow programmability
Better VLAN handling, GRE/VXLAN tunnel endpoints
More complex to configure and troubleshoot
Install: apt install openvswitch-switch, then configure in Proxmox UI

Software-Defined Networking (Proxmox 7+)

SDN Architecture

Proxmox SDN provides a declarative overlay networking model managed from the web UI.

Zones (Transport Layer)

Simple — isolated bridge, no VLAN, single L2 domain
VLAN — traditional 802.1Q VLANs on existing bridges
VXLAN — L2 overlay over L3 (UDP encapsulation, 16M segment IDs)
EVPN — BGP-based fabric, distributed routing, most advanced

VNets (Virtual Networks)

Each VNet belongs to a Zone
VNets are the networks VMs/CTs attach to
Defined centrally, automatically deployed to all nodes
Can have subnets with DHCP, DNS, gateway configuration

Device Passthrough

PCI Passthrough (VFIO)

What is PCI Passthrough?

Assign a physical PCI device (GPU, NIC, NVMe controller, etc.) directly to a VM. The VM gets bare-metal performance for that device. The host loses access to it.

Enable IOMMU in BIOS & kernel

console


          # /etc/default/grub — Intel
          GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"
          # /etc/default/grub — AMD
          GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
          # Apply
          update-grub && reboot

Identify IOMMU groups

console


          # List IOMMU groups and their devices
          find /sys/kernel/iommu_groups/ -type l | sort -V
          # All devices in the same IOMMU group must be passed through together

Bind device to vfio-pci driver

console


          # /etc/modprobe.d/vfio.conf
          options vfio-pci ids=10de:2484,10de:228b
          # /etc/modules
          vfio
vfio_iommu_type1
vfio_pci
          update-initramfs -u -k all && reboot

Add to VM config

console


          # VM must use q35 machine type
          machine: q35
hostpci0: 0000:01:00.0,pcie=1,x-vga=1

Warning

IOMMU group rule: All devices in the same IOMMU group must be passed through to the same VM (or all left on the host). You cannot split an IOMMU group. Check groups carefully before planning passthrough.

SR-IOV (Single Root I/O Virtualization)

SR-IOV Architecture

A single physical NIC presents multiple Virtual Functions (VFs), each of which can be passed to a different VM. Unlike full passthrough, the host keeps the Physical Function (PF).

SR-IOV NIC (e.g., Intel X710)

PF (Physical Function)

Host manages — driver: i40e

VF 0

Passed to VM 100

VF 1

Passed to VM 101

VF 2

Passed to VM 102

console


    # Enable 4 VFs on a NIC
    echo 4 > /sys/class/net/eth1/device/sriov_numvfs
    # Verify
    lspci | grep "Virtual Function"

USB Passthrough

By Device ID

Follows the device regardless of which USB port it is plugged into.

console


        # Find device
        lsusb
Bus 002 Device 003: ID 046d:c52b Logitech
        # VM config
        usb0: host=046d:c52b

By Port

Always passes the specific USB port, regardless of what device is plugged in.

console


        # VM config — host bus 2, port 3
        usb0: host=2-3

Cross-References

VLANs

For 802.1Q VLAN fundamentals, tagging, trunk vs access ports, and inter-VLAN routing, see Net 02 — VLANs.

Bridges & Tap Interfaces

For Linux bridge internals, tap/tun devices, veth pairs, and how virtual networking works at the kernel level, see Net 09 — Bridges & Tap Devices.

VM Lifecycle

Create

Start — What Actually Happens

Build QEMU Command

Launch Process

VMCS Setup

VM Entry

Shutdown

Live Migration

Pre-Copy

Iterative Rounds

Stop-and-Copy

Resume on Destination

Snapshots

Clone

Networking

vmbr Bridges — The Foundation

VM Network Stack — Packet Path

VM Guest OS

virtio-net

tap interface

vmbr0 bridge

Physical NIC

VLAN-Aware Bridges

Open vSwitch (OVS)

Software-Defined Networking (Proxmox 7+)

Device Passthrough

PCI Passthrough (VFIO)

SR-IOV (Single Root I/O Virtualization)

USB Passthrough

Cross-References