Raw Disk Mapping fait partie de ces options de virtualisation qui n’attirent pas forcément l’œil au premier coup d’écran, mais qui peuvent transformer le comportement d’un cluster sous charge. En donnant à une machine virtuelle un accès très direct à un disque brut ou à un LUN de SAN, on sort du schéma classique « tout en VMDK » pour se rapprocher du matériel, avec des effets visibles sur la latence, la réplication et la manière de penser la gestion des disques.
VMware a popularisé ce mécanisme sous le nom de Raw Disk Mapping (RDM) dans vSphere et ESXi, pendant que des plateformes comme Proxmox ont suivi une autre voie, plus centrée sur LVM, ZFS et les pools de stockage.
Sur le terrain, ce sujet ne concerne pas seulement les grosses banques ou les éditeurs de logiciels. Dans beaucoup de PME, on retrouve un ERP un peu nerveux, un SQL Server qui sert de colonne vertébrale aux métiers, ou un cluster de fichiers qui n’a pas le droit de tousser pendant la journée.
Pour ces cas-là, comprendre comment mapper un disque brut dans une VM, quand privilégier un accès direct au LUN, et dans quels cas rester sagement sur du VMDK ou du disque virtuel classique, devient une vraie décision d’architecture. L’enjeu est de garder une plateforme stable, prévisible, et surtout réparable en cas de coup dur.
Ce mode d’emploi propose un tour d’horizon concret du Raw Disk Mapping sur VMware, des équivalents sous Proxmox et de ce qu’implique ce type de choix au quotidien. On va parler modes physique/virtuel dans ESXi, LUN, LVM, clusters, snapshots manquants, mais aussi procédures de configuration pas à pas et arbitrages très terre-à-terre entre performance brute et confort d’exploitation.
Nous prendrons l’exemple d’une entreprise, « Studio Cartouche », qui doit faire évoluer son infra sans se tirer une balle dans le pied.
En bref
- Raw Disk Mapping permet à une machine virtuelle d’accéder presque directement à un LUN ou un disque brut, sans passer intégralement par un fichier VMDK ou un disque virtuel classique.
- Sous VMware ESXi, le RDM existe en deux variantes majeures, mode physique et mode virtuel, avec un compromis net entre performance et fonctionnalités comme les snapshots.
- Sur Proxmox, on ne parle pas de RDM au sens strict, mais l’ajout d’un disque brut via LVM, ZFS ou directement en block device répond à la même logique.
- Le gain se ressent surtout sur des workloads ciblés (bases de données, clusters, réplication SAN), pas sur le serveur web moyen ni la VM de test.
- Une configuration RDM bien pensée repose sur un zoning SAN propre, un nommage clair, une documentation partagée et une stratégie de sauvegarde cohérente.
Raw Disk Mapping sur VMware et ESXi : définition concrète, modes et cas d’usage
Dans l’univers VMware, le Raw Disk Mapping est parfois présenté comme une option « avancée » de l’assistant de disque. En pratique, c’est beaucoup plus simple que ça : un RDM, c’est un tout petit fichier stocké sur un datastore VMFS, qui sert de raccourci vers un disque brut externe, généralement un LUN de SAN. Ce fichier de mappage ne contient pas les données, seulement des métadonnées qui indiquent à ESXi : « pour ce disque, envoie les I/O directement vers ce LUN précis ».
Pour la machine virtuelle, le disque RDM se présente comme un disque SCSI tout ce qu’il y a de plus banal. L’OS invité le voit, le partitionne, le formate, exactement comme un disque local. La différence se joue entre l’hyperviseur ESXi et la baie : au lieu de traverser la couche VMFS qui gère les fichiers VMDK classiques, la majorité des opérations passent en direct vers le LUN. Ce détour en moins peut paraître minime, mais sur un volume demandé en permanence, il se fait sentir.
Prenons l’exemple de « Studio Cartouche », une imprimerie qui s’est mise au web-to-print. Son ERP maison, couplé à une base PostgreSQL, monopolise un serveur virtuel sous ESXi. La base tourne déjà sur un VMDK dédié, mais à chaque clôture mensuelle, les I/O explosent et le datastore partagé commence à montrer des signes de fatigue. L’équipe infra décide de basculer le volume de données sur un LUN SAN mappé en RDM. Résultat : la base se retrouve isolée là où ça compte, la latence devient plus stable, et surtout les pics d’activité se lisent clairement dans les graphes de la baie.
Sous le capot, le chemin complet ressemble à ceci : la baie de stockage expose un LUN, les hôtes ESXi le détectent, puis vSphere propose de créer un fichier RDM dans un datastore existant. Ce fichier lie la machine virtuelle à ce LUN précis. Quand la VM écrit un bloc, ESXi consulte le mapping et l’envoie directement au disque brut, sans passer par les mécanismes de gestion de fichiers applicables à un VMDK classique.
La vraie subtilité vient des deux modes possibles du Raw Disk Mapping dans ESXi : le mode compatible virtuel et le mode compatible physique. Les deux se sélectionnent au moment d’ajouter le disque, mais ils correspondent à deux philosophies d’architecture bien différentes, qui ont un impact direct sur tes snapshots, tes clones et ta mobilité de VM.
En mode virtuel, le RDM se comporte en partie comme un disque logique géré par VMware. Certaines commandes SCSI sont filtrées, ce qui permet à vSphere de garder la main sur les snapshots au niveau de la VM, certaines migrations de stockage ou des outils comme Storage vMotion. On reste proche de l’expérience VMDK, tout en profitant d’un accès plus direct au LUN.
En mode physique, les commandes SCSI sont transmises quasiment telles quelles au LUN. La baie voit alors la VM comme un serveur physique qui dialogue directement avec elle. C’est ce qu’attendent certains clusters Microsoft, Oracle ou des fonctionnalités pointues de réplication matérielle. En contrepartie, une bonne partie des fonctions de snapshot au niveau de la VM disparaissent, car ESXi n’intercepte plus assez de choses pour rejouer proprement un retour arrière.
| Aspect | RDM mode virtuel | RDM mode physique |
|---|---|---|
| Accès au LUN | Médié par ESXi, commandes SCSI filtrées | Commandes SCSI passées quasi directement au disque brut |
| Snapshots VMware | Généralement disponibles | Souvent indisponibles ou très limités |
| Fonctions SAN avancées | Partiellement exploitées | Exploitées pleinement côté baie |
| Performance brute | Bon compromis | Légère marge en plus dans les cas extrêmes |
| Complexité d’exploitation | Proche d’un VMDK | Plus exigeante pour les équipes stockage/VM |
Cette distinction explique pourquoi certaines documentations d’éditeurs exigent noir sur blanc un « RDM en mode physique » pour leurs clusters, tandis que d’autres tolèrent ou recommandent le mode virtuel. La bonne pratique consiste à suivre ces prérequis à la lettre, car bricoler à contre-courant pour préserver tel ou tel confort côté VMware finit souvent en incident difficile à diagnostiquer.
Un détail souvent sous-estimé : un même serveur peut très bien mixer les approches. Sur une VM SQL critique, par exemple, il est courant de laisser l’OS, les binaires et les fichiers de logs secondaires sur des VMDK, et de placer uniquement les volumes de données ou de journaux transactionnels sur des RDM. Ce découpage permet de réserver la complexité du Raw Disk Mapping là où il apporte réellement quelque chose.
Au final, sous VMware, le RDM n’est ni une relique ni un gadget. C’est une manière de faire dialoguer une VM avec un stockage de niveau entreprise, sans complètement renoncer aux services de la plateforme ESXi. La nuance, c’est que chaque RDM est une petite exception par rapport au standard VMDK, qui doit donc être assumée, expliquée, et surveillée.
Performance, stockage et virtualisation : ce que change vraiment l’accès direct au disque brut
Dès qu’on parle de Raw Disk Mapping, une phrase revient souvent dans les couloirs : « ça ira plus vite ». C’est partiellement vrai, mais pas dans le sens magique qu’on imagine parfois. Le principal impact se voit sur la régularité des temps de réponse et la manière dont les graphes de la baie de stockage reflètent le comportement réel de l’application.
Reprenons « Studio Cartouche ». Avant le passage en RDM, la base PostgreSQL partageait un datastore VMFS avec d’autres VMDK. Sur les fenêtres de clôture, les admins voyaient le datastore grimper à 100 % d’IOPS, sans savoir précisément quel volume tirait véritablement dessus. Après migration vers un LUN dédié en RDM, un simple coup d’œil sur les métriques SAN suffisait à corréler les pics de latence avec les opérations de l’ERP. Les perfs n’ont pas doublé d’un coup, mais la courbe de latence est devenue plus plate, plus prédictive.
Sur les workloads très gourmands en écriture aléatoire, un disque brut mappé en RDM permet souvent de grappiller quelques millisecondes par opération. Sur un million de transactions, ces petits gains se cumulent et se traduisent par des traitements de batch qui terminent plus tôt, ou une interface utilisateur qui répond de manière plus fluide. La différence n’a rien à voir avec un changement d’algorithme côté base, évidemment, mais du point de vue perception utilisateur, la nuance se sent.
Autre point intéressant : la disparition d’une couche de contention potentielle. Avec du VMDK, plusieurs VM peuvent brutaliser le même datastore VMFS. Les mécanismes d’arbitrage d’ESXi font leur travail, mais les profils d’I/O importants ont quand même tendance à se gêner. En basculant la base principale sur un LUN séparé en RDM, on met physiquement à l’écart son trafic disque, ce qui réduit mécaniquement les interférences.
Pour que ces bénéfices existent, encore faut-il que le reste de la chaîne soit propre. Un Raw Disk Mapping posé sur un LUN saturé ou partagé de manière sauvage avec d’autres hôtes ne fera que déplacer le problème. C’est là que la coordination avec l’équipe stockage devient décisive : il faut un zoning clair, des pools correctement dimensionnés et, idéalement, une QoS adaptée au type d’application.
Les cas où la différence est la plus nette restent assez typés : grosses bases OLTP, journaux de transactions, clusters de fichiers très actifs, ou moteurs de messagerie d’entreprise. Pour un serveur applicatif Java ou un front web, la saturation vient souvent d’ailleurs (CPU, réseau, code dupliqué), et passer ces VM en RDM n’apporte qu’une complexité supplémentaire sans retour visible.
Une erreur classique consiste à multiplier les RDM « au cas où », parce que « qui peut le plus peut le moins ». On se retrouve vite avec des VM qui cumulent dix volumes bruts, des LUN éparpillés sur la baie et une équipe d’astreinte qui n’ose plus toucher à rien. La bonne stratégie, vue et revue en production, consiste à réserver le RDM à quelques volumes critiques par application.
- Limiter le nombre de LUN RDM par VM à ce qui est strictement nécessaire (données, logs critiques, disque partagé de cluster).
- Isoler ces LUN dans des pools ou des groupes de disques conçus pour ce profil d’I/O.
- Nommer clairement chaque LUN et chaque fichier de mapping côté vSphere, pour qu’un coup d’œil suffise à comprendre qui consomme quoi.
À partir de là, la différence entre un RDM sain et un RDM toxique tient surtout à la discipline d’équipe. Quand tout est documenté, qu’une revue régulière fait le ménage dans les mappings devenus inutiles et que les métriques de latence sont suivies par LUN, le Raw Disk Mapping devient un outil relativement confortable. Quand rien n’est écrit et que chacun ajoute son LUN au fil de l’eau, les incidents de performance finissent par ressembler à une enquête policière mal engagée.
Vue du dessus, la morale est simple : le RDM ne sert pas à transformer chaque VM en bolide, mais à donner à quelques disques une voie rapide entre l’application et la baie. Pour une plateforme de virtualisation qui abrite des workloads très variés, ce petit nombre de « voies rapides » bien gérées peut faire toute la différence.
Configuration d’un Raw Disk Mapping sous VMware ESXi : étapes, erreurs classiques et sauvegarde
Passer de la théorie à la pratique sur ESXi se joue dans un assistant assez sobre, mais chaque clic a des conséquences réelles. Pour « Studio Cartouche », l’équipe a commencé par dupliquer son environnement sur un cluster de préproduction. Le but : tester le passage en Raw Disk Mapping sans risquer de planter l’ERP en plein milieu d’un tirage.
Le premier chantier se situe côté stockage. L’admin de la baie crée un nouveau LUN, dimensionné pour la base de données, avec un niveau de service clair. Le volume est étiqueté de façon explicite, par exemple « LUN_DB_ERP_RDM_1 », ce qui évite déjà les confusions lors de l’étape suivante. Ce LUN est ensuite présenté à tous les hôtes ESXi susceptibles d’héberger la VM critique, avec un zoning FC ou iSCSI propre.
Côté ESXi, une rapide resynchronisation des adaptateurs de stockage fait apparaître le nouveau disque dans la liste des périphériques. Aucun formatage VMFS n’est appliqué dessus, puisqu’il est destiné à servir de disque brut. Dans le vSphere Client, l’admin édite ensuite la configuration de la VM, choisit « Ajouter un nouveau disque dur », puis sélectionne l’option de mappage de périphérique brut. L’assistant liste alors les LUN visibles, avec leur taille et leur identifiant.
C’est ici que le nommage amont fait gagner plusieurs années de vie. En sélectionnant le bon LUN, il suffit ensuite de choisir le datastore où sera stocké le petit fichier RDM (souvent le même datastore que le VMDK système de la VM), puis le mode compatible virtuel ou physique. Après validation, le disque apparaît dans la configuration de la VM, qui peut alors booter et découvrir ce nouveau volume comme n’importe quel disque SCSI attaché.
Une fois l’OS démarré, l’admin système prend le relais pour initialiser le nouveau disque : partitionnement, système de fichiers, réglages spécifiques si l’on parle de base de données. Dans un scénario de migration, les données existantes peuvent être basculées avec un outil de réplication, un dump/restaur SQL, ou un rsync maîtrisé. À ce stade, la partie configuration RDM est terminée, mais la vraie vie ne fait que commencer.
La première série d’erreurs fréquentes concerne les sauvegardes. Beaucoup de solutions de backup d’environnements VMware reposent sur des snapshots de VM et l’export d’images VMDK. Avec un Raw Disk Mapping, ce modèle ne fonctionne pas toujours tel quel, notamment en mode physique. Il faut donc vérifier noir sur blanc si l’outil de sauvegarde supporte les RDM, et dans quelles conditions.
Deux grandes approches se dégagent. La première consiste à déporter la protection au niveau de la baie : snapshots SAN, clones, réplication asynchrone ou synchrone. La seconde s’appuie sur des agents de sauvegarde installés dans la VM, qui parlent directement au disque RDM comme s’il était local. Chaque méthode a ses avantages, mais l’erreur est d’ignorer complètement la différence et de supposer que « ça marchera comme avant ».
Autre piège récurrent : l’oubli de la compatibilité lors des montées de version vSphere. Les notes de version VMware mentionnent parfois des comportements spécifiques concernant les disques RDM, surtout en mode physique. Monter un cluster ESXi sans avoir vérifié l’impact sur ces VM particulières, c’est courir après les ennuis. Un petit environnement de test, avec au moins une VM RDM représentative, aide à valider que tout se passe comme prévu.
Pour y voir plus clair, un tableau de contrôle minimal peut servir de check-list interne avant toute mise en production d’un nouveau RDM :
| Étape | Responsable | Point de vigilance clé |
|---|---|---|
| Création du LUN | Équipe stockage | Nommage explicite, capacité adaptée, classe de service |
| Présentation aux hôtes ESXi | Stockage / virtualisation | Zoning cohérent, visibilité depuis tous les hôtes du cluster |
| Création du fichier RDM | Équipe virtualisation | Choix du bon LUN, sélection du mode physique/virtuel documenté |
| Initialisation dans l’OS invité | Admin système | Alignement des partitions, tests d’I/O avant usage en prod |
| Intégration sauvegarde | Sauvegarde / infra | Stratégie claire SAN vs agent, test de restauration réalisé |
Un dernier volet à ne pas oublier concerne le monitoring. Un Raw Disk Mapping sans métriques, c’est comme une autoroute sans radar ni panneau : on ne sait pas si on tire trop dessus. Mettre en place des graphes de latence, d’IOPS et de capacité par LUN, côté baie et côté ESXi, permet de détecter rapidement les dérives. De nombreux incidents de performance auraient pu être évités si quelqu’un avait vu arriver, trois mois plus tôt, cette courbe de latence qui grimpe gentiment après chaque ajout de client.
En synthèse, configurer un RDM sous VMware n’est pas sorcier en soi. Le vrai sujet est de l’inscrire dans un cycle de vie complet : création propre, intégration à la sauvegarde, suivi, puis éventuelle migration vers un autre modèle si l’application évolue. C’est ce cycle qui transforme un « simple mappage de disque brut » en composant fiable d’une architecture de virtualisation solide.
Raw Disk Mapping et équivalents dans Proxmox : LVM, ZFS et gestion des disques bruts
Du côté de Proxmox, le vocabulaire change, mais l’idée reste proche : une machine virtuelle peut aussi parler directement à un disque brut ou à un volume logique, sans passer par un gros fichier disque stocké sur un simple système de fichiers. La plateforme met plutôt en avant LVM, ZFS, Ceph et d’autres backends de stockage, mais le besoin d’un accès très direct au bloc existe tout autant.
Dans un déploiement classique, Proxmox propose de créer des disques de VM sous forme de volumes LVM, de datasets ZFS ou d’images qcow2/raw sur un filesystem. Pour un workload critique, beaucoup d’admins optent pour un volume LVM par disque applicatif, exposé à la VM comme un block device. On ne parle pas officiellement de « Raw Disk Mapping », mais la logique est similaire : peu d’abstraction entre l’OS invité et le support physique.
Reprenons « Studio Cartouche », qui décide d’ouvrir un second site et d’y déployer un cluster Proxmox pour certains services. Pour sa base de données de production locale, l’équipe choisit un volume LVM dédié, alloué sur un groupe de volumes construit directement sur un SSD d’entreprise. Dans l’interface Proxmox, ce volume est attaché à la VM sous forme de disque virtuel, mais en mode raw, sans couche de format qcow2 au-dessus. La base bénéficie alors d’un chemin simplifié vers le bloc, comparable à un RDM côté VMware, même si le terme n’est pas utilisé.
Autre cas fréquent : l’utilisation de ZFS avec des datasets ou des zvols mappés dans les VMs. Un zvol ZFS agit comme un block device, et peut être présenté à une VM Proxmox comme un disque raw. Là aussi, la frontière entre « disque brut » et « volume logique » est plus fluide, mais la promesse est la même : des I/O très proches du matériel, avec en bonus les fonctions de ZFS (snapshots, scrubs, compression facultative) au passage.
La différence majeure avec VMware, c’est que Proxmox pousse davantage vers une approche globale du stockage : on choisit un backend (LVM, ZFS, Ceph…), puis on décline tout le reste dessus. Le besoin de cas particuliers façon RDM se ressent un peu moins, car les chemins bloc restent déjà relativement courts. Pourtant, sur certains projets, notamment quand il faut connecter une VM Proxmox à un LUN iSCSI existant ou à un vieux disque physique recyclé, l’envie de « brancher en direct » revient vite.
Dans ce genre de scénario, la procédure typique consiste à :
- déclarer le LUN externe (par exemple iSCSI) au niveau des nœuds Proxmox ;
- créer un volume LVM ou ZFS par-dessus, ou le consommer directement comme block device ;
- attacher ce volume à une VM en mode raw, sans couche d’image supplémentaire.
Ce schéma ne s’appelle pas RDM, mais du point de vue de la VM, c’est une expérience très proche : elle voit un disque qui colle au plus près du matériel, avec un minimum d’intermédiaires. Les mêmes questions reviennent alors : comment intégrer ce volume dans la sauvegarde (snapshot ZFS, backup à l’intérieur de la VM, autre mécanisme), et comment documenter cette exception par rapport aux disques standard de l’infrastructure.
Un autre point sur lequel Proxmox se distingue concerne la transparence. Son interface et ses fichiers de configuration exposent très directement la réalité du backend de stockage. On voit rapidement si un disque de VM est un volume LVM, un zvol, une image qcow2, etc. Cette transparence aide pour les diagnostics, mais elle oblige aussi à une bonne discipline de nommage, sous peine de transformer un cluster en labyrinthe d’identifiants.
Sur la question de la virtualisation de disques bruts, Proxmox incite aussi à réfléchir au long terme. Un volume ZFS raw parfaitement adapté à un serveur PostgreSQL en 2026 peut devenir un fardeau si, trois ans plus tard, l’équipe décide de basculer l’appli vers une autre stack ou un cloud managé. C’est là que le parallèle avec RDM se retrouve : l’accès direct au bloc apporte un plus, mais il complique souvent les migrations majeures.
Globalement, que l’on soit dans vSphere ou dans Proxmox, le message reste similaire : donner un accès brut au disque à une VM est un choix d’architecture, pas juste un réglage de performance. Sous Proxmox, ce choix se traduit davantage par la sélection du backend de stockage et du type de volume (LVM, ZFS raw), mais la question de fond demeure identique : quels volumes méritent cette attention particulière, et comment les intégrer dans le reste du cycle de vie des services.
Comparer Raw Disk Mapping, VMDK et disques virtuels : critères de décision pragmatiques
Face à un nouveau projet, la tentation est souvent de poser la question en mode duel : VMDK ou RDM sur VMware, image qcow2 ou volume LVM raw sur Proxmox. En pratique, les infrastructures qui vieillissent bien s’appuient sur un mélange raisonnable des deux approches, avec un modèle par défaut très simple, et quelques écarts parfaitement assumés.
Pour une majorité de VMs, le modèle standard (VMDK sur datastore VMFS, ou disque virtuel géré par le backend défini dans Proxmox) suffit largement. Il facilite l’automatisation, les clones rapides, les snapshots avant mise à jour, la réplication de datastores, bref tout ce qui rend les projets agiles. Passer ces machines en Raw Disk Mapping ou en bloc raw aurait pour principal effet d’augmenter le nombre de manipulations à documenter pour chaque intervention.
Pour un petit nombre de services, ceux qui portent une part disproportionnée de la charge métier, la question se pose vraiment. Une base de données qui encaisse 80 % des I/O du cluster, un cluster de fichiers partagé utilisé par toute la boîte, un moteur de messagerie qui ne doit jamais perdre une transaction sont de bons candidats à un traitement à part. Dans ces cas, le Raw Disk Mapping ou son équivalent raw sur Proxmox deviennent des options sérieuses.
Une méthode qui fonctionne bien consiste à passer chaque application dans un filtre de questions simples :
- La charge est-elle très sensible à la latence disque, mesurée en millisecondes, ou seulement au débit global ?
- Le fournisseur de baie propose-t-il des fonctions clés (snapshots, réplication) qui nécessitent un accès direct au LUN ?
- Les fonctionnalités de snapshots VMware ou Proxmox sont-elles au cœur de la stratégie de sauvegarde/PRA de cette VM ?
- L’équipe en charge de la gestion des disques est-elle à l’aise avec l’ajout de cette exception dans son paysage ?
Si la réponse est oui aux deux premières questions et plutôt non aux deux dernières, le curseur penche clairement vers RDM ou raw. Dans le cas inverse, rester sur du VMDK ou de l’image classique garde tout son sens. La clé, c’est que ce choix ne devrait jamais dépendre d’un simple réflexe « plus brut = mieux », mais de ces contraintes très concrètes.
Pour fixer les idées, un rapide panorama de profils fréquents aide à trancher :
| Profil de VM | Choix recommandé | Raison principale |
|---|---|---|
| Base SQL centrale d’un ERP critique | RDM (VMware) ou volume LVM/ZFS raw (Proxmox) | Latence, réplication SAN, observabilité fine par LUN |
| Serveurs web front qui scalent horizontalement | VMDK / disque virtuel standard | Besoin de clones rapides, montée en charge par multiplication de VMs |
| Cluster de fichiers partagé multi-VM | RDM mode physique ou équivalent raw | Compatibilité clustering, partage de disque imposé par l’éditeur |
| Environnements de test, recette, sandbox | VMDK / qcow2, snapshots fréquents | Souplesse, retours arrière faciles, faible criticité |
| Appliances virtuelles fournies clé en main | Modèle préconisé par l’éditeur | Éviter de sortir des sentiers supportés |
Un point mérite d’être souligné pour 2026 : la montée en puissance des stockages NVMe et des architectures hyperconvergées ne rend pas le Raw Disk Mapping inutile, mais elle change le contexte. Sur certains clusters tout-flash NVMe avec un réseau interne très rapide, la différence entre VMDK et RDM sur une base SQL donnée devient ténue. Dans ces environnements, la simplicité retrouvée des disques virtuels standard peut redevenir un argument majeur.
Sur d’autres terrains, notamment ceux où la baie SAN offre encore beaucoup de valeur ajoutée (réplication multi-site, snapshots instantanés, intégration avec des outils de sauvegarde spécialisés), un RDM bien utilisé reste une passerelle irremplaçable entre le monde matériel et la couche de virtualisation. La frontière n’est pas théorique : elle se lit dans la documentation support des éditeurs, les contrats de service avec les fournisseurs de stockage, et l’appétit de l’équipe pour la complexité.
En fin de compte, la meilleure boussole n’est ni une promesse marketing ni un dogme technique, mais une cartographie honnête de tes applications et de tes équipes. Si l’on sait précisément pourquoi tel volume mérite un RDM, la majorité des décisions qui suivent deviennent beaucoup plus simples à prendre et à assumer.
Dans quels cas le Raw Disk Mapping apporte-t-il un vrai plus sur VMware ESXi ?
Le Raw Disk Mapping devient pertinent quand une machine virtuelle supporte une application très sensible à la latence disque, ou qui doit exploiter des fonctions avancées de la baie SAN comme les snapshots et la réplication matérielle. Sur ESXi, c’est typiquement le cas des bases de données transactionnelles centrales, de certains clusters Microsoft ou Oracle, ou de volumes utilisés pour de la réplication temps quasi réel entre sites. Pour un serveur web, un intranet ou une VM de test, un VMDK classique reste généralement plus simple et suffisant.
RDM et snapshots VMware sont-ils compatibles dans tous les cas ?
Non. En mode compatible virtuel, un disque RDM se comporte globalement comme un VMDK et reste compatible avec les snapshots VMware, ce qui permet de l’intégrer dans une stratégie de sauvegarde image-based. En mode compatible physique, la plupart des fonctions de snapshot au niveau de la VM ne sont plus disponibles, car les commandes SCSI sont passées directement au LUN. Dans ce cas, il faut basculer la protection vers des snapshots SAN ou vers des agents de sauvegarde installés dans la VM.
Proxmox propose-t-il un équivalent direct au Raw Disk Mapping de VMware ?
Proxmox n’emploie pas le terme RDM, mais permet d’atteindre un résultat proche en attachant des volumes LVM, ZFS (zvol) ou des block devices bruts directement aux machines virtuelles, en mode raw. Dans ce modèle, l’OS invité parle quasiment en direct au backend de stockage, ce qui rapproche le comportement de celui d’un RDM sous VMware. Les mêmes questions se posent alors : latence, intégration à la sauvegarde, documentation de ces volumes particuliers.
Peut-on mélanger VMDK et RDM dans une même machine virtuelle ?
Oui, et c’est même une pratique saine dans bien des cas. Par exemple, une VM peut conserver son système d’exploitation, ses fichiers temporaires et certains logs sur des VMDK classiques, tout en plaçant sa base de données principale ou son journal de transactions sur un ou plusieurs disques RDM. Cela permet de réserver la complexité du Raw Disk Mapping aux volumes qui en tirent un vrai bénéfice, sans renoncer à la souplesse des disques virtuels pour le reste.
Le Raw Disk Mapping reste-t-il pertinent avec le stockage NVMe et les architectures hyperconvergées ?
Le stockage NVMe et les architectures hyperconvergées ont réduit l’écart de performance entre disques virtuels et accès bruts, mais n’ont pas rendu le RDM obsolète. Il garde un intérêt dès qu’une application doit profiter de fonctions SAN spécifiques ou impose un dialogue très proche du matériel. En revanche, sur des clusters tout-flash centrés sur la mobilité des VMs, beaucoup d’équipes préfèrent revenir à un modèle 100 % disques virtuels pour simplifier la gestion, et ne conservent le RDM que pour quelques applications très exigeantes ou contraintes par des prérequis éditeurs.
