Sur un cluster Microsoft pour Hyper-V, il existe plusieurs manières d'adresser les volumes disques. Il est possible d'utiliser les lettres de l'alphabet latin, mais il s'agit d'une solution très peu satisfaisante car le nombre de volumes est limité (il n'y a que 25 lettres disponibles au maximum car C: est traditionnellement occupé par le disque système). Avec Windows Server 2008 R2 Microsoft a introduit CSV (Cluster Shared Volume), et les volumes disques sont accessibles via un pseudo point de montage (C:\ClusterStorage\VolumeX). La troisième alternative, d'ailleurs régulièrement utilisée avant CSV (sur Windows Server 2008), est l'utilisation du GUID de volume. C'est cette méthode qui fera l'objet de la suite de cet article.
Ainsi, à la place d'une lettre de lecteur, il est possible de recourir à une notation appelée GUID, et se présentant sous la forme d'une chaîne de caractère présentée en hexadécimal (ex : 7d586b8e-593b-11e0-8384-3c4a92f64c2c). Pour comprendre comment Windows Server 2008 R2 fonctionne sur ce point particulier, quelques explications sont nécessaires.
Volume "local"
Quand un nouveau volume de stockage (au sens général du terme et qui englobe par exemple clé USB ou autres lecteurs amovibles) est présenté au serveur et qu'une partition est créée sur ce dernier, Windows attribut automatiquement à la partition un GUID unique. Sans même attribuer une lettre de lecteur ou un point de montage à cette partition, il est directement possible d'accéder à la partition via le chemin d'accès suivant : \\?\Volume{le_guid_de_la_partition}. Windows maintient la correspondance entre partitions (représentées par une signature de volume) et GUID / chemin d'accès dans la base de registre (HKLM\System\MountedDevices).
Sur cette capture d'écran on voit bien que le volume système possède le GUID 4cf19022-fd98-11df-a9ed-806e6f6e6963 et peut être accédé par la lettre "C:" ou par \\?\Volume{4cf19022-fd98-11df-a9ed-806e6f6e6963}.
Volume de "cluster"
Dans le cas d'un cluster, un volume disque est présenté à plusieurs serveurs physiques. De ce fait, pour chacun des serveurs du cluster, un même volume disque se verra attribuer un GUID local différent.
| Serveur 1 | |
 |
|
| Serveur 2 | |
 |
Les 2 captures d'écran ci dessus montrent les valeurs prises par le GUID pour le même volume disque (ici le quorum du cluster). Sur le serveur 1 le volume disque dont la signature est "a6 40 c8 0a 00 00 01 00 00 00 00 00" possède le GUID 7d586b8f-593b-11e0-8384-3c4a92f64c2. Pour le serveur 2 le même disque possède le GUID 0e8b5a92-593f-11e0-8e07-3c4a92f66d0c.
Si l'on choisit d'adresser les volumes disques en cluster autrement que par une lettre de lecteur ou en CSV, un autre GUID sera créé pour le même volume. Ce GUID du volume en cluster sera le même sur tous les serveurs du cluster.
| Serveur 1 |
 |
| Serveur 2 |
 |
Les 2 captures d'écran ci dessus montrent que le GUID du volume en cluster prend la même valeur (7d586b8e-593b-11e0-8384-3c4a92f64c2c) sur tous les serveurs du cluster. Il s'agit du comportement attendu, dans la mesure ou quand un groupe de ressource bascule d'un serveur à un autre, le système doit pouvoir retrouver exactement les mêmes éléments (dont la ressource disque) sur le serveur destination. Ainsi, sur chaque serveur du cluster, le volume dont la signature est "a6 40 c8 0a 00 00 01 00 00 00 00 00" pourra être accédé par le chemin d'accès suivant : \\?\Volume{7d586b8e-593b-11e0-8384-3c4a92f64c2c}.
Dans la console de gestion du cluster de basculement, cette valeur peut être retrouvée dans la partie stockage et pour chaque volume. Il est possible de copier (pour la coller ailleurs) cette valeur (plutôt que de la recopier manuellement) en éditant les propriétés de la ressource disque concernée (voir capture d'écran ci dessous).
SCVMM 2008 R2
Alors quel rapport entre les GUID des volumes disques, et Virtual Machine Manager ? Tout simplement parce dans le cas qui nous occupe (un cluster Hyper-V sans CSV, donc avec un volume de cluster par machine virtuelle et adressé par un GUID), il sera nécessaire d'indiquer un chemin de type GUID lors de la création de chaque machine virtuelle. Dans SCVMM, lors de la création d'une machine virtuelle, l'assistant demande où il doit stocker cette dernière. Le champ (qui doit contenir le chemin) est également une liste déroulante qui contient un certain nombre de chemins, dont des GUID si le cluster possède des volumes disques présentés par un GUID (voir capture d'écran ci dessous).
Il arrive que dans certains cas, SCVMM propose le GUID local (comme décrit plus haut), plutôt que le GUID du volume en cluster. Dans ce cas, si une VM est créée sur le GUID local, tout ira bien jusqu'à ce qu'on tente une bascule "Live Migration". Cette dernière échouera bien entendu. Dans certains environnement, la ressource disque cluster associée à la machine virtuelle se verra même attribuer une lettre de lecteur de façon arbitraire. C'est pourquoi il est fortement recommandé de faire un copier / coller du GUID entre la console de gestion du cluster (qui contient forcément le bon GUID) et l'assistant SCVMM de création de machine virtuelle.
Un peu de Powershell
Si comme moi, vous êtes confrontés au problème décrit plus haut et que vous vous demandez quelles sont les machines virtuelles ayant un chemin avec le GUID local (d'un des serveurs du cluster) plutôt que le chemin avec le GUID du volume en cluster, Powershell peut être d'un grand secours. Il vous permettra d'interroger le chemin d'accès actuel de chaque VM (avec les cmd-let SCVMM) et de le comparer au GUID du volume en cluster. Retrouver le GUID d'un volume disque en cluster n'est pas forcément évident au premier abord et j'ai moi même passé quelques heures à trouver les bonnes informations.
Le GUID d'un volume disque en cluster est "caché" dans un tableau d'octets que l'on retrouve dans les paramètres du cluster pour une ressource donnée (ici la ressource est bien évidemment une ressource disque). Pour lister les ressources du cluster utiliser la commande Get-ClusterResource. Pour connaître les paramètres du cluster pour une ressource en particulier la commande est la suivante : Get-ClusterResource 'nom_de_la_ressource_disque' | Get-ClusterParameter .
La capture d'écran ci dessus montre le résultat de la commande Powershell citée plus haut. Le champ qui nous intéresse et qui contient entre autres le GUID est DiskVolumeInfo qui est un tableau d'octets. Pour connaître précisément comment interpréter ce tableau voir cette page du MSDN : http://msdn.microsoft.com/en-us/library/bb309235(v=vs.85).aspx . Pour résumer, les 4 premiers octets représentent le nombre de partitions dans le volume et les 4 suivants sont vides. Après ces 8 premiers octets, le tableau contient un bloc de 40 octets par partition. Dans ce bloc de 40 octets, les 8 premiers représentent l'offset de démarrage de la partition ("Starting Offset"), les 8 suivants donnent la taille de la partition, les 4 d'après indiquent le numéro de la partition et les 4 encore ensuite indiquent la lettre de lecteur. Enfin les 16 derniers octets de ce bloc de 40 contiennent le GUID. Si l'on considère un volume disque en cluster avec une seule partition, le GUID sera contenu dans le tableau d'octets DiskVolumeInfo, de l'indice 32 à 47. Powershell renvoi un tableau d'octets en décimal, il faudra donc convertir chaque valeur en hexadécimal pour construire la chaîne représentant le GUID. Enfin le GUID est exprimée de la manière suivante : "4 octets-2 octets-2 octets-2 octets-6 octets".
Sur le lien MSDN que je cite dans cet article, on remarque qu'avec l'exemple donné le GUID est lu de l'indice (du tableau) supérieur vers l'indice inférieur, et ce par "morceau" de GUID (séparé par des tirets). Ainsi le tableau "D7 69 5F A4 65 91 B5 48 06 AE 61 64 3D 6B B2 4D" deviendrais le GUID A45F69D7-9165-48B5-AE06-4DB26B3D6461.
Je n'ai pas réussi à retrouver cette règle sur tous les clusters que j'ai traité (Windows 2008 R2 et Windows 2008 R2 SP1), et peut être s'agit-il de la règle sur Windows Server 2008. La règle que j'ai retrouvé sur tous mes clusters est la suivante : "4 octets lus de l'indice 35 à 32 - 2 octets lus de l'indice 37 à 36 - 2 octets lus de l'indice 39 à 38 - 2 octets lus de l'indice 40 à 41 - 6 octets lus de l'indice 42 à 47". En reprenant le même tableau exemple "D7 69 5F A4 65 91 B5 48 06 AE 61 64 3D 6B B2 4D", le GUID est maintenant A45F69D7-9165-48B5-06AE-61643D6BB24D.
Voici un exemple de script Powershell qui vous permettra de retrouver le GUID des volumes disques en cluster (selon la règle que j'ai constaté).
Import-Module Failoverclusters
$diskVols = Get-ClusterResource | Where {$_.ResourceType -match "Physical Disk"}
foreach ($disk in $diskVols)
{
$volParams = Get-ClusterResource $disk.Name | Get-ClusterParameter | where {$_.Name -match "DiskVolumeInfo"}
$id = ""
for ($i = 35; $i -ge 32; $i--)
{
if ($volParams.value[$i] -le 15)
{$id = $id + "0" + [convert]::ToString($volParams.value[$i],16)}
else
{$id = $id + [convert]::ToString($volParams.value[$i],16)}
}
$id = $id + "-"
for ($i = 37; $i -ge 36; $i--)
{
if ($volParams.value[$i] -le 15)
{$id = $id + "0" + [convert]::ToString($volParams.value[$i],16)}
else
{$id = $id + [convert]::ToString($volParams.value[$i],16)}
}
$id = $id + "-"
for ($i = 39; $i -ge 38; $i--)
{
if ($volParams.value[$i] -le 15)
{$id = $id + "0" + [convert]::ToString($volParams.value[$i],16)}
else
{$id = $id + [convert]::ToString($volParams.value[$i],16)}
}
$id = $id + "-"
for ($i = 40; $i -le 41; $i++)
{
if ($volParams.value[$i] -le 15)
{$id = $id + "0" + [convert]::ToString($volParams.value[$i],16)}
else
{$id = $id + [convert]::ToString($volParams.value[$i],16)}
}
$id = $id + "-"
for ($i = 42; $i -le 47; $i++)
{
if ($volParams.value[$i] -le 15)
{$id = $id + "0" + [convert]::ToString($volParams.value[$i],16)}
else
{$id = $id + [convert]::ToString($volParams.value[$i],16)}
}
write-host $disk.Name " : " $id
}
N'hésitez pas à laisser vos remarques éventuelles dans les commentaires.
