Aller au contenu principal

Proxmox VE

Proxmox VE est l'hyperviseur sur lequel OpenVLE gère les machines virtuelles et les modèles de VM. OpenVLE communique exclusivement avec le cluster via l'API REST de Proxmox — il n'y a pas d'accès direct aux hôtes Proxmox.

Composant requis

Proxmox VE est une dépendance essentielle d'OpenVLE. Sans configuration correcte de Proxmox, l'application démarre certes, mais toutes les actions sur les VMs et les modèles de VM échoueront.

Connexion​

OpenVLE se connecte à l'API Proxmox via la bibliothèque Python proxmoxer. L'authentification se fait par jeton API (et non par mot de passe) :

ParamètreDescriptionExemple
PVE_HOSTNAMEPoint d'accès API (hôte:port)proxmox.example.com:8006
PVE_USERUtilisateur Proxmox (User@Realm)OpenVLE@pve
PVE_TOKEN_NAMEIdentifiant du jetonprod01
PVE_TOKEN_VALUESecret du jetonxxxxxxxx-xxxx-...
PVE_VERIFY_SSLVérifier le certificat SSLTrue

Concept de pool​

Toutes les VMs et modèles de VM gérés par OpenVLE sont organisés dans un pool Proxmox dédié (configuré via PVE_VMS_POOL, par défaut : OpenVLE-VMs). Les permissions Proxmox du jeton API OpenVLE sont restreintes à ce pool — OpenVLE ne peut donc ni voir, ni contrôler, ni supprimer de VMs en dehors du pool. Les autres charges de travail sur le même cluster Proxmox restent entièrement isolées et intactes.

Grâce à la combinaison du pool et de la séparation des privilèges, plusieurs instances OpenVLE (par exemple production, staging) peuvent être exploitées sur le même cluster Proxmox : chaque instance reçoit son propre jeton API avec accès à son propre pool, sans pouvoir voir ni influencer l'autre instance.

Cycle de vie des VMs​

Modèles de VM​

Les modèles de VM (templates) sont stockés directement dans Proxmox en tant que templates QEMU. OpenVLE synchronise périodiquement leur statut et leurs métadonnées (nom, CPU, RAM, noeud) dans sa propre base de données. Les templates peuvent être créés, mis à jour et supprimés via OpenVLE.

Opérations sur les VMs​

Lors du déploiement d'un événement ou sur demande manuelle, OpenVLE crée des VMs par clonage de templates :

OpérationDescription
ClonerCrée une nouvelle VM à partir d'un modèle de VM (Full Clone ou Linked Clone, configurable via PVE_VMS_FULL_CLONE_DEFAULT)
Démarrer / ArrêterDémarre ou arrête une VM sur Proxmox
ÉteindreÉteint proprement une VM via le QEMU Guest Agent
RedémarrerRedémarre une VM en cours d'exécution
RéinitialiserHard-Reset d'une VM
Suspendre / ReprendreSuspend une VM ou la reprend
MigrerDéplace une VM vers un autre noeud Proxmox (en ligne ou hors ligne)
SupprimerSupprime une VM de Proxmox et nettoie la base de données

Gestion des noeuds​

OpenVLE est entièrement compatible multi-noeuds et fonctionne avec un nombre quelconque de noeuds Proxmox :

  • Découverte des noeuds — La synchronisation périodique détecte tous les noeuds du cluster et enregistre leur statut
  • Sélection automatique du noeud — Lors du clonage d'une VM, OpenVLE sélectionne automatiquement le noeud disposant de la plus grande capacité CPU disponible
  • Suivi des noeuds — Pour chaque VM et modèle de VM, le noeud sur lequel il se trouve est enregistré. Lors des migrations, cette information est automatiquement mise à jour

Réseau et attribution d'IP​

OpenVLE prend en charge deux méthodes de configuration réseau pour les VMs.

Sans Apache Guacamole

Si OpenVLE est exploité sans Apache Guacamole — par exemple uniquement pour la gestion et le déploiement de VMs sans accès bureau à distance via le web — les informations réseau des VMs ne sont pas strictement nécessaires pour OpenVLE. Les adresses IP sont dans ce cas toujours lues et affichées, mais ne sont pas indispensables pour les fonctionnalités principales.

DHCP (standard, recommandé)​

En fonctionnement standard (PVE_CI_ENABLED=False), OpenVLE attend qu'un serveur DHCP externe soit actif dans le sous-réseau/VLAN des VMs pour leur attribuer dynamiquement des adresses IP. Les modèles de VM doivent simplement être configurés en DHCP.

Après le démarrage d'une VM, OpenVLE lit l'adresse IPv4 attribuée par le DHCP via le QEMU Guest Agent depuis la VM et l'enregistre dans la base de données. C'est la méthode standard recommandée.

Cloud-Init (expérimental)​

Lorsque Cloud-Init est activé (PVE_CI_ENABLED=True), OpenVLE prend en charge l'attribution des IP lui-même et écrit une configuration IP statique directement dans la VM :

  1. Le sous-réseau est formé à partir de PVE_VMS_NETWORK et PVE_VMS_SUBNET
  2. Les IP déjà attribuées (depuis la base de données) et les IP exclues (PVE_VMS_EXCLUDED_IPS) sont ignorées
  3. La première IP libre est attribuée à la nouvelle VM via Cloud-Init (y compris la passerelle et le DNS)
Expérimental

L'attribution d'IP basée sur Cloud-Init est actuellement une fonctionnalité expérimentale. Vous trouverez plus de détails et toutes les variables Cloud-Init sous Cloud-Init et dans la Référence de configuration — Proxmox VE.

QEMU Guest Agent​

OpenVLE requiert que le QEMU Guest Agent soit installé dans les VMs. Il est nécessaire pour les fonctionnalités suivantes :

  • Détection d'IP — Lecture de l'adresse IPv4 réelle d'une VM en cours d'exécution (avec DHCP et Cloud-Init)
  • Arrêt propre — Graceful Shutdown via l'agent
Permission Proxmox

À partir de Proxmox VE 9, le privilège VM.GuestAudit est requis sur le pool pour qu'OpenVLE puisse exécuter les requêtes et commandes du Guest Agent. Pour PVE < 9, ce privilège n'existe pas et peut être omis. Vous trouverez les détails de la mise en place sous Proxmox VE — Intégration.

Synchronisation périodique​

Le Worker worker-periodic synchronise le statut entre Proxmox et OpenVLE toutes les WORKER_PVE_PERIODIC_INTERVAL secondes (par défaut : 60) :

  1. Récupérer les ressources du cluster — Liste complète de toutes les VMs, templates et noeuds depuis Proxmox
  2. Mettre à jour MongoDB — Instantané des ressources du cluster pour un accès rapide
  3. Mettre à jour MariaDB — Mises à jour de statut pour toutes les VMs et templates connus (par exemple cloning → running, changement de noeud lors d'une migration)
  4. Créer le changelog — Toutes les modifications de statut sont consignées

Les VMs dans des états transitoires (starting, deleting, stopping) sont ignorées lors de la synchronisation pour éviter les conflits avec les opérations en cours.

Fonctionnalités optionnelles​

Cloud-Init (expérimental)​

Lorsque Cloud-Init est activé (PVE_CI_ENABLED=True), OpenVLE configure automatiquement les nouvelles VMs, en plus de l'attribution d'IP, avec :

  • Nom d'utilisateur et mot de passe (PVE_VMS_CIUSER, PVE_VMS_CIPASSWORD)
  • Mise à jour optionnelle des paquets au premier démarrage (PVE_VMS_CIUPGRADE)

Vous trouverez toutes les variables Cloud-Init dans la Référence de configuration — Proxmox VE.

Métadonnées SMBIOS​

Lorsque PVE_VMS_SMBIOS_METADATA est activé (par défaut : True), OpenVLE écrit des métadonnées de l'application dans les informations SMBIOS (Type 1) de la VM :

Champ SMBIOSContenu
manufacturerNom du projet
productNom de la VM
versionID du template
serialUUID VM OpenVLE
familySlug de l'événement

Ces métadonnées sont lisibles depuis le système d'exploitation invité (par exemple via dmidecode sous Linux ou WMI sous Windows) et permettent de mettre en place des automatisations personnalisées au sein des VMs. Les scripts dans la VM peuvent ainsi identifier à l'exécution à quel événement et environnement ils appartiennent, et ajuster automatiquement des configurations, démarrer des services ou synchroniser des données en conséquence — sans avoir à établir une connexion API directe avec OpenVLE.

Haute disponibilité​

Les VMs des événements sont par défaut intégrées dans la configuration HA de Proxmox et bénéficient ainsi automatiquement de la haute disponibilité du cluster : en cas de défaillance d'un noeud, les VMs sont automatiquement redémarrées sur un autre noeud. OpenVLE gère entièrement la configuration HA — les VMs sont ajoutées lors du déploiement et retirées lors de l'archivage.

Informations complémentaires​