Proxmox VE - Fonctionnement et usage courant

Ce guide a pour objectif de faire découvrir Proxmox VE en tant qu’outil, comprendre ce qu’il permet de faire une fois qu’il fonctionne, comment se retrouver dans son interface…

Interfaces

Proxmox VE dispose de 2 principales interfaces :

  • une interface web, accessible sur le réseau d’administration ;
  • une interface en ligne de commande accessible localement (ou via SSH).

Nous présenterons surtout l’interface web, car elle constitue le moyen principal d’interagir humainement avec PVE, mais nous mentionnerons aussi les outils Command Line Interface (CLI) pour réaliser les mêmes tâches sans accès web. Certaines actions ne sont d’ailleurs possibles qu’en CLI.

Interface web

Proxmox VE fournit donc une interface web, généralement sur le port 8006. Elle peut être accessible par le WAN ou par un réseau d’administration dédié.

Si on connaît l’interface vSphere de VMware, on retrouve les mêmes concepts et principes d’organisation.

L’interface web de Proxmox se découpe en plusieurs parties, en essayant d’appliquer une logique d’organisation hiérarchique.

Elle est partiellement naviguable au clavier, mais ça n’est pas exhaustif.

Infos détaillées dans la documentation officielle

Se connecter

Proxmox utilise plusieurs “royaumes” d’authentification (realms) : pam (connecté au PAM du système), pve (base interne d’utilisateurs).

Nous utilisons un compte root@pam comme accès de secours, avec un mot de passe très fort et un second facteur, et des comptes <username>@pve pour les accès courants.

Dans la fenêtre d’authentification, on saisit :

  • User name : jdoe
  • Password : <password>
  • Realm : <PVE|PAM>
  • Language : <Fr|En|…>

Une fois connecté, Proxmox montre un identifiant combiné avec la partie personnelle et le royaume, exemple root@pam ou jdoe@pve.

En-tête principal

Il montre le logo de Proxmox, le nom et la version du produit.

Ensuite une zone de saisie Search permet une recherche rapide dans les VM, conteneurs, réseaux, stockages…

Un bouton Documentation permet d’ouvrir la documentation dans une fenêtre dédiée. Il s’agit de la documentation “locale”, spécifique à la version installée de Proxmox.

Des boutons bleus Create VM et Create CT permettent un accès rapide à ces fonctionnalités.

Note : Nous ne gérons aucun conteneur (CT) via Proxmox, donc ils seront simplement ignorés dans le reste de ce guide.

Enfin, un menu déroulant permet d’accéder au profil de la personne connectée, les préférences d’affichage…

Situé tout à gauche, il permet de choisir les ressources à consulter/configurer, de manière arboresente

Il présente plusieurs modes d’affichage :

  • Server view : pour organiser les ressources par membre du cluster : chacun ses VM, son stockage, …
  • Folder view : pour voir les ressources par type : toutes les VM, tous les membres, tous les réseaux…
  • Pool View : aucune idée de son utilité
  • Tag View : pour voir les ressources par étiquette. Nous créons généralement des étiquettes par type OS des VM, mais on peut s’en servir pour plein d’autres usages.

Un bouton avec l’icône de roue crantée permet de régler d’autres préférences d’affichage (tri…).

Panneau de contenu

La ressource sélectionnée dans le menu des ressources devient le contexte du panneau de contenu.

Un menu supérieur (en haut du panneau) donne des infos et des actions possibles sur la ressource affichée dans le panneau, y compris un bouton Help qui ouvre la documentation sur la page correspondant au contenu courant du panneau.

Un menu latéral (sur la gauche du panneau) permet de naviguer dans les sous-parties de la ressource affichée dans le panneau.

Panneau de logs

Tout en bas de l’interface, se trouve une section compactable.

La partie Tasks liste toutes les actions effectuées manuellement ou automatiquement : ouverture d’une console pour une VM, démarrage/arrêt de VM, migration de VM, sauvegarde, mise à jour de paquets.

Chaque entrée montre certaines informations, mais on peut consulter le détail par un double-clic sur la ligne en question, ou un clic sur le chevron tout à droite de la ligne. L’onglet Output montre le log complet. L’onglet Status montre une série de métadonnées sur la tâche.

Les tâches en cours montrent une icône de spinner. Elles peuvent être stoppées.

Les tâches en erreur sont affichées avec un fond rouge.

La partie Cluster log liste ce qui touche au cluster en lui-même : identification d’un utilisateur…

CLI

L’interface en ligne de commande est composée de plusieurs programmes et démons, donc voici les plus utiles :

Concepts

Datacenter, Node, VM/CT

Proxmox permet de gérer un datacenter virtuel et toutes ses composantes, en s’appuyant sur un ensemble de nœuds apportant des capacités de virtualisation, stockage… interconnectés via différents réseaux.

Certaines configurations et actions s’appliquent à l’ensemble du datacenter. Dans l’interface web on les trouve en sélectionnant le Datacenter dans le menu des ressources. C’est ici qu’on trouve la gestion des utilisateurs, les règles du firewall général, l’aperçu des ressources du cluster, les réplications, les sauvegardes, les règles de haute-disponibilité…

À l’échelle d’un nœud, on va retrouver la gestion de sa configuration réseau, ses disques, ses configurations système (mises à jour de paquets, DNS, horloge), les licences Proxmox…

Pour être gérés de manière cohérente à l’échelle du datacenter, plusieurs types de ressources doivent porter le même nom sur tous les nœuds : pools ZFS, bridge réseau…

Au final, ce sont des serveurs virtuels (VM) ou des conteneurs (CT) qui sont manipulés. Ils disposent tous d’un identifiant unique (VMID ou CTID) qui ne change pas, même si on renomme le conteneur ou la VM. En CLI (et dans une moindre mesure dans l’interface web) toutes les actions se rapportent au VMID/CTID, contrairement à nos KVM “classiques” où on utilise le nom de la VM.

Réseau

La configuration réseau de chaque nœud permet de définir localement la manière d’exposer les bridges qui seront utilisables par les VM et CT.

Par exemple si une VM dispose d’une interface réseau associée au bridge vmbr0, il faut qu’un bridge portant ce nom soit présent sur tous les nœuds susceptibles d’accueillir la VM.

Nous utilisons une configuration statique des réseaux (basée sur des fichiers dans /etc/network/interfaces), mais Proxmox est aussi capable d’exploiter des fonctionnalités de Software Defined Network (SDN) que nous n’utilisons pas encore.

Comme pour nos KVM “classiques”, la modification des réseaux d’un hyperviseur est une action plutôt rare, à faire avec une prudence particulière.

Firewall

Il existe des capacités de filtrage à plusieurs niveaux : datacenter, nœud, VM. Tout est cumulatif.

Nous n’utilisons actuellement que le filtrage au niveau du datacenter :

  • tout est autorisé en sortie
  • tout est refusé en entrée
  • interface web, SSH… autorisées pour des IP privilégiées

Le filtrage spécifique à chaque VM est géré dans la VM par minifirewall, pf ou autre outil adapté.

Stockage

À l’échelle du datacenter, Proxmox peut exploiter plusieurs types de stockages.

Un stockage local de type Directory (dans /var/lib/vz) existe par défaut et nous le restreignons à contenir seulement des snippets et container templates. Dans la pratique il n’est quasiment pas utilisé.

Un stockage Storage_ISO de type Directory (dans /home/images) permet de dédier un espace conventionnel pour les images ISO.

On peut avoir des stockages de type ZFS qui référencent les pools des membres du cluster qu’on veut associer. Ces stockages seront alors disponibles pour les outils de création, réplication et de migration de VM. Attention à bien cocher la case thin provisioning.

On peut avoir des stockages de type Proxmox Backup Server qui référencent des PBS pour qu’ils soient ensuite disponibles pour les outils de sauvegarde/restauration.

On peut avoir des stockages de type RBD ou CephFS (TODO : documenter).

D’autres types de stockage sont disponibles : iSCSI, NFS, SMB/CIFS, BTRFS, LVM…

Haute-disponibilité

Proxmox parle de HA (High Availability) pour désigner la capacité du cluster à prendre des mesures automatisées pour la continuité de service : démarrer des VM, les déplacer en cas de besoin, rapprocher ou éloigner des VM sur les hyperviseurs…

Ça se gère dans la partie Datacenter > HA.

C’est ici qu’on voit si le quorum est atteint ou pas, et le rôle de chaque membre.

Note : si on utilise un QDevice il ne sera pas visible ici car il ne s’agit par réellement d’un membre. Par contre il sera visible dans les commandes Corosync de bas niveau.

On peut définir des Resources en ciblant des VM.

Dans Datacenter > HA > Affinity Rules on peut ajouter :

  • des HA Node Affinity Rules pour plus ou moins forcer des VM à être présentes sur tel ou tel menbre du cluster.
  • des HA Resource Affinity Rules pour que des ressources (précédemment définies) soient rapprochées ou éloignées.

Cette partie HA est délicate à manipuler car des règles peuvent aussi bien faciliter ou entraver la gestion d’un incident. Il faut les manipuler avec précaution. Nous ne maitrisons pas encore tous les aspects de cette fonctionnalité.

Réplication

Pour les VM qui utilisent ZFS comme système de stockage, il est possible de programmer des réplications vers d’autres membres du cluster.

On peut accéder aux réplications de manière globale, au niveau du datacenter, mais aussi au niveau de chaque hyperviseur.

On peut définir autant de réplications que de cibles souhaitées pour chaque VM. On choisit la cible, la fréquence…

Attention : si on a configuré des règles de HA pour des VM répliquées, en cas de crash de l’hyperviseur la VM sera redémarrée sur un autre hyperviseur sur lequel elle est répliquée, mais ses données seront plus ou moins périmées. Il est alors conseillé de mettre un max_relocate = 0 dans la définition de la ressource HA (TODO : bien vérifier ça).

Il est possible de déclencher manuellement une réplication, avec le bouton Schedule Now.

Le bouton Log permet de voir les informations détaillées de la réplication sélectionnée.

Comment faire ?

On retrouve ici plusieurs cas d’usage concrets, pour l’administration courante.

Sauf mention particulière, nous conseillons d’utiliser l’interface web (qui a été beaucoup plus éprouvée), mais nous indiquons aussi les commandes CLI possibles, à utiliser avec prudence.

Se connecter à la console d’une VM

Dans l’interface web, il y a plusieurs possibilités :

  • un double-clic ou un clic-droit > Console sur une VM dans une des listes va ouvrir la console virtuelle dans une nouvelle fenêtre ;
  • si la VM est sélectionnée (et affichée dans le panneau principal) le bouton Console (menu supérieur de la VM) permet d’activer la console virtuelle (avec un choix possible de type de console : NoVNC, SPLICE, xterm.js) ;
  • la partie Console (menu latéral de la VM) affiche la console virtuelle dans la zone principale de la fenêtre courante.

Migrer une ou plusieurs VM

Une par une

Dans l’interface web on peut commander la migration d’une VM en la sélectionnant, puis par clic-droit > Migrate ou par le bouton Migrate (menu supérieur de la VM). On peut alors choisir la cible.

En CLI, on utilise qm migrate pour une migration à chaud :

# qm migrate <vmid> <target> --with-conntrack-state 1 --online 1

Par lot

Ça peut être utile de rapidement vider un hyperbviseur.

Dans l’interface web, on sélectionne le nœud puis par clic-droit > Bulk Migrate ou par le bouton Bulk Actions > Bulk Migrate (menu supérieur de la VM). On choisi ensuite les VM à migrer, le nombre de tâches parallèles de migration…

En CLI, on utilise pvenode migrateall pour tout migrer d’un coup :

# pvenode migrateall <target>

… ou pour une sélection de VM :

# pvenode migrateall <target> --vms [vmid,vmid,]

Note : si le paramètre max_workers n’est pas présent dans /etc/pve/datacenter.cfg il faut le spécifier dans la ligne de commande :

# pvenode migrateall <target> --vms [vmid,vmid,] --max-workers 4

Note : si des VM disposent de disques locaux, il faut ajouter le paramètre --with-local-disks true pour forcer leur migration.

Maintenance d’un nœud du cluster

Il est possible de mettre eu nœud en mode maintenance, pour l’exclure temporairement du cluster, afin de faire des mises à jour… sans perturber le reste du cluster.

Cette action n’est accessible qu’en CLI, mais peut être exécutée depuis n’importe quel nœud du cluster.

Pour activer le mode maintenance d’un nœud :

# ha-manager crm-command node-maintenance enable <node>

Après quelques secondes, le nœud aura une petite icone de clé bleue, au lieu de la marque verte.

Pour désactiver le mode maintenance d’un nœud :

# ha-manager crm-command node-maintenance disable <node>

Pour les ressources (VM…) concernées, les règles HA vont déclancher leur déplacement. pour les autres il faudra les migrer manuellement.

Modifier les ressources d’une VM

Dans l’interface web, il faut choisir la VM à modifier, puis la partie Hardware (menu latéral de la VM).

Toutes les modifications sont mises en attente si elles nécessitent un redémarrage de la VM. Pour ça on peut utiliser l’action Reboot de l’interface web (menu supérieur de la VM).

Processeurs

Sauf raison particulière on garde 1 seul socket et on met autant de cores qu’on souhaite et on garde le type host

Tou se passe via le menu latéral de la VM, dans le panneau principal pour une VM sélectionnée.

Disques

Ajout

Pour ajouter un disque, on passe par Add > Hard disk :

  • Bus/Device : SCSI
  • Storage : <zpool>
  • Discard: yes
  • IOthread : yes
  • Cache : Default (No cache)

Note : Il existe des réglages avancés, mais pas encore bien maîtrisés (par exemple : SSD Emulation)

Agrandissement

Pour agrandir un disque existant, on passe par Disk Action > Resize et on indique la quantité à ajouter (et pas la quantité totale !).

Suppression

Attention : Si le disque est en cours d’utilisation sur la VM, il est fortement conseillé de le démonter proprement avant toute manipulation dans PVE.

Pour retirer un disque d’une VM, il faut le détacher par le bouton Detach. Il va devenir un Unused disk [id].

Pour supprimer définitivement le disque inutilisé, il faut passer par le bouton Remove.

Cartes réseau

On passe par Add > Network device :

  • on indique le bridge à utiliser ;
  • on n’indique pas de VLAN (sauf besoin spécifique) ;
  • on désactive la fonction firewall (sauf si on est cerain d’en avoir besoin).

Renommer une VM

On passe par Options dans le menu de la VM, puis double-clic sur le nom de la VM dans la ligne Name, ou encore sélectionner la ligne Name puis bouton Edit

Dans Proxmox tout utilise le VMID (ou CTID pour les conteneurs) donc le nom d’une VM n’est jamais contenu dans les ressources… Ça rend le changement trivial par rapport à nos KVM “classiques”.

Détruire une VM

On sélectionne la VM et on s’assure qu’elle est éteinte, puis More > Remove (menu supérieur de la VM). Il faut :

  • confirmer le VMID (pour éviter les erreurs)
  • cocher Purge from job configurations (supprime les réplications, backups…)
  • cocher Destroy unreferenced disks owned by guest

Créer une VM

Dans l’en-tête principal, il y a un bouton bleu Create VM. On peut aussi faire clic-droit > Create VM sur un nœud. Une fenêtre dédie permettra de régler tous les paramètres de la VM à créer.

La documentation officielle donne plus de détails.

Onglet General

  • Node : on choisit le nœud sur lequel on souhaite créer la VM.
  • VMID : on peut forcer l’identifiant de la VM mais il est conseillé de garder celui qui est proposé.
  • Name : nom à donner à la VM.
  • Resource Pool : on peut spécifier le groupe à utiliser, si on en a créé.
  • Add to HA : permet de créer une ressource HA à la volée.
  • Start at boot : on coche si on souhaite que la VM démarre autmatiquement lorsque le nœud démarre.
  • Start/Shutdown order, Startup delay, Shutdown timeout : paramètres additionnels pour le démarrage, consultez la doc officielle
  • Tags : on peut ajouter des étiquettes

Onglet OS

Pour une installation à partir d’une image ISO stockée localement, on conserve le choix Use CD/DVD disc image file (iso) et on choisit l’image locale à utiliser.

Onglet System

On conserve tous les choix par défaut.

Il est conseillé de cocher Qemu Agent et de l’installer dans la VM

Onglet Disks

On crée autant de disques virtuels que souhaité, généralement 2 : 1 de 20 Go pour la partie système et 1 pour la partie données (/home).

On conserve à priori le mode VirtIO SCSI single, en cochant IO thread, ainsi que Discard. Voir la doc officielle pour plus de détail.

Attention : aucun réglage de sauvegarde ni de réplication n’est créé. Si une politique de sauvegarde globale existe elle sera appliquée, sinon il faudra en configurer une manuellement pour la VM. Aucune réplication ne sera créée par défaut, il faut le faire manuellement.

Onglet CPU

Sauf besoin spécifique on conserve 1 seule Socket et on indique autant de Cores qu’on souhaite avoir de vCPU dans la VM.

On conserve a priori tous les autres réglages par défaut.

Onglet Memory

On indique la mémoire (en multiples de 1024 Mo) qu’on souhaite allouer à la VM. Par exemple 12288 pour 12 Go.

Onglet Network

Si la VM ne doit avoir aucune interface réseau (très rare) on coche No network device. Sinon, il y aura une première interface réseau.

Si la VM doit avoir plusieurs interfaces réseau, il faut d’abord créer la VM puis aller les ajouter plus tard.

Bridge : on choisit le bridge à utiliser. Pour le WAN, c’est généralement vmbr0, mais on a le choix de tous les bridges existants sur ce nœud.

On garde a priori tous les autres paramètres par défaut.

Onglet Confirm

Un récapitulatif est montré avant validation finale.

Start after created : on coche cette case si on souhaite que la VM démarre immédiatement après avoir été créée.

Cloner une VM

On passe par clic-droit > Clone (sur une VM dans une liste) ou par More > Clone (menu supérieur de la VM).

  • À minima il faut donner un nom à la nouvelle VM.
  • On conserve en général Target storage : Same as source.
  • On peut choisir la cible avec Target node.
  • Si la source est un modèle de VM, on choisit Mode : Full clone.

Note : La VM ne sera pas démarrée automatiquement, pour ne pas risquer de conflit réseau…