Renommer une machine virtuelle sous VMware vSphere 4

Il y a beaucoup de raisons qui peuvent vous amener à vouloir renommer une machine virtuelle. Hélas, la souplesse de la virtualisation ne va pas encore jusqu’à rendre triviale cette opération au-delà du nom affiché dans le vCenter. On espère donc que dans un futur proche, renommer une machine permettra également de renommer ses fichiers associés, ce qui serait quand même la moindre des choses.

Etat des lieux

Prenons une machine test nommée Exchangev1. Lorsque vous naviguez dans le Datastore qui héberge ses fichiers, vous observez que le dossier conteneur de la VM ainsi que tous ses fichiers correspondent au nom donné à la création.

Nous voulons simplement renommer cette machine en Exchange. Dans le vCenter, En faisant un clic droit > Rename sur la VM, on la renomme avec le nom désiré. Cette opération s’incrémente dans les tâches récentes et la VM prend le nouveau nom. En revanche, rien ne change au niveau des fichiers bruts. Il va donc falloir ruser…

Evaluer les options pour renommer une machine virtuelle

Plusieurs moyens d’arriver à vos fins existent et sont plus ou moins recommandables selon votre niveau d’expertise. Sans être exhaustif, cet article devrait vous permettre d’explorer la plupart des façons de faire. Aussi, nous balayerons trois possibilités, de la plus facile à la plus compliquée :

1. Cloner la machine virtuelle
2. Migrer la machine virtuelle vers un nouveau datastore
3. Renommer manuellement les fichiers bruts

Quelle que soit la solution que vous adopterez, c’est une bonne pratique que de supprimer tout snapshot résiduel d’une VM. Cela va sans dire, mais pensez également à éteindre votre serveur pour ne pas provoquer un drame…

Enfin, gardez toujours en mémoire que le nom que vous donnez à une VM ne doit pas comporter d’espace, de parenthèses ou de caractère non compatible avec l’encodage UTF-8.

1. Cloner la machine virtuelle

Ce n’est clairement pas la vocation première de cette opération, mais probablement la façon de faire la moins complexe ! Si vous avez l’espace disque nécessaire sur votre espace de stockage et que vous ne voulez pas investir trop de temps ou risquer une mauvaise manipulation, préférez cette option.

Cloner une VM est enfantin. Cliquez droit sur votre machine puis choisissez l’option Clone… Vous aurez dès lors un assistant dont le premier écran consistera justement à vous demander…le nouveau nom de VM. S’en suivront les opérations habituelles de création de machine donc nous ne nous attarderons pas là-dessus ici.

Une fois la tâche terminée, vous pouvez constater le résultat en naviguant dans le Datastore qui reflètera la réussite de l’opération

2. Migrer la machine virtuelle vers un nouveau datastore

Deuxième possibilité tout aussi simple, la migration de VM vous permet de modifier le nom de votre machine. Pour cela, commencez par changer de nom à votre VM dans le vCenter puis cliquez droit > Migrate… sur la machine préalablement renommée (on a choisi Exchangev2)

L’assistant n’a rien de compliqué. Pensez juste à bien choisir l’option Change datastore quand elle se présentera à vous.

Une fois l’opération terminée, vous constaterez que les modifications ont été prises en compte dans le datastore.

Le clone et la migration sont deux opérations aisées. A vous de décider laquelle est la plus opportune selon vos contraintes de production et la performance de vos espaces de stockage sources et cibles.

3. Renommer manuellement les fichiers bruts

Cette opération est nettement plus délicate alors attention aux mauvaises manipulations !

Une fois la machine éteinte, supprimez-la de l’inventaire du vCenter. Attention, ne confondez pas l’option Remove from Inventory et Delete from Disk qui supprimerait purement et simplement votre serveur ! Pour supprimer la machine de l’inventaire, passez par le menu contextuel, donc, ou par la ligne de commande avec vmware-cmd -s unregister <path>

Voici une illustration :

[root@esx1 Exchange]# vmware-cmd -s unregister
/vmfs/volumes/vmfs-local1-esx1/Exchange/Exchange.vmx

Je privilégie toujours l’option graphique car en ligne de commandes, votre machine apparaît par la suite comme orpheline dans le vCenter. D’autres opérations inhérentes étant alors nécessaires, on s’en prémunira par avance…

Une fois votre machine desinventoriée, passez en ligne de commande pour renommer les fichiers .vmx et .vmdk (et son flat) avec le nouveau nom souhaité.

[root@esx1 vmfs-local1-esx1]# mv Exchange Exchangev3
[root@esx1 vmfs-local1-esx1]# cd Exchangev3/
[root@esx1 Exchangev3]# mv Exchange.vmx Exchangev3.vmx
[root@esx1 Exchangev3]# mv Exchange.vmdk Exchangev3.vmdk
[root@esx1 Exchangev3]# mv Exchange-flat.vmdk Exchangev3-flat.vmdk
[root@esx1 Exchangev3]# ll
total 20972992
-rw------- 1 root root        8684 Apr  2 10:29 Exchange.nvram
-rw------- 1 root root 21474836480 Apr  2 10:29 Exchangev3-flat.vmdk
-rw------- 1 root root         502 Apr  2 10:41 Exchangev3.vmdk
-rwxr-xr-x 1 root root        1919 Apr  2 10:32 Exchangev3.vmx
-rw------- 1 root root           0 Apr  2 10:32 Exchange.vmsd
-rw------- 1 root root         263 Apr  2 10:32 Exchange.vmxf
-rw-r--r-- 1 root root       74453 Apr  2 10:29 vmware-1.log
-rw-r--r-- 1 root root       29569 Apr  2 10:29 vmware-2.log
-rw-r--r-- 1 root root       28649 Apr  2 10:29 vmware-3.log
-rw-r--r-- 1 root root       55627 Apr  2 10:29 vmware.log

Editez à présent le fichier .vmx et repérez la ligne scsi:0.fileName de manière à modifier la valeur pour refléter le nouveau descripteur.

scsi0:0.fileName = "Exchangev3.vmdk"

Pensez à sauvegarder avant de quitter puis de la même manière, éditez le fichier .vmdk pour refléter le nouveau nom du fichier -flat en repérant la mention Extent description.

# Extent description
RW 41943040 VMFS "Exchangev3-flat.vmdk"

Vous pouvez à présent parcourir de nouveau le datastore et cliquer droit sur le fichier .vmx renommé. Sélectionnez Add to Inventory pour inventorier votre machine virtuelle.

Vous aurez peut-être remarqué que trois fichiers (.nvram, .vmsd et .vmxf) n’ont pas eu besoin d’être renommés via la ligne de commande et que malgré tout votre machine démarre. C’est tout simplement parce-que l’hyperviseur est capable de les régénérer au besoin pour refléter les nouveaux descripteurs mis en place comme l’atteste la capture écran ci-dessous :

Bien sûr cela fait des fichiers inutiles résidents du conteneur de votre VM et l’opération la plus propre aurait été de renommer tous les fichiers, sans oublier de modifier le fichier .vmx en conséquence. A vous de choisir, sachant que ce n’est qu’une histoire de rigueur de chacun…

Remarque : la commande vmkfstools permet aussi le renommage d’un fichier .vmdk et plus encore. La richesse de cette commande étant d’ailleurs telle, je tenterai carrément de lui consacrer un article dans un futur proche.

Cloner un replica d’une baie Dell EqualLogic PS4000 en volume

Lorsque vous mettez en place un plan de reprise d’activité avec une réplication matérielle entre deux baies EqualLogic PS4000, vous devez définir une politique de sauvegarde qui correspond à vos impératifs de production. Pour l’exemple d’aujourd’hui, nous avons défini une réplication journalière et nous voulons restaurer le volume PRD1-LUN0 à la date du 01/02/10.

Pour sélectionner un replica, passez par le menu Replication Partners puis sélectionnez votre partenaire de réplication. Ensuite, sélectionnez l’onglet Inbound puis repérez le replica à utiliser. Une fois le bon replica sélectionné, cliquez sur Clone replica dans la partie Administration. Cela a pour effet de lancer un assistant.

Donnez un nouveau nom et éventuellement une description au volume que vous désirez remonter puis cliquez sur Next.

Si un message en rouge indique Volume reserve is less than current use, cela signifie que le clone tente de créer du thin provisionning (observez la case à cochée grisée…) alors que ce n’est pas possible à ce moment car 100% de la place disque du LUN est déjà vue comme utilisée dans le replica. Passer outre n’est pas bloquant. Autrement, on peut déplacer les curseurs pour faire disparaître le message (voir plus bas).

Ici, on a simplement déplacé les curseurs et le message a disparu.

L’étape 3 permet de créer les accès iSCSI au volume que l’on remonte. Soit on sélectionne No access pour ne créer aucun accès dans l’immédiat, soit on peut préférer Restricted access et renseigner par exemple la valeur Limit access to iSCSI initiator name afin de rentrer l’IQN d’un hôte auquel on présentera le nouveau volume. Notez qu’à cette étape, seul un accès est autorisé. On pourra bien sûr en rajouter plus tard…

Enfin, on choisi un accès en lecture-écriture. On aurait également pu cocher la case Allow simultaneous connections from initiators with different IQN names pour autoriser plusieurs connexions à un hôte avec plusieurs IQN définis. Terminez ensuite l’assistant en vérifiant vos réglages puis en cliquant sur Finish.

Un volume apparaît désormais dans la section Volumes du Group Manager. Il est exploitable comme n’importe quel volume et contient les mêmes informations que le volume répliqué, à la date choisie.

Avant de tenter la présentation iSCSI, si vous êtes sous VMware ESX 3.5, assurez-vous d’avoir modifié les paramètres avancés de votre hôte dans l’onglet Configuration > Advanced Settings (dans la partie Sotfware) et de changer l’option LVM > LVM.EnableResignature de 0 à 1 pour éviter que le volume puisse être candidat à un reformatage VMFS (une fois les fichiers récupérés, pensez à modifier l’option de nouveau !). Sous VMware vSphere, cette option n’existe plus.

Lorsque qu’enfin vous présentez votre volume iSCSI (lisez cet article qui traite le point), vous pouvez observer qu’il prend un nom par défaut qui vous permet de repérer qu’il s’agit d’un volume “snapshoté”.

Utiliser les bonnes pratiques de création et d’organisation des LUNs et volumes VMFS

Dans la série des bonnes pratiques de modélisation de votre infrastructure de stockage, le sizing de vos LUNs et volumes VMFS ne sera pas un élément bloquant de vos déploiements mais plutôt une tranquillité d’esprit quant à l’optimisation des moyens mis en œuvre pour rendre une installation plus facile et cohérente à administrer à long terme.

Déterminer les spécificités d’environnement

Pour cela, nous allons partir de préalables à déterminer selon vos besoins :

• Nombre total de VMs
• Taille moyenne (maximale) des VMs (en Go/To)
• Taille totale de la baie de stockage (en To)
• Pourcentage d’espace disque estimé réservé aux snapshots et au swap

Garder en tête les pratiques habituellement constatées

Chaque configuration révèle ses vérités et l’expérience que vous obtenez au fur et à mesure de vos déploiements peut radicalement vous faire changer de méthode. Néanmoins, il reste certaines recommandations jusqu’alors bien utiles :

• On dépasse rarement 30 machines virtuelles par LUN pour garder une file d’attente disque raisonnable. Idéalement, on restera dans la dizaine.
• On tente le plus possible de distinguer et de rapprocher en groupes les machines virtuelles de taille similaire : 0 à 100Go, 100 à 500Go etc…
• On arrondit toujours la taille totale estimée à une valeur supérieure d’au moins 20Go
• On utilise toujours des DataStores plutôt que des Raw Device Mapping (RDM), sauf si l’on désire présenter des volumes de plus de 800Go.
• VMFS3 supporte des volumes allant jusqu’à 64To donc vous n’avez pas à vous inquiéter d’un quelconque bridage technique.

Simuler une taille de volume

Comme il n’existe pas de taille idéale par définition, nous allons partir de valeurs de test pour effectuer notre exemple de modélisation :

• Nombre total de VMs : 112
• Taille moyenne (maximale) des VMs : 50Go pour 102 machines (soit une taille totale de 5,1To) et 3 VMs à 1To (soit une taille totale de 3To)
• Taille totale de la baie de stockage : 10To
• Pourcentage d’espace disque estimé réservé aux snapshots et au swap : 20

La formule mathématique qui en découle est donc très simple :

Nombre total de VMs x Taille moyenne (maximale) des VMs + 20% = Taille du volume

Comme dans notre configuration test nous nous retrouvons avec de nombreuses machines virtuelles – qui plus est hétérogènes – et que nous désirons suivre les bonnes pratiques et recommandations, nous allons créer les volumes en conséquence. Attention, ce n’est pas compliqué mais il faut être attentif avec la succession du raisonnement logique :

• 102 VMs x 50Go + 20% =  6120Go > comme on préfère travailler avec des datastores et qu’ils ne doivent pas dépasser 800Go, on divise donc 6120 par 800, ce qui donne 8 datastores de 800Go (6,4To au total) .
• 3 VMs x 1To + 20% = 3,6To > comme nos disques dépassent 800Go par machine, on crée un RDM pour chacune, ce qui donne 3 RDM de 1,5To (4,5To au total) au lieu de 1,2To normalement car avec des machines de cette taille, on surévalue par précaution le sizing en prévoyant des snapshots gourmands qui traîneraient et grossiraient bien plus vite qu’avec de petites machines virtuelles…

J’insiste sur le fait que ce n’est pas un calcul très complexe mais tout de même fin et très emprunt d’une dose de vécu qui vous fera adapter intelligemment chaque paramètre pour satisfaire au mieux votre déploiement. Rappelez-vous enfin que la concaténation de LUNs existe (MetaLUN) et que vous n’avez aucune raison de vous en priver. De même, si vous passez d’un environnnement Virtual Infrastructure à vSphere, aucun problème étant donné que le VMFS de vSphere, en version 3.33, est totalement compatible avec la version 3.31 de Virtual Infrastructure.

Rester lucide sur son travail

Voilà, votre modélisation est désormais argumentée et sérieuse. Cependant, n’avez-vous rien remarqué de bloquant ? 6,4To + 4,5To font 10,9To. Or, votre baie ne fait que 10To ! Pourtant vous ne pouvez pas avoir plus d’espace disque. Vous êtes donc confronté à une réalité tout à fait opérationnelle : il va falloir faire “comme vous pouvez”, en prenant soin de respecter au mieux les bonnes pratiques tout en faisant avec les contraintes techniques du client. C’est là que vont entrer en jeu votre imagination et votre expertise, sachant que travailler avec une baie aussi pleine n’est pas serein, ne serait-ce que vis-à-vis du blocage immédiat que vous allez rencontrer concernant la création de nouvelles VMs ou l’extension à prévoir des VMDK déjà en production.

Bon courage !