Agrandir la partition système de Windows Server 2003 sous VMware vSphere 4

La virtualisation vous permet d’avoir la possibilité d’agrandir les disques VMDK en trois clics. On sait déjà que le SWAP appliqué sur une partition empêche l’agrandissement de disque sous Windows, de même que des snapshots résiduels. Il y a un autre cas particulier désagréable concernant le disque système de vos machines virtuelles, qui n’est une nouvelle fois pas causé directement par VMware (c’est le système de fichiers NTFS utilisé par Windows…) mais qu’il va falloir apprendre à gérer.

Préparer les opérations d’agrandissement d’un disque système

Bien que simples à réaliser, les opérations de préparation d’agrandissement d’un disque système doivent suivre une certaine logique pour éviter la confusion. Dans l’exemple qui suit, nous voulons partir sur deux machines virtuelles identiques Extend et Extend1 pour lesquelles la première servira à l’agrandissement du disque système de la seconde. Toutes deux ont un disque VMDK de 30 Go de base comme vous pouvez le constater sur l’illustration suivante.

Les deux machines doivent impérativement être éteintes. Agrandissez le disque de Extend1 à 40 Go puis ajoutez un nouveau disque à Extend et choisissez l’option Use an existing virtual disk.

Vous l’avez peut-être compris, le but est ici d’attacher le disque que l’on vient d’agrandir sur la machine virtuelle Extend qui servira de maître aux opérations d’agrandissement du disque système d’Extend1. L’opération est très aisée puisque vous pouvez simplement naviguer dans le datastore à la recherche du fichier VMDK correspondant.

De retour dans les paramètres de votre machine Extend, vous observez désormais que le disque de 40 Go vient d’être attaché et fait référence à l’emplacement de la machine Extend1.

Allumez la machine Extend et lancez l’utilitaire de Gestion de disques. Un rapide inventaire vous permet de comprendre que le premier disque de 30 Go correspond à une partition Systeme sur C: de 20 Go et à une partition Data sur D: de 10 Go.

Le deuxième disque indique 40 Go comme prévu, suit le même partitionnement et comprend bien l’espace de 10 Go non alloué.

Peut-être avez-vous remarqué que les partitions du disque de 40 Go n’ont pas de lettre assignée dans Windows ? Corrigeons-cela en cliquant droit et en sélectionnant Modifier la lettre de lecteur et les chemins d’accès… sur chacune d’entre eux.

Maintenant que nos deux disques sont prêts, on arrive enfin à l’allocation de l’espace non alloué. L’étude de cas est d’autant plus intéressante que notre disque VMDK possède deux partitions et que cela n’est pas sans conséquence.

Un article précédent indiquait comment utiliser Diskpart pour étendre un disque Windows. Je vous y renvoie donc pour comprendre le fonctionnement de l’utilitaire.

En lignes de commandes, tapez la commande list disk pour lister les disques physiques. On repère bien la configuration attendue.

DISKPART> list disk

  N° disque   Statut         Taille   Libre         Dyn  GPT
  ----------  -------------  -------  ------------  ---  ---
  Disque 0    En ligne         30 Go      0 octets
  Disque 1    En ligne         40 Go    10 Go

On sélectionne donc le disque 1 avec la commande select disk 1. Remarquez l’astérisque qui confirme que votre modification a bien été prise en compte.

DISKPART> select disk 1

Le disque 1 est maintenant le disque sélectionné.

DISKPART> list disk

  N° disque   Statut         Taille   Libre         Dyn  GPT
  ----------  -------------  -------  ------------  ---  ---
  Disque 0    En ligne         30 Go      0 octets
* Disque 1    En ligne         40 Go    10 Go

On veut maintenant sélectionner la partition E: qui correspond à la partition système de la machine Extend1. Pour cela on calque les commandes précédentes appliquées à la sélection du volume désiré.

DISKPART> list volume

  N° volume   Ltr  Nom          Fs     Type        Taille   Statut     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     G                       CD-ROM          0 o  Sain
* Volume 1     E   Systeme      NTFS   Partition     20 Go  Sain
  Volume 2     F   Data         NTFS   Partition     10 Go  Sain
  Volume 3     C   Systeme      NTFS   Partition     20 Go  Sain       Système
  Volume 4     D   Data         NTFS   Partition     10 Go  Sain

Tout est prêt pour augmenter le disque système de la machine Extend1, pourtant, lorsque vous tapez la commande extend, les opérations d’agrandissement ne fonctionnent pas. Pourquoi ?

Pour comprendre votre erreur, je vous renvoie à la documentation Microsoft :

La commande extend peut causer l'extension du volume actif actuel dans un
espace contiguë non alloué. L'espace non alloué doit suivre (ou être dans le
décalage du secteur le plus élevé) la partition active.

Cela signifie que non seulement, vous ne pourrez pas avoir de snapshot résiduel, de SWAP configuré sur la partition système, ou d’agrandissement possible si Windows est démarré sur le disque système à agrandir,  mais que vous devrez accessoirement vous assurer d’avoir votre partition système active seule sur le disque VMDK (pour bien faire) ou contigüe à  l’espace disque non alloué ! Cela fait beaucoup de vérifications préalables à la possibilité d’agrandir votre partition mais c’est le prix à payer pour cette souplesse toute relative qui vous dépannera énormément lorsque votre système d’exploitation sera saturé.

La bonne pratique à retenir est donc évidente : pensez à utiliser un disque VMDK par partition Windows que vous désirez créer dans votre système d’exploitation. Ainsi, vous en ferez ce que bon vous semble et éviterez de perdre de précieuses informations connexes si un disque venait à être corrompu ou malencontreusement supprimé !

Gérer les adresses MAC sous VMware vSphere 4

Habituellement, une adresse MAC est un identifiant physique stocké dans une carte réseau utilisé pour attribuer mondialement une adresse unique au niveau de la couche de liaison du modèle OSI. Le vHardware implique aussi la gestion des adresses MAC à cela de près qu’elle est relativement modulable, virtualisation oblige.

Gérer les adresses MAC automatiquement

Quand une machine virtuelle démarre, une adresse MAC est automatiquement attribuée au Virtual Network Adapter, c’est à dire à la carte réseau virtuelle. Pour éviter les conflits, chaque machine virtuelle se voit assignée un identifiant unique à l’intérieur d’un hôte ESX. Le champ MAC Address est d’ailleurs grisé pour interdire la modification de l’identifiant.

Dans la plupart des cas, les machines virtuelles gardent le même identifiant à chaque démarrage du moment qu’elles ne sont pas déplacées et que le chemin et le nom de fichier de la configuration de la VM restent identiques. Néanmoins, VMware ne certifie pas qu’une machine qui tourne sur plusieurs hôtes puisse garder la même adresse MAC. Autrement dit, partez du postulat qu’à chaque déplacement de votre VM, celle-ci pourra se voir attribuer un nouvel identifiant.

Gérer les adresses MAC manuellement

Pour certains besoins tels que l’activation d’une clé de licence par adresse MAC, vous pouvez avoir besoin de garantir que votre identifiant unique reste inchangé. Pour cela, sélectionnez le bouton radio Manual et laissez la suite de chiffres invariables 00:50:56 propre à VMware que vous complèterez par une suite de chiffres allant de 00:00:00 à 3F:FF:FF

Pour information, les 3 premières suites de chiffres et/ou lettres correspondent au fabricant de votre interface réseau. Vous pouvez déterminer vous-même cette information avec des logiciels dédiés ou le site coffer.com qui vous donne facilement cette information.

Dans le fichier de configuration .vmx de votre machine virtuelle, vous retrouverez les informations relatives à l’adaptateur réseau avec les modifications que vous venez d’apporter.

• La valeur par défaut ethernet[n].addressType = “vpx” est automatiquement changée à static
• La valeur ethernet[n].generatedAddress = “00:50:56:XX:YY:ZZ” indique l’identifiant unique généré automatiquement avant le passage en mode manuel
• La valeur ethernet[n].address = “00:50:56:XX:YY:ZZ” indique la valeur attribuée manuellement qui fait foi

ethernet1.addressType = "static"
ethernet1.generatedAddress = "00:50:56:9e:2c:d5"
ethernet1.networkName = "vSwitch-Prod"
ethernet1.present = "TRUE"
ethernet1.address = "00:50:56:00:00:00"
ethernet0.present = "FALSE"

Ces opérations ne sont valables que pour l’adaptateur réseau virtuel courant ou [n] correspond à son numéro. Si d’aventure vous veniez à supprimer la carte réseau virtuelle, vos réglages seraient purement et simplement effacés. La virtualisation a quand même des limites.

Cas particuliers

Pensez toujours à vous assurer que les réglages de votre Port Group permettent bien des changement d’adresse MAC. L’option MAC Address Changes permet en effet de choisir l’option Accept ou Reject. Si c’est la deuxième qui est choisie, vous ne pourrez pas changer l’adresse MAC de vos machines virtuelles. Ce réglage est utilisé la plupart du temps afin d’éviter l’usurpation d’adresse MAC et ne sera donc utilisé qu’à dessein. Vu qu’il ne pourra de toute façon pas être utilisé dans les configurations qui utilisent du stockage iSCSI, on y trouvera peu d’utilité.

Dans certains cas, on peut avoir besoin d’utiliser la même adresse MAC pour deux adaptateurs réseau. C’est par exemple le cas lorsque l’on veut utiliser du load balancing réseau Microsoft en mode unicast :

Network Load Balancing uses layer-two broadcast or multicast to simultaneously distribute incoming network traffic to all cluster hosts. In its default unicast mode of operation, Network Load Balancing reassigns the station address (“MAC” address) of the network adapter for which it is enabled (called the cluster adapter), and all cluster hosts are assigned the same MAC address.

Mettre en place des règles d’affinité dans un cluster DRS sous VMware vSphere

Les règles d’affinité permettent de définir que certaines machines virtuelles doivent être placées sur le même hôte ESX (affinity) ou au contraire sur des hôtes distincts (anti-affinity).

En général, on présume que les règles d’affinité s’établissent pour améliorer les performances et que les règles d’anti-affinité privilégient au contraire la haute disponibilité. En effet, on n’agira pas de la même manière selon que l’on doit sécuriser un cluster Exchange ou donner le maximum de proximité – et donc de performances – à une base de données et son serveur applicatif.

Pour définir une règle sur un cluster DRS, il suffit de cliquer droit sur le cluster et sélectionner Edit Settings…

La fenêtre qui apparaît propose ensuite de régler les paramètres du cluster, que ce soit au niveau de VMware HA ou de VMware DRS. Ici, on s’astreindra à sélectionner le menu Rules et à cliquer sur le bouton Add… pour ajouter une nouvelle règle.

Après avoir donné un nom à la nouvelle règle, il suffit juste de sélectionner des machines virtuelles du cluster (toujours via un bouton Add…) et de sélectionner le type de règle qui nous intéresse :

• Separate Virtual Machines : impose aux machines virtuelles sélectionnées de s’exécuter sur des hôtes distincts
• Keep Virtual Machines Together : impose aux machines virtuelles sélectionnées de rester sur le même hôte ESX

Sachez également qu’une règle d’anti-affinité n’autorise que deux machines virtuelles à la fois. C’est dommage mais c’est ainsi pour le moment…

Une fois vos modifications effectuées, vous les retrouverez dans le menu Rule. En décochant la case, vous pourrez à tout moment désactiver cette règle sans la détruire.

Le bouton Details vous permettra d’obtenir un résumé de votre règle et déterminer si d’autres règles rentrent en conflit avec votre nouvelle règle.

Le vCenter indiquera enfin par une tâche récente que la reconfiguration du cluster a bien été prise en compte.

Bien que les règles d’affinité soient très facilement compréhensibles, n’oubliez jamais que le niveau d’automation de votre cluster DRS agira également sur vos réglages. Si vous optez pour une automation Manual ou Partially automated, votre cluster ne prendra pas de décision à votre place. En ce sens, il ne pourra qu’établir des recommandations suivant vos règles.

Par exemple, si vous sélectionnez trois machines qui doivent rester ensemble et qu’une de ces trois machines se trouve sur un autre hôte ESX, vous devrez manuellement appliquer la recommandation.

Dans l’onglet DRS de votre cluster, vous aurez peut-être remarqué qu’il existe trois vues : Recommandations, Faults et History. La première vous permet de visualiser et de valider les recommandations le cas échéant. La deuxième vous permet de rapidement déterminer les problèmes sur vos règles. Le vue History permet quant à elle de retracer l’évolution des opérations.

Changez votre niveau d’automation à Fully automated si vous voulez que vos règles s’exécutent immédiatement, et ce sans intervention supplémentaire.

En outre, utiliser le cmdlet Powershell Get-DrsRule, vous permettra également connaître à tout moment le détail des règles existantes (activées ou pas) qui s’appliquent sur un cluster donné (notez l’astérisque qui sert de wildcard…).

[vSphere PowerCLI] C:> Get-DrsRule -Name "*" -Cluster "Cluster Prod"

Name            Enabled KeepTogether VMIDs
----            ------- ------------ -----
Serveur web     True    True         {VirtualMachine-vm-789, VirtualMachine-vm-...