Corrélation VMDK aux volumes Windows: méthode fiable.

Quand le bricolage procure plus de joie que la technique

Je vous l’avoue volontiers : j’ai ressenti plus de satisfaction à changer deux pneus sur une vieille remorque qu’à résoudre un problème de corrélation entre VMDK, Windows et leurs volumes. Et pourtant, techniquement, le second défi était bien plus ardu.
Pourquoi ? Parce que trouver une méthode fiable pour établir cette corrélation VMDK aux volunes Windows sans activer l’option disk.EnableUUID est un véritable casse-tête…

L’option magique… qui ne sert à rien dans mon cas

En effet, disk.EnableUUID permet de faire remonter le numéro de série des disques dans le guest OS. C’est pratique, propre… et inutilisable si votre parc de VM n’a pas cette option activée, et que vous ne pouvez pas la modifier facilement (surtout en prod).

Un outil maison pour une frustration bien réelle

C’est justement de cette frustration (et de cette obstination) qu’est né ce petit outil PowerShell : Get-VMStorageWinMapping. Grâce à lui, vous obtenez une correspondance claire entre les fichiers VHD/VHDX utilisés par vos machines virtuelles Hyper-V et les volumes visibles dans Windows – sans bidouilles obscures ni dépendances risquées.

Les trois méthodes de corrélation VMDK aux volumes Windows

Pour résoudre une corrélation VMDK aux volumes Windows, j’ai testé trois approches..

Méthode 1 : la fausse bonne idée

Je ne vais pas m’attarder. On compare simplement la taille des fichiers VMDK avec celles des volumes dans Windows. Ça marche… sauf quand deux volumes font la même taille. Et dans les environnements pro, devinez quoi ? C’est courant.

Méthode 2 : la méthode miracle qui ne marche jamais en prod

Beaucoup la vendent comme la solution idéale. En réalité, elle repose sur l’activation de disk.EnableUUID. Et pour ça, il faut éteindre la VM. Super pratique en production, n’est-ce pas ? Merci, mais non.

Méthode 3 : là où ça devient vraiment intéressant

Comparer les disques via leurs IDs semble prometteur. Mais quel ID utiliser ? Celui du disque ? Du bus ? Du slot ? De la carte SCSI ? Très vite, on s’y perd.

L’idée : exploiter la « location » affichée par Windows

Certains IDs ne se comparent pas tels quels. Ils nécessitent une conversion. C’est le cas du slot ID, aussi appelé ID de la carte SCSI. Windows ne l’affiche pas directement mais le traduit dans l’interface sous forme de « location » (ou « localisation » en français).

Quand j’ai mis en lumière cet ID, je me suis dit : génial, ce n’était pas sorcier. Mais en validant mon script à plus grande échelle, je suis tombé sur un Slot ID un peu singulier, présenté par VMware sous le numéro 1184 et observé sous Windows comme 161.

Un secret bien gardé

Après de longues conversations avec ChatGPT (il n’a pas réponse à tout, mais il aide à structurer ses idées), je suis tombé sur une liste d’IDs PCI étonnante :

ethernet0.pciSlotNumber = « 160 »
ethernet1.pciSlotNumber = « 1184 »
ethernet2.pciSlotNumber = « 192 »
ethernet3.pciSlotNumber = « 1216 »
ethernet4.pciSlotNumber = « 224 »
ethernet5.pciSlotNumber = « 1248 »
ethernet6.pciSlotNumber = « 256 »
ethernet7.pciSlotNumber = « 1280 »

Si j’en crois l’ordre des pci slots on se rend compte qu’une carte sur deux à 1000 de plus qui semble venir de nul part

En regardant cette liste, on remarque qu’une carte sur deux a 1024 de plus, comme si ce bit supplémentaire venait de nulle part.

Une hypothèse… mais pas besoin qu’elle soit bonne

Hypothèse principale :

Ce décalage systématique de 1024 pourrait être une stratégie VMware pour identifier une deuxième « banque » de périphériques PCI ou une forme de séparation entre différents types de périphériques.

Il est possible que VMware attribue :

1. Des slots normaux aux périphériques de base.
2. Des slots supérieurs à 1000 à des périphériques considérés comme « secondaires » ou appartenant à un autre contrôleur virtuel.

Est-ce vrai ? Je ne suis pas sûr. Mais ça n’a pas tellement d’importance pour ce que je vais montrer ensuite.

Le secret percé : une histoire de bits

Je vous la fais courte. On a entamé une discussion sur la représentation binaire (c’était mon idée 😉), et là, tout s’éclaire. Voici un extrait de ce que j’ai observé :

Et nous avons tenté de poursuivre la logique:

Vous avez vu ? Un bit de poids fort à gauche devient un bit de poids faible à droite. En d’autres termes :
Windows = (VMware – 1024) + 1

Script PowerShell pour établir la corrélation VMDK aux volumes Windows

Ce script permet une corrélation VMDK Windows volume claire et automatisée, même sur des VMs complexes.

Voici un exemple d’appel simple :

.\Get-VMStorageWinMapping.ps1

En sortie, vous obtiendrez un tableau clair, avec pour chaque volume :

• Le nom du disque (Windows)
• La taille
• Le numéro de slot PCI
• Le nom du fichier VMDK associé (si déterminé)
• La lettre de volume correspondante

Mickael R.

Ingénieur tout terrain, je m’adapte avec rigueur et autonomie. Mon sens du travail en commun fait de moi un atout dans une équipe technique. Le pilier de mon métier? l’automatisation par le script!