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 à jour le Virtual Hardware sous VMware vSphere 4

Lors de la migration de VMware Virtual Infrastructure 3.5 vers vSphere 4, le Virtual Hardware ayant évolué pour passer de la version 4 à la version 7, vous devrez également planifier cette mise à jour pour toutes les machines qui en tirent réellement des bénéfices. Les autres pourront pour l’heure rester en version 4 vu la lourdeur des opérations que cela implique.

Le Virtual Hardware 7 offre plusieurs nouvelles caractéristiques dont :

• Périphériques virtuels SAS (Serial Attached SCSI) : permet le support des configurations en clustering de Windows Server 2008
• Périphériques virtuels IDE : permet le support des anciens systèmes d’exploitation qui ne gèrent pas les pilotes SCSI
• Support Hot Plug : permet aux systèmes d’exploitation supportés d’utiliser des fonctions hot add CPU et RAM et périphériques virtuels
• VMDirectPath : permet d’améliorer l’efficacité CPU des VMs en gérant la charge en fonction du nombre et de la fréquence des I/O des périphériques
• Block Tracking : permet d’améliorer les opérations de sauvegarde et de restauration
• VMXNET 3 : permet l’amélioration des performances réseau, le support IPv6, etc…

Identifier et mettre à jour le Virtual Hardware

Lorsque vous éditez les paramètres de configuration de votre machine virtuelle, l’information du vHardware s’obtient très simplement, en regardant au-dessus de la RAM allouée à la machine. Ici, vous cherchez toutes les machines en version 4.

Pour mettre à jour le Virtual Hardware d’une machine, éteignez votre VM et passez par le menu VM > Upgrade Virtual Hardware de la console ou simplement au moyen du clic droit > Upgrade Virtual Hardware.

Un message apparaît alors pour vous demander de confirmer l’opération. Notez le caractère irréversible de l’opération et prenez les dispositions qui s’imposent (préférez toujours le clone au snapshot).

Si vos VMware Tools ne sont pas à jour, l’assistant vous demandera d’annuler ou de continuer malgré tout. C’est une bonne pratique que de s’assurer que ses VMware Tools soient à jour avant toute upgrade du vHardware. Annulez donc l’installation, mettez vos VMware Tools à jour et recommencez.

L’installation des VMware Tools pour Windows se fait aisément au moyen du menu VM > Guest > Install/Upgrade VMware Tools ou par clic droit > Guest > Install/Upgrade VMware Tools. Pour Debian (Lenny), consultez cet article.

La mise à jour du Virtual Hardware ne prend que quelques secondes. Vous pouvez suivre son avancement dans la fenêtre des tâches récentes.

De retour dans les paramètres de configuration de votre serveur, vous devriez obtenir l’indication de la nouvelle version.

Sachez que la mise à jour que vous venez de faire apporte également un nouveau pilote réseau VMXNET 3 et un pilote para-virtuel PVSCSI (à ne pas utiliser pour les disques de démarrage avant vSphere 4 U1)

Utiliser le pilote VMXNET 3

Rendez-vous dans les paramètres de configuration de machine. Vous verrez qu’il n’est pas possible de changer le type d’adaptateur courant.

Vous devrez donc créer un adaptateur supplémentaire pour bénéficier du nouveau pilote VMXNET 3. Une fois celui-ci créé, supprimez l’ancien en ayant bien sûr pris soin de sauvegarder la configuration réseau de votre ancienne interface.

Pour obtenir plus de détails concernant les cartes réseau virtuelles, rendez-vous sur le blog VMware.

Si vos paramètres réseau sont trop laborieux à recopier, simplifiez-vous la vie en utilisant l’utilitaire en ligne de commandes netsh pour les sauvegarder :

C:>netsh interface ipv4 dump > "c:ip.txt"

Pour les restaurer sur la/les nouvelle(s) interface(s) (pensez à changer le nom de vos connexions dans le fichier d’export…), passez l’argument -f :

C:>netsh –f "c:ip.txt"
Réinitialisation de Général, OK !
Réinitialisation de Interface, OK !
Réinitialisation de Adresse unicast, OK !
Réinitialisation de Routage, OK !
Redémarrez l'ordinateur pour terminer cette action.

Rendez-vous sur le KB VMware 1005595 ou sur le site Microsoft Technet pour obtenir toutes les informations relatives à la commande netsh (lien pour Windows Server 2008)

Utiliser le pilote PVSCSI

Ce pilote n’est à utiliser que pour les machines très sollicitées niveau I/O (lire le KB VMware 1017652), autrement, cela peut même dégrader les performances.

Pour éviter un écran bleu Windows (BSOD) au démarrage, créez un deuxième disque VMDK (peut importe la taille, c’est temporaire) pour lequel vous choisirez le pilote VMware Paravirtual. Puisque c’est un nouveau contrôleur, isolez-le complètement en le mappant par exemple sur la Virtual Device node SCSI (1:0).

Une fois Windows démarré, il prendra en compte le changement matériel et sera prêt à accepter le nouveau pilote pour vos disques existants préalablement configurés en LSI Logic moyennenant un redémarrage pour charger les nouveaux pilotes.

Il ne vous reste donc plus qu’à effectuer les modifications sur vos disques de production et à supprimer le disque tampon.

Voici un exemple de BSOD que vous rencontrerez inévitablement si vous ne suivez pas ces conseils :

Il ne fait aucun doute que l’upgrade du vHardware doit être effectuée sur vos templates. Pour ce qui est de vos machines de production, comme je l’indiquais en début d’article, l’intérêt est bien moins évident. Analysez-donc attentivement les nouveautés avant de vous lancer dans ces opérations tête baissée et en tout état de cause, SAUVEGARDEZ !

Utiliser vSphere PowerCLI pour interagir sur un vSwitch

Voici la liste non exhaustive des opérations que vous pourrez réaliser en utilisant vSphere PowerCLI pour interagir sur un vSwitch :

[table id =26 /]

Récupérer la liste des vSwitchs d’un hôte ESX

On utilise la commande Get-VirtualSwitch -VMHost <hote>

[vSphere PowerCLI] C:> Get-VirtualSwitch -VMHost esx.xitim.com

Name       Num Ports  Num Ports  Mtu   Key
                      Available
----       ---------  ---------- ---   ---
vSwitch0   32         29         9000  key-vim.host.VirtualSwitch-...
vSwitch1   64         60         1500  key-vim.host.VirtualSwitch-...
vSwitch2   64         63         1500  key-vim.host.VirtualSwitch-...

Récupérer la liste des vSwitchs attachés à une machine virtuelle

On utilise la commande Get-VirtualSwitch -VM <machine_virtuelle>

[vSphere PowerCLI] C:> Get-VirtualSwitch -VM "Exchange1"

Name       Num Ports  Num Ports  Mtu   Key
                      Available
----       ---------  ---------- ---   ---
vSwitch2   64         63         1500  key-vim.host.VirtualSwitch-...

Créer un nouveau vSwitch

On utilise la commande New-VirtualSwitch -VMHost <hote> -Name <nom>

[vSphere PowerCLI] C:> New-VirtualSwitch -VMHost esx.xitim.com -Name vSwitchDEV

Name       Num Ports  Num Ports  Mtu   Key
                      Available
----       ---------  ---------- ---   ---
vSwitchDEV 64         63         1500  key-vim.host.VirtualSwitch-...

Supprimer un vSwitch

On utilise la commande Remove-VirtualSwitch redirigée d’après une récupération préalable de l’hôte et du nom de vSwitch à supprimer.

[vSphere PowerCLI] C:> Get-VMHost "esx.xitim.com" |
Get-VirtualSwitch -Name "vSwitchDEV" | Remove-VirtualSwitch

Modifier la configuration d’un vSwitch

On utilise la commande Set-VirtualSwitch redirigée d’après une récupération préalable de l’hôte et du nom de vSwitch à modifier.

[vSphere PowerCLI] C:> Get-VMHost "esx.xitim.com" |
Get-VirtualSwitch -Name "vSwitchDEV" | Set-VirtualSwitch -MTU 9000

Name       Num Ports  Num Ports  Mtu   Key
                      Available
----       ---------  ---------- ---   ---
vSwitchDEV 64         63         9000  key-vim.host.VirtualSwitch-...

Je vous invite à suivre cet article qui sera régulièrement mis à jour.