Proxmox VE — Machines virtuelles

Pourquoi maîtriser les VMs KVM dans Proxmox

Les machines virtuelles sont le socle de toute infrastructure moderne. Qu’il s’agisse d’un lab de trois serveurs ou d’un datacenter en production, la capacité à créer, configurer et industrialiser des VMs détermine ta vitesse de déploiement et ta fiabilité opérationnelle.

Proxmox VE s’appuie sur KVM — l’hyperviseur intégré au noyau Linux — pour offrir des performances quasi bare-metal. Combiné avec les drivers VirtIO, le QEMU Guest Agent et cloud-init, tu obtiens une stack de virtualisation complète, gratuite et prête pour la production.

🔥 Cas réel : Une startup SaaS provisionne 15 VMs par sprint pour ses environnements de test. Grâce aux templates cloud-init sur Proxmox, chaque VM est prête en 30 secondes — contre 25 minutes d’installation manuelle. Le gain annuel : des centaines d’heures d’ingénierie récupérées.

Dans ce cours, tu vas apprendre à créer des VMs via l’interface et en CLI, installer le Guest Agent pour des snapshots cohérents, puis industrialiser le tout avec les templates et cloud-init.

Créer une VM — Interface web et CLI

Via l’assistant web

L’interface Proxmox te guide en plusieurs étapes. Voici les choix qui comptent vraiment à chaque onglet :

General — Adopte une convention d’ID dès le départ. Par exemple : 100-199 pour l’infra (DNS, reverse proxy), 200-299 pour les services, 300-399 pour le dev/test, 900-999 pour les templates. Le nom doit être explicite : ubuntu-web-01, pas vm1.

OS — Sélectionne ton ISO et le type de guest OS. Proxmox optimise certains paramètres selon ce choix, notamment pour Windows.

System — C’est ici que se joue la performance. La combinaison recommandée pour les VMs modernes :

• Machine q35 (support PCIe natif)
• BIOS OVMF (UEFI)
• SCSI Controller VirtIO SCSI single
• Case Qemu Agent cochée

💡 Tip DevOps : Le choix q35 + UEFI est le standard pour toute VM Linux moderne. Réserve i440fx + SeaBIOS uniquement pour les OS legacy ou les cas de compatibilité spécifiques.

Disks — Utilise VirtIO Block pour la meilleure performance I/O. Active Discard sur SSD (support TRIM) et IO Thread pour paralléliser les opérations disque. Le thin provisioning consomme uniquement l’espace réellement écrit.

CPU — Un seul socket, et choisis le type selon ton besoin : host expose le CPU réel à la VM (meilleure perf, mais empêche la live migration), x86-64-v2-AES offre un bon compromis. Ne dépasse pas un ratio de 2:1 entre vCPUs allouées et threads physiques.

Memory — Alloue ce dont la VM a besoin. Le ballooning permet à Proxmox de récupérer la RAM inutilisée, mais il nécessite le Guest Agent. Règle d’or : on n’overcommit pas la RAM.

Network — Toujours VirtIO (paravirtualized) pour Linux. Pour Windows, il faut installer les drivers VirtIO depuis l’ISO dédiée.

Via la CLI — pour l’automatisation

La CLI qm est ta meilleure amie pour scripter les déploiements :

# Créer une VM complète en une commande
qm create 200 \
  --name ubuntu-web-01 \
  --memory 4096 \
  --cores 2 \
  --sockets 1 \
  --cpu cputype=x86-64-v2-AES \
  --net0 virtio,bridge=vmbr0 \
  --scsihw virtio-scsi-single \
  --scsi0 local-lvm:32,iothread=1,discard=on \
  --ide2 local:iso/ubuntu-24.04-live-server-amd64.iso,media=cdrom \
  --boot order=ide2 \
  --ostype l26 \
  --machine q35 \
  --bios ovmf \
  --efidisk0 local-lvm:1 \
  --agent enabled=1

qm start 200

Chaque paramètre de l’assistant web a son équivalent CLI. L’avantage : tu peux versionner cette commande dans un script, la rejouer, l’intégrer dans un pipeline.

Le QEMU Guest Agent — le lien vital

Le QEMU Guest Agent (QGA) est un daemon qui tourne à l’intérieur de la VM et communique avec l’hyperviseur via un canal série virtio. Sans lui, Proxmox est “aveugle” : il ne connaît pas l’IP de la VM, ne peut pas faire de shutdown propre, et tes snapshots risquent d’être incohérents.

Concrètement, le Guest Agent permet :

• Arrêt propre : Proxmox envoie un signal de shutdown au lieu de couper l’alimentation
• Freeze du filesystem : les snapshots capturent un état cohérent des données
• Récupération d’infos : IP, mémoire utilisée, filesystems montés — visibles dans le Summary
• TRIM : libération des blocs inutilisés sur les disques thin-provisioned

L’installation est simple sur toutes les distributions :

# Debian/Ubuntu
apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent

# RHEL/Rocky/Alma
dnf install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent

Vérifie depuis l’hôte Proxmox que la communication fonctionne :

# Test de connectivité avec le Guest Agent
qm agent 200 ping
qm agent 200 network-get-interfaces

⚠️ Attention : Sans le Guest Agent, un snapshot pris sur une VM en cours d’écriture peut capturer un filesystem dans un état incohérent — exactement comme débrancher un disque dur en pleine copie. Installe-le systématiquement.

Templates et cloud-init — industrialiser le provisioning

Le problème que ça résout

Installer un OS manuellement, c’est 20 minutes par VM. Configurer SSH, les paquets de base, le réseau — encore 10 minutes. Multiplie par 10 VMs et ta journée est fichue. Les templates et cloud-init éliminent ce travail répétitif.

Créer un template cloud-init

La méthode la plus propre utilise les images cloud officielles des distributions. Ces images sont pré-optimisées, légères (2-3 Go) et incluent cloud-init nativement :

# Télécharger l'image cloud Ubuntu
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

# Créer la VM, importer le disque, ajouter cloud-init
qm create 9000 --name ubuntu-cloud --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 \
  --scsihw virtio-scsi-single \
  --machine q35 --bios ovmf \
  --efidisk0 local-lvm:1 \
  --agent enabled=1

qm set 9000 --scsi0 local-lvm:0,import-from=/root/noble-server-cloudimg-amd64.img
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0
qm disk resize 9000 scsi0 +28G

# Préconfigurer les valeurs par défaut
qm set 9000 --ciuser admin
qm set 9000 --sshkeys ~/.ssh/id_ed25519.pub
qm set 9000 --ipconfig0 ip=dhcp

# Convertir en template
qm template 9000

🧠 À retenir : Un template est une VM figée. On ne peut plus la démarrer ni la modifier — seulement la cloner. C’est une image de référence, pas un environnement de travail.

Déployer en 30 secondes

Une fois le template prêt, chaque nouveau déploiement se résume à un clone + personnalisation :

# Cloner et personnaliser
qm clone 9000 300 --name web-prod-01 --full true
qm set 300 --ipconfig0 ip=192.168.1.50/24,gw=192.168.1.1
qm set 300 --nameserver 1.1.1.1
qm cloudinit update 300
qm start 300

# 30 secondes plus tard
ssh admin@192.168.1.50

Pour aller plus loin, les snippets cloud-init permettent d’exécuter des scripts personnalisés au premier boot — installation de paquets, configuration du firewall, timezone :

cat > /var/lib/vz/snippets/vendor-data.yaml << 'EOF'
#cloud-config
package_update: true
packages: [curl, git, htop, vim, ufw]
runcmd:
  - ufw allow 22/tcp
  - ufw --force enable
  - timedatectl set-timezone Europe/Zurich
EOF

qm set 300 --cicustom "vendor=local:snippets/vendor-data.yaml"

💡 Tip DevOps : Clone full pour la production (indépendant du template), clone linked pour le dev/test (plus rapide, moins d’espace, mais dépend du template source).

Gestion des disques et snapshots

Opérations disque courantes

Les disques des VMs se manipulent à chaud dans la plupart des cas :

# Ajouter un disque de 50 Go
qm set 200 --scsi1 local-lvm:50,iothread=1,discard=on

# Agrandir un disque existant (jamais réduire !)
qm disk resize 200 scsi0 +20G

# Dans la VM, étendre le filesystem
growpart /dev/sda 2
resize2fs /dev/sda2

# Déplacer un disque vers un autre stockage
qm disk move 200 scsi0 local-zfs --delete true

Snapshots — filet de sécurité, pas backup

Les snapshots capturent l’état d’une VM à un instant T. Ils sont parfaits avant une mise à jour risquée ou un changement de configuration :

# Créer un snapshot avant une opération risquée
qm snapshot 200 before-upgrade --description "Avant upgrade Ubuntu 24.04"

# Quelque chose a cassé ? Rollback instantané
qm rollback 200 before-upgrade

# Nettoyer les snapshots obsolètes
qm delsnapshot 200 before-upgrade

⚠️ Attention : Les snapshots ne sont PAS des backups. Ils vivent sur le même disque que la VM. Si le stockage tombe, snapshots et VM disparaissent ensemble. Utilise PBS (Proxmox Backup Server) pour les vraies sauvegardes.

Bonnes pratiques et pièges à éviter

Nommage cohérent — Adopte le format {env}-{role}-{numéro} dès le début : prod-web-01, dev-db-02, staging-api-01. Ajoute des tags pour filtrer dans l’interface :

qm set 200 --tags "production,web,ubuntu"
qm set 200 --protection 1  # empêche la suppression accidentelle

Pièges classiques :

• Oublier le Guest Agent → snapshots incohérents, pas d’IP visible
• Overcommit la RAM → OOM killer qui tue des process aléatoirement
• CPU type host partout → impossible de migrer les VMs entre nœuds
• Pas de convention d’ID → chaos à 50+ VMs
• Snapshots comme backups → fausse sécurité

Checklist VM production :

• ✅ Guest Agent installé et actif
• ✅ VirtIO pour disque et réseau
• ✅ Protection activée
• ✅ Tags configurés
• ✅ Backup PBS planifié
• ✅ Convention de nommage respectée

🔥 Cas réel : Un admin supprime accidentellement une VM de production avec qm destroy. Pas de --protection 1, pas de backup récent. 4 heures de downtime et une restauration depuis un snapshot vieux de 3 jours. Le flag protection aurait bloqué la commande avec un simple message d’erreur.

Résumé

Les VMs KVM dans Proxmox offrent des performances proches du bare-metal grâce aux drivers VirtIO et à l’intégration KVM native dans le noyau Linux.

Le QEMU Guest Agent est non-négociable : installe-le sur chaque VM pour des snapshots cohérents, un shutdown propre et une visibilité complète depuis l’hyperviseur.

Les templates cloud-init transforment un processus de 30 minutes en un déploiement de 30 secondes. Utilise les images cloud officielles comme base, configure via qm set, et clone à volonté.

Les snapshots sont un filet de sécurité temporaire, pas une stratégie de backup. Combine-les avec Proxmox Backup Server pour une protection complète.

🧠 À retenir : La vraie valeur de Proxmox n’est pas de créer une VM — c’est d’industrialiser la création de centaines de VMs identiques, reproductibles et gérées comme du code.