4. Créer une VM KVM — Créer une VM en ligne de commande

4.2 Créer une VM en ligne de commande

La commande qm est l'interface CLI de Proxmox pour les VMs. Chaque paramètre correspond à un champ de l'assistant graphique.

C'est précisément l'intérêt de la faire une fois en ligne de commande. On voit d'un seul coup d'œil tout ce que l'assistant a rempli à votre place, valeurs par défaut comprises.

Pourquoi apprendre la CLI alors que l'interface web existe. Trois raisons, et aucune n'est une question de préférence :

Elle est scriptable. Créer trente VMs par l'assistant demande trente fois les mêmes clics, avec trente occasions de se tromper. Une boucle sur qm create ne se trompe pas.

Elle est reproductible et documentable. La commande complète tient dans un fichier, se relit, se versionne, se colle dans un ticket. Une suite de captures d'écran ne remplace pas cela.

Elle est parfois la seule disponible. Sur un nœud dont l'interface web ne répond plus, ou en dépannage via une console de secours, qm reste accessible.

Le VMID est le premier argument, et il n'est pas anodin. C'est l'identifiant unique de la VM sur tout le cluster : il ne peut pas être réutilisé tant que la VM existe.

Et c'est lui, pas le nom, qui sert de référence à toutes les autres commandes, aux sauvegardes et à l'API. Le nom, lui, peut changer librement.

D'où l'utilité d'une convention de numérotation dès le premier jour. Celle de ce support — les 100 pour les VM, les 200 pour les conteneurs, les 9000 pour les modèles — est appliquée dans tous les chapitres et tous les ateliers.

C'est elle qui permet au conteneur 200 du chapitre 1 et aux VM de ce chapitre de cohabiter sur le même nœud. Elle évite aussi les collisions le jour où plusieurs personnes créent des machines en parallèle.

Les valeurs par défaut ne sont pas neutres. Ce que la commande ne précise pas est choisi par Proxmox, et rarement au mieux. Sans --cpu, la ligne de commande retient kvm64, un processeur générique volontairement conservateur qui masque les jeux d'instructions modernes.

D'où le x86-64-v2-AES de l'exemple, qui expose notamment l'accélération matérielle du chiffrement. L'assistant graphique, lui, présélectionne x86-64-v2-AES depuis Proxmox VE 8 : une même VM créée des deux façons n'a donc pas le même processeur si l'on ne précise rien. qm config <VMID> affiche la configuration réellement retenue, valeurs implicites comprises : c'est la commande à passer juste après une création pour vérifier ce qu'on a obtenu.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Créer une VM Debian 13 en CLI
qm create 105 \
  --name vm-debian \
  --machine q35 \
  --memory 2048 \
  --cores 2 \
  --sockets 1 \
  --cpu cputype=x86-64-v2-AES \
  --net0 virtio,bridge=vmbr0 \
  --scsi0 local-lvm:20 \
  --scsihw virtio-scsi-single \
  --ide2 local:iso/debian-13.6.0-amd64-netinst.iso,media=cdrom \
  --boot 'order=scsi0;ide2' \
  --ostype l26 \
  --agent enabled=1

# Démarrer la VM
qm start 105

Résultat attendu : qm create et qm start ne répondent rien en cas de succès. La VM 105 apparaît dans le panneau de gauche avec un indicateur vert, et sa console affiche l'installateur Debian.

L'ordre de démarrage scsi0;ide2 place le disque avant le lecteur CD. Le premier démarrage trouve un disque vide, passe au CD et lance l'installation ; les suivants démarrent sur le système installé, sans qu'il faille penser à retirer l'ISO. Avec order=ide2 seul, la VM relancerait l'installateur à chaque démarrage.

Et l'adresse IP ? Elle ne figure pas dans la commande, et c'est normal : --net0 virtio,bridge=vmbr0 ne décrit que la carte réseau de la VM, branchée sur le pont vmbr0.

L'adresse appartient au système installé dans la VM : elle se saisit dans l'installateur Debian, à l'étape Configurer le réseau. qm ne sait fixer l'adresse d'une VM qu'au travers de cloud-init (--ipconfig0 ip=…/24,gw=…), présenté au §10. C'est ce que font les ateliers 7 et 8, avec une image cloud au lieu de cette ISO.

Avec l'ISO debian-13.6.0-amd64-netinst.iso (installation graphique, en français), sur un nœud du lab :

S'il n'y a pas de serveur DHCP sur le réseau, l'installateur échoue à se configurer seul et propose la méthode de configuration.
S'il y en a un, il prend une adresse sans rien demander et passe directement au nom de machine. Pour garder une adresse fixe, revenez en arrière (bouton Revenir en arrière, ou touche Échap) : le choix de la méthode apparaît.

Choisissez Configurer vous-même le réseau :

Les deux premières lignes relancent le DHCP ; la troisième ouvre la saisie manuelle ; la dernière laisse la VM sans réseau, à configurer plus tard.

Saisissez ensuite l'adresse fixe du plan d'adressage, avec son masque au format CIDR : 10.<site>.<N>.54/24 pour la VM 105, la première VM des ateliers.

L'écran le dit lui-même : le masque s'ajoute directement à l'adresse (/24). Sur la capture, l'adresse d'essai du lab d'exemple ; chez vous, celle de votre vmbr0, à partir de .50. Une valeur invalide est refusée par le message Adresse IP mal formée.

Viennent ensuite la Passerelle, puis les Adresses des serveurs de noms :

L'installateur propose d'office l'adresse en .1 du réseau saisi, pour la passerelle comme pour le serveur de noms : vérifiez qu'elle correspond à votre réseau, puis Continuer. L'installation reprend au nom de machine.

Vérifiez l'adresse au premier démarrage. Sur le lab, sur un réseau qui annonce de l'IPv6 : malgré la saisie manuelle, l'installateur a écrit iface ens18 inet6 auto dans /etc/network/interfaces, et la VM a démarré sans adresse IPv4. ip -br a dans la console le montre tout de suite ; l'atelier 2 (étape 3) donne la correction.

4.3 Pièges fréquents à la création d'une VM

Certaines erreurs reviennent systématiquement lors des premières créations de VM, aussi bien via l'assistant graphique qu'en CLI. Les connaître à l'avance évite de perdre du temps en diagnostic.

La VM ne démarre pas, TASK ERROR: start failed. VM ID déjà utilisé, ou pool LVM-thin saturé. Remède : qm list pour vérifier les VMID existants, lvs pour l'espace disponible.

Écran noir dans la console au boot. Ordre de boot incorrect (--boot order=...) ou ISO non attachée. Remède : qm config <vmid> | grep boot puis corriger avec qm set.

Réseau invisible dans l'OS installé. Pilote VirtIO non supporté par un OS ancien. Remède : Basculer temporairement sur le modèle E1000 (carte réseau Intel émulée) le temps d'installer les pilotes VirtIO.

L'agent QEMU ne répond jamais. qemu-guest-agent non installé dans la VM, ou service non démarré. Remède : Cocher l'agent (qm set <vmid> --agent enabled=1), arrêter puis démarrer la VM, et apt install qemu-guest-agent dans le guest ; le service démarre alors tout seul.

Disque visible dans lvs mais absent dans la VM. Bus/Device mal choisi (SCSI vs IDE — ancien bus de disques — vs VirtIO Block) sans pilote correspondant dans l'OS. Remède : Vérifier la compatibilité du bus avec l'OS installé, privilégier VirtIO SCSI pour les OS modernes.

Face à une VM qui se comporte anormalement, le réflexe est le même que pour un serveur physique. Consulter d'abord les journaux (journalctl, qm config, qm monitor), avant de recréer la VM depuis zéro. Cette rigueur diagnostique est particulièrement précieuse en production, où recréer une VM n'est pas toujours une option instantanée.

À retenir : une VM se crée par l'assistant Create VM (onglets General, OS, System, Disks, CPU, Memory, Network) ou par qm create, dont chaque option reprend un champ de l'assistant. Les valeurs par défaut ne sont pas neutres : on choisit explicitement contrôleur, carte réseau et type de CPU.

▶ À pratiquer maintenant — Atelier 2

Créer la première VM de bout en bout : l'assistant onglet par onglet, l'installation de Debian depuis l'ISO, l'adresse fixe, la connexion.