--- title: Proxmox VE description: Ajoutez des clusters Proxmox VE comme source de VM : jeton API à privilèges minimaux, stockage, templates d'images cloud, pools IP et épinglage TLS. url: https://nexcmp.com/fr/docs/infrastructure/proxmox/ applies_to: NexCMP 1.6.1 updated: 2026-11-02 --- # Proxmox VE > **Où dans l'administration :** Infrastructure › Cloud provider › Providers (`/infra/providers`), puis la page du fournisseur (`/infra/providers/`) avec les onglets Overview, Clusters, VMs, Servers et Credentials. Les plans se paramètrent sous Services › Virtual Machines › Plans & pricing (`/vm/catalog`). ## Description {#what-it-does} NexCMP peut vendre des machines virtuelles s'exécutant sur un ou plusieurs clusters Proxmox VE, en complément ou à la place de CloudStack. Une VM est créée en clonant un modèle d'OS par clonage intégral, puis configurée via cloud-init : taille, adresse IP issue d'un pool que vous définissez, mot de passe root et clé SSH. Les clients bénéficient du contrôle d'alimentation, de la console, des instantanés, de la réinstallation, de la réinitialisation du mot de passe et des métriques dans le portail. Ils ne voient jamais le nom du cluster, du nœud ou de la source. À utiliser lorsque vous exploitez déjà Proxmox VE, ou pour proposer un second pool de VM aux tarifs différents. ## Prérequis {#requirements} | Élément | Prérequis | |---|---| | Proxmox VE | PVE 9.x. L'intégration a été vérifiée sur la version 9.2. Elle nécessite le contenu de stockage `import` et l'option de disque `import-from` (PVE 8.2 ou version ultérieure). | | Réseau depuis le panneau | HTTPS vers l'API du cluster, `https://:8006`. Aucun chemin, nom d'utilisateur ou requête. Le panneau et le worker s'y connectent tous les deux ; la console du navigateur passe par un proxy via le panneau. | | Compte | Un utilisateur PVE dédié doté d'un **jeton API** et d'un rôle personnalisé disposant des privilèges listés ci-dessous. N'utilisez jamais `root@pam`. | | Stockage | Un stockage pour les disques de VM prenant en charge les clones (par exemple `local-lvm`). Pour le générateur de modèles intégré, le stockage nommé `local` avec les types de contenu `import` et `snippets`. | | Réseau | Un bridge Linux (par exemple `vmbr0`) atteignant le réseau où résident les IP des clients. Utilisez un bridge compatible VLAN si vous saisissez un identifiant de VLAN. | | IP | Un bloc IPv4 (/16 à /30) routé vers ce bridge, avec une passerelle. NexCMP attribue les adresses lui-même ; Proxmox ne gère pas les IP. | | Templates | Une machine virtuelle modèle cloud-init par OS, sur chaque nœud où vous déployez, avec l'agent QEMU guest. | | Zone | Une zone existante à laquelle rattacher le cluster. Voir [Zones](https://nexcmp.com/fr/docs/infrastructure/zones/). | | Dépend de | Aucun. | ## Préparer l'infrastructure {#prepare-the-infrastructure} Exécutez les commandes en tant que root sur n'importe quel nœud du cluster. ### 1. Créer un rôle, un utilisateur et un jeton API à privilèges minimaux {#_1-create-a-least-privilege-role-user-and-api-token} 1. Créez le rôle. La liste des privilèges correspond exactement à ce que NexCMP utilise ; elle ne contient rien qui modifie les utilisateurs, les définitions de stockage ou le centre de données. ```bash pveum role add NexCMP -privs "VM.Allocate VM.Clone VM.Config.CDROM VM.Config.CPU VM.Config.Cloudinit VM.Config.Disk VM.Config.HWType VM.Config.Memory VM.Config.Network VM.Config.Options VM.PowerMgmt VM.Audit VM.Console VM.Snapshot VM.Snapshot.Rollback VM.Backup VM.GuestAgent.Audit VM.GuestAgent.Unrestricted Datastore.Audit Datastore.AllocateSpace Datastore.AllocateTemplate Sys.Audit Sys.AccessNetwork SDN.Use SDN.Audit Pool.Audit Mapping.Audit Mapping.Use" ``` `Sys.AccessNetwork` est requis pour le téléchargement de l'image cloud. PVE 9 ne possède pas le privilège `VM.Monitor` ; ne l'ajoutez pas. 2. Créez l'utilisateur et un jeton. `--privsep 1` signifie que les droits du jeton correspondent à **l'intersection** des permissions propres de l'utilisateur et de celles du jeton. ```bash pveum user add nexcmp@pve --comment "NexCMP" pveum user token add nexcmp@pve api --privsep 1 ``` La commande affiche le **secret du token une seule fois** (un UUID). Copiez-le maintenant. L'id du token est `nexcmp@pve!api`. 3. Attribuez le rôle **à la fois** à l'utilisateur et au token. C'est l'étape souvent oubliée: avec la séparation des privilèges, l'attribuer uniquement au token entraîne des erreurs 403 telles que `Datastore.Audit` si l'utilisateur n'a pas de permission. ```bash pveum acl modify / --roles NexCMP --users nexcmp@pve pveum acl modify / --roles NexCMP --tokens 'nexcmp@pve!api' ``` 4. Testez-le depuis le serveur du panel: ```bash curl -sk -H 'Authorization: PVEAPIToken=nexcmp@pve!api=' https://192.0.2.10:8006/api2/json/version ``` Un document JSON contenant `version` signifie que le token fonctionne. (`-k` sert uniquement pour ce test rapide; NexCMP épingle lui-même le certificat, voir ci-dessous.) ### 2. Vérifier le bridge et le stockage {#_2-check-the-bridge-and-the-storage} ```bash pvesm status # storages, type, content and free space ip -br link show type bridge ``` - Les VM clientes reçoivent des interfaces réseau `virtio` sur le bridge renseigné dans NexCMP. Si vous définissez un VLAN, le bridge doit être VLAN-aware. - Placez les VM clientes sur un bridge ou un VLAN **séparé de l'adresse de gestion du nœud**. S'ils partagent le même réseau, l'IP set de gestion automatique du pare-feu Proxmox ouvre les ports 22, 8006, 3128, 5900-5999 et 60000-60050 du nœud à toutes les VM de ce réseau. Si vous ne pouvez pas les séparer, ajoutez au-dessus de la règle ACCEPT de gestion une règle DROP explicite pour le sous-réseau des VM vers ces ports. ### 3. Remarques sur le stockage (LVM-thin) {#_3-storage-notes-lvm-thin} - Laissez le **zeroing du thin-pool sur sa valeur par défaut**. Le désactiver (`lvchange -Zn`) peut laisser d'anciennes données dans les blocs nouvellement alloués et corrompre les tables de partition ou les systèmes de fichiers des VM clonées. - Les disques qui indiquent "write cache: disabled" peuvent cloner à seulement quelques Mo/s. Vérifiez avec `hdparm -W /dev/sdX` et activez le cache d'écriture si le disque dispose d'une protection contre les coupures de courant. ### 4. Activer le contenu `import` (uniquement pour le créateur de modèles intégré) {#_4-enable-the-import-content-only-for-the-built-in-template-builder} Le générateur intégré télécharge l'image cloud dans le stockage nommé `local` et crée le modèle à partir de celle-ci. Ajoutez `import` (et `snippets`) à la liste des contenus de ce stockage. Conservez les types que vous utilisez déjà; `--content` remplace la liste entière: ```bash pvesm status --storage local # note the current content pvesm set local --content iso,vztmpl,backup,import,snippets ``` ### 5. Créer un modèle d'OS à partir d'une image cloud {#_5-build-an-os-template-from-a-cloud-image} Un modèle est une VM cloud-init que NexCMP clone. Chacun est enregistré sous une **OS key** courte telle que `ubuntu-24.04` avec son id de VM. Créez un modèle par OS **sur chaque nœud destiné à recevoir des VM**, car le clone s'exécute sur le nœud sélectionné. **Option A, recommandée: construisez-le vous-même.** Les images cloud Ubuntu et Debian standard ne contiennent pas le guest agent et n'autorisent pas la connexion root, or NexCMP définit le mot de passe root via cloud-init. Préparez d'abord l'image: ```bash apt install -y libguestfs-tools wget -O noble.qcow2 https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img virt-customize -a noble.qcow2 --install qemu-guest-agent \ --write /etc/cloud/cloud.cfg.d/99-nexcmp.cfg:$'ssh_pwauth: true\ndisable_root: false\n' \ --write /etc/ssh/sshd_config.d/00-nexcmp.conf:$'PermitRootLogin yes\nPasswordAuthentication yes\n' ``` Créez ensuite la VM modèle (l'id 9000 est un exemple; conservez les id de modèles sous la valeur `vmid from`, par défaut 1000): ```bash qm create 9000 --name tpl-ubuntu-24-04 --memory 2048 --cores 2 --cpu host --ostype l26 \ --scsihw virtio-scsi-single --net0 virtio,bridge=vmbr0 --agent 1 --serial0 socket --vga serial0 qm set 9000 --scsi0 local-lvm:0,import-from=$PWD/noble.qcow2,discard=on,iothread=1 qm set 9000 --ide2 local-lvm:cloudinit --boot order=scsi0 qm template 9000 ``` **Option B : le générateur intégré.** La carte **Create OS template from cloud image** de l'onglet Clusters (voir plus bas) télécharge une image qcow2, génère le template et l'enregistre. Elle crée la VM avec cloud-init et le flag du guest agent, mais ne modifie pas le contenu de l'image. Utilisez-la uniquement avec une image autorisant déjà la connexion root et exécutant le guest agent, ou si vous fournissez également un extrait vendor-data cloud-init. Le guest agent est requis pour **Reset password** et pour afficher l'adresse IP de la VM. ### 6. Connaître l'empreinte du certificat (optionnel) {#_6-know-the-certificate-fingerprint-optional} NexCMP fait confiance au cluster en épinglant l'empreinte SHA-256 de son certificat TLS, un certificat auto-signé convient donc parfaitement. Pour voir la valeur que NexCMP va épingler : ```bash openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -fingerprint -sha256 ``` ## Connecter dans NexCMP {#connect-in-nexcmp} 1. Ouvrez **Infrastructure › Cloud provider › Providers** et cliquez sur **Add cloud provider**. Choisissez **Proxmox VE** et renseignez : | Champ | Exemple de valeur | |---|---| | Name | `Proxmox cluster 1` | | Endpoint | `https://192.0.2.10:8006` | | Token id | `nexcmp@pve!api` | | Token secret | `XXXX` (l'UUID affiché à l'étape 1) | | Slug | `pve-1` (a-z, 0-9, tiret, 2-32 caractères) | | Default node | `pve1` (vide : le nœud en ligne disposant de la plus grande RAM libre) | | Stockage | `local-lvm` | | Bridge | `vmbr0` | ![Boîte de dialogue Ajouter un fournisseur de cloud avec Proxmox VE sélectionné et des exemples de valeurs pour l'endpoint, le jeton et le stockage](https://nexcmp.com/fr/docs/images/infrastructure/proxmox-01-add-provider.webp) 2. Cliquez sur **Save & open provider**, puis saisissez un motif lorsque vous y êtes invité. Le jeton est chiffré avant d'être stocké. 3. Sous l'onglet **Overview**, cliquez sur **Test connection**. Le premier test réussi **épingle l'empreinte TLS du cluster** ; par la suite, tout certificat différent sera refusé. 4. Ouvrez l'onglet **Clusters**. La carte **Node · storage · bridge** indique ce que l'API détecte, tandis que la carte **Cluster configuration** regroupe les paramètres : | Champ | Description | |---|---| | Default node | Nœud utilisé pour les nouvelles VM. Vide signifie le nœud en ligne disposant de la plus grande RAM libre. | | Storage, Bridge, VLAN | Stockage disque, pont réseau (NIC bridge) et balise VLAN facultative (0 signifie aucun). | | CPU type | `host` par défaut. Utilisez `x86-64-v2-AES` lorsque les nœuds possèdent différentes générations de processeurs. | | vmid from | Premier ID de VM attribué aux VM des clients (1000 par défaut). | | Storage ISO, Storage backup | Laissez vide sauf si vous les utilisez ; vide signifie que les fonctionnalités ISO et de sauvegarde ne sont pas proposées. | | Template OS | Un par ligne, `os-key=vmid`, par exemple `ubuntu-24.04=9000`. | | Pinned TLS fingerprint (SHA-256) | Renseigné par le premier test. Effacez-le et effectuez un nouveau test après avoir remplacé le certificat du cluster. | ![Onglet Clusters, carte de configuration du cluster avec des exemples de nœud, de stockage, de pont et de liste de modèles d'OS](https://nexcmp.com/fr/docs/images/infrastructure/proxmox-03-cluster-config.webp) 5. Facultatif : si vous avez utilisé l'option B ci-dessus, renseignez **Create OS template from cloud image** (clé d'OS `ubuntu-24.04`, vmid `9000`, nœud `pve1`, URL de l'image qcow2) et cliquez sur **Create template**. L'opération s'exécute en arrière-plan pendant quelques minutes ; le résultat se trouve dans le journal d'audit. ![Carte de création de modèle d'OS à partir d'une image cloud avec un exemple d'URL d'image Ubuntu](https://nexcmp.com/fr/docs/images/infrastructure/proxmox-04-template-from-image.webp) 6. Cliquez sur **Add pool** dans **Cluster IP pool** et créez le pool dans lequel les VM piocheront leurs adresses : | Champ | Exemple de valeur | |---|---| | Name | `customers-1` | | CIDR | `198.51.100.0/24` | | Gateway | `198.51.100.1` (jamais attribué à une VM) | | DNS | `1.1.1.1,8.8.8.8` (1 à 4 adresses IPv4) | | Bridge, VLAN | `vmbr0`, `0` | | Already used IPs | un par ligne, `ip note`, par exemple `198.51.100.10 monitoring` | NexCMP n'attribue jamais l'adresse réseau, l'adresse de diffusion (broadcast), la passerelle ou une adresse réservée. Les pools d'un même cluster ne peuvent pas se chevaucher. Un pool ne peut être supprimé que lorsqu'aucune de ses adresses n'est utilisée. ![Boîte de dialogue d'ajout de pool d'IP avec un exemple de /24 et de passerelle](https://nexcmp.com/fr/docs/images/infrastructure/proxmox-05-ip-pool.webp) 7. Dans **Attach cluster to zone**, choisissez la zone et, facultativement, un nom de nœud, puis cliquez sur **Attach to zone**. Le cluster rejoint la zone qui propose déjà des VM, ce qui permet à une même zone de regrouper CloudStack et Proxmox. La nouvelle source n'est **pas vendue par défaut** et ne modifie pas le comportement des offres existantes. ![Carte d'association du cluster à la zone avec une zone existante sélectionnée](https://nexcmp.com/fr/docs/images/infrastructure/proxmox-06-attach-zone.webp) 8. Ouvrez **Services › Virtual Machines › Plans & pricing** et cliquez sur **Add plan**. Dans **Infrastructure source**, choisissez le cluster Proxmox, puis définissez le processeur, la RAM, le disque et le prix. Un plan Proxmox ne requiert aucune offre CloudStack. Pour vendre la même configuration à partir des deux sources, utilisez **Clone** sur un plan et sélectionnez l'autre source. Le disque du plan doit être au moins aussi grand que celui du modèle ; Proxmox ne peut pas réduire la taille d'un disque. ### Importer une VM existante {#import-a-vm-that-already-exists} Ouvrez l'onglet **Servers** pour lister les VM du cluster. **Import** assigne une VM existante à un compte client sans frais : rien n'est facturé pour les heures, le temps d'arrêt ou le trafic. Le client peut démarrer, arrêter, redémarrer et ouvrir la console mais ne peut pas la supprimer ; seul un administrateur le peut. NexCMP effectue uniquement des lectures sur le cluster lors de l'importation. - Le cluster doit être rattaché à une zone **avec le nom de nœud** de cette VM (laissez le nœud vide et les importations indiqueront que la région n'est pas configurée). - Pour rendre une VM **protégée** (l'arrêt, le redémarrage, la réinstallation, la restauration de snapshot, la destruction et le changement de forfait sont refusés), importez-la en ligne de commande avec `--protect` : ```bash sudo -u nexcmp /opt/nexcmp/bin/nexcmp px-import --provider pve-1 --server-ref pve1/101 --account-id 12 --hostname web-1 --protect ``` ### Ce qui est pris en charge ou non sur Proxmox {#what-is-and-is-not-supported-on-proxmox} | Fonctionnalité | Proxmox VE | |---|---| | Création, mise sous/hors tension, redémarrage, suppression | Oui | | Redimensionnement du CPU et de la RAM, extension du disque | Oui, mais la VM est arrêtée, modifiée puis redémarrée (pas de redimensionnement à chaud) | | Snapshots | Oui, jusqu'à 5 par VM : création, liste, restauration, suppression | | Réinstallation | Oui : la VM est reconstruite à partir du modèle et conserve son identifiant, son IP et ses paramètres, avec un nouveau mot de passe | | Réinitialisation du mot de passe | Oui, via l'agent invité | | Console | Oui, une console de navigateur transmise par proxy via le panneau | | Métriques | Oui : CPU, mémoire, réseau et disque | | Montage ISO, sauvegardes, pare-feu, IPv6, redirection de port, changement d'IP, volumes supplémentaires, Auto Scaling, DDoS Shield, VPC, mesure de la bande passante | Non disponible. La page de la VM du client masque ce qu'une source ne peut pas faire. | ## Vérification {#verify} 1. **Test connection** indique OK et le statut du fournisseur est actif. 2. **Clusters** liste vos nœuds comme étant en ligne, avec le stockage et le bridge. 3. **Cluster IP pool** affiche les comptes d'adresses libres, utilisées et réservées. 4. La clé OS apparaît sous les modèles de la zone dans **Services › Virtual Machines › Template** après le rattachement du cluster. 5. Commandez une VM de test à partir d'un forfait qui utilise le cluster. Elle doit obtenir une adresse du pool, un mot de passe root et une console fonctionnelle ; le pool indique une adresse utilisée. ## Limites et remarques {#limits-and-notes} ::: tip Zones à sources mixtes Depuis NexCMP 1.4.0, la grille tarifaire publique Cloud Server fonctionne aussi lorsque CloudStack et Proxmox VE partagent une zone. Chaque plan utilise sa propre **Infrastructure source**. Après avoir rattaché un cluster, vérifiez la grille tarifaire publique et passez une commande de test pour chaque source. ::: - Plusieurs clusters Proxmox peuvent être ajoutés. Chacun constitue un fournisseur. - Une zone propose une source par défaut ; un forfait doté de sa propre **Infrastructure source** est déployé exactement sur ce cluster, à condition que le cluster soit actif et dans la zone du forfait. - Un cluster situé derrière la même zone que CloudStack conserve ses forfaits hérités sur CloudStack. Testez une commande de bout en bout avant le lancement. - Le jeton API peut uniquement être remplacé, jamais visualisé. Remplacez-le dans l'onglet **Credentials** : créez d'abord le nouveau jeton dans Proxmox, saisissez-le, exécutez **Test connection**, puis révoquez l'ancien jeton. - Les actions Test, Sync et cluster-info sont limitées à six appels par minute et par administrateur. - NexCMP facture vos clients ; le coût du matériel et des licences du cluster reste à votre charge. ## Dépannage {#troubleshooting} | Symptôme | Cause | Solution | |---|---|---| | Test : "Key rejected (wrong access key / secret, or revoked)" ou HTTP 401/403 | Mauvais ID de jeton ou secret, ou l'ACL a été attribuée uniquement au jeton | Relancez les deux commandes `pveum acl modify` (utilisateur **et** jeton) et vérifiez que l'id du jeton est `user@realm!tokenid`. | | Test : "Could not connect to the provider" ou "Timed out" | Pare-feu, hôte ou port incorrect | Vérifiez `https://host:8006` depuis le serveur du panneau. | | Test : "Invalid endpoint or not on the allowlist" | L'endpoint comporte un chemin, un utilisateur, une requête ou n'est pas en HTTPS | Utilisez exactement `https://host:8006`. | | "le certificat TLS du cluster NE CORRESPOND PAS à l'empreinte épinglée" | Le certificat du cluster a été remplacé | Effacez **Pinned TLS fingerprint** dans l'onglet Clusters, enregistrez, puis relancez **Test connection**. | | Slug rejeté | Caractères non autorisés (a-z, 0-9, tiret) ou longueur différente de 2-32 caractères | Utilisez quelque chose comme `pve-1`. | | "Format du Token id : user@realm!tokenid et le secret est requis" | Identifiant de jeton ou secret manquant | Saisissez les deux ; le secret est l'UUID affiché lors de la création du jeton. | | "Ligne de modèle invalide : …" | Une ligne dans **Template OS** n'est pas `key=vmid` | Utilisez des lettres, chiffres, `.`, `_`, `-` dans la clé et un vmid d'au moins 100. | | "Clé OS : a-z 0-9 . _ - et vmid ≥ 100" | Clé ou id invalide dans **Create template** | Corrigez la clé OS et utilisez un vmid libre. | | "vmid … already exists" lors de la création d'un modèle | Le vmid est déjà utilisé | Choisissez un autre id. | | "l'URL pointe vers une adresse interne" | L'URL de l'image est une IP interne | Utilisez une URL publique ; les noms sont résolus par Proxmox. | | La tâche du modèle échoue au téléchargement | Le stockage `local` n'a pas de contenu `import` | `pvesm set local --content …,import,snippets`, puis réessayez. Un nom de fichier doit se terminer par `.qcow2`, `.raw`, `.vmdk`, `.ova` ou `.ovf`. | | "cluster has no online nodes" ou "node … is not online" | Le nœud par défaut est arrêté ou mal orthographié | Corrigez **Default node** ou laissez-le vide. | | "l'image n'appartient pas au cluster" | L'OS du plan ne figure pas dans **Template OS** | Ajoutez la clé à la liste et enregistrez. | | Le déploiement patiente, puis échoue lors du clonage | La machine virtuelle modèle ne se trouve pas sur le nœud choisi | Créez le modèle sur ce nœud, ou définissez **Default node** sur le nœud qui l'héberge. | | Le client ne peut pas se connecter en tant que root | L'image bloque la connexion root | Reconstruisez le modèle comme indiqué dans l'Option A. | | La réinitialisation du mot de passe n'a aucun effet | Aucun agent invité n'est installé dans la machine virtuelle | Installer et activer `qemu-guest-agent` dans le modèle. | | "Nom, CIDR et passerelle requis" | Champ de pool manquant | Remplir les trois. | | Pool create: "overlaps with pool …", "gateway must be within range (not network/broadcast address)" ou "cidr: network address must be …" | Pool en chevauchement, passerelle erronée ou CIDR ne se trouvant pas sur une limite de réseau | Utiliser une plage libre, une passerelle à l'intérieur de celle-ci et un CIDR écrit sous forme d'adresse réseau (par exemple `198.51.100.0/24`). | | Importation : "la région n'est pas configurée" | Le cluster est rattaché sans le nom du nœud de la VM | Rattacher le cluster à la zone avec le nom du nœud. |