Raw Disk Mapping (RDM) : configuration sous VMware et alternatives

Donner un accès direct à un disque brut depuis une machine virtuelle change totalement la façon de penser ton infrastructure de stockage. Avec le Raw Disk Mapping (RDM) sous VMware vSphere, tu peux exposer un LUN de SAN quasiment tel quel à un OS invité, tout en gardant les services de la couche de virtualisation. C’est un outil puissant pour certaines applis gourmandes en I/O, pour du clustering ou pour préparer une migration vers d’autres technologies de stockage.

Le revers de la médaille, c’est que le RDM est souvent mal compris, mal utilisé, et parfois mis en place « parce qu’on a toujours fait comme ça » alors que des alternatives plus modernes existent. Entre le mode physique, le mode virtuel, les contraintes de snapshots, de vMotion, de NPIV, et les nouvelles options comme les VMDK classiques optimisés, les Virtual Volumes (vVols) ou même un bon vieux LVM dans l’invité, il y a de quoi s’emmêler. L’enjeu, ce n’est pas de cocher une case exotique dans vSphere, c’est de garder une architecture lisible, maintenable, et surtout adaptée à ce que ton applicatif attend vraiment du stockage.

Ce qui suit passe en revue le fonctionnement du Raw Disk Mapping, les étapes concrètes de configuration dans VMware, les choix de modes et d’options, puis les alternatives RDM qui tiennent la route en 2026. L’idée est simple : après lecture, tu dois savoir si tu as vraiment besoin d’un RDM, comment le déployer proprement, et dans quels cas il vaut mieux choisir une autre approche plutôt que d’empiler de la complexité inutile.

En bref

• RDM permet à une VM d’accéder directement à un disque brut (LUN SAN) tout en gardant un fichier de mappage sur une banque de données VMFS.
• Deux modes principaux existent : compatibilité physique pour un accès très proche du matériel, et compatibilité virtuelle pour profiter des fonctionnalités VMware (snapshots, clonage, etc.).
• La configuration RDM dans vSphere repose sur un fichier .vmdk spécial qui contient uniquement des infos de mappage, pas les données elles-mêmes.
• Les RDM sont utiles pour certains clusters, appliances de stockage, migrations ou outils qui exigent un accès bas niveau au LUN, mais ils compliquent la gestion quotidienne.
• Les alternatives RDM modernes incluent des VMDK bien dimensionnés, les vVols, le passthrough de contrôleurs, ou la gestion du stockage avec LVM / MD dans le système invité.

Raw Disk Mapping et VMware : comprendre ce qui se passe vraiment sous le capot

Avant de cliquer sur « Ajouter un disque RDM » dans vSphere, ça vaut le coup de bien comprendre ce que fait la plateforme derrière l’interface. Quand tu définis un Raw Disk Mapping, tu ne présentes pas un simple fichier de disque virtuel .vmdk classique à ta VM. Tu crées un tout petit fichier de mappage, stocké sur une banque de données VMFS, qui pointe vers un LUN brut exposé par ton SAN.

Ce fichier a la même extension .vmdk qu’un disque virtuel standard, mais son rôle est radicalement différent. Au lieu de contenir les blocs de données, il joue le rôle de raccourci très avancé : l’OS invité lit et écrit comme si tout se passait sur un disque virtuel, alors que les blocs arrivent et repartent directement vers le LUN physique. Le stockage réel ne transite donc pas par un fichier volumineux sur VMFS, mais file tout droit vers ton array SAN.

C’est là que le RDM devient intéressant pour certaines applis qui veulent dialoguer presque directement avec le SAN. Par exemple, des outils de réplication spécifiques au fournisseur de stockage, ou des clusters d’applications qui ont besoin de gérer eux-mêmes la façon dont les blocs sont écrits et verrouillés. Dans ce cas, un VMDK classique peut devenir une couche de trop.

Dans vSphere, le RDM apparaît côté VM comme un « disque dur » dans la liste des périphériques virtuels, mais le moteur VMware sait que ce disque est particulier. C’est lui qui fait le lien entre la VM, le fichier de mappage sur VMFS, et le disque brut vu par les hôtes ESXi. Tu conserves donc certains services de l’hyperviseur : gestion des permissions, suivi de la ressource, liens avec vCenter, etc.

Il faut aussi garder en tête que le RDM ne remplace pas la gestion SAN. Si ton LUN est mal découpé, mal répliqué, ou partagé n’importe comment entre plusieurs environnements, le RDM ne va rien arranger. Il expose juste ce LUN à la VM de façon plus directe, avec les qualités et les défauts du stockage sous-jacent. Un LUN saturé restera une source de lenteurs, même enveloppé dans un RDM « bien configuré ».

Dernier point important : contrairement à ce qu’on entend parfois, un environnement moderne ne devient pas soudainement « obsolète » s’il n’utilise pas de RDM. Pour la majorité des workloads, un bon VMDK sur VMFS ou sur vVol correctement dimensionné donne des performances et une souplesse très correctes. Le RDM est une option ciblée, pas une obligation.

Différences clés entre RDM, VMDK classique et stockage présenté directement

Pour un admin qui jongle entre plusieurs approches, le plus simple est de comparer. Tu as trois grandes familles de scénarios : le VMDK standard sur VMFS, le RDM, et la présentation directe de disques physiques sans passer par VMFS (par exemple via passthrough de contrôleur).

Voici un tableau synthétique pour y voir plus clair sur les usages avec VMware :

Chaque choix vient avec son prix : soit tu gagnes en contrôle côté invité et SAN, soit tu gagnes en souplesse dans vSphere. Penser que le RDM « accélère tout » par principe est une erreur fréquente. Le vrai sujet, c’est de coller au besoin fonctionnel, pas de chasser un benchmark théorique.

Créer et configurer un disque RDM dans vSphere pas à pas

Passons au concret. Imagine une PME industrielle, appelons-la NordMétal, qui veut virtualiser une appli de gestion de production connectée à un SAN Fibre Channel historique. L’éditeur impose un accès direct à un LUN pour sa réplication propriétaire. Le bon candidat, ici, c’est un Raw Disk Mapping bien cadré.

Dans VMware vSphere, la création d’une VM avec RDM suit la même trame qu’une VM standard, avec quelques étapes en plus sur le disque. On part d’un objet parent valide dans l’inventaire (datacenter, cluster, pool de ressources, hôte seul, peu importe) et on déclenche la création d’une nouvelle machine virtuelle. Les écrans initiaux restent classiques : nom, compatibilité matériel, banque de données pour les fichiers de configuration, choix du système invité.

Au moment de personnaliser le matériel, vSphere crée par défaut un disque virtuel VMDK sur la banque de données choisie. Si tu veux travailler uniquement avec un disque brut via RDM, ce disque peut être supprimé. Un simple clic sur l’icône de suppression en face du disque suffit, la VM restera tout à fait opérationnelle avec un RDM comme unique disque de données (voire de système, si tu assumes ce choix).

Ensuite, dans la partie « Ajouter de nouveaux périphériques », tu choisis Disque RDM. vSphere te présente alors la liste des LUN bruts que l’hôte ESXi voit, mais qui ne sont pas déjà revendiqués par un système de fichiers VMFS ou par un autre usage. C’est souvent à ce moment que les erreurs commencent : si l’équipe stockage ne t’a pas clairement documenté les LUN, tu risques de mapper le mauvais volume. D’où l’intérêt d’une convention de nommage claire côté SAN.

Une fois le LUN cible sélectionné, vSphere génère le fichier de mappage dans la banque de données VMFS que tu auras choisie. Ce fichier apparaît dans la liste des périphériques comme un nouveau « disque dur ». Tu peux ensuite dérouler ses propriétés pour régler les paramètres clés : emplacement du fichier, mode de compatibilité, mode de disque.

Choix de la banque de données, du mode RDM et des options de disque

Le premier réglage concerne l’emplacement du fichier RDM. Deux stratégies reviennent souvent. La plus simple consiste à placer ce fichier sur la même banque de données que les autres fichiers de la VM, ce qui simplifie la lisibilité et certains scénarios de vMotion. C’est même une obligation si tu utilises NPIV (N_Port ID Virtualization) et que tu veux garder la capacité de migrer la VM avec vMotion tant que les identités NPIV restent cohérentes.

Tu peux aussi décider d’héberger le fichier RDM sur une autre banque de données VMFS que le reste de la VM, par exemple pour des raisons d’organisation ou de performances de métadonnées. Dans la pratique, sauf contrainte particulière, regrouper les fichiers de la même VM reste plus simple à maintenir et à déboguer.

Deuxième décision : le mode de compatibilité. C’est là que tu choisis entre le mode physique et le mode virtuel. En mode physique, l’OS invité a un accès très direct au LUN. C’est utile si l’application tient absolument à piloter des fonctions avancées du SAN, ou si tu mets en place un cluster invité qui veut gérer lui-même les verrous de disque. En contrepartie, tu perds plusieurs fonctionnalités conviviales de vSphere : impossible de cloner la VM en copiant ce disque, pas de conversion en template avec ce volume, et certaines migrations impliquant une copie du disque sont exclues.

En mode virtuel, le RDM se comporte davantage comme un VMDK. Tu peux faire des snapshots, cloner la VM, la transformer en modèle, et surtout migrer de façon flexible. Si tu clones le disque ou le modèle, le contenu du LUN brut est copié dans un fichier .vmdk classique. Lors d’une migration Storage vMotion, soit tu déplaces simplement le fichier de mappage, soit tu convertis totalement le contenu du LUN en VMDK. Ce mode sert souvent de tremplin pour sortir progressivement d’un RDM, tout en gardant la maîtrise des données.

Enfin, pour les RDM en mode virtuel seulement, tu peux définir un mode de disque. Trois options existent et ont un impact direct sur les sauvegardes et les tests :

• Dépendant : le disque est inclus dans les snapshots. Tout snapshot de la VM capture donc aussi l’état du RDM.
• Indépendant persistant : le disque se comporte comme un disque physique normal, toutes les écritures sont durables et ne sont pas capturées par des snapshots niveau VM.
• Indépendant non persistant : les modifications sont écrites dans un journal de rétablissement temporaire supprimé à l’arrêt ou au reset de la VM, ce qui permet de repartir à l’identique à chaque démarrage.

Cette dernière option est souvent sous-exploitée alors qu’elle est redoutable pour faire des tests destructifs côté applicatif, sans devoir reconstruire un environnement en permanence. Un RDM en mode virtuel, disque indépendant non persistant, peut devenir un bac à sable très pratique pour simuler des scénarios compliqués.

Modes RDM, snapshots, vMotion : ce qui marche bien et ce qui casse en production

On arrive maintenant au point qui fâche souvent : tout ce qui concerne les mouvements de VMs, les sauvegardes et les clones dès qu’un Raw Disk Mapping entre dans l’équation. Sur le papier, RDM promet un bel équilibre entre accès direct au disque brut et services de la plateforme de virtualisation. Dans la vraie vie, certains choix de configuration ferment des portes sans que l’équipe en ait conscience.

Premier sujet, les snapshots. En mode de compatibilité physique, un RDM ne participe pas aux snapshots de VM. Tu peux toujours prendre un snapshot, mais il ne contiendra pas l’état du LUN mappé. Résultat : toute stratégie de sauvegarde qui se base uniquement sur des snapshots vSphere plus sauvegarde dans le backend va sortir des images incohérentes si l’app critique réside sur ce RDM. C’est une bonne manière de découvrir en urgence, un lundi matin, que le plan de reprise n’existait que dans les slides.

En mode virtuel, les snapshots fonctionnent, à condition que le disque ne soit pas marqué comme indépendant. Tu peux donc intégrer le RDM dans une politique de backup unifiée, ou l’exclure volontairement si un autre outil prend déjà en charge la protection de ce LUN. Dans bien des cas, le bon compromis consiste à garder le mode virtuel et à laisser l’applicatif ou le SAN gérer sa propre cohérence, tout en gardant une sauvegarde de la VM pour la couche système.

Deuxième sujet, vMotion et Storage vMotion. Le vMotion standard, qui déplace une VM d’un hôte à l’autre sans changer la localisation du stockage, fonctionne très bien avec des RDM, tant que les hôtes ont tous accès au même LUN. C’est exactement comme un VMDK sur VMFS partagé. Les ennuis arrivent avec Storage vMotion, qui doit parfois copier ou transformer le support de stockage. Un RDM en mode physique ne peut pas être déplacé de cette manière : le LUN reste où il est, point barre.

Avec un RDM en mode virtuel, Storage vMotion propose deux options. Soit tu ne touches qu’au fichier de mappage, et tu déplaces juste ce petit fichier d’une banque de données VMFS à une autre, le LUN brut restant à sa place sur le SAN. Soit tu profites de l’opération pour tout convertir en VMDK, ce qui revient à vidanger le LUN vers un disque virtuel classique. Ce dernier scénario est pratique pour sortir progressivement d’un héritage SAN trop rigide, sans couper le service.

Troisième angle, la duplication des VMs. Clonage, conversion en template, déploiement de masse : tout ça repose sur la capacité à copier les disques. Avec un RDM en mode physique, oublie. Tu vas cloner la VM sans son disque RDM, ou te retrouver avec un clone à moitié exploitable. En mode virtuel, au contraire, tu peux dupliquer le contenu du LUN dans un VMDK comme partie intégrante de l’opération. C’est souvent sous-estimé, alors que cela sert de levier pour transformer une architecture sans big-bang.

Dernier cas à surveiller : NPIV. Si tu l’utilises pour donner à une VM ses propres identités Fibre Channel, les contraintes se resserrent. Les fichiers de la VM, y compris le fichier de mappage RDM, doivent résider sur la même banque de données, et certaines opérations de Storage vMotion sont bloquées. Là aussi, le RDM ne fait pas « gagner » des fonctions, il impose des règles supplémentaires qu’il faut assumer.

Au fond, RDM et agilité ne font pas toujours bon ménage. Plus tu multiplies les RDM physiques, plus la plateforme perd en souplesse. La règle simple : réserver le RDM aux volumes qui ont une vraie justification technique, et laisser tout le reste en VMDK ou en vVol.

Quand choisir RDM plutôt que VMDK : cas concrets, limites et erreurs fréquentes

Face au choix RDM ou VMDK, beaucoup d’équipes se racontent l’histoire suivante : « RDM, c’est plus proche du physique, donc c’est plus rapide ». Dans les infrastructures actuelles, avec des arrays SAN optimisés, du cache agressif et du réseau rapide, cette équation ne tient pas vraiment. La différence de performances brutes entre un bon VMDK et un Raw Disk Mapping est souvent marginale, voire invisible, comparée à ce que font le SAN et l’application.

Le vrai argument en faveur du RDM réside ailleurs : certains logiciels veulent accéder au LUN sans la couche abstraite d’un VMDK pour des raisons fonctionnelles, pas pour grappiller quelques microsecondes. C’est le cas de solutions de réplication bloc-à-bloc fournies par des constructeurs de stockage. Elles comparent directement les blocs sur deux LUN pour propager les changements. En mettant le LUN derrière un VMDK, tu casses leur modèle mental.

Autre cas fréquent, les clusters invités. Si tu montes un cluster Windows Failover Cluster ou Linux Pacemaker qui partage un disque entre plusieurs VMs, les instructions officielles de certains éditeurs t’orientent vers un RDM en mode physique. Le but est de laisser le cluster gérer lui-même les verrous et les écritures concurrentes sur le disque partagé. Dans ce scénario, le RDM n’est pas une coquetterie, c’est une exigence de support.

On croise aussi des appliances virtuelles spécialisées qui exigent un accès très brut à un LUN pour faire office de passerelle de stockage, de cible de sauvegarde ou de système de fichiers distribué. Là encore, le Raw Disk Mapping sert de trait d’union entre le monde SAN et un logiciel qui, historiquement, vivait sur du physique.

Côté limites, la première erreur est de faire du RDM la solution par défaut « pour les grosses bases de données ». Une base SQL bien dimensionnée sur VMDK, avec un bon alignement bloc, suffisamment d’IOPS garantis dans le SAN, et une latence contrôlée donne d’excellents résultats. En ajoutant un RDM sans comprendre ce qui bloque vraiment, tu compliques la vie des sauvegardes, de la supervision et des migrations, sans régler le goulot d’étranglement, qui se trouve souvent du côté des requêtes, des index ou de la contention applicative.

Deuxième erreur, faire cohabiter de multiples approches sans ligne directrice. Dans certains environnements, tu trouves des VM avec trois VMDK, deux RDM virtuels, un RDM physique partagé, plus un bout de stockage local. Quand un incident survient, personne ne sait plus où résident les données critiques, ni quel outil est censé les protéger. Mieux vaut quelques règles simples que tout le monde comprend, plutôt qu’un patchwork de techniques exotiques.

Pour repérer si tu vas trop loin avec le RDM, pose-toi trois questions très terre à terre : l’éditeur de l’appli le réclame-t-il noir sur blanc pour des raisons précises, ton équipe de stockage t’apporte-t-elle une vraie valeur ajoutée sur ce LUN (réplication matérielle, snapshot SAN orchestré, etc.), et as-tu documenté comment ce volume est sauvegardé et migré ? Si tu réponds « non » à deux de ces points, il y a probablement un VMDK qui t’attend.

Au final, le RDM reste une option spécialisée. Bien choisie et assumée, elle rend service. Par réflexe ou par superstition, elle devient un piège technique qui enferme tes VMs dans le passé.

Alternatives RDM modernes : vVols, VMDK, LVM invité et autres chemins possibles

Le paysage du stockage virtualisé ne s’est pas arrêté au Raw Disk Mapping. VMware pousse depuis des années les Virtual Volumes (vVols), qui proposent une façon plus fine de présenter des volumes logiques au niveau de la VM, directement pilotés par l’array. Pour beaucoup de besoins où on songe instinctivement au RDM, un vVol bien géré peut donner la même granularité, avec une intégration bien plus fluide dans vSphere.

Avec les vVols, chaque disque de VM devient un objet premier dans le stockage, mappé un pour un avec une entité côté SAN. Tu gardes les fonctionnalités natives de VMware (vMotion, snapshots pilotés, clones rapides), tout en profitant des services avancés de l’array : QoS, réplication, snapshots matériels, etc. Pour une base de données importante ou une appli sensible, c’est souvent plus propre qu’un RDM en mode physique qui bloque la moitié des automatisations.

Autre alternative, le retour au VMDK classique, mais pensé correctement. Beaucoup de critiques contre les disques virtuels viennent de déploiements approximatifs : VMFS surchargé, partage sauvage de LUN, absence de garanties d’IOPS, monitoring quasi inexistant. En corrigeant ces points, un VMDK bien isolé sur une banque de données calibrée peut répondre aux besoins de la plupart des workloads, sans l’ombre d’un RDM.

On sous-estime aussi ce qu’un bon LVM (Logical Volume Manager) ou équivalent peut faire dans le système invité. Sous Linux, combiner plusieurs VMDK dans un groupe de volumes LVM, avec du striping, du mirroring ou des snapshots locaux, donne un contrôle très fin à l’équipe système, sans bousculer la couche de virtualisation. Côté Windows, des volumes dynamiques bien utilisés ou Storage Spaces remplissent un rôle proche. L’idée est simple : confier au système invité ce qui relève de son domaine, sans nécessairement passer par un RDM.

Pour certains appliances ou cas ultra exigeants, le passthrough de contrôleur (donc la présentation directe d’un HBA ou d’un contrôleur RAID à la VM) reste sur la table. Là, on sort presque de la logique de virtualisation classique : la VM devient une sorte de firmware logiciel très lié à son matériel. Pratique pour un serveur de stockage virtuel ou un labo, nettement moins pour un SI qui doit évoluer et se déplacer.

Enfin, il y a le scénario hybride, qui mixe RDM, VMDK, vVols et outils de stockage internes à l’OS. Par exemple, garder certains LUN en RDM virtuel pour une période de migration, tout en plaçant les nouveaux volumes applicatifs en vVol et les données transitoires en VMDK. Ce genre de plan impose une documentation sérieuse et une gouvernance claire, mais il permet de sortir par le haut d’un environnement SAN hérité sans tout casser.

Si on regarde froidement l’évolution des infrastructures en 2026, la tendance est nette : le RDM ne disparaît pas, mais il recule. Là où il était parfois utilisé par réflexe, il se voit peu à peu remplacé par des approches plus intégrées, qui parlent mieux le langage de la plateforme et des équipes DevOps. En gardant cette perspective, chaque nouveau RDM créé devrait être questionné, pas juste reproduit.

Dans quels cas le Raw Disk Mapping reste vraiment pertinent sous VMware ?

Le RDM garde du sens quand une application ou un éditeur exige un accès direct au LUN pour des fonctions précises : réplication bloc par bloc fournie par le constructeur de stockage, cluster invité qui partage un disque commun, appliance virtuelle qui agit comme passerelle SAN. Dans ces scénarios, le VMDK peut masquer des informations ou gêner la gestion des verrous. Pour des serveurs applicatifs classiques, des bases de données générales ou des frontaux web, un VMDK bien dimensionné ou un vVol suffit dans la plupart des cas.

Mode physique ou mode virtuel pour un RDM vSphere ?

Le mode physique donne à l’OS invité un accès très proche du matériel, au prix de fortes limites sur les fonctionnalités VMware (clones, templates, Storage vMotion). Il est adapté aux clusters invités et aux outils SAN qui s’attendent à parler directement au LUN. Le mode virtuel se comporte davantage comme un VMDK : snapshots possibles, clones, conversions. Il fonctionne bien pour des migrations progressives ou pour garder de la souplesse tout en exposant un LUN brut. Si tu n’as pas une exigence claire de mode physique, le mode virtuel est en général plus facile à vivre.

Un RDM améliore-t-il vraiment les performances par rapport à un VMDK ?

Dans beaucoup d’environnements actuels, la différence de performances entre un RDM et un VMDK bien conçu est faible. Les goulots viennent plutôt du SAN lui-même, des profils d’IO, du code applicatif ou des index de base de données. Le RDM enlève une fine couche d’abstraction, mais ne transforme pas un LUN saturé en fusée. Miser sur le RDM comme accélérateur magique est donc une mauvaise stratégie. Il faut d’abord régler l’architecture de stockage, la qualité des banques de données et la configuration de l’appli.

Comment sauvegarder une VM qui utilise un RDM ?

La stratégie dépend du mode choisi. En mode physique, le RDM ne participe pas aux snapshots de VM, il faut donc utiliser un outil capable de parler au SAN (snapshots matériels, réplication) ou une solution d’agent dans l’OS invité qui sauvegarde les données directement. En mode virtuel, tu peux inclure le RDM dans les snapshots tant que le disque n’est pas marqué comme indépendant. Une approche courante consiste à sauvegarder la VM pour la couche système, et à laisser la protection du LUN à un outil natif du stockage.

Faut-il migrer tous les anciens RDM vers des vVols ou VMDK ?

Pas forcément. Si un RDM fonctionne, qu’il est documenté, qu’il répond à une exigence de support et que le plan de sauvegarde est clair, tu peux le garder tant qu’il n’entrave pas l’évolution de ta plateforme. En revanche, pour chaque nouveau projet, il vaut la peine d’évaluer les alternatives : vVols, VMDK dédiés, LVM dans l’invité. Lorsque tu planifies une refonte de stockage ou une montée de version majeure de vSphere, c’est un bon moment pour réduire le nombre de RDM et simplifier l’architecture, plutôt que d’en créer de nouveaux par habitude.