Installer PegaProx sur un serveur dédié : gérer plusieurs clusters Proxmox depuis un seul tableau de bord

PegaProx : plusieurs clusters Proxmox VE dans un seul tableau de bord

PegaProx est une console de gestion multi-cluster open source pour Proxmox VE : une seule interface web pour administrer plusieurs clusters Proxmox, des nœuds isolés, des serveurs Proxmox Backup Server et, en préversion technique, des pools XCP-ng. Le projet est publié sur GitHub sous licence AGPL-3.0 ; la version 1.4.1, sortie le 24 octobre 2026, est une version de sécurité et de correctifs qui suit la 1.4.0 ; la 1.0 du 1er août 2026 avait clos la phase bêta ouverte en septembre 2025. Il prend en charge Proxmox VE 8.0 et 9.0 ou plus récents, et XCP-ng 8.2 ou plus récent.

Là où l'interface native de Proxmox VE ne montre qu'un cluster à la fois, PegaProx ajoute ce qui manque quand on gère un parc : tableau de bord unifié avec métriques CPU, RAM et stockage en temps réel, migration à chaud entre nœuds et entre clusters, équilibrage de charge prédictif, assistant de migration depuis VMware ESXi, gestion de PBS avec vérification des sauvegardes, supervision Ceph, contrôle d'accès par rôles (RBAC), double authentification TOTP ou WebAuthn, authentification LDAP et OIDC (Entra ID, Keycloak, Google Workspace, Authentik), et un exporteur Prometheus. Le tout sans agent sur les hyperviseurs : PegaProx parle à l'API Proxmox sur le port 8006 et, pour certaines opérations, en SSH aux nœuds.

Pour l'administrateur d'un ou plusieurs serveurs dédiés sous Proxmox VE, ce guide couvre l'installation sur une machine Linux à part via le dépôt APT Debian ou Docker Compose, la création d'un compte Proxmox à droits limités plutôt que l'accès root que la documentation propose par défaut, la mise en HTTPS derrière un reverse proxy, le raccordement de plusieurs clusters et de PBS, puis deux cas d'usage concrets : un serveur dédié de production plus un second de secours, et plusieurs serveurs dédiés gérés comme un seul parc.

Prérequis : une petite VM Linux, Python 3.10 à 3.13 et les ports 8006, 8007 et 22

PegaProx est une application Python qui tourne sur une machine Linux séparée des hyperviseurs. La documentation dimensionne par nombre de clusters gérés, et la plus petite configuration couvre déjà jusqu'à cinq clusters, soit bien plus qu'un parc de quelques serveurs dédiés :

Le disque grossit avec l'historique des métriques ; la 1.4.1 l'a justement réorganisé par cluster pour que les pages d'historique restent rapides avec plusieurs milliers d'invités. Le reste de la liste :

• Système : Debian ou Ubuntu recommandés (le script d'installation est testé sur Debian 12 et 13 et Ubuntu 22.04 et 24.04 LTS), RHEL et Rocky fonctionnent aussi. Le paquet Debian n'existe que pour Debian 13 « trixie » ;
• Python : 3.10 à 3.13, 3.12 recommandé. L'installeur refuse les versions plus anciennes et avertit sur 3.14. Sans importance avec Docker, l'image embarque son interpréteur ;
• Ports entrants : 5000 (interface web, API et événements), 5001 (console VNC noVNC) et 5002 (shell xterm.js), tous en HTTPS. Le port 1514 (serveur syslog intégré, UDP et TCP) est ouvert par défaut et sans authentification : limitez-le aux nœuds qui envoient leurs journaux ou coupez-le dans « Settings → Syslog » ;
• Ports sortants : 8006 vers chaque nœud Proxmox VE, 8007 vers chaque PBS, 22 vers les nœuds pour le shell et les transferts de fichiers, 443 et 22 vers un hôte ESXi à migrer ;
• Proxmox : PVE 8.0 ou 9.0 et plus. Un hôte encore en 8 reste pilotable, mais notre guide migrer Proxmox VE 8 vers 9 décrit le passage à la version actuelle ;
• Un compte ou un token Proxmox par cluster, détaillé plus bas.

Où installer PegaProx : VPS, VM sur un second dédié ou conteneur

La règle est la même que pour toute console de gestion : ne l'hébergez pas sur l'hyperviseur qu'elle administre, sinon vous perdez la vue d'ensemble précisément quand un nœud tombe. Trois emplacements tiennent la route :

• Un petit VPS Linux séparé, hébergé en France comme vos serveurs dédiés. L'offre Starter (2 vCPU, 4 Go de RAM, 50 Go SSD) dépasse le profil « 1 à 5 clusters » ; l'offre Classic (4 vCPU, 8 Go, 70 Go SSD) correspond à la base recommandée en production ;
• Une VM Debian 13 sur un second serveur dédié, quand vous en gérez plusieurs : chaque hôte surveille l'autre, et PegaProx peut lui-même tourner en haute disponibilité avec une instance de secours ;
• Un conteneur LXC ou Docker sur l'hôte Proxmox, acceptable pour un lab ou un serveur unique, en gardant l'interface Proxmox native comme secours.

Entre un VPS et des serveurs dédiés distants, faites passer les ports 8006, 8007 et 22 par un tunnel Tailscale ou WireGuard plutôt que d'exposer l'API Proxmox sur Internet. Un détail à connaître : depuis la 1.4.0, PegaProx refuse les adresses du bloc 100.64.0.0/10 (CGNAT, donc aussi les adresses Tailscale) partout où il refuse déjà les adresses privées : webhooks d'alerte, téléchargement d'ISO depuis une URL, fournisseur OIDC (sauf à cocher « Internal IdP / Private Network » dans ses réglages). PBS et ESXi acceptent les adresses privées ; pour les nœuds Proxmox, lancez « Check connection » avant de compter sur une adresse du tunnel. Gardez enfin la console hors du budget de RAM de l'hyperviseur, comme expliqué dans dimensionner Proxmox VE sur un serveur dédié.

Installer PegaProx par le dépôt APT Debian (recommandé en production)

Le README propose quatre voies : un script deploy.sh qui suit la branche principale et peut donc embarquer des changements non encore testés, un dépôt APT Debian maintenu par un contributeur du projet (gyptazy) et recommandé par le README pour la production, une image Docker, et l'installation depuis les sources. Sur un serveur de production, le paquet Debian a trois avantages : une version figée et signée, des mises à jour par apt upgrade avec le reste du système, et un service systemd prêt. Sur Debian 13 « trixie », en root :

curl -fsSL https://git.gyptazy.com/api/packages/gyptazy/debian/repository.key -o /etc/apt/keyrings/gyptazy.asc
echo "deb [signed-by=/etc/apt/keyrings/gyptazy.asc] https://packages.gyptazy.com/api/packages/gyptazy/debian trixie main" | tee /etc/apt/sources.list.d/gyptazy.list
apt-get update
apt-get -y install pegaprox

Le dépôt ne publie que la distribution trixie. Sur un VPS encore en Debian 12, notre guide migrer de Debian 12 vers Debian 13 précède donc l'installation ; sur Ubuntu, passez par Docker ou par le script. Le paquet, maintenu par Florian Paul Azim Hoberg (gyptazy), s'appuie sur les modules Python de Debian (python3-flask, python3-paramiko, python3-requests...), crée un utilisateur système pegaprox sans shell, range l'état de l'application (base de données chiffrée, plugins) dans /var/lib/pegaprox en mode 750, et active pegaprox.service. La clé maîtresse qui protège la base est lue depuis PEGAPROX_KEY_FILE, puis /etc/pegaprox/secret.key ; elle n'est pas récupérable, sauvegardez-la. Les commandes habituelles s'appliquent :

systemctl status pegaprox
journalctl -u pegaprox -f
systemctl restart pegaprox

Si vous préférez le script, lisez-le avant de l'exécuter : il installe dans /opt/PegaProx avec un environnement virtuel Python dans /opt/PegaProx/venv, crée le même utilisateur et le même service, génère la clé dans /etc/pegaprox/secret.key, et accepte --port=443 (sans root grâce à la capacité CAP_NET_BIND_SERVICE posée sur l'interpréteur) et --no-interactive :

curl -O https://raw.githubusercontent.com/PegaProx/project-pegaprox/refs/heads/main/deploy.sh
less deploy.sh
chmod +x deploy.sh
sudo ./deploy.sh

Dans les deux cas, ouvrez https://ip-du-serveur:5000. Le certificat auto-signé généré au premier démarrage déclenche un avertissement du navigateur, et il faut l'accepter séparément sur les ports 5000, 5001 et 5002, sinon les consoles VNC et shell restent noires. Il n'y a aucun identifiant par défaut : un assistant crée le premier administrateur (nom, mot de passe évalué par un indicateur de robustesse, e-mail) et propose d'activer la double authentification tout de suite. Acceptez.

Installer PegaProx avec Docker Compose

L'image officielle ghcr.io/pegaprox/pegaprox (aussi sur Docker Hub en pegaprox/pegaprox) existe en amd64, arm64 et, depuis la 1.3, arm/v7. Le fichier docker-compose.yml du dépôt publie les ports 5000, 5001 et 5002, persiste deux volumes nommés (pegaprox-config monté sur /app/config et pegaprox-logs sur /app/logs) et redémarre le conteneur sauf arrêt volontaire. Une version minimale équivalente, dans un répertoire /opt/pegaprox :

services:
  pegaprox:
    image: ghcr.io/pegaprox/pegaprox:${PEGAPROX_VERSION:-latest}
    container_name: pegaprox
    ports:
      - "5000:5000"
      - "5001:5001"
      - "5002:5002"
    volumes:
      - pegaprox-config:/app/config
      - pegaprox-logs:/app/logs
    restart: unless-stopped

volumes:
  pegaprox-config:
  pegaprox-logs:

cd /opt/pegaprox
PEGAPROX_VERSION=1.4.1 docker compose up -d
docker compose logs -f

La variable PEGAPROX_VERSION fige la version ; la documentation accepte aussi un condensé (1.4.1@sha256:...) pour l'épinglage le plus strict, et les images de version portent une provenance de construction signée. En production, figez toujours la version plutôt que latest, et sauvegardez le volume pegaprox-config : il contient la base de données, les certificats et les identifiants chiffrés de vos clusters. Le même fichier Compose accepte, en commentaire, un service pegaprox-witness (port 5005) qui sert de troisième vote à un groupe de haute disponibilité PegaProx et doit tourner sur un site distinct. Si Docker est nouveau pour vous, installer Docker sur un serveur Linux et Docker Compose sur VPS Linux couvrent la mise en place.

Créer un compte Proxmox à droits limités plutôt que root@pam

La documentation de démarrage rapide recommande de connecter chaque cluster avec root@pam et son mot de passe, parce que quelques fonctions exigent root. C'est la voie la plus rapide, et la page consacrée aux permissions dit elle-même qu'elle n'est pas recommandée en production : un mot de passe root stocké dans une application web, c'est tout le parc compromis si la console l'est. Deux points de fonctionnement à comprendre avant de choisir :

• quand vous donnez à PegaProx un compte et un mot de passe, il crée lui-même un token API à la première connexion et garde le mot de passe pour ce qu'un token ne sait pas faire. Avec root@pam, ce token hérite de tous les droits ;
• quand vous saisissez un token API (identifiant pegaprox@pve!pegaprox dans le champ utilisateur, secret dans le champ mot de passe), PegaProx n'a que les droits du token. Les terminaux texte xterm.js des invités et la migration inter-clusters, la réplication et la reprise de site vers ce cluster exigent une connexion par mot de passe, pas un token saisi à la main.

Le bon compromis pour un parc de serveurs dédiés est donc un compte de service dédié pegaprox@pve avec un rôle personnalisé, connecté par mot de passe : PegaProx génère son propre token sous ce compte, borné par le rôle, et la migration inter-clusters reste possible. La documentation fournit la liste de privilèges pour toutes les fonctions optionnelles ; sur n'importe quel nœud du cluster, en root, pour Proxmox VE 9 :

pveum role add PegaProx --privs "Sys.Audit,VM.Audit,VM.PowerMgmt,VM.Migrate,VM.Console,VM.Snapshot,VM.Snapshot.Rollback,VM.Backup,VM.Allocate,VM.Clone,VM.Config.CPU,VM.Config.Memory,VM.Config.Disk,VM.Config.Network,VM.Config.Options,VM.Config.CDROM,VM.Config.HWType,VM.Config.Cloudinit,VM.GuestAgent.Audit,Datastore.Audit,Datastore.AllocateSpace,Datastore.AllocateTemplate,VM.Replicate,SDN.Use,Pool.Audit,Mapping.Audit,Mapping.Use,Sys.PowerMgmt,Sys.Modify,Sys.Syslog,Sys.Console,SDN.Audit"
pveum user add pegaprox@pve --comment "PegaProx"
pveum passwd pegaprox@pve
pveum aclmod / --users pegaprox@pve --roles PegaProx

Sur Proxmox VE 8, remplacez VM.GuestAgent.Audit par VM.Monitor. Si le rôle existe déjà, pveum role modify PegaProx --privs "..." remplace la liste. Depuis la 1.4.0, le rôle prêt à copier s'affiche aussi dans « Add Cluster » et dans « Check connection ». Pour une console en lecture et en actions courantes sans pouvoir créer ni détruire, retirez de la liste VM.Allocate, VM.Clone, Sys.Modify et Sys.PowerMgmt : les privilèges se lisent fonction par fonction.

Si vous préférez un token saisi à la main, à séparation de privilèges activée (le réglage par défaut de Proxmox), posez l'ACL sur le token lui-même, sinon il ne voit rien :

pveum user add pegaprox@pve --comment "PegaProx"
pveum user token add pegaprox@pve pegaprox --privsep 1 --comment "PegaProx"
pveum aclmod / --tokens 'pegaprox@pve!pegaprox' --roles PegaProx

Le secret du token s'affiche une seule fois. Trois limites restent, quel que soit le compte : le passthrough PCI et USB brut, la plupart des options de conteneurs LXC et la création ou la suppression d'OSD Ceph exigent le mot de passe de root@pam, aucun token ne les autorise, pas même celui de root. Et les fonctions qui passent par SSH (shell du nœud, mises à jour, scripts, contrôles de durcissement, migration ESXi) demandent une clé SSH dans les réglages du cluster ou des mots de passe par nœud ; pour un utilisateur SSH non root, PegaProx exécute sudo -n bash, donc une règle sudoers limitée à quelques commandes échoue. Si root en SSH n'est pas acceptable chez vous, n'indiquez aucun identifiant SSH : les fonctions API continuent de marcher et « Check connection » liste celles qui manquent. Un compte par cluster, jamais partagé avec Pulse ou un autre outil : un compte compromis se désactive sans toucher aux autres intégrations.

Raccorder plusieurs clusters Proxmox VE et un PBS

Dans PegaProx, « Settings → Clusters → Add Cluster ». Indiquez un nom, l'adresse d'un nœud et le port 8006, puis pegaprox@pve et son mot de passe (ou l'identifiant et le secret du token). Une seule entrée suffit par cluster : à la première connexion, PegaProx relève tous les nœuds en ligne comme hôtes de repli et bascule vers eux si le nœud d'entrée ne répond plus. Répétez pour chaque cluster ou serveur isolé : un dédié de production en Proxmox VE 9 et un serveur de lab encore en 8 cohabitent dans la même liste.

Lancez ensuite « Check connection » sur chaque cluster : disponible depuis la 1.3, il teste en lecture seule l'API, les hôtes de repli, l'empreinte TLS et les privilèges du token, et nomme une correction pour chaque échec. Vérifiez que le tableau de bord affiche le bon nombre de nœuds et d'invités : un test réussi prouve l'authentification, pas la visibilité de chaque ressource. Les clusters se rangent ensuite en groupes hiérarchiques, chacun avec sa propre politique d'équilibrage, de réplication et de bascule, et un locataire (tenant) peut être limité à un groupe.

Pour Proxmox Backup Server, même logique dans la section PBS : adresse sur le port 8007, et, depuis la 1.3, un token API plutôt qu'un mot de passe. L'empreinte du certificat PBS, une fois enregistrée, fait refuser toute connexion dont le certificat ne correspond pas, y compris dans le contrôle préalable du stockage. Chaque PBS est lié aux clusters autorisés à l'utiliser ; PegaProx parcourt les sauvegardes, restaure des fichiers isolés ou des invités entiers, planifie les tâches, lance les vérifications (recalcul des sommes de contrôle des blocs) et, depuis la 1.4.0, des tests de restauration. Les tests de restauration restent la seule preuve qu'une sauvegarde sert à quelque chose, et ici ils se planifient depuis la console.

Mettre PegaProx derrière un reverse proxy HTTPS

PegaProx sait porter lui-même un certificat Let's Encrypt : « Settings → Server → SSL Certificates → ACME », domaine pointant vers le serveur, défi HTTP-01 sur le port 80 ou DNS-01 (RFC 2136) quand le port 80 n'est pas joignable, renouvellement automatique 30 jours avant expiration. Si vous centralisez déjà vos certificats sur un reverse proxy Nginx, activez « Settings → Server → Behind Reverse Proxy » : PegaProx coupe son TLS interne et n'écoute plus que sur 127.0.0.1. En conteneur, posez en plus PEGAPROX_BEHIND_PROXY=true dans l'environnement Compose, sinon le contrôle de santé sonde le mauvais protocole et les journaux se remplissent d'erreurs TLS. Le fichier examples/nginx.conf du dépôt sert de base ; les points qui comptent :

map $http_upgrade $connection_upgrade { default upgrade; '' close; }

upstream pegaprox_app { server 127.0.0.1:5000; }
upstream pegaprox_vnc { server 127.0.0.1:5001; }
upstream pegaprox_ssh { server 127.0.0.1:5002; }

server {
    listen 443 ssl;
    http2 on;
    server_name pegaprox.example.com;
    # ssl_certificate / ssl_certificate_key ...
    ssl_protocols TLSv1.2 TLSv1.3;
    client_max_body_size 100g;
    proxy_read_timeout 3600;
    proxy_send_timeout 3600;

    location /api/sse/ {
        proxy_pass http://pegaprox_app;
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding off;
        proxy_read_timeout 86400;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    location ~ ^/api/clusters/.*/vncwebsocket {
        proxy_pass http://pegaprox_vnc;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_read_timeout 3600;
    }
    location ~ ^/api/clusters/.*/(shellws|termwebsocket) {
        proxy_pass http://pegaprox_ssh;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_read_timeout 3600;
    }
    location / {
        proxy_pass http://pegaprox_app;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Trois pièges documentés. Le flux /api/sse/ (événements temps réel) ne supporte pas la mise en tampon : sans proxy_buffering off, le tableau de bord ne se rafraîchit plus. Les WebSockets des consoles passent par 5001 (noVNC) et 5002 (shell des nœuds shellws et terminal des invités termwebsocket), toujours « port principal plus 1 » et « plus 2 » : si vous changez le port 5000, décalez les deux autres dans chaque bloc. Et PegaProx ne fait confiance à X-Forwarded-For que depuis la boucle locale : si Nginx tourne sur une autre machine, ajoutez son adresse ou son sous-réseau dans « Settings → Server → Trusted Proxies » (ou PEGAPROX_TRUSTED_PROXIES), jamais 0.0.0.0, qui ferait confiance à tout le monde. Un client_max_body_size trop bas renvoie une erreur 413 à l'envoi d'une ISO. Restreignez ensuite le port 443 à vos adresses d'administration ou à votre VPN avec un pare-feu nftables : une console qui détient les identifiants de tous vos hyperviseurs n'a rien à faire ouverte à tout Internet.

Exporteur Prometheus, RBAC, 2FA et OIDC

L'exporteur expose GET /api/metrics au format OpenMetrics. Créez un token dans « Settings → API Tokens » pour un compte dont le rôle contient la permission metrics.view (depuis la 1.3, plus besoin d'un administrateur), puis déclarez la cible dans Prometheus :

scrape_configs:
  - job_name: pegaprox
    metrics_path: /api/metrics
    scheme: https
    bearer_token: 'votre_token_pegaprox'
    tls_config:
      insecure_skip_verify: false
    static_configs:
      - targets: ['pegaprox.example.com:5000']

Les métriques couvrent le cluster (pegaprox_cluster_quorum_held, pegaprox_cluster_nodes_online), les nœuds (pegaprox_node_cpu_percent, pegaprox_node_apt_updates_available), les invités (pegaprox_guest_mem_percent, pegaprox_guest_last_backup_age_seconds), le stockage, la réplication, Ceph (pegaprox_ceph_health_status, pegaprox_ceph_osd_up) et les intégrations (pegaprox_pbs_connected). Un tableau de bord Grafana de référence est fourni dans le dépôt (misc/grafana/pegaprox-overview.json, Grafana 10 ou plus récent) ; notre guide Grafana et Prometheus sur VPS Linux couvre la pile elle-même. L'exporteur n'est pas cloisonné par locataire : réservez metrics.view aux comptes de supervision autorisés à voir toute l'installation.

Côté accès, PegaProx distingue trois rôles intégrés (Admin, Operator, Viewer) et des rôles personnalisés, applique le contrôle côté serveur et sait cloisonner des locataires sur des pools, des invités ou des groupes de clusters, avec une plage de VMID par locataire. La double authentification est TOTP ou WebAuthn/FIDO2, et peut être rendue obligatoire ; l'authentification externe accepte LDAP et OIDC (Entra ID, Keycloak, Google Workspace, Authentik, avec PKCE). Si vous avez déjà un Keycloak pour vos autres outils, c'est l'endroit où le brancher. Les mots de passe sont hachés en Argon2id, les tokens API stockés en SHA-256, la base chiffrée avec SQLCipher sur Linux x86_64 et les champs sensibles chiffrés individuellement en Fernet ; le projet le dit lui-même, un hôte PegaProx compromis peut lire la base, d'où l'importance de l'isoler et de sauvegarder la clé /etc/pegaprox/secret.key hors du répertoire config/, car elle n'est pas récupérable.

Équilibrage de charge prédictif et migration inter-clusters

L'équilibrage prédictif, qui s'appuie sur le projet ProxLB, est désactivé par défaut et s'active par cluster dans « Cluster Settings → Options ». PegaProx garde 288 points de mesure CPU, RAM et disque par nœud (environ 24 heures à 5 minutes), calcule une tendance par moyenne mobile pondérée et déclenche une migration quand le score d'un nœud dépasse le seuil (75 par défaut, réglable de 50 à 95) avec une confiance d'au moins 60 %. La cible est le nœud le moins chargé qui respecte les règles d'affinité, la compatibilité CPU et les nœuds exclus :

Deux garde-fous utiles sur un parc hétérogène. Le mode de compatibilité CPU fixe une base commune au cluster (x86-64-v2 à x86-64-v4) et bloque la migration automatique des VM dont le type de CPU la dépasse ; les VM en cpu: host sont contrôlées sur le fournisseur, Intel ou AMD. Et les étiquettes ProxLB, activables par le bouton « ProxLB VM Tags », posent des règles directement sur les invités : plb_affinity_<groupe> (même nœud), plb_anti_affinity_<groupe> (nœuds différents), plb_ignore (jamais déplacé) et plb_pin_<nœud> (épinglé). Le mode maintenance d'un nœud (évacuation) applique les mêmes règles.

La migration inter-clusters déplace une VM d'un cluster Proxmox vers un autre depuis la même interface : le déplacement seul demande vm.migrate côté PegaProx, la suppression de la source vm.delete, et le cluster de destination doit être connecté par mot de passe. Avant de lancer, PegaProx signale les ISO attachées ou un stockage absent de la cible, contrôle préalable (preflight) renforcé en 1.4.0, et depuis la 1.4.1 les migrations à chaud transfèrent l'état conntrack quand les deux nœuds le permettent. Entre hyperviseurs différents (ESXi, XCP-ng vers Proxmox), la migration passe par une conversion de disque (VMDK ou VHD vers qcow2 ou raw) ; pour un hôte ESXi, SSH doit être activé sur l'hôte et le nœud Proxmox cible a besoin de sshfs. Le mode vmkfstools_clone est celui recommandé par défaut, le mode offline le plus fiable, et le mode « snapshot-iterative » reste expérimental. Proxmox VE intègre de son côté son propre importateur ESXi, que nous évoquons dans Proxmox VE face à VMware.

Deux cas d'usage sur des serveurs dédiés ElypseCloud

Un dédié de production plus un dédié de secours. Deux serveurs dédiés, chacun avec son Proxmox VE, sont le plus souvent laissés en nœuds indépendants : un cluster Proxmox à deux nœuds perd le quorum dès qu'un hôte tombe, sauf à ajouter un troisième vote (QDevice). Indépendants, ils ne se voient pas l'un l'autre dans l'interface native. Dans PegaProx, ce sont deux clusters à un nœud dans la même liste : inventaire commun, consoles, sauvegardes PBS partagées, et surtout la migration inter-clusters pour déplacer une VM du serveur de production vers le serveur de secours avant une maintenance, puis la ramener. Ajoutez une réplication de stockage et les tests de restauration PBS, et vous avez un plan de reprise que l'interface d'un seul hôte ne permet pas. PegaProx lui-même peut tourner dans une VM sur le serveur de secours, avec une instance de réserve sur le premier.

Plusieurs serveurs dédiés gérés comme un seul parc. Un hébergeur de serveurs de jeu, une agence ou une équipe qui a loué trois ou quatre serveurs dédiés au fil du temps se retrouve avec autant d'interfaces Proxmox et de comptes. PegaProx les range en groupes de clusters, applique une politique d'équilibrage par groupe, donne à chaque client ou collègue un locataire limité à ses VM via le RBAC et l'OIDC, remonte les mises à jour apt en attente sur chaque nœud dans Prometheus et déclenche les mises à jour progressives des nœuds depuis la console. Les serveurs dédiés ElypseCloud, bi-processeur Intel Xeon E5-2620 v4 ou Xeon Gold 6230 avec 32 à 256 Go de RAM ECC, sont taillés pour accueillir chacun un Proxmox VE bien rempli ; les règles d'affinité évitent ensuite que deux VM qui doivent rester ensemble se retrouvent sur des nœuds différents. Pour l'alternative officielle, Proxmox Datacenter Manager, et pour ProxCenter, une autre console communautaire, notre guide installer ProxCenter détaille le positionnement de chacun ; rien n'empêche de faire tourner plusieurs consoles sur le même parc, chacune avec son propre compte de service.

Mises à jour et sécurité de la console

Avec le paquet Debian, apt update && apt upgrade met PegaProx à jour avec le système ; avec Docker, changez PEGAPROX_VERSION puis docker compose pull && docker compose up -d ; avec le script, update.sh depuis /opt/PegaProx (il télécharge l'archive de version, vérifie la somme SHA-256 et redémarre le service) ou « Settings → Updates » dans l'interface. Lisez la boîte de dialogue de mise à jour : elle liste les changements de comportement, et une version peut retirer volontairement une permission. La 1.4.1 recommande en plus un apt upgrade du système hôte pour récupérer le correctif Debian de Brotli (DSA-6582-1), puisque PegaProx décode des réponses Brotli venant des systèmes connectés. Pour le reste, les règles d'une console qui a la main sur tous vos hyperviseurs :

• Jamais root@pam en production : un compte de service par cluster, borné par le rôle PegaProx, et aucun identifiant SSH si vous n'en avez pas l'usage ;
• Double authentification obligatoire pour tous les comptes, un compte par personne, et l'OIDC dès que vous avez un fournisseur d'identité ;
• Console injoignable depuis Internet : pare-feu sur 443 ou 5000 à 5002, syslog 1514 fermé ou limité, API Proxmox et PBS jointes via le tunnel ;
• Sauvegarde conjointe du répertoire config/ (ou du volume pegaprox-config) et de la clé /etc/pegaprox/secret.key, l'un sans l'autre ne se restaure pas, dans vos sauvegardes chiffrées hors site ;
• Hyperviseurs à jour : PegaProx remonte les mises à jour en attente, il ne remplace pas les correctifs de Proxmox VE.

Conclusion

Une VM ou un VPS de 2 vCPU et 4 Go de RAM, un paquet Debian et un compte de service par cluster : en moins d'une heure, vos serveurs dédiés Proxmox VE partagent un tableau de bord, des consoles, des sauvegardes PBS vérifiées, un exporteur Prometheus et une migration inter-clusters que l'interface native ne propose pas. Le compte pegaprox@pve à rôle limité à la place de root, le reverse proxy HTTPS restreint à vos adresses et la sauvegarde de la clé maîtresse sont les trois réglages qui séparent une console utile d'un point de compromission de tout le parc. PegaProx reste un projet jeune, stable depuis le 1er août 2026 et très actif : figez la version, lisez les notes de chaque mise à jour, et testez d'abord sur un serveur de lab avant de lui confier la production.