Installer Proxmox dans VMware permet de tester un hyperviseur sans réserver un serveur physique. Cette virtualisation imbriquée convient à un homelab, à une formation ou à un POC en PME, à condition de transmettre correctement les fonctions VT-x ou AMD-V à la machine virtuelle. Sans ce réglage, l’interface de Proxmox peut s’ouvrir, mais les machines invitées ne profiteront pas de l’accélération KVM et le laboratoire perdra une bonne partie de son intérêt.
Le fil conducteur est celui d’une petite équipe informatique qui souhaite comparer Proxmox à son environnement VMware existant. Elle commence sur VMware Workstation, avec un réseau NAT isolé, puis peut reproduire les essais sur Fusion ou ESXi. La démarche reste la même : dimensionner la machine virtuelle, activer la virtualisation imbriquée, installer Proxmox depuis son image ISO et préparer l’accès à l’interface web sur le port 8006. Les performances obtenues ne seront pas celles d’un serveur dédié, mais elles suffisent pour observer les outils, les flux réseau et les contraintes d’administration.
En bref : prévois au moins 8 Go de mémoire pour la machine Proxmox, plusieurs vCPU et un disque virtuel dédié. Vérifie la virtualisation matérielle dans le BIOS de l’hôte, puis dans les réglages VMware. Pour un premier essai, privilégie un réseau NAT et une redirection de port maîtrisée. Garde ce montage pour les tests : il ne remplace pas une installation sur matériel physique en production.
Installer Proxmox sur VMware : comprendre les limites de la virtualisation imbriquée
Dans cette configuration, VMware exécute une machine virtuelle qui héberge Proxmox, lequel peut à son tour démarrer ses propres machines virtuelles. On parle de virtualisation imbriquée parce qu’un hyperviseur fonctionne à l’intérieur d’un autre. C’est pratique pour tester une installation ou simuler plusieurs nœuds, mais chaque couche réclame une part du processeur, de la mémoire et du stockage.
Ce montage n’est donc pas un raccourci vers une infrastructure de production. Il ajoute de la latence et rend les mesures de performances difficiles à comparer avec celles d’un serveur dédié. En revanche, pour une pré-étude, une démonstration ou une formation interne, il évite d’immobiliser une machine physique. Une équipe peut ainsi examiner l’interface, les sauvegardes et les tâches d’administration avant de décider si un essai sur matériel réel vaut le temps et le budget engagés.
Ce que VT-x et AMD-V changent concrètement
Pour démarrer les invités KVM de Proxmox, le processeur doit exposer ses fonctions de virtualisation matérielle. Intel nomme notamment cette fonction VT-x, tandis que les processeurs AMD proposent AMD-V. Le BIOS ou l’UEFI de l’hôte doit d’abord l’activer. VMware doit ensuite transmettre cette capacité à la machine Proxmox.
Si l’une de ces étapes manque, Proxmox peut s’installer et son interface d’administration rester accessible, mais la création d’une machine invitée échouera ou signalera l’absence de KVM. On se retrouve alors avec un tableau de bord opérationnel, mais incapable de faire le travail attendu. Avant de chercher une panne dans Proxmox, vérifie donc le BIOS, les paramètres du processeur virtuel et les messages du système.
La mémoire mérite la même attention. Huit gigaoctets constituent un plancher raisonnable pour installer Proxmox et lancer un petit invité, mais l’hôte doit conserver sa propre marge. Avec 12 ou 16 Go attribués à Proxmox, quelques tests supplémentaires deviennent possibles, à condition que la machine physique dispose de suffisamment de RAM. Sur un portable de 16 Go, allouer presque toute la mémoire à la VM rend l’hôte pénible à utiliser : le navigateur et les outils d’administration finiront eux aussi par manquer de ressources.
À retenir : l’installation peut réussir sans virtualisation imbriquée, mais les tests de machines KVM, eux, ne seront pas valides. Le bon diagnostic commence par vérifier la chaîne complète, du BIOS jusqu’à Proxmox.
Une fois ces limites comprises, le choix du réseau et des ressources devient plus simple. C’est lui qui détermine si le laboratoire reste isolé ou rejoint le réseau de l’entreprise.
Configuration réseau et ressources pour Proxmox dans VMware Workstation
Sur Windows ou Linux, VMware Workstation offre un chemin direct pour créer un premier laboratoire. Il faut sélectionner l’image ISO de Proxmox, choisir un profil Linux de type Debian 64 bits lorsqu’il est proposé, puis attribuer un nom explicite à la VM. Un nom comme « Proxmox-lab-01 » évite de confondre le nœud avec les autres environnements lorsque plusieurs tests sont en cours.
Pour la configuration réseau, NAT est généralement le point de départ le plus prudent. La machine Proxmox sort vers Internet par l’intermédiaire de l’hôte, ce qui permet de récupérer les mises à jour, tout en restant séparée du réseau local. Le mode bridge peut être utile si Proxmox doit recevoir une adresse IP du réseau de test et communiquer directement avec d’autres équipements. Le mettre d’emblée sur le réseau de production est une mauvaise idée : une adresse mal choisie ou une interface d’administration exposée peut créer un incident évitable.
Régler le processeur, la mémoire et le stockage
Attribue au minimum 8 Go de RAM à la VM, puis ajuste selon les invités que tu veux lancer. Deux à quatre processeurs virtuels forment une base raisonnable pour un test simple. Davantage de vCPU ne garantit pas de meilleures performances : si l’hôte est déjà chargé, les processeurs virtuels se disputent le temps de calcul avec le système principal et les autres VM.
Dans les réglages du processeur de VMware, active l’option qui expose la virtualisation Intel VT-x/EPT ou AMD-V/RVI à l’invité. Le libellé varie selon la version de Workstation, mais le principe ne change pas. Après installation, vérifie que Proxmox peut créer et démarrer une machine KVM de test. Cette vérification concrète vaut mieux qu’une simple inspection de la case cochée.
Prévois un disque virtuel distinct pour le système Proxmox et ses essais. Un volume de 64 Go laisse de la place pour l’installation et quelques opérations, mais il ne permet pas de simuler un gros parc de VM. Le stockage repose souvent sur un fichier placé sur le disque de l’hôte : si celui-ci est presque plein ou très lent, les résultats des tests seront trompeurs. Un SSD avec de l’espace libre donne une expérience plus cohérente qu’un disque saturé.
La création de la VM peut suivre cette séquence :
- Charger l’ISO de Proxmox et sélectionner un invité Linux 64 bits adapté.
- Attribuer la mémoire, les vCPU et un disque virtuel dédié en fonction du test prévu.
- Activer la virtualisation imbriquée dans les réglages du processeur.
- Choisir NAT pour un premier laboratoire isolé, puis démarrer l’installation depuis l’ISO.
- Noter les versions de VMware, de Proxmox et du système hôte afin de reproduire le test.
Une installation de laboratoire gagne à rester simple. Il vaut mieux commencer avec une VM bien dimensionnée et un seul invité de test que d’empiler des composants avant d’avoir validé l’accès KVM et le réseau.
Workstation permet de prendre ses repères sur un poste de travail. Sur Mac, Fusion suit une logique proche, mais le processeur et la plateforme matérielle changent les possibilités réelles.
Proxmox dans VMware Fusion ou ESXi : adapter la méthode à l’hôte
VMware Fusion permet de monter un laboratoire Proxmox sur un Mac Intel en reprenant les principes de Workstation : image ISO, ressources suffisantes, réseau adapté et transmission de la virtualisation matérielle. Un ordinateur portable reste toutefois limité par sa mémoire et son refroidissement. Attribuer 12 Go à Proxmox sur un Mac doté de 16 Go peut laisser trop peu de marge à macOS, surtout si plusieurs applications tournent en même temps.
Les Mac Apple Silicon demandent davantage de prudence. Leur architecture ARM diffère du matériel x86 auquel Proxmox VE est habituellement destiné, et la prise en charge des invités imbriqués dépend des capacités de Fusion et de la version utilisée. Pour un test sérieux de Proxmox dans une VM, un hôte x86 demeure le choix le plus prévisible. Il vaut mieux vérifier la compatibilité documentée avant de passer du temps à régler un scénario que le processeur ne peut pas exécuter comme attendu.
Créer une VM Proxmox sur un hôte ESXi
Sur ESXi, Proxmox peut être installé dans une machine virtuelle placée sur un datastore de laboratoire. Cette approche rapproche le test de l’environnement existant d’une PME : l’équipe peut examiner le comportement du nouvel hyperviseur tout en gardant ses outils VMware pour superviser l’hôte. Elle ne transforme pas pour autant le test en comparaison de performances équitable, car les deux couches de virtualisation influencent les résultats.
La VM doit utiliser un système invité Linux 64 bits, disposer d’un disque adapté et être connectée à un portgroup de test, idéalement associé à un VLAN isolé. Il faut ensuite autoriser la virtualisation matérielle imbriquée dans les paramètres de la VM et vérifier que l’hôte ESXi expose lui-même cette capacité. Les droits nécessaires et les options disponibles peuvent varier selon les versions et les politiques de l’infrastructure : mieux vaut valider ces points avec l’administrateur vSphere avant de modifier une VM hébergée sur un cluster partagé.
Le stockage mérite aussi un contrôle spécifique. Un disque virtuel placé sur un datastore sollicité par des charges de production peut ralentir les tests et gêner d’autres services. Pour une comparaison utile, documente le type de stockage, l’espace disponible et les charges en cours. Si l’équipe étudie des scénarios impliquant des disques physiques ou un accès direct aux périphériques, le guide sur le mappage de disque brut sous VMware ESXi aide à comprendre les précautions propres à cette approche.
Un laboratoire peut également contenir plusieurs VM Proxmox afin d’explorer les échanges entre nœuds ou certains scénarios de cluster. Il faut alors dimensionner chaque instance et ne pas confondre une démonstration fonctionnelle avec une validation de haute disponibilité. Une panne simulée dans un environnement imbriqué permet d’observer des mécanismes, pas de certifier leur comportement sur des serveurs réels.
Le bon réflexe : isoler le portgroup et documenter les réglages avant de toucher à un environnement partagé. La proximité avec l’infrastructure réelle est utile seulement si le périmètre du test reste maîtrisé.
La plateforme choisie modifie donc les réglages, mais pas l’objectif : produire un essai reproductible, sans exposer inutilement le réseau ni tirer de conclusion abusive sur les performances.
Accéder à l’interface web Proxmox sans ouvrir le réseau de production
Après l’installation, l’interface d’administration de Proxmox est accessible en HTTPS sur le port 8006. Avec un réseau NAT, son adresse IP appartient au réseau virtuel VMware et n’est pas toujours joignable directement depuis le navigateur de l’hôte. Une redirection de port permet de conserver l’isolation tout en ouvrant un chemin d’administration ciblé.
Dans VMware Workstation, l’éditeur de réseaux virtuels permet de configurer le NAT et son transfert de ports. Le principe consiste à faire écouter un port sur l’hôte, puis à rediriger les connexions TCP vers l’adresse de la VM Proxmox et son port 8006. L’URL d’accès prend alors une forme comme https://adresse-de-l-hote:8006, sous réserve que le port choisi soit libre sur l’hôte.
| Paramètre | Exemple | Fonction |
|---|---|---|
| Port de l’hôte | 8006 | Point d’entrée local pour le navigateur |
| Protocole | TCP | Transport utilisé par l’interface web |
| Adresse de la VM | 192.168.14.130 | Adresse Proxmox sur le réseau NAT |
| Port de la VM | 8006 | Port HTTPS de l’interface Proxmox |
L’adresse IP de la VM doit rester cohérente avec le réseau NAT configuré. Si elle change après un redémarrage, la règle peut pointer vers une ancienne adresse et l’accès échouer. Une réservation ou une configuration IP stable dans le laboratoire évite ce genre de panne, à condition de respecter la plage d’adresses du réseau virtuel.
Vérifier la règle et limiter l’exposition
Teste d’abord l’accès depuis l’hôte, puis vérifie que l’interface ne répond pas depuis un réseau qui ne devrait pas y accéder. Une redirection de port n’est pas une mesure de sécurité complète : elle crée un chemin d’entrée, même si celui-ci reste local. Évite d’exposer l’administration Proxmox vers Internet et ne réutilise pas une règle de laboratoire sur un réseau de production sans revue préalable.
Si la règle disparaît après un redémarrage, commence par vérifier que la configuration NAT a bien été enregistrée et que le service VMware concerné a été relancé. Sur certaines installations Windows, le fichier de configuration NAT peut servir au diagnostic, mais une modification manuelle doit rester une solution contrôlée et documentée. Après chaque changement, valide le service, l’adresse de destination et le port avant de conclure que Proxmox est en cause.
Le mode bridge constitue une autre option. Proxmox obtient alors une adresse directement sur le réseau auquel l’hôte est connecté. C’est utile pour tester les échanges avec d’autres machines du VLAN de laboratoire, mais moins adapté à un premier essai isolé. Il faut prévoir l’adresse IP, la passerelle, le DNS et les règles de filtrage, puis s’assurer que le réseau n’autorise pas des appareils non prévus à atteindre l’interface d’administration.
Pour une équipe qui compare les plateformes, cette étape révèle aussi les différences de gestion et d’intégration. Le dossier comparant Proxmox et VMware peut aider à organiser les critères à examiner, plutôt que de réduire le choix à une impression après quelques clics.
Un accès simple n’est pas forcément un accès sûr. NAT et redirection de port conviennent au poste d’administration d’un laboratoire ; les règles de production doivent, elles, être pensées avec le réseau et la sécurité de l’entreprise.
Évaluer le laboratoire Proxmox et éviter les faux diagnostics
Un test Proxmox dans VMware répond à une question précise : l’équipe veut-elle vérifier une interface, une procédure de migration, une sauvegarde ou un scénario réseau ? Sans objectif défini, le laboratoire finit souvent par produire des avis vagues comme « c’est lent » ou « ça marche bien ». Or, une machine sous-dimensionnée peut fausser l’évaluation avant même que la plateforme ait été testée dans de bonnes conditions.
Dans l’exemple de la PME industrielle, l’équipe peut comparer les tâches courantes : création d’une VM, configuration du stockage, accès à la console, sauvegarde et restauration d’un invité de test. Elle doit noter les ressources allouées et les limites de l’environnement imbriqué. Les mesures obtenues servent à repérer des différences de fonctionnement, pas à annoncer qu’un hyperviseur est plus rapide qu’un autre sur du matériel physique.
La gestion des ressources demande une observation régulière. Une machine Proxmox qui consomme toute la RAM disponible peut ralentir l’hôte, puis faire croire que les invités sont responsables. Surveille la mémoire, l’activité du processeur et les entrées-sorties du disque, sans oublier la charge générale de VMware. Pour tester plusieurs nœuds, ajoute-les progressivement : un seul nœud fonctionnel aide à isoler les erreurs, alors que trois machines mal réglées multiplient les pistes de dépannage.
Les choix de stockage doivent correspondre au scénario. Un disque virtuel dynamique économise de l’espace tant qu’il n’est pas rempli, mais il ne garantit pas que l’hôte dispose de la capacité nécessaire au moment où les VM grossissent. Un disque préalloué consomme l’espace dès sa création, ce qui rend la capacité plus visible. Aucun des deux choix ne remplace une sauvegarde : un laboratoire reste supprimable, mais les données utilisées pour un test doivent être récupérables.
Avant de commencer, consigne les éléments suivants :
- La version de Proxmox, celle de VMware et le système d’exploitation de l’hôte.
- La mémoire, les vCPU et la taille du disque attribués à chaque VM.
- Le mode réseau, l’adresse IP utilisée et les règles de transfert de ports.
- Les scénarios évalués, les résultats observés et les limites liées à l’hyperviseur imbriqué.
Cette documentation n’a rien de cérémoniel. Quand un collègue reproduit le test quelques semaines plus tard, elle permet de comprendre pourquoi les résultats diffèrent. Elle évite aussi de comparer un Proxmox doté de 8 Go à un environnement VMware bénéficiant d’un serveur complet, puis de présenter l’écart comme une conclusion technique.
Pour un essai d’administration, l’environnement imbriqué est souvent suffisant. Pour valider une migration, des performances de stockage ou une haute disponibilité, il faut compléter le travail sur des machines physiques ou un environnement équivalent à la cible. Un laboratoire local aide à poser les bonnes questions ; il ne remplace pas la validation finale.
La meilleure comparaison n’est pas celle qui désigne un vainqueur après une démonstration, mais celle qui rend visibles les contraintes, les coûts d’exploitation et les opérations que l’équipe devra réellement maintenir.
Questions fréquentes sur l’installation de Proxmox dans VMware
Peut-on utiliser Proxmox installé dans VMware en production ?
Ce montage convient aux tests, à la formation et aux preuves de concept. La virtualisation imbriquée ajoute des couches et des limites de performances ; pour la production, installe Proxmox sur un serveur adapté ou conserve une plateforme déjà validée.
Combien de mémoire attribuer à Proxmox dans VMware ?
Huit gigaoctets constituent un minimum raisonnable pour un petit laboratoire. Prévois 12 à 16 Go si tu veux lancer plusieurs invités, tout en gardant assez de mémoire pour le système hôte et les autres applications.
Comment vérifier que la virtualisation imbriquée fonctionne ?
Active VT-x ou AMD-V dans le BIOS, puis l’option correspondante dans les paramètres du processeur virtuel VMware. Après installation, crée et démarre une petite VM KVM dans Proxmox ; une erreur signalant KVM désactivé indique qu’un réglage manque.
Faut-il choisir NAT ou bridge pour la configuration réseau ?
NAT est généralement préférable pour commencer, car il garde le laboratoire séparé du réseau local. Le bridge permet à Proxmox de rejoindre directement un réseau de test, mais exige une adresse IP maîtrisée et des règles de sécurité adaptées.
Peut-on simuler plusieurs nœuds Proxmox dans VMware ?
Oui, si l’hôte possède assez de processeur, de mémoire et de stockage. Cette configuration permet d’observer des scénarios de communication ou de cluster, mais les résultats ne valident pas à eux seuls une architecture de haute disponibilité en production.
