Utiliser le Thin Provisionning sous VMware vSphere 4

Une des avancées majeures de vSphere 4 concerne le support du Thin Provisionning qui permet d’économiser de l’espace disque sur un SAN en donnant la possibilité à l’administrateur de spécifier à des disques virtuels de ne consommer que la place réellement utile et de grandir au besoin, plutôt que d’allouer tout l’espace par défaut. Si la technologie est connue, son comportement sous vSphere mérite d’être mieux appréhendé.

Lorsque l’on déploie une machine, l’assistant Disk Format nous propose désormais l’option Thin provisioned format. Vous remarquerez au passage que seuls les systèmes de fichiers VMFS-3 supportent cette fonctionnalité.

Dans le montage ci-dessous, on a déployé le même template deux fois de suite. La première fois on a choisi Same format as source qui crée dans notre cas un disque Thick par défaut. La deuxième fois, on a choisi Thin provisioned format. On peut dès lors observer les différences d’allocation d’espace disque. La machine dont le disque utilise le Thin Provisionning ne consomme effectivement que 5,90 Go sur les 16 potentiels.

Lorsque l’on navigue dans le Datastore correspondant et qu’on ouvre le conteneur de la VM, on obtient la preuve que le Thin Provisionning est bien pris en compte.

Si maintenant on veut tester la fonctionnalité, il suffit de remplir l’espace disque vide en copiant des fichiers et constater l’agrandissement du disque VMDK en temps réel dans le Datastore.

Dans l’inventaire de la VM, un rafraîchissement de la vue du stockage indiquera la nouvelle allocation.

A partir de ces observations, vous devrez avoir compris le principe. Sachez toutefois que faire de la place sur un disque en Thin provisioned format ne provoquera pas une réduction du disque .vmdk pour autant. L’opération ne fonctionne en effet que dans un sens…

Le cas des snapshots

Etude de cas très importante que la création de snapshots en mode Thin Provisionning. Du moment où vous en aurez créé un, le provisionnement du disque augmentera automatiquement pour refléter les changements.

De retour dans le conteneur de la VM, vous découvrirez alors les fichiers habituels .vmsn et le nouveau .vmdk dans lequel les écritures s’effectueront jusqu’à la consolidation du snapshot. Lors de sa suppression, le provisionnement reviendra à son état initial.

Thin Provisionning rime avec planification

Si l’utilisation de cette technique est séduisante et permet de maximiser l’utilisation d’un SAN, n’oubliez jamais qu’elle peut vous amener à gérer des situations douloureuses, par exemple dans le cas où la taille totale de l’espace provisionné dépasserait l’espace disque total de votre Datastore à cause – pourquoi pas – de snapshots non maîtrisés.

La capture écran ci-dessous reflète l’utilisation la plus sécurisée de l’espace, dans le sens où la valeur Provisioned Space ne dépasse pas la valeur Capacity. C’est en revanche un constat extrêmement fréquent que de relever des valeurs de provisionning bien supérieures à la capacité totale physiquement disponible.

Pour éviter de vous faire surprendre par un volume plein, une seule solution invariable : monitorez plutôt deux fois qu’une le remplissage des disques, que ce soit par le biais d’alarmes dans le vCenter ou par un outil tiers !

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.

Rendre possible l’installation de Windows XP sous VMware ESX Server 3.5

En principe, vous installerez uniquement des OS serveur dans votre infrastructure virtuelle. Néanmoins, pour déployer un OS client tel que Windows XP, il faut éviter quelques pièges. Vous rappelez-vous du passage de Windows XP à Windows Vista, quand l’installation d’XP était impossible sans charger des drivers RAID spécifiques pour supporter les disques Serial ATA ? Eh bien sous VMware Server, le principe est plus ou moins le même.

Premièrement, assurez-vous que le contrôleur SCSI sélectionné dans les paramètres hardware de votre hôte est bien BusLogic. C’est un préalable nécessaire à la suite des opérations.

Lorsque vous tentez l’installation d’XP, un message apparaît vous indiquant qu’aucun disque dur n’a été détecté. L’installation ne peut donc pas aboutir et vous vous retrouvez bloqué.

C’est à ce moment qu’il faut effectuer quelques opérations spécifiques qui consistent à pré-charger les pilotes de disques SCSI pour VMware Server. Rendez-vous pour cela dans un datastore accessible par l’hôte ESX puis déposez le fichier téléchargé en cliquant sur l’icône dédiée (1) et en allant chercher le pilote au format .flp (pour floppy) sur votre disque dur local. Le fichier ainsi uploadé (2) pourra maintenant être accessible par notre machine cliente.

A présent, éditez les paramètres hardware de votre machine virtuelle et dans la partie Floppy Drive, assurez-vous de cocher la case Connect at power on pour que la disquette soit bien vue par l’hôte au boot, puis sélectionnez la case Use existing floppy image in datastore qui vous permettra – via le bouton Browse… – de pointer sur le fichier .flp précédemment uploadé.

Il est également possible de charger les pilotes SCSI déjà présents sur votre hôte ESX. Toutefois ils peuvent ne pas être aussi récents que ceux du site VMware. Si cette option vous intéresse malgré tout, naviguez en lignes de commandes jusqu’à /vmimages/floppies et chargez ces pilotes.

Ci-dessous, un exemple du fichier de pilotes SCSI disponible dans l’ESX :

[root@srv-esx floppies]# ll
total 1444
lrwxrwxrwx  1 root  root        18 Dec  5  2008 floppies -> /vmimages/floppies
-r--r--r--  1 root  root   1474560 Mar 14  2009 vmscsi-1.2.0.2.flp

Vous êtes maintenant prêt à relancer l’installation. Lorsque l’assistant demande d’appuyer sur la touche F6 pour installer un pilote SCSI tierce partie, exécutez-vous.

Pour l’instant, vous pouvez observer la mention <aucun> qui indique qu’aucun pilote n’est chargé. Tapez sur la touche S pour spécifier un périphérique supplémentaire.

L’assistant repère les pilotes SCSI contenus dans votre fichier .flp via le lecteur de disquette. Cliquez sur Entrée pour valider la sélection.

Votre pilote VMware SCSI Controller enfin chargé, l’installation de Windows XP pourra désormais se dérouler normalement.

Pour obtenir plus d’informations au sujet de l’installation de Windows XP sur VMware Server, je vous invite vivement à lire le KB VMware 1006956 qui traite le point.