SCSI on Zwindler's Reflection

[Tutoriel] Reconstruire le fichier de définition « .vmdk » manquant lorsqu’on a que le « -flat.vmdk »

Sat, 01 Aug 2015 10:30:48 +0000

Introduction de principe sur les disques durs virtuels par VMware

Quite à enfoncer des portes ouvertes, les disques virtuels chez VMware ont l’extension .vdmk. Mais en vrai, il y a deux types de fichiers VMDK et chaque disque dur virtuel VMware dispose des deux fichiers pour fonctionner :

le fichier contenant les données brutes, avec comme nom mavm_X-flat.vmdk
un fichier de configuration en mode texte avec des informations sur l’emplacement des données, le contrôleur à utiliser, la taille, … et nommé mavm_X.vmdk

Généralement, les fichiers VMDK sont nommés comme leur VM et un indice (X) apparaît quand il y en a plusieurs. Cependant, ces fichiers peuvent être renommés pour placés dans d’autres dossiers et fausser la numérotation donc ne prenez pas les informations fournies par le nom du fichier pour argent comptant.

Récupérer les informations nécessaires

Au même titre que perdre le fichier -flat qui contient les données serait problématique pour le fonctionnement de votre VM, la perte du fichier de définition est assez fâcheux. Le disque n’est tout simplement pas utilisable car l’ESXi ne sait pas interpréter le fichier -flat seul.

Cependant, on peut le reconstruire. Ouf !

D’ailleurs, on peut reconstruire le fichier -flat.vmdk aussi, mais sans les données bien entendu. Du coup je trouve que c’est quand même nettement moins intéressant que le contraire. Je ferai peut être quand même un article là dessus.

La première chose à faire est de déterminer le type de contrôleur virtuel que la machine virtuelle utilise pour se connecter au disque.

C’est très important et il peut parfois y en avoir plusieurs sur une même VM. On trouve ces informations dans le fichier de définition de la VM (.vmx) ou directement depuis la console VMware.

En règle générale, ce paramètre est souvent laissé par défaut et dans mon cas, la VM utilisait un lsilogic en position 0 (scsi0). Le disque était lui branché sur l’emplacement 0 du contrôleur, aussi visible dans la console comme 0:0.

scsi0.present = "true"
scsi0.sharedBus = "virtual"
scsi0.virtualDev = "lsilogic"

L’étape d’après consiste à savoir quelle est la taille du disque virtuel. En se connectant en SSH sur l’ESXi qui a accès au datastore, vous pouvez retrouver simplement cette information via un ls -l qui vous donnera la taille totale que peut avoir le disque.

# ls -l mavm-flat.vmdk
-rw------- 1 root root 1036160860160 Dec 11 12:30 mavm-flat.vmdk

Maintenant qu’on dispose de toutes les informations nécessaires, on va recréer un disque virtuel vierge temporaire. On récupérera et adaptera son fichier .vmdk pour pouvoir réutiliser notre fichier -flat.vmdk.

# vmkfstools -c 1036160860160 -a lsilogic -d thin temp.vmdk

La commande devrait créer deux fichiers temp.vmdk et temp-flat.vmdk. Pour plus d’options concernant la commande, je vous invite à lire le kb suivant : kb.vmware.com (lien mort)

Thin provisioning ou pas ?

Vous avez peut être noté le -d thin dans la commande un peu plus haut. Tous mes disques sont en Thin Provisioning car ça permet de ne consommer que l’espace réellement nécessaire. VMware a prouvé que les performances étaient similaire à l’allocation normale du disque à sa création et dans la majorité des cas c’est donc 100% gagnant.

Cependant, dans le cas où votre disque n’est pas en Thin provisioning, il y a quand même intérêt -pour le disque temporaire- à le créer avec l’option -d thin. Comme nous n’allons réutiliser que le fichier de définition .vmdk, le fichier temp-flat.vmdk aurait mis du temps à se construire, et aurait consommé de l’espace disque pour rien. J’indiquerai comment corrigé le tir dans la partie suivante.

Paramétrage du fichier reconstruit

On peut supprimer le fichier temp-flat.vmdk (le fichier de données donc) qui n’est plus nécessaire, et renommer le fichier temp.vmdk avec le nom correspondant au fichier manquant.

# rm -i temp-flat.vmdk
# mv -i temp.vmdk mavm.vmdk

A l’aide d’un éditeur de texte (soit via vi si vous êtes directement sur l’ESXi soit vous le récupérez pour l’éditer sur votre poste), on va modifier les sections qui ne correspondent pas encore à notre disque -flat :

vérifiez que la taille annoncée (en nombre de blocs de 512 octets, donc multiplier par 2 le nombre obtenu plus haut) sous #Extent Description
modifiez le nom du fichier après VMFS pour qu’il corresponde au fichier -flat
adaptez si besoin le contrôleur (si vous n’avez pas rentré le bon lors du lancement de la commande plus haut)
supprimez la ligne ddb.thinProvisioned = « 1 » si le fichier -flat.vmdk n’était pas en thin provisioning initialement.

[...]
# Extent description
RW 2072321720320 VMFS "mavm-flat.vmdk"
[...]
ddb.adapterType = "lsilogic"
ddb.thinProvisioned = "1"

Vous devriez avoir un disque virtuel de nouveau fonctionnel.

Bonus track : vérifier l’intégrité du « disk chain »

Vous pouvez vérifier que le fichier .vmdk correspond au fichier -flat avec les commandes suivantes :

Pour ESXi 3.5/4.x:

# vmkfstools -q mavm.vmdk
mavm.vmdk is not an rdm

Pour ESXi 5.x et 6.x :

# vmkfstools -e mavm.vmdk
Disk chain is consistent

Partage de VMDK entre plusieurs VMs

Wed, 07 Jan 2015 16:05:17 +0000

Si vous déjà voulu faire un POC de cluster Linux sur des machines virtuelles VMware, vous vous êtes déjà demandé comment vous alliez faire pour partager entre deux serveurs un espace de stockage commun à ces deux machines.

Une façon de faire consiste à rajouter une couche d’abstraction du stockage au dessus de l’OS (via GlusterFS ou DRBD par exemple), mais dans le cas d’un POC pour valider un cluster connecté au SAN, ce n’est pas forcément la première solution qui vient à l’esprit. Personnellement, la plupart des clusters que je construis sont encore dans un schéma plus simple à base de LUNs iSCSI ou FC partagés sur un SAN en actif/actif ou actif/passif.

Cependant, pour simuler ce fonctionnement sur vos VMs, il va falloir bidouiller un peu.

En effet, pour éviter toute erreur malencontreuse (et même désastreuse), VMware interdit par défaut le démarrage de toute machine virtuelle qui aurait un disque en cours d’utilisation par une autre machine virtuelle. Aïe…

Voici un petit mode opératoire pour s’en sortir ;-)

Dans ce mode opératoire, les disques qu’on souhaite partager entre les deux serveurs sont des disques LVM en miroir, hébergés sur les baies de disques qui sont accessibles depuis les deux serveurs ESXi.

Cet exemple permet de valider la fiabilité de la méthode dans le cadre d’un cluster Linux virtuel de type RedHat Cluster Suite. Le principe reste tout de même valide pour une utilisation en dehors de RedHat Cluster Suite, certaines opérations ne seront juste pas nécessaires (qui peut le plus peut le moins).

Prérequis

Pour les besoins de la documentation, deux machines virtuelles test_partage_vmdk_1 et test_partage_vmdk_2 ont été créés. Elles disposent des caractéristiques techniques suivantes :

test_partage_vmdk_1
- hébergée sur ESXi1
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.1/24 sur un réseau virtuel
test_partage_vmdk_2
- hébergée sur ESXi2
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.2/24 sur un réseau virtuel

Création des disques virtuels

Les machines test_partage_vmdk_1 et test_partage_vmdk_2 doivent être éteintes avant de réaliser les modifications.

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_1, et ajouter un nouveau périphérique (Disque dur).

Le provisionnement du disque doit impérativement être « statique immédiatement mis à zéro ». De plus, il doit aussi être hébergé sur un datastore commun aux deux machines physiques ESXi.

Créer le disque et l’affecter à un Nœud périphérique virtuel qui n’est pas encore utilisé.

Ici, le disque interne est stocké sur l’adresse SCSI (0:0). Par défaut VMware propose de créer le disque à la suite en SCSI (**0:**1).

Il faut impérativement dérouler la liste pour affecter le disque à l’adresse SCSI (**1:**0) qui représente un nouveau contrôleur SCSI.

De plus, pour permettre l’usage des snapshots sur la partie disque dur interne, les disques doivent être créés en Mode Indépendant/Persistant. Dans le cas contraire, les snapshots seront impossibles sur la machine virtuelle.

Une fois le disque créé, un nouveau contrôleur SCSI est également créé. Avant de valider la création du disque et du contrôleur SCSI, il faut modifier le paramètre de Partage de bus de SCSI en mode « Physique ».

[4]Le second disque dur devra être créé de la même manière, et affecté au même contrôleur SCSI (on prendra l’adresse 1:1).

Remettre test_partage_vmdk_1 sous tension.

Ajout des disques virtuels sur la deuxième machine virtuelle

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_2, ajouter un nouveau périphérique (Disque dur) puis sélectionner « Utiliser un disque virtuel déjà configuré ».

Sélectionner le premier disque créé précédemment.

De la même manière que précédemment, on doit créer un disque dur virtuel sur un nouveau contrôleur SCSI et en mode Indépendant-Persistant.

Modifier le nouveau contrôleur SCSI comme précédemment :

Ajouter enfin le second disque de la même manière à l’adresse SCSI (1:1).

Valider et mettre la machine virtuelle sous tension. Si elle boot correctement c’est que le partage fonctionne.

Créer le miroir LVM partagé

Sur les deux serveurs, exécuter les commandes suivantes :

chkconfig acpid off #seulement pour RHCS
service acpid stop #seulement pour RHCS
vi /etc/lvm/lvm.conf
     filter = [ "a/.*/" ]
   #filter = [ "a|/dev/cciss/.*|", "a|/dev/mpath.*|", "r|.*|" ] #utiliser cette ligne en cas d’utilisation de multipath et de disques locaux présentés en tant que /dev/cciss. A adapter au contexte
[…]
volume_list = [ "vg01" , "@[TAG]" ]

Dans le cas de RedHat Cluster Suite, remplacer [TAG] par le nom de la machine tel qu’il est définit dans le fichier /etc/cluster/cluster.conf.

En dehors du cas d’un traitement automatisé par cluster, n’importe quel tag convient du moment qu’il est unique à la machine. Dans le cas présent, les tags choisis sont respectivement tag_vm1 et tag_vm2.

Quelques précisions :

filter permet de traiter les cas où on doit ignorer certains disques. C’est typiquement nécessaire lorsque l’on utilise LVM avec multipath ou powerpath, car l’OS voit plusieurs « disques » sda ,sdb, … pour un même disque mpath (1 sdX pour chaque chemin vers mpathY).
volume_list indique à LVM que seul le vg01 (interne) et les VG explicitement taggués avec le nom de la machine qui peuvent être utilisés. Cela permet de s’assurer qu’il n’y a qu’une seule machine qui peut activer le VG du moment qu’on n’ajoute jamais plus d’un tag au VG.

Même si les modifications du fichier lvm.conf sont prises en compte immédiatement, RedHat Cluster Suite impose une recompilation de l’initrd. Dans le cas d’un cluster RHCS, il faut donc lancer la commande suivante :

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

Sur un seul nœud (le premier) :

pvcreate /dev/sdb
pvcreate /dev/sdc
vgcreate -c n vg_mirror /dev/sdb /dev/sdc

Tagger le VG pour pouvoir travailler dessus sur ce nœud.

vgchange --addtag tag_vm1 -ay vg_mirror
lvcreate -n lv_mirror -m1 -l 5116 /dev/vg_mirror
Logical volume "lv_mirror" created

Le journal des écritures doit lui aussi être en miroir

lvconvert --mirrorlog mirrored /dev/vg_mirror/lv_mirror
Logical volume lv_mirror converted.

Il est enfin possible de formater le disque, et de le monter sur le test_partage_vmdk_1

mkfs.ext3 /dev/vg_mirror/lv_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Tester la bascule

Scanner les VGs pour vérifier que le nouveau VG est bien disponible sur le test_partage_vmdk_2

vgscan
vgs

Même s’il le VG est visible, il n’est pas possible de le monter car il n’a pas le bon tag (tel que spécifié dans le lvm.conf). Cela permet de vérifier que l’on ne pourra pas écrire sur les disques sur les deux nœuds en même temps.

Not activating vg_mirror/lv_mirror since it does not pass activation filter.
0 logical volume(s) in volume group “vg_mirror” now active

On peut démonter le FS, désactiver le vg et enlever le tag sur le serveur test_partage_vmdk_1 et vérifier qu’on peut bien le monter et écrire dessus sur le test_partage_vmdk_2.

Ce comportement est automatique sous RedHat Cluster Suite, qui gère lui même les tags lors de la bascule d’un VG/LV.

Sur test_partage_vmdk_1

umount /mnt
vgchange --deltag tag_vm1 -an vg_mirror

Sur test_partage_vmdk_2

vgchange --addtag tag_vm1 -ay vg_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Have fun