Installer Proxmox sur VMware peut paraître étrange au premier abord : pourquoi héberger un hyperviseur dans un autre hyperviseur ? En pratique, cette approche rend de fiers services pour monter un labo, préparer une migration ou valider une configuration sans toucher à la production. Un Proxmox VE encapsulé dans VMware Workstation ou ESXi permet de tester la virtualisation KVM, les conteneurs LXC, la haute disponibilité ou des scénarios de migration à froid vers un futur cluster bare metal. Encore faut-il respecter une procédure détaillée et quelques points de vigilance pour éviter un serveur virtuel poussif et des erreurs de configuration réseau difficiles à diagnostiquer.
Dans un contexte où les coûts de licences pèsent plus lourd qu’il y a dix ans, beaucoup de petites structures cherchent à se former sur Proxmox avant d’envisager une bascule partielle ou totale depuis VMware. C’est exactement ce que fait Lucas, admin infra dans une PME de 80 personnes : un portable costaud, un VMware Workstation bien réglé, et plusieurs instances de Proxmox pour simuler un futur cluster. Entre les limites de la virtualisation imbriquée, la gestion du stockage virtuel et les pièges liés aux cartes réseau virtuelles, ce type de labo peut soit accélérer les projets, soit les ralentir si la base n’est pas propre. L’objectif ici est d’apporter un guide structuré, sans bla-bla marketing, pour monter ce genre de setup proprement et comprendre où se trouvent les vraies contraintes.
En bref
- Objectif : installer Proxmox VE comme machine virtuelle dans VMware pour disposer d’un labo réaliste sans matériel dédié.
- Pré-requis : machine hôte avec support de la virtualisation matérielle, VMware bien configuré, ISO Proxmox à jour et réseau pensé en amont.
- Points sensibles : activation de la virtualisation imbriquée, choix du contrôleur disque, type de carte réseau virtuelle, gestion des ressources CPU/RAM.
- Cas d’usage : tests de migration VMware vers Proxmox, homelab domotique, formation interne, validation de scripts d’automatisation.
- À éviter : utiliser ce montage pour de la production, négliger les sauvegardes, empiler les snapshots VMware sur un Proxmox lui-même chargé en VM.
Installer Proxmox VE dans VMware : comprendre les usages, les limites et les bénéfices
Avant de lancer la moindre installation, il vaut mieux clarifier ce que l’on cherche à faire avec Proxmox dans VMware. Un Proxmox imbriqué reste une couche de plus dans la pile, avec ses gains mais aussi ses frottements. Dans le cas de Lucas, l’enjeu est de simuler un futur cluster de trois nœuds avec quelques machines virtuelles Linux et Windows sans toucher au vieux cluster ESXi de prod. Pour ce type de labo, Proxmox dans VMware fait parfaitement le job, à condition de respecter quelques règles simples.
Premier point à garder en tête : une VM Proxmox dans VMware n’a rien à voir avec un hyperviseur nu type ESXi ou Proxmox installé directement sur un serveur physique. La couche VMware garde le contrôle sur le CPU, la RAM et surtout le stockage. Toute la chaîne d’I/O passe par le contrôleur virtuel de VMware, ce qui ajoute de la latence et dégrade rapidement les performances si l’hôte tourne déjà plusieurs VM lourdes. Utiliser cette architecture pour de la production critique serait un pari risqué, même si beaucoup de homelabs la tolèrent pour des services peu sensibles.
D’un autre côté, pour un usage formation ou POC, c’est un outil redoutable. Monter un Proxmox dans VMware Workstation sur un simple PC de bureau permet d’apprendre la configuration réseau, les bridges, la gestion du stockage ZFS, ou de suivre une formation VMware intermédiaire tout en comparant les concepts avec ceux de Proxmox. On peut par exemple préparer des scénarios de migration décrits dans un guide comme Proxmox vs VMware pour la virtualisation, sans casser quoi que ce soit.
Autre avantage clair : la portabilité. Une VM Proxmox sous VMware Workstation peut être copiée d’un poste à un autre, archivée sur un disque externe, ou même transférée sur un hôte ESXi de test. Pour un formateur ou un consultant, trimballer un homelab complet dans un fichier de quelques dizaines de gigas est nettement plus simple que d’embarquer un NUC supplémentaire.
Là où il faut rester lucide, c’est sur la mécanique de la virtualisation imbriquée. Chaque VM créée à l’intérieur de Proxmox sera en fait une « VM dans une VM ». Sans support matériel correct (VT-x/AMD-V activé et exposé à la VM Proxmox), ces machines internes devront s’exécuter en mode émulé, avec des performances catastrophiques. Un test rapide sur un portable de milieu de gamme montre facilement un facteur 3 à 5 sur le temps de démarrage d’un Linux invité si cette option est oubliée.
Pour finir ce premier bloc, un point souvent sous-estimé : même pour un simple labo, la qualité du disque virtuel reste déterminante. Monter un Proxmox sur un unique VMDK posé sur un vieux HDD mécanique va rendre l’expérience très désagréable. Sur un poste équipé d’un SSD NVMe, la différence est nette. Dans certains cas, revoir la base de stockage sur l’hôte, en s’appuyant sur des bonnes pratiques comme celles détaillées pour Windows dans ce guide sur les disques internes, évite des heures de galère ultérieure.
En résumé, Proxmox dans VMware rend d’énormes services pour expérimenter, former et préparer des migrations, mais il ne doit pas masquer l’écart de comportement avec un hyperviseur installé directement sur le métal.
Cas concret de labo Proxmox sur VMware : domotique, tests Windows et Linux
Un scénario fréquent consiste à utiliser Proxmox dans VMware pour centraliser des services annexes, par exemple toute une domotique qui vivait jusque-là sur plusieurs Raspberry Pi éparpillés. Lucas a justement regroupé un Home Assistant de production, un broker MQTT, un conteneur Zigbee2MQTT et une petite VM Windows dédiée à quelques outils de supervision. Tout tourne dans une VM Proxmox de 8 Go de RAM et 4 vCPU, elle-même hébergée sur un hôte VMware équipé de 32 Go de RAM et d’un SSD NVMe de 1 To.
Ce type d’architecture reste jouable tant que l’on garde la main sur la consommation de ressources. Tant que chaque service est léger, le système tient sans broncher. Par contre, dès qu’un Plex ou un gros Windows Server s’ajoute dans le mix, la limite se fait sentir. Dans ces cas-là, mieux vaut envisager une installation native de Proxmox sur un NUC ou un mini PC comme ceux évoqués dans la littérature domotique spécialisée, plutôt que d’empiler les couches de virtualisation.
Dernier point sur ce cas concret : les mises à jour. Quand Proxmox est installé dans VMware, toute opération de maintenance sur l’hôte VMware impacte automatiquement l’hyperviseur invité et tout ce qu’il héberge. Planifier les patchs en anticipant ces dépendances évite les arrêts surprise de l’ensemble du labo.
Préparer l’hôte VMware et la VM avant l’installation de Proxmox VE
Une procédure détaillée d’installation de Proxmox sur VMware commence toujours par la préparation de l’hôte. Sans une base propre, les problèmes apparaissent plus tard, au pire moment. La première étape consiste à vérifier que la machine physique dispose bien du support de virtualisation matérielle dans le BIOS (Intel VT-x ou AMD-V) et que celui-ci est activé. Sur une station de travail un peu ancienne, ce paramètre est parfois désactivé par défaut.
Côté VMware, que ce soit Workstation Pro, Player ou ESXi, l’option de virtualisation imbriquée doit être explicitement autorisée. Sur Workstation, cela passe par la case à cocher « Virtualize Intel VT-x/EPT or AMD-V/RVI » dans les paramètres de la VM. Sur ESXi, on s’appuie sur une directive dans le fichier de configuration de la machine. Sans cette étape, Proxmox s’installera mais refusera de lancer des VM KVM, ce qui casse complètement l’intérêt du montage.
Le dimensionnement de la VM Proxmox dépend du projet. Pour un simple labo avec quelques petits Linux, 4 Go de RAM et 2 vCPU suffisent pour démarrer et se familiariser avec l’interface. Dès qu’on veut simuler un environnement un peu sérieux ou héberger une domotique complète, 8 à 16 Go de RAM deviennent vite nécessaires. Les recommandations classiques pour Proxmox sur machine physique restent valables ici, mais il faut garder un peu de marge pour les autres VM VMware présentes sur le même hôte.
Sur le stockage, il vaut mieux prévoir d’emblée un disque virtuel d’au moins 80 à 120 Go, voire plus si plusieurs VM internes sont prévues. Un VMDK de 32 Go « pour voir » finira très rapidement saturé, surtout si l’on active les sauvegardes locales dans Proxmox. Dans l’idéal, ce VMDK repose sur un SSD, ce qui donne un comportement proche d’un vrai serveur moderne. Ceux qui hésitent encore sur la manière d’organiser leurs volumes peuvent s’appuyer sur une méthode comparable à celle décrite pour Windows dans cet article comparant Windows 10 et 11, en adaptant simplement les principes à un usage serveur.
Enfin, la carte réseau virtuelle de la VM Proxmox mérite un minimum de réflexion. Une carte de type VMXNET3 sur ESXi, par exemple, offre de meilleures performances et un overhead réduit par rapport à une carte e1000 classique. Sur Workstation, le choix est plus restreint, mais l’idée reste la même : éviter les modèles vieillissants et privilégier les drivers modernes que Linux gère bien.
Création de la VM et configuration initiale dans VMware
Dans la console VMware, la création de la VM suit un canevas assez standard. On choisit « Linux » comme système invité, puis une variante de type « Debian 64 bits », puisque Proxmox repose sur Debian. Lucas, lui, a pris l’habitude de nommer ses VM de labo avec un préfixe clair, par exemple « LAB-PVE01 », pour éviter de les confondre avec d’anciennes machines de test.
Une fois la VM définie, plusieurs options méritent un réglage spécifique :
- Le firmware : BIOS ou UEFI, en cohérence avec la manière dont on installe Proxmox en physique.
- Le contrôleur disque : LSI Logic SAS ou VMware Paravirtual, plutôt que les vieilles variantes IDE ou SCSI basique.
- La réservation de ressources : dans un labo chargé, réserver un minimum de CPU et de RAM évite que la VM Proxmox soit affamée par d’autres VM plus gourmandes.
Sur Workstation, certains préfèrent aussi désactiver la mise en veille de la VM et la suspension automatique en cas de fermeture de l’interface. Une VM Proxmox mise en pause alors qu’elle héberge une demi-douzaine de VM internes peut se réveiller dans un état un peu chaotique.
Une fois cette base en place, l’étape suivante consiste à monter l’ISO Proxmox téléchargée depuis le site officiel comme lecteur CD/DVD de la VM, puis à préparer le premier démarrage pour lancer l’installation graphique.
Procédure détaillée d’installation de Proxmox VE dans une VM VMware
L’installation de Proxmox VE dans une VM VMware ressemble fortement à celle sur un serveur physique, ce qui est justement l’intérêt pour un labo. La séquence se déroule en quelques grandes étapes simples, mais chaque écran cache de petites décisions qui peuvent avoir un impact plus tard.
Au premier démarrage sur l’ISO Proxmox, l’installeur propose de lancer l’installation avec interface graphique. Pour un environnement d’apprentissage, ne pas hésiter à garder cette option plutôt que de se compliquer la vie avec un mode texte. Une fois le noyau chargé, un écran de licence s’affiche. Une acceptation permet d’accéder aux choix de disque.
Le point clé ici réside dans la sélection du disque cible et du format de stockage. Dans une VM VMware, Proxmox voit un disque virtuel présenté par l’hyperviseur. Pour un labo simple, laisser l’option par défaut (souvent « ext4 ») reste plus lisible. Ceux qui souhaitent se familiariser avec ZFS peuvent déjà le tester, mais il faut garder en tête que ZFS sur un disque virtuel lui-même posé sur un autre datastore ajoute encore un niveau de complexité, notamment pour la gestion du cache et de la mémoire.
L’écran suivant concerne le fuseau horaire, la langue et le clavier. Là encore, ce sont des paramètres classiques, mais prendre le temps de les régler proprement évite des surprises dans les logs. Vient ensuite la création du compte root et du mot de passe d’administration. Rien de très original, mais ce mot de passe restera le sésame pour la première connexion à l’interface web, donc mieux vaut l’éviter dans des listes de mots de passe génériques.
La configuration réseau affiche enfin la carte détectée, souvent en DHCP si le réseau VMware est déjà paramétré. c’est l’occasion de fixer une adresse IP statique pour le futur Proxmox, surtout si d’autres nœuds doivent le rejoindre plus tard. Lucas, pour son labo, réserve un petit bloc d’adresses dans son routeur domestique pour éviter les conflits avec d’autres équipements.
Tableau récapitulatif des choix d’installation recommandés dans VMware
Pour rendre les décisions plus claires, le tableau suivant récapitule quelques réglages courants pour un Proxmox dans VMware, adaptés à un usage de labo.
| Paramètre | Valeur conseillée | Commentaire |
|---|---|---|
| Type de système invité VMware | Linux / Debian 64 bits | Aligné avec la base Debian de Proxmox, simplifie la compatibilité. |
| vCPU alloués | 2 à 4 vCPU | Suffisant pour un petit labo, à augmenter si plusieurs VM internes sont prévues. |
| RAM allouée | 8 à 16 Go | 8 Go pour un labo léger, 16 Go dès que plusieurs services tournent en parallèle. |
| Taille du disque virtuel | 80 à 200 Go | 80 Go minimum, 200 Go ou plus si des backups internes sont stockés sur le même disque. |
| Type de stockage Proxmox | ext4 ou ZFS simple | ext4 plus simple à gérer dans un environnement imbriqué, ZFS à réserver aux tests ciblés. |
| Mode réseau VMware | Bridged ou VLAN dédié | Facilite l’accès aux VM internes depuis le réseau physique et la simulation de topologies réelles. |
Une fois ces paramètres validés dans l’installeur, un écran de synthèse affiche la configuration finale. C’est l’occasion de vérifier une dernière fois l’adresse IP, le nom de machine (de préférence un FQDN) et le disque sélectionné. Le lancement de l’installation formate alors le disque virtuel et déploie le système.
Au redémarrage, il ne faut pas oublier de retirer l’ISO de Proxmox du lecteur virtuel, sous peine de retomber en boucle sur l’installeur. Le système affiche ensuite un écran texte avec l’adresse de l’interface web, du type « https://192.168.1.100:8006 ». Une connexion depuis un navigateur moderne déclenche un avertissement de certificat autosigné. Sur un labo local, on peut simplement le contourner en acceptant l’exception de sécurité.
Ce premier accès à l’interface fournit l’occasion de vérifier que la VM VMware a bien transmis la virtualisation matérielle à Proxmox. Dans l’onglet « Node » puis « Summary », l’affichage du type de CPU et du support KVM donne rapidement la réponse. Si quelque chose cloche, il vaut mieux corriger maintenant, avant de créer des VM internes.
Une fois ces vérifications faites, Proxmox est prêt à héberger des machines virtuelles de test, et la partie intéressante peut commencer.
Configuration de Proxmox après installation et premiers points de vigilance dans VMware
Avec Proxmox en place, beaucoup s’arrêtent à la simple création de leur première VM, sans toucher aux réglages plus fins. Pourtant, une courte phase de post-configuration améliore nettement le comportement du serveur virtuel, surtout quand il tourne lui-même dans VMware. Lucas s’appuie souvent sur un script communautaire d’optimisation post-installation pour nettoyer quelques paquets, ajuster la configuration de l’APT et désactiver des options inutiles dans un contexte de labo.
Cette optimisation peut se faire en ouvrant une console sur le nœud et en lançant une commande qui télécharge et exécute le script adapté. Ce type d’outil ajuste notamment certains paramètres de journaux, met à jour les dépôts et peut même installer des utilitaires utiles comme htop ou iftop. Sur une VM Proxmox qui ne dispose pas de ressources illimitées, cela évite de gaspiller de la RAM dans des process qui n’ont pas grande valeur en environnement de test.
Premier point de vigilance fort : la gestion des snapshots. VMware propose ses propres snapshots pour la VM Proxmox, tandis que Proxmox lui-même offre des snapshots pour chaque VM interne. Cumuler les deux conduit vite à un empilement de disques delta difficile à maîtriser. Une règle simple consiste à choisir un seul niveau pour les snapshots. Soit on snapshot la VM Proxmox côté VMware avant une grosse mise à jour de l’hyperviseur, soit on s’en tient à la gestion interne des snapshots Proxmox pour les VM invitées, mais pas les deux en série.
Deuxième point, la sauvegarde. La tentation est grande de considérer qu’une simple copie de la VM Proxmox dans VMware suffit comme stratégie de sauvegarde. Ce n’est pas sérieux dès qu’on stocke le moindre service un peu important à l’intérieur. Proxmox dispose de son propre système de backup, capable de pousser des sauvegardes sur un stockage externe. Même dans un labo, tester ces mécanismes avec un second datastore VMware ou un NAS montre à quoi ressemblera la vie en production.
Réseau, performances et cohérence de l’horloge dans un Proxmox imbriqué
Le réseau représente souvent la première source de surprise. Une VM interne Proxmox qui ne rejoint pas le bon VLAN, ou qui perd des paquets, révèle en général une configuration ambiguë au niveau du réseau virtuel VMware. Lucas a rencontré le cas en utilisant un simple mode NAT dans Workstation pour sa VM Proxmox, ce qui rendait difficile l’accès aux VM internes depuis le reste de son LAN. En passant en mode bridged et en réservant un petit bloc d’adresses sur son routeur, l’ensemble est devenu beaucoup plus lisible.
La question des performances CPU se joue aussi sur plusieurs tableaux. Dans VMware, les options d’économie d’énergie ou la gestion dynamique des fréquences peuvent limiter les performances de la VM Proxmox. Dans ce contexte, caler le profil d’alimentation sur un mode « performance » et éviter de sur-allouer les vCPU à trop de VM concurrentes donne des résultats plus réguliers. Côté Proxmox, surveiller la charge moyenne et adapter le nombre de VM internes empêche la machine de se retrouver perpétuellement à 100 %.
Dernier détail, souvent négligé : la synchronisation de l’heure. Une VM Proxmox qui dérive de plusieurs minutes parce que VMware n’arrive pas à garder le rythme, combinée à des VM internes qui se basent sur Proxmox, peut provoquer des erreurs TLS et des comportements étranges dans les applications. Activer un service NTP fiable dans Proxmox, quitte à désactiver la synchronisation horaire côté VMware, stabilise la situation.
Une fois ce socle consolidé, Proxmox dans VMware cesse d’être une simple curiosité pour devenir un outil de labo crédible, utilisable au quotidien sans craindre une panne dès que l’on lance une VM de plus.
Installer et tester des VM invitées dans Proxmox sur VMware : bonnes pratiques et pièges
Un Proxmox vierge n’apporte pas grand-chose tant qu’il ne fait pas tourner de charges utiles. C’est donc le moment de déployer quelques VM invitées pour valider le montage. Lucas commence souvent par un petit Debian en VM, puis un conteneur LXC léger, et enfin une VM un peu plus lourde, par exemple un Home Assistant ou un Windows Server minimal. L’objectif est de voir comment l’hyperviseur réagit dans ces trois cas, en gardant un œil sur la charge de l’hôte VMware.
Lors de la création d’une première VM Linux, Proxmox propose différents types de contrôleurs disque et d’adaptateurs réseau. Rester cohérent avec le choix fait dans VMware en amont évite les cascades de conversions. Par exemple, utiliser virtio pour le disque et la carte réseau dans Proxmox s’accorde bien avec un contrôleur performant dans VMware. Les tests montrent souvent des gains sensibles en débit I/O sur les disques virtuels avec cette approche.
Sur une VM plus lourde, comme un Windows, le comportement diffère un peu. Le système invité reste conscient du fait qu’il tourne lui-même dans un environnement virtualisé, même si Proxmox lui présente un matériel standardisé. Pour valider des scénarios de compatibilité entre Windows 10 et 11, Lucas s’appuie parfois sur des VM hébergées dans Proxmox puis compare les comportements à ceux décrits dans des ressources plus orientées poste de travail, comme cette analyse des différences entre Windows 10 et 11. Cette double lecture aide à distinguer ce qui vient du système et ce qui vient de la couche de virtualisation.
Dans tous les cas, le point critique reste la consommation cumulée en RAM. Chaque VM interne réserve une part de la mémoire nécessaire, qui se trouve décomptée dans la VM Proxmox, elle-même contrainte par la RAM assignée dans VMware. Une surcharge se traduit par du swap dans Proxmox, puis potentiellement dans la VM VMware, ce qui massacre les temps de réponse. Mieux vaut commencer petit, mesurer, puis augmenter progressivement.
Domotique et services annexes : quand arrêter d’empiler dans une VM Proxmox imbriquée
La domotique illustre bien la limite de cette approche. Monter Home Assistant, MQTT, Zigbee2MQTT, Plex et quelques petits scripts d’automatisation dans un Proxmox qui tourne lui-même comme VM VMware fonctionne techniquement. Tant que le nombre d’utilisateurs reste faible et que les flux vidéo ne sont pas trop nombreux, le système tient. Mais au premier ajout de caméra supplémentaire ou de transcodage vidéo un peu agressif, la chaîne complète commence à souffrir.
À ce stade, la question se pose vraiment : conserver ce montage imbriqué, ou migrer la domotique vers un Proxmox installé directement sur un mini PC dédié. Beaucoup de retours d’expérience montrent qu’un simple NUC correctement dimensionné, avec 16 ou 32 Go de RAM et un SSD, offre une bien meilleure stabilité qu’un Proxmox qui doit composer avec les contraintes de VMware en amont. La comparaison détaillée entre ces architectures dans des articles du type analyse Proxmox et VMware pour la virtualisation aide à trancher.
Pour un labo, la réponse est plus nuancée. Continuer à empiler quelques services supplémentaires dans Proxmox sur VMware reste acceptable, à condition de garder une vision claire des risques. Tout incident sur l’hôte VMware, un simple redémarrage planifié ou une mise à jour ratée, arrêtera en une fois tous les services domotiques, sans filet. Un serveur dédié Proxmox, même modeste, offre une autonomie bien plus grande.
En bref, la VM Proxmox imbriquée sert à tester, documenter et apprivoiser l’outil. Dès qu’une charge devient un peu critique pour le quotidien, il est temps de réfléchir à un vrai déploiement bare metal.
Points de vigilance spécifiques à la combinaison Proxmox / VMware et arbitrages à faire
La cohabitation entre Proxmox et VMware amène quelques sujets qui ne se posent pas de la même façon dans un environnement mono-hyperviseur. Le premier concerne la lisibilité globale de l’infra. Quand une VM Windows tombe, par exemple, la cause se situe-t-elle dans Windows, dans Proxmox, dans la VM VMware ou sur l’hôte physique ? Plus il y a de couches, plus le diagnostic se complique. Lucas a résolu en partie ce casse-tête en tenant une petite documentation de labo, avec un schéma simple des dépendances entre chaque élément.
Deuxième souci, les mises à jour croisées. VMware publie ses patchs, Proxmox aussi, et les VM internes ont leurs propres cycles. Appliquer tout ça au fil de l’eau sans plan peut conduire à des incohérences, surtout si une mise à jour de VMware modifie la manière dont la virtualisation imbriquée est gérée. La bonne pratique consiste à définir une petite fenêtre de maintenance pour le labo, à commencer par mettre à jour l’hôte VMware, puis la VM Proxmox, puis enfin les invités internes.
Les questions de licences surviennent aussi plus souvent qu’on ne l’imagine. Proxmox lui-même reste open source, mais certaines VM internes peuvent nécessiter des licences Windows ou applicatives. Les environnements de test bénéficient parfois de programmes spéciaux (MSDN, programmes partenaires, etc.), à condition de rester dans le cadre prévu. Utiliser une architecture imbriquée ne change pas ce point, mais il est facile de le perdre de vue quand on duplique des VM à la volée pour expérimenter.
Quand envisager une migration depuis VMware vers Proxmox nu sur le serveur
Pour certains, ce labo Proxmox sur VMware n’est qu’une étape vers une migration plus large. La logique est claire : prendre en main Proxmox, évaluer ses capacités, puis déplacer progressivement des charges de VMware vers un cluster Proxmox nu. Des guides complets sur la migration, comme ceux qui circulent déjà largement, détaillent les aspects techniques d’une telle bascule. Le labo imbriqué sert alors à simuler ces migrations à froid et à tester les outils d’import.
Les critères qui déclenchent vraiment ce basculement tiennent souvent à trois éléments : le coût des licences VMware, la flexibilité attendue de l’infra, et la maturité de l’équipe sur Proxmox. Une fois ces trois feux au vert, rester sur une architecture où Proxmox est coincé dans une VM fera plus perdre de temps qu’autre chose. À ce moment-là, la question des serveurs physiques se pose, avec les choix habituels entre NUC, serveurs rack, ou recyclage de machines existantes.
Dans ce contexte, le labo imbriqué garde malgré tout son intérêt, en devenant un environnement de pré-production ou de formation interne. Il permet, par exemple, de tester les différences de comportement entre des systèmes invités fonctionnant sur l’ancien ESXi et sur le nouveau cluster Proxmox, comme on le ferait pour comparer le comportement d’une appli entre deux versions de Windows, analogie que l’on retrouve dans des ressources du type comparatif Windows 10 / 11.
En définitive, ce montage Proxmox dans VMware n’est ni une aberration, ni une fin en soi. Utilisé à bon escient, il sert de tremplin vers une maîtrise plus large de la virtualisation open source, tout en s’appuyant sur des compétences VMware déjà en place.
Peut-on utiliser Proxmox sur VMware pour un environnement de production permanent ?
Techniquement oui, mais ce n’est pas recommandé. La virtualisation imbriquée ajoute de la complexité, dégrade les performances et rend le diagnostic des pannes plus difficile. Ce montage convient surtout à un labo, à des POC ou à de la formation. Pour la production, mieux vaut installer Proxmox directement sur le serveur physique.
Quelle configuration minimale pour une VM Proxmox dans VMware ?
Pour un petit labo, prévoyez au moins 4 Go de RAM, 2 vCPU et un disque virtuel de 80 Go sur SSD. Pour des tests plus ambitieux avec plusieurs VM internes, 8 à 16 Go de RAM et un disque de 200 Go ou plus deviennent vite nécessaires. Il faut aussi que l’hôte VMware dispose du support VT-x/AMD-V activé et que la virtualisation imbriquée soit autorisée.
Comment accéder aux VM internes Proxmox depuis le réseau local ?
Le plus simple consiste à configurer la VM Proxmox en mode réseau bridged ou sur un VLAN dédié dans VMware, puis à créer un bridge réseau dans Proxmox relié à cette interface. Les VM internes obtiennent alors des adresses IP sur le même segment que le reste du réseau ou sur un sous-réseau routé, ce qui rend l’accès beaucoup plus direct.
Faut-il utiliser ZFS dans Proxmox quand il tourne dans VMware ?
ZFS fonctionne dans une VM Proxmox hébergée par VMware, mais il ajoute de la consommation RAM et un niveau de complexité supplémentaire. Pour un labo, cela peut servir à se former, à condition de réserver une quantité de RAM suffisante. Pour un environnement limité en ressources, ext4 reste souvent plus adapté.
Comment gérer les sauvegardes avec Proxmox installé comme VM VMware ?
Évitez de compter uniquement sur un snapshot de la VM Proxmox côté VMware. Utilisez le système de sauvegarde intégré à Proxmox pour exporter les backups des VM internes vers un stockage externe (autre datastore, NAS, disque réseau). Les snapshots VMware peuvent servir ponctuellement avant une mise à jour de l’hyperviseur Proxmox, mais ne remplacent pas de vraies sauvegardes.
