5. Accès console et cycle de vie d'une VM

La console d'une VM passe par VNC (Virtual Network Computing, protocole d'affichage à distance).

5.1 La console VNC et noVNC

Proxmox expose la console de chaque VM via noVNC, une implémentation VNC qui fonctionne dans le navigateur web sans plugin. Pour y accéder, cliquez sur la VM dans le panneau de gauche, puis sur Console. Un onglet s'ouvre avec l'écran de la VM.

La console VNC est particulièrement utile pendant l'installation de l'OS et pour diagnostiquer une VM qui ne répond plus au réseau. C'est votre accès de secours — indépendant de l'état du réseau de la VM.

Pour les VMs équipées de l'agent QEMU (qemu-guest-agent), Proxmox peut également obtenir des informations depuis l'intérieur de la VM (adresses IP, état des disques) sans passer par le réseau.

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

# Depuis l'hôte Proxmox : ouvrir un terminal série vers la VM (si configuré)
qm terminal 100

# Vérifier que l'agent QEMU répond
qm guest cmd 100 ping

Résultat attendu de qm guest cmd 100 ping : aucun affichage, et un code de retour 0 (echo $?). Le silence est la réponse positive : l'agent a répondu.

Si l'agent n'est pas installé, ou si le service qemu-guest-agent n'est pas démarré dans la VM, la commande échoue au bout de quelques secondes avec QEMU guest agent is not running. qm agent est un ancien nom de la même commande, toujours accepté.

5.2 Gérer le cycle de vie

Au-delà du démarrage initial, les commandes suivantes couvrent le cycle de vie complet d'une VM au quotidien.

La distinction à ne pas manquer est celle entre shutdown et stop, parce qu'elle a des conséquences directes sur les données.

Ce que déclenche chacune des deux commandes, et le piège du shutdown ignoré. Cliquez sur une commande pour le détail.

qm shutdown envoie un signal ACPI à la VM — l'équivalent d'un appui sur le bouton d'alimentation d'une machine physique. C'est le système invité qui décide : il ferme ses services, vide ses tampons d'écriture sur disque, démonte ses systèmes de fichiers, puis s'éteint. Rien n'est perdu.

qm stop coupe l'alimentation du processus, sans prévenir personne. C'est l'équivalent de débrancher le câble.

Tout ce qui était en mémoire et pas encore écrit disparaît. Le système de fichiers reste marqué comme non démonté : d'où la vérification au redémarrage suivant, et parfois une base de données à réparer.

Le piège pratique : qm shutdown peut ne rien faire du tout. Si la VM n'a pas de gestionnaire ACPI — un système minimal, un invité figé — le signal est ignoré.

Quand l'agent invité est installé et activé, Proxmox lui passe la demande d'arrêt par son canal plutôt que par ACPI, ce qui est plus fiable. L'option --timeout borne l'attente, mais ne force rien à elle seule :

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

# Arrêt propre, abandonné si la VM n'a pas répondu au bout de 60 secondes
qm shutdown 100 --timeout 60

Résultat attendu :

root@pxe211:~# qm shutdown 100 --timeout 60
VM quit/powerdown failed - got timeout
root@pxe211:~# qm status 100
status: running

Le message dit exactement ce qui s'est passé : la VM n'a pas répondu au signal ACPI dans le délai imparti et tourne toujours. Pour qu'elle soit coupée d'office à l'expiration du délai, il faut le demander explicitement : qm shutdown 100 --timeout 60 --forceStop 1. Mais une VM qui ignore l'arrêt propre signale surtout un agent absent : c'est à ce moment-là qu'on installe l'agent invité (§7.2), plutôt que de prendre l'habitude du qm stop.

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

# Démarrer une VM
qm start 100

# Arrêt propre (envoie un signal ACPI — comme appuyer sur le bouton power)
qm shutdown 100

# Forcer l'arrêt (équivalent débrancher le câble — à éviter sauf urgence)
qm stop 100

# Redémarrer
qm reboot 100

# Mettre en pause (suspend la VM, garde l'état en RAM)
qm suspend 100

# Voir l'état de toutes les VMs
qm list

# Voir la configuration complète d'une VM
qm config 100

# Modifier des paramètres : sur une VM allumée, ils restent « en attente »
# jusqu'au prochain démarrage, sauf si le hotplug mémoire/CPU a été activé
qm set 100 --memory 4096
qm set 100 --cores 4   # 4 cœurs, appliqué au prochain démarrage

Résultat attendu de qm list :

      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       100 debian-base          running       2048             32.00 12345
       101 debian-cloud         stopped       2048             20.00 0

Chaque VM est listée avec son VMID, son nom et son statut (running ou stopped). Suivent la RAM allouée, la taille du disque système, et le PID du processus QEMU (0 si arrêtée).

5.3 Dépannage et journaux

Quand une VM refuse de démarrer ou se bloque, les journaux Proxmox sont le premier réflexe.

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

# Journaux du service pve-cluster (état général)
journalctl -u pve-cluster --since "1 hour ago"

# Tâches récentes de la VM 100 (démarrage, arrêt, migration...), en JSON lisible
pvesh get /nodes/$(hostname)/tasks --vmid 100 --limit 5 --output-format json-pretty

# Démarrer au premier plan affiche l'erreur QEMU complète, sans passer par un journal
qm start 100

# Moniteur QEMU interactif (diagnostic avancé)
qm monitor 100
# Dans le moniteur : "info status", "info block", "quit"

Résultat attendu de la commande pvesh (extrait, une tâche) :

[
   {
      "endtime" : 1781683203,
      "id" : "100",
      "node" : "pxe211",
      "starttime" : 1781683200,
      "status" : "OK",
      "type" : "qmstart",
      "upid" : "UPID:pxe211:00003A2B:0012F3C4:6A31D2C0:qmstart:100:root@pam:",
      "user" : "root@pam"
   }
]

qm start 100 lancé à la main a un avantage sur le bouton de l'interface : l'erreur complète de QEMU s'affiche directement dans le terminal. Les trois messages les plus fréquents se reconnaissent vite.

VM is locked (backup) ou (snapshot) : une opération précédente a laissé un verrou, visible dans qm config par une ligne lock: ; si l'opération est réellement terminée, qm unlock 100 le lève. timeout waiting on systemd : QEMU n'a pas démarré dans le délai, souvent faute de mémoire libre sur l'hôte. no such logical volume : le disque référencé dans la configuration n'existe plus — typiquement après une suppression manuelle dans LVM.

qm monitor 100 ouvre enfin le moniteur de QEMU, pour interroger la VM en cours d'exécution. info status dit si elle tourne ou est en pause : une VM figée par un pool thin plein y apparaît paused (io-error). info block liste ses disques et leur état.

Chaque tâche Proxmox (démarrage, arrêt, migration, backup) est enregistrée avec son type, son statut (OK, ou le message d'erreur), et ses horodatages Unix. L'upid est son identifiant complet : pvenode task log <upid> en affiche le journal détaillé, exactement celui que l'interface montre en double-cliquant sur la tâche dans le panneau du bas. C'est le premier endroit à consulter lors d'un dysfonctionnement.

À retenir : la console noVNC reste l'accès de secours quand le réseau de la VM ne répond plus. qm shutdown demande un arrêt propre à l'invité ; qm stop coupe l'alimentation. En cas de problème : qm config, les journaux (journalctl), puis l'espace du pool.