VMWARE ESXi - 5.5 User Manual [fr]

Dépannage vSphere

Mise à jour 1

ESXi 5.5

vCenter Server 5.5

Ce document prend en charge la version de chacun des produits
répertoriés, ainsi que toutes les versions publiées par la suite
jusqu'au remplacement dudit document par une nouvelle
édition. Pour rechercher des éditions plus récentes de ce
document, rendez-vous sur :

http://www.vmware.com/fr/support/pubs.

FR-001419-00

Dépannage vSphere

Vous trouverez la documentation technique la plus récente sur le site Web de VMware à l'adresse :

http://www.vmware.com/fr/support/

Le site Web de VMware propose également les dernières mises à jour des produits.

N’hésitez pas à nous transmettre tous vos commentaires concernant cette documentation à l’adresse suivante :

[e-mail]

Copyright © 2010–2014 VMware, Inc. Tous droits réservés. Copyright et informations sur les marques.

VMware, Inc.

3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com

2 VMware, Inc.

VMware, Inc.

100-101 Quartier Boieldieu
92042 Paris La Défense
France
www.vmware.com/fr

Table des matières

A propos du Dépannage vSphere 5

Dépannage de machines virtuelles 7

1

Dépannage de machines virtuelles tolérantes aux pannes 7
Dépanner les périphériques de relais USB 11
Récupérer des machines virtuelles orphelines 13
Impossible de consolider des snapshots pour des disques de grande capacité 13
Échec de l'activation d'une machine virtuelle après un clonage ou un déploiement effectué à partir

d'un modèle dans Client Web vSphere 14

Dépannage des hôtes 17

2

Dépannage des états de l'hôte vSphere HA 17
Dépannage de la fonction Auto Deploy 21
Erreur de manipulation du jeton d'authentification 27
Une erreur de l'ensemble de règles Active Directory provoque une défaillance de conformité du

profil d'hôte dans Client Web vSphere 28

Impossible d'accéder au domaine lorsque les ressources Likewise sont faibles 29

Dépannage de vCenter Server et Client Web vSphere 31

3

Dépannage de vCenter Server 31
Dépannage de Client Web vSphere 34
Dépannage de Linked Mode 36
Dépannage des certificats d'hôte ESXi et vCenter Server 39
Dépannage des plug-ins vCenter Server 40

VMware, Inc.

Résolution des problèmes de disponibilité 41

4

Dépannage du contrôle d'admission vSphere HA 41
Dépannage des banques de données de signaux de pulsation 43
Dépannage des problèmes de protection de basculement vSphere HA 45
Dépannage de vSphere Fault Tolerance dans des partitions réseau 47

Dépannage de gestion des ressources 49

5

Informations de dépannage de DRS 49
Dépannage du DRS de stockage 58
Dépannage du contrôle d'E/S de stockage 65

Dépannage du stockage 67

6

Résolution des problèmes d'affichage de stockage SAN 68
Résolution des problèmes de performance de SAN 70
Les machines virtuelles dotées de RDM doivent ignorer la mise en cache SCSI INQUIRY 73
L'adaptateur iSCSI logiciel est désactivé lorsqu'il n'est pas nécessaire 74

3

Dépannage vSphere

Echec dans le montage des banques de données NFS 74
Les fichiers journaux VMkernel contiennent des codes de détection SCSI 75
Dépannage des adaptateurs de stockage 76
Vérification de la cohérence des métadonnées avec VOMA 77
Dépannage des disques SSD (Solid-State Drives) 78
Dépannage de Virtual SAN 82

Résolution des problèmes de mise en réseau 85

7

Adresses MAC dupliquées de machines virtuelles appartenant à un même réseau 86
Échec de la conversion vers la prise en charge étendue du protocole LACP 88
Impossible de supprimer un hôte d'un vSphere Distributed Switch 89
Les hôtes d'un vSphere Distributed Switch 5.1 (et versions ultérieures) perdent la connectivité à

vCenter Server 90

Les hôtes de vSphere Distributed Switch 5.0 et versions antérieures perdent leur connectivité à

vCenter Server 92
Alarme indiquant une perte de redondance du réseau sur un hôte 93
Les machines virtuelles perdent leur connectivité après la modification de l'ordre de basculement

des liaisons montantes d'un groupe de ports distribués 94
Une machine virtuelle exécutant un client VPN provoque un déni de service pour les machines

virtuelles sur l'hôte ou sur un cluster vSphere HA 95
Faible débit pour les charges de travail UDP sur des machines virtuelles Windows 97
Des machines virtuelles situées dans un même groupe de ports distribués, mais sur des hôtes

différents, ne peuvent pas communiquer entre elles 99
Une machine virtuelle qui utilise une fonction virtuelle SR-IOV est mise hors tension, car l'hôte n'a

plus de vecteurs d'interruption 99
Les tentatives de mise sous tension d'un vApp migré échouent, car le profil de protocole associé est

manquant 100
Restauration d'une opération de configuration de mise en réseau et déconnexion d'un hôte de

vCenter Server 101

Dépannage de l'attribution de licence 103

8

Résolution des problèmes de licence d'hôte 103
Résolution des problèmes de rapport de licence 105
Impossible d'activer une machine virtuelle 108
Impossible d'affecter une clé de licence à vCenter Server 108
Impossible de configurer ou d'utiliser une fonction 109

Index 111

4 VMware, Inc.

A propos du Dépannage vSphere

Dépannage vSphere décrit les problèmes et les procédures de dépannage des implémentations de vCenter
Server et de ses composants.

Public cible

Ces informations concernent toutes les personnes qui souhaitent dépanner les machines virtuelles, les hôtes
ESXi, les clusters, ainsi que les solutions de stockage en lien. Les informations fournies dans ce livre sont
destinées aux administrateurs du système Windows ou Linux expérimentés qui connaissent le
fonctionnement de la technologie des machines virtuelles et des centres de données.

VMware, Inc. 5

Dépannage vSphere

6 VMware, Inc.

Dépannage de machines virtuelles 1

Les rubriques de dépannage de machines virtuelles proposent des solutions aux problèmes potentiels qui
peuvent apparaître lors de l'utilisation de vos machines virtuelles.

Ce chapitre aborde les rubriques suivantes :

« Dépannage de machines virtuelles tolérantes aux pannes », page 7

n

« Dépanner les périphériques de relais USB », page 11

n

« Récupérer des machines virtuelles orphelines », page 13

n

« Impossible de consolider des snapshots pour des disques de grande capacité », page 13

n

« Échec de l'activation d'une machine virtuelle après un clonage ou un déploiement effectué à partir

n

d'un modèle dans Client Web vSphere », page 14

Dépannage de machines virtuelles tolérantes aux pannes

Il est nécessaire de connaître quelques rubriques de dépannage pour conserver un haut niveau de
performance et de stabilité pour les machines virtuelles tolérantes aux pannes et pour réduire les taux de
basculement.

Les rubriques de dépannage traitées concernent des problèmes que vous pourriez rencontrer lors de
l'utilisation de la fonction vSphere Fault Tolerance sur vos machines virtuelles. Les rubriques expliquent
également comment résoudre les problèmes.

Vous pouvez également consulter l'article dans la base de connaissances VMware accessible à l'adresse

http://kb.vmware.com/kb/1033634 pour vous aider à dépanner la fonction de Fault Tolerance. Cet article

contient la liste des messages d'erreur pouvant être rencontrés lorsque vous essayez d'utiliser la fonction et,
si applicable, conseille comment résoudre chaque erreur.

Virtualisation matérielle non activée

Vous devez activer la Virtualisation matérielle (HV) avant d'utiliser vSphere Fault Tolerance.

Problème

Lorsque vous essayez de mettre sous tension une machine virtuelle dont Fault Tolerance est activée, un
message d'erreur risque d'apparaître si vous n'avez pas activé HV.

Cause

Cette erreur est souvent dû à la non disponibilité de HV sur le serveur ESXi sur lequel vous essayez de
mettre sous tension la machine virtuelle. Il est possible que la virtualisation matérielle ne soit pas non plus
disponible parce qu'elle n'est pas prise en charge par les composants matériels du serveur ESXi ou qu'elle
n'a pas été activée dans le BIOS.

VMware, Inc.

7

Dépannage vSphere

Solution

Si les composants matériels du serveur ESXi prennent en charge la virtualisation matérielle, mais que celle-ci
n'est pas activée, activez-la dans le BIOS du serveur Le processus d'activation de la virtualisation matérielle
varie en fonction du BIOS. Reportez-vous à la documentation du BIOS de vos hôtes pour plus
d'informations sur la configuration de la virtualisation matérielle.

Si les composants matériels du serveur ESXi ne prennent pas en charge la virtualisation matérielle, basculez
sur des composants matériels utilisant des processeurs qui prennent en charge Fault Tolerance

Hôtes compatibles non disponibles pour les machines virtuelles secondaires

Si vous mettez sous tension une machine virtuelle avec Fault Tolerance activée et qu'aucun hôte compatible
n'est disponible pour sa machine virtuelle secondaire, un message d'erreur s'affichera peut-être.

Problème

Le message d'erreur suivant peut s'afficher :

La machine virtuelle secondaire ne peut être allumée car il n'existe pas d'hôte compatible.

Cause

Ce problème peut s'expliquer de différentes manières. Parmi les causes possibles, on peut citer le fait qu'il
n'y a pas d'autres hôtes dans le cluster, qu'il n'y a pas d'autres hôtes dont la virtualisation matérielle est
activée, que les banque de données sont inaccessibles, qu'il n'y a pas de capacité disponible ou que les hôtes
sont en mode maintenance.

Solution

S'il n'y a pas suffisamment d'hôtes, ajoutez-en davantage dans le cluster. S'il y a des hôtes dans le cluster,
vérifiez qu'ils prennent en charge la virtualisation matérielle et que celle-ci est activée. Le processus
d'activation de la virtualisation matérielle varie en fonction du BIOS. Reportez-vous à la documentation du
BIOS de vos hôtes pour plus d'informations sur la configuration de la virtualisation matérielle. Vérifiez que
les hôtes disposent de capacité suffisante et qu'ils ne sont pas en mode de maintenance.

Une machine virtuelle secondaire sur un hôte surchargé dégrade les performances de la machine virtuelle principale

Lorsqu'une machine virtuelle principale semble ralentie, alors que la charge de travail de son hôte est légère
et qu'elle conserve du temps de CPU inactif, vérifiez que l'hôte sur lequel la machine virtuelle secondaire est
exécutée n'est pas surchargé.

Problème

Lorsqu'une machine virtuelle secondaire réside sur un hôte fortement chargé, ceci peut affecter la
performance de la machine virtuelle principale.

Une manifestation de ce problème peut être le voyant jaune ou rouge pour l'intervalle vLockstep sur le
panneau de Fault Tolerance de la machine virtuelle principale. Cela signifie que la machine virtuelle
secondaire a quelques secondes de retard par rapport à la machine virtuelle principale. Dans ce cas, Fault
Tolerance ralentit la machine virtuelle principale. Si l'intervalle vLockstep reste jaune ou rouge de manière
prolongée, cela indique que la machine virtuelle secondaire ne bénéficie pas de suffisamment de ressources
CPU pour suivre la machine virtuelle principale.

8 VMware, Inc.

Chapitre 1 Dépannage de machines virtuelles

Cause

Une machine virtuelle secondaire exécutée sur un hôte dont les ressources de CPU sont surchargées ne
bénéficiera pas nécessairement de la même quantité de ressources CPU que la machine virtuelle principale.
Si c'est le cas, la machine virtuelle principale doit ralentir pour que la machine virtuelle secondaire
parvienne à la suivre. Elle réduit alors sa vitesse d'exécution pour atteindre la vitesse inférieure de la
machine virtuelle secondaire.

Solution

Pour résoudre ce problème, définissez une réservation de CPU explicite pour la machine virtuelle principale
en réglant une valeur en MHz suffisante pour l'exécution de la charge de travail au niveau de performances
requis. Cette réservation est appliquée à la fois aux machines virtuelles principale et secondaire, ce qui
garantit qu'elles pourront toutes deux fonctionner à la vitesse spécifiée. Pour vous aider à définir cette
réservation, consultez les courbes de performances de la machine virtuelle (avant l'activation de Fault
Tolerance) pour vérifier la quantité de ressources CPU utilisée dans des conditions normales.

Les machines virtuelles ayant une grosse mémoire peuvent empêcher l'utilisation de Fault Tolerance

Il est uniquement possible d'activer Fault Tolerance sur les machines virtuelles dont la mémoire ne dépasse
pas 64 Go.

Problème

L'activation de Fault Tolerance sur une machine virtuelle possédant plus de 64 Go peut échouer. La
migration d'une machine virtuelle tolérante aux pannes, en cours d'exécution et utilisant vMotion, risque
aussi d'échouer si sa mémoire dépasse 15 Go ou si celle-ci change à une vitesse supérieure à la capacité de
copie de vMotion sur le réseau.

Cause

Cela se produit si, à cause de la capacité de mémoire de la machine virtuelle, il n'y a plus suffisamment de
bande passante pour achever l'opération de basculement vMotion pendant le délai d'expiration par défaut
(8 secondes).

Solution

Pour résoudre ce problème, avant d'activer Fault Tolerance, mettez la machine virtuelle hors tension et
augmentez son délai d'expiration en ajoutant la ligne suivante dans le fichier vmx de la machine virtuelle :

ft.maxSwitchoverSeconds = "30"

où 30 est le délai d'expiration en nombre de secondes. Activez Fault Tolerance et rallumez la machine
virtuelle. Cette solution devrait être efficace lorsque le réseau présente une forte activité.

REMARQUE Si vous augmentez le délai d'expiration à 30 secondes, la machine virtuelle tolérante aux pannes
risque de ne plus répondre pendant une durée plus longue (jusqu'à 30 secondes) lors de l'activation de la
tolérance aux pannes ou lorsqu'une nouvelle machine virtuelle secondaire est créée suite à un basculement.

L'utilisation du CPU par la machine virtuelle secondaire semble excessive

Dans certains cas, vous constatez que l'utilisation du CPU pour une machine virtuelle secondaire est
supérieure à celle de la machine virtuelle principale qui y est associée.

Problème

Lorsque la machine virtuelle principale est inactive, la différence relative entre les machines virtuelles
principale et secondaire peut paraître importante.

VMware, Inc. 9

Dépannage vSphere

Cause

Le fait de relire des événements (comme des interruptions du temporisateur) sur la machine virtuelle
secondaire peut être légèrement plus coûteux en charge de calcul que leur enregistrement sur la machine
virtuelle principale. Cette charge additionnelle est minime.

Solution

Aucune requise. L'examen de l'utilisation effective du CPU révèle que très peu de ressources CPU sont
utilisées par la machine virtuelle principale ou secondaire.

La machine virtuelle principale rencontre une erreur de dépassement d'espace

Si le système de stockage que vous utilisez dispose de provisionnement dynamique intégré, une machine
virtuelle principale peut se bloquer lorsqu'elle rencontre une erreur de dépassement d'espace.

Problème

En cas d'utilisation avec un système légèrement provisionné, une machine virtuelle principale peut se
bloquer. La machine virtuelle secondaire remplace la machine virtuelle principale mais le message d'erreur
suivant s'affiche : « Il n'y a plus d'espace pour le disque virtuel <disk_name> ».

Cause

Si le provisionnement dynamique est intégré au sein du système de stockage, il n'est pas possible pour les
hôtes ESX/ESXi de savoir si suffisamment d'espace disque a été alloué à une paire de machines virtuelles
tolérantes aux pannes. Si la machine virtuelle principale requiert plus d'espace disque mais qu'il n'y a plus
d'espace restant au niveau du stockage, la machine virtuelle principale se bloque.

Solution

Le message d'erreur vous donne le choix de continuer la session en cliquant sur « Réessayer » ou de mettre
fin à la session en cliquant sur « Annuler ». Vérifiez s'il y a suffisamment d'espace disque pour la paire de
machines virtuelles tolérantes aux pannes et cliquez sur « Réessayer ».

Basculement d'une machine virtuelle tolérante aux pannes

Une machine virtuelle principale ou secondaire peut basculer même si ses hôtes ESXi ne sont pas
défectueux. Dans ce cas, l'exécution de la machine virtuelle n'est pas interrompue mais la redondance est
temporairement perdue. Pour éviter ce type de basculement, soyez conscient de quelques-unes des
situations pouvant survenir et prenez des mesures pour les éviter.

Panne matérielle partielle liée au stockage

Ce problème peut survenir lorsque l'accès au stockage est lent ou interrompu sur l'un des hôtes. Lorsque
cela se produit, de nombreuses erreurs de stockage sont présentes dans le journal VMkernel. Pour résoudre
ce problème, vous devez traiter les problèmes liés à votre stockage.

Panne matérielle partielle liée au réseau

Si la carte réseau de journalisation ne fonctionne pas ou si les connexions à d'autres hôtes via cette carte
réseau sont défectueuses, cela risque de déclencher le basculement d'une machine virtuelle tolérante aux
pannes de façon à rétablir la redondance. Pour éviter ce problème, dédiez un adaptateur réseau séparée au
trafic de journalisation vMotion et FT et exécutez uniquement les migrations vMotion quand les machines
virtuelles sont moins actives.

10 VMware, Inc.

Chapitre 1 Dépannage de machines virtuelles

Bande passante insuffisante sur le réseau de la carte de journalisation

Cela peut se produire lorsque trop de machines virtuelles tolérantes aux pannes se trouvent sur un hôte.
Pour résoudre ce problème, répartissez davantage les paires de machines virtuelles tolérantes aux pannes
entre les hôtes.

Défaillances de vMotion en raison du niveau d'activité des machines virtuelles

En cas d'échec de la migration vMotion d'une machine virtuelle tolérante aux pannes, celle-ci peut avoir
besoin d'être basculée. Cela se produit généralement lorsque la machine virtuelle est trop active pour que la
migration soit achevée avec seulement des perturbations minimales de l'activité. Pour éviter ce problème,
effectuez uniquement les migrations vMotion quand les machines virtuelles sont moins actives.

Une activité excessive sur le volume VMFS peut entraîner le basculement des
machines virtuelles

Lorsqu'un certain nombre d'opérations de verrouillage du système de fichiers, de mises hors et sous tension
des machines virtuelle ou de migrations vMotion se produisent sur un seul volume VMFS, cela risque de
déclencher le basculement des machines virtuelles tolérantes aux pannes. La réception de nombreux
avertissements relatifs à des réservations SCSI dans le journal VMkernel peut être un symptôme. Pour
résoudre ce problème, réduisez le nombre d'opérations dans le système de fichiers ou vérifiez que la
machine virtuelle tolérante aux pannes se trouve sur un volume VMFS qui ne contient pas un grand nombre
de machines virtuelles régulièrement mises sous tension, mises hors tension ou migrées à l'aide de vMotion.

Le manque d'espace dans le système de fichiers empêche le démarrage d'une
machine virtuelle secondaire

Vérifiez que les systèmes de fichiers /(root) ou /vmfs/datasource ont de l'espace disponible. Ces systèmes de
fichiers peuvent être pleins pour de nombreuses raisons et un manque d'espace peut empêcher le démarrage
d'une nouvelle machine virtuelle secondaire.

Dépanner les périphériques de relais USB

Les informations sur le comportement de fonction peuvent vous aider à dépanner ou éviter des problèmes
potentiels quand des périphériques USB sont connectés à une machine virtuelle.

Message d'erreur quand vous essayez de migrer la machine virtuelle avec des périphériques USB attachés

La migration à l'aide de vMotion ne peut pas continuer et elle émet un message d'erreur confus quand vous
connectez plusieurs périphériques de relais USB d'un hôte ESXi vers une machine virtuelle et qu'un ou
plusieurs périphériques ne sont pas activés pour vMotion.

Problème

L'assistant Migrer la machine virtuelle exécute un contrôle de compatibilité avant que l'opération de
migration ne commence. Si des périphériques USB non pris en charge sont détectés, le contrôle de
compatibilité échoue et un message d'erreur similaire au suivant apparaît : Périphérique 'USB 1' connecté

actuellement utilise 'path:1/7/1' de sauvegarde, qui n'est pas accessible.

Cause

Pour réussir les tests de compatibilité vMotion, vous devez activer vMotion sur tous les périphériques USB
connectés à la machine virtuelle depuis un hôte. Si un ou plusieurs périphériques ne sont pas activés pour la
vMotion, la migration échouera.

VMware, Inc. 11

Dépannage vSphere

Solution

1 Assurez-vous que les périphériques ne sont pas en cours de transfert de données avant de les

supprimer.

2 Ré-ajoutez et activez la vMotion pour chaque périphérique USB affecté.

Le périphérique de relais USB ne répond pas

Les périphériques USB peuvent ne plus répondre pour plusieurs raisons, dont l'interruption non sécurisée
d'un transfert de données ou si un pilote de système d'exploitation client envoie une commande non prise
en charge au périphérique.

Problème

Le périphérique USB ne répond pas.

Cause

Un transfert de données a été interrompu ou des périphériques non pris en charge sont utilisés. Par
exemple, si un pilote invité envoie une commande SCSI REPORT LUNS à certains lecteurs flash USB non pris
en charge, le périphérique cesse de répondre à toutes les commandes.

Solution

Détachez physiquement le périphérique USB de l'hôte ESXi et rattachez-le.

u

Si l'hôte est physiquement inaccessible, vous pouvez arrêter l'hôte (pas redémarrer) et le laisser hors
tension pendant au moins 30 secondes pour vous assurer que le bus USB de l'hôte est entièrement mis
hors tension.

Lorsque vous mettez l'hôte sous tension, le périphérique USB est restauré à partir de son état sans
réponse.

Impossible de copier les données d'un hôte ESXi vers un périphérique USB connecté à l'hôte

Vous pouvez connecter un périphérique USB à un hôte ESXi et copier les données de l'hôte vers le
périphérique. Par exemple, vous pouvez rassembler le bundle vm-support après que l'hôte a perdu la
connectivité réseau. Pour ce faire, vous devez interrompre l'arbitre USB.

Problème

Si l'arbitre USB est utilisé pour le relais USB entre un hôte ESXi et une machine virtuelle, le périphérique
USB apparaît sous lsusb mais n'est pas correctement monté.

Cause

Ce problème se produit car le périphérique USB non amorçable est relayé à la machine virtuelle par défaut.
Il n'apparaît pas sur le système de fichiers de l'hôte, même si lsusb peut voir le périphérique.

Solution

1 Interrompez le service usbarbitrator : /etc/init.d/usbarbitrator stop

2 Déconnectez et reconnectez physiquement le périphérique USB.

Par défaut, l'emplacement du périphérique est /vmfs/devices/disks/mpx.vmhbaXX:C0:T0:L0.

3 Une fois que vous avez reconnecté le périphérique, redémarrez le service

usbarbitrator :/etc/init.d/usbarbitrator start

4 Redémarrez hostd et toute machine virtuelle en cours d'exécution pour rétablir l'accès aux

périphériques de relais dans la machine virtuelle.

12 VMware, Inc.

Suivant

Reconnectez les périphériques USB à la machine virtuelle.

Récupérer des machines virtuelles orphelines

Les machines virtuelles apparaissent avec le terme (orphaned) ajouté à leur nom.

Problème

Les machines virtuelles résidant sur un hôte ESXi géré par vCenter Server peuvent devenir orphelines dans
certains cas rares. Ces machines virtuelles existent dans la base de données vCenter Server mais l'hôte ESXi
ne les reconnaît plus.

Cause

Des machines virtuelles peuvent devenir orphelines en cas d'échec du basculement d'un hôte ou lorsque
l'enregistrement de la machine virtuelle est directement annulé sur l'hôte. Si cette situation se produit,
déplacez la machine virtuelle orpheline vers un autre hôte du centre de données sur lequel les fichiers de la
machine virtuelle sont stockés.

Solution

1 Cliquez avec le bouton droit de la souris sur la machine virtuelle et sélectionnez Migrer.

Chapitre 1 Dépannage de machines virtuelles

La liste des hôtes disponibles s'affiche.

2 Cliquez sur Changer d’hôte, puis sur Suivant.

3 Sélectionnez l'hôte sur lequel mettre la machine virtuelle.

Si aucun hôte n'est disponible, ajoutez un hôte qui peut accéder à la banque de données sur laquelle les
fichiers de la machine virtuelle sont stockés.

4 Cliquez sur Finish pour enregistrer vos modifications.

La machine virtuelle est connectée au nouvel hôte et apparaît dans l'inventaire.

Impossible de consolider des snapshots pour des disques de grande capacité

Si vous prenez au moins un snapshot d'une machine virtuelle disposant de disques d'une capacité
supérieure à 2 To, et que vous supprimez un ou plusieurs des snapshots, les fichiers de snapshots risquent
de ne pas se consolider.

Problème

L'un des fichiers de snapshots, un journal de rétablissement ou un disque enfant, risquent de ne pas être
consolidés. Un fichier non consolidé peut causer une utilisation inefficace du stockage, et le disque enfant
non consolidé peut grandir dans le temps en raison des E/S du système d'exploitation invité.

Solution

Supprimez les snapshots pendant que la machine virtuelle est hors tension.

n

Prévoyez une mise hors service routinière de la machine virtuelle pour supprimer les fichiers non
consolidés afin d'éviter ce problème.

Vous pouvez également mettre hors tension la machine virtuelle et consolider de force les disques non

n

consolidés à l'aide de vSphere Web Client. Reportez-vous à la documentation Administration de machine
virtuelle.

VMware, Inc. 13

Dépannage vSphere

Échec de l'activation d'une machine virtuelle après un clonage ou un déploiement effectué à partir d'un modèle dans Client Web vSphere

Les machines virtuelles ne sont pas activées après la fin du clonage ou du déploiement effectué à partir du
workflow d'un modèle dansClient Web vSphere.

Problème

Lorsque vous clonez une machine virtuelle ou déployez une machine virtuelle à partir d'un modèle, vous
pouvez cocher la case Mettre sous tension cette machine virtuelle après création sur la page Prêt à
terminer. Toutefois, la machine virtuelle peut ne pas se mettre automatiquement sous tension après sa
création.

Cause

La taille du fichier d'échange n'est pas réservée lors de la création des disques de la machine virtuelle.

Solution

Réduisez la taille du fichier d'échange qui est requise pour la machine virtuelle. Pour ce faire,

n

augmentez la réservation de mémoire de la machine virtuelle.

a Cliquez avec le bouton droit sur la machine virtuelle et sélectionnez Modifier les paramètres.

b Sélectionnez Matériel virtuel, puis cliquez sur Mémoire.

c Utilisez le menu déroulant Réservation pour augmenter la quantité de mémoire allouée à la

machine virtuelle.

d Cliquez sur OK.

Vous pouvez également augmenter la quantité d'espace disponible du fichier d'échange en déplaçant

n

d'autres disques de machine virtuelle en dehors de la banque de données qui est utilisée pour le fichier
d'échange.

a Accédez à la banque de données dans le navigateur d'objets de Client Web vSphere.

b Sélectionnez l'onglet Objets associés, puis cliquez sur l'ongletMachines virtuelles.

c Pour chaque machine virtuelle à déplacer, effectuez un clic droit sur la machine virtuelle et

sélectionnez l'option Déplacer.

d Sélectionnez Changer la banque de données.

e Continuez en utilisant l'assistant Migrer la machine virtuelle.

Vous pouvez également augmenter la quantité d'espace disponible du fichier d'échange en modifiant

n

l'emplacement du fichier d'échange vers une banque de données ayant suffisamment d'espace.

a Accédez à l'hôte dans le navigateur d'objets de Client Web vSphere.

b Sélectionnez l'onglet Gérer et cliquez sur Paramètres.

c Dans Machines Virtuelles, sélectionnez Emplacement du fichier d'échange de VM.

d Cliquez sur Edit.

REMARQUE Si l'hôte fait partie d'un cluster qui établit que les fichiers d'échange de la machine
virtuelle sont stockés dans le même répertoire que celui de la machine virtuelle, vous ne pouvez
pas cliquer sur Modifier. Vous devez utiliser la boîte de dialogue Paramètres du cluster pour
modifier la règle d'emplacement du fichier d'échange pour le cluster.

14 VMware, Inc.

Chapitre 1 Dépannage de machines virtuelles

e Cliquez sur Banques de données sélectionnées et sélectionnez une banque de données dans la

liste.

f Cliquez sur OK.

VMware, Inc. 15

Dépannage vSphere

16 VMware, Inc.

Dépannage des hôtes 2

Les rubriques de dépannage des hôtes proposent des solutions aux problèmes potentiels qui peuvent
apparaître lors de l'utilisation de vos hôtes vCenter Servers et ESXi.

Ce chapitre aborde les rubriques suivantes :

« Dépannage des états de l'hôte vSphere HA », page 17

n

« Dépannage de la fonction Auto Deploy », page 21

n

« Erreur de manipulation du jeton d'authentification », page 27

n

« Une erreur de l'ensemble de règles Active Directory provoque une défaillance de conformité du

n

profil d'hôte dans Client Web vSphere », page 28

« Impossible d'accéder au domaine lorsque les ressources Likewise sont faibles », page 29

n

Dépannage des états de l'hôte vSphere HA

vCenter Server signale que les états de l'hôte vSphere HA indiquent une condition d'erreur au niveau de
l'hôte. De telles erreurs peuvent empêcher vSphere HA de protéger totalement les machines virtuelles sur
l'hôte et peuvent gêner la capacité de redémarrage des machines virtuelles de vSphere HA suite à une
défaillance. Des erreurs peuvent se produire lorsque vSphere HA est configuré ou déconfiguré sur un hôte
ou, plus rarement, pendant une opération normale. Quand cela se produit, vous devez définir comment
résoudre l'erreur, afin que vSphere HA soit totalement opérationnel.

L'agent vSphere HA est à l'état Inaccessible

L'agent vSphere HA se trouvant sur un hôte est à l'état Agent inaccessible pendant une minute ou plus. Une
intervention utilisateur peut être requise afin de résoudre cette situation.

Problème

vSphere HA signale qu'un agent est à l'état Agent inaccessible lorsque l'agent de l'hôte ne peut être contacté
par l'hôte principal ou par vCenter Server. Par conséquent, vSphere HA ne peut pas surveiller les machines
virtuelles se trouvant sur l'hôte et est dans l'impossibilité de les redémarrer suite à une défaillance.

Cause

Un agent vSphere HA peut être à l'état Agent inaccessible pour plusieurs raisons. Cette condition signifie le
plus souvent qu'un problème de mise en réseau empêche vCenter Server de contacter l'hôte principal et
l'agent se trouvant sur l'hôte, ou que tous les hôtes du cluster ont échoué. Cette condition peut également
indiquer la situation peu probable où vSphere AH a été désactivé puis réactivé sur le cluster alors que
vCenter Server ne pouvait pas communiquer avec l'agent vSphere HA sur l'hôte ou que l'agent sur l'hôte a
échoué, et que le processus de surveillance n'était pas en mesure de le redémarrer.

VMware, Inc.

17

Dépannage vSphere

Solution

Déterminez si vCenter Server signale que l'hôte ne répond pas. Si tel est le cas, il existe un problème de mise
en réseau ou un échec global du cluster. Une fois que chaque condition est résolue, vSphere HA doit
fonctionner à nouveau correctement. Sinon, reconfigurez vSphere HA sur l'hôte. De même, si vCenter
Server signale que les hôtes répondent mais que l'état d'un hôte est Agent inaccessible, reconfigurez vSphere
HA sur cet hôte.

L'agent vSphere HA est à l'état Non initialisé

L'agent vSphere HA se trouvant sur un hôte est à l'état Non initialisé pendant une minute ou plus. Une
intervention utilisateur peut être requise afin de résoudre cette situation.

Problème

vSphere HA signale qu'un agent est à l'état Non initialisé quand l'agent de l'hôte ne peut pas entrer dans
l'état d'exécution et qu'il devient l'hôte principal ou quand il ne peut pas se connecter à l'hôte principal. Par
conséquent, vSphere HA ne peut pas surveiller les machines virtuelles se trouvant sur l'hôte et est dans
l'impossibilité de les redémarrer suite à une défaillance.

Cause

Un agent vSphere HA peut être à l'état Non initialisé pour une ou plusieurs raisons. Cette condition indique
souvent que l'hôte n'a pas accès aux banques de données. Moins fréquemment, cette condition indique que
l'hôte n'a pas accès à la banque de données locale sur laquelle vSphere HA met en cache les informations sur
les états, que l'agent se trouvant sur l'hôte est inaccessible, ou que l'agent vSphere HA ne peut pas ouvrir les
ports du pare-feu requis.

Solution

Recherchez la liste des événements de l'hôte dans le cas des occurrences récentes de l'événement L'agent

vSphere HA de l'hôte comporte une erreur. Cet événement indique la raison pour laquelle l'hôte est à l'état

non initialisé. Si la condition existe suite à un problème de banque de données, une résolution quelconque
peut empêcher l'hôte d'accéder aux banques de données concernées. Une fois que le problème a été résolu, si
l'agent ne retourne pas dans un état opérationnel, reconfigurez vSphere HA au niveau de l'hôte.

REMARQUE Si la condition existe suite à un problème de pare-feu, vérifiez qu'il existe un autre service sur
l'hôte qui utilise le port 8192. Si tel est le cas, arrêtez ce service et reconfigurez vSphere HA.

L'agent vSphere HA est à l'état Erreur d'initialisation

L'agent vSphere HA se trouvant sur un hôte est à l'état Erreur d'initialisation pendant une minute ou plus.
Une intervention utilisateur est requise pour résoudre cette situation

Problème

vSphere HA signale qu'un agent est à l'état Erreur d'initialisation depuis que la dernière tentative de
configuration de vSphere HA pour l'hôte a échoué. vSphere HA ne surveille pas les machines virtuelles se
trouvant sur un tel hôte et est dans l'impossibilité de les redémarrer suite à une défaillance.

Cause

Cette condition indique la plupart du temps que vCenter Server ne pouvait pas se connecter à l'hôte alors
qu'un agent vSphere HA avait été installé ou configuré sur l'hôte. Cette condition peut également indiquer
que l'installation et la configuration sont terminées, mais que l'agent n'est pas devenu un hôte principal ou
un hôte dépendant pendant une période d'attente. D'une manière moins fréquente, la condition indique que

18 VMware, Inc.

Chapitre 2 Dépannage des hôtes

l'espace disque de la banque de données de l'hôte est insuffisant pour installer l'agent, ou qu'il n'y a pas
suffisamment de ressources de mémoire non réservées sur l'hôte pour l'ensemble des ressources de l'agent.
Enfin, dans le cas des hôtes ESXi 5.0, la configuration échoue si la précédente installation d'un autre
composant a nécessité un redémarrage de l'hôte, mais que ce redémarrage n'a pas encore eu lieu.

Solution

Lorsqu'une tâche de Configuration de HA échoue, la raison de l'échec est rapportée.

Raison de l'échec Action

Erreurs de
communication de l'hôte

Erreurs de dépassement
du délai d'attente

Manque d'espace de
fichier

Redémarrage en attente Si l'installation d'un hôte d'une version 5.0 ou supérieure échoue suite à un redémarrage mis

Corrigez toute erreur de communication avec l'hôte et réessayez l'opération de
configuration.

Parmi les causes éventuelles de l'échec peuvent se rencontrer les cas suivants : l'hôte s'est
bloqué pendant la tâche de configuration, l'agent n'a pas réussi à démarrer après son
installation ou l'agent n'a pas été capable de s'initialiser lui-même après le démarrage.
Vérifiez si vCenter Server est capable de communiquer avec l'hôte. Si tel est le cas, voir

« L'agent vSphere HA est à l'état Inaccessible », page 17 ou « L'agent vSphere HA est à l'état
Non initialisé », page 18 pour d'éventuelles solutions.

Libérez environ 75 Mo d'espace disque. Si l'échec provient d'une mémoire non réservée
insuffisante, libérez la mémoire sur l'hôte en déplaçant des machines virtuelles vers un autre
hôte ou en réduisant leurs réservations. Dans les deux cas, relancez la tâche de configuration
de vSphere HA après avoir corrigé le problème.

en attente, redémarrez l'hôte et relancez la tâche de configuration de vSphere HA.

L'agent vSphere HA est à l'état Erreur de non initialisation

L'agent vSphere HA se trouvant sur un hôte est à l'état Erreur de non initialisation. Une intervention
utilisateur est requise afin de résoudre cette situation.

Problème

vSphere HA signale qu'un agent est à l'état Erreur de non initialisation lorsque vCenter Server est dans
l'impossibilité de supprimer la configuration de l'agent sur l'hôte pendant la tâche Unconfigure HA. Un
agent laissé dans cet état peut interférer avec le fonctionnement du cluster. Par exemple, l'agent se trouvant
sur l'hôte peut se définir lui-même comme étant l'hôte principal et verrouiller une banque de données. Le
verrouillage d'une banque de données empêche l'hôte principal valide du cluster de gérer les machines
virtuelles avec les fichiers de configuration se trouvant sur cette banque de données.

Cause

Cette conditIon indique en général que l'hôte vCenter Server a perdu la connexion avec l'hôte pendant que
la configuration de l'agent était en train d'être supprimée.

Solution

Ajoutez à nouveau l'hôte à vCenter Server (version 5.0 ou ultérieure). L'hôte peut être ajouté en tant qu'hôte
autonome ou ajouté à n'importe quel cluster.

L'agent vSphere HA est à l'état Hôte en échec

L'agent vSphere HA se trouvant sur un hôte est à l'état Hôte en échec. Une intervention utilisateur est
requise pour résoudre la situation.

Problème

En général, de tels rapports indiquent qu'un hôte a réellement échoué, mais les rapports de défaillance
peuvent parfois être incorrects. Un hôte en échec réduit la capacité disponible dans le cluster et, en cas de
rapport incorrect, empêche vSphere HA de protéger les machines virtuelles s'exécutant sur l'hôte.

VMware, Inc. 19

Dépannage vSphere

Cause

Cet état d'hôte se rencontre lorsque l'hôte principal de vSphere HA auquel vCenter Server est connecté est
incapable de communiquer avec l'hôte et avec les banques de données à signal de pulsation qui sont en
cours d'utilisation pour l'hôte. Toute défaillance de stockage qui rend les banques de données inaccessibles
aux hôtes peut provoquer cette condition si elle est accompagnée d'une défaillance réseau.

Solution

Vérifiez s'il existe une des conditions de défaillance énoncées et corrigez celles que vous rencontrez.

L'agent vSphere HA est à l'état Réseau partitionné

L'agent vSphere HA se trouvant sur un hôte est à l'état Réseau partitionné. Une intervention utilisateur peut
être requise afin de résoudre cette situation.

Problème

Tandis que les machines virtuelles s'exécutant sur l'hôte continuent à être surveillées par les hôtes
principaux qui sont responsables d'elles, la capacité de vSphere HA à redémarrer les machines virtuelles
suite à une défaillance est affectée. Premièrement, chaque hôte principal a accès à un sous-ensemble d'hôtes,
de sorte qu'une capacité de basculement moindre est disponible pour chaque hôte. Deuxièmement, vSphere
HA peut être dans l'impossibilité de redémarrer une deuxième machine virtuelle suite à une défaillance
(voir « La machine virtuelle principale reste à l'état Secondaire nécessaire », page 47).

Cause

Un hôte est signalé partitionné si les deux conditions suivantes se rencontrent :

L'hôte principal vSphere HA auquel vCenter Server est connecté est dans l'impossibilité de

n

communiquer avec l'hôte en utilisant le réseau de gestion, mais est capable de communiquer avec cet
hôte par le biais des banques de données à signal de pulsation qui ont été choisies pour lui.

L'hôte n'est pas isolé.

n

Une partition réseau peut se produire pour différentes raisons, notamment un mauvais balisage VLAN, une
panne de commutateur ou de NIC physique, une configuration de cluster avec certains hôtes qui utilisent
uniquement IPv4 et d'autres qui utilisent uniquement IPv6, ou des réseaux de gestion pour certains hôtes
ayant été déplacés vers un autre commutateur virtuel sans mettre au préalable l'hôte en mode maintenance.

Solution

Corrigez le problème de mise en réseau qui empêche les hôtes de communiquer par le biais des réseaux de
gestion.

L'agent vSphere HA est à l'état Réseau isolé

L'agent vSphere HA se trouvant sur un hôte est à l'état Réseau isolé. Une intervention utilisateur est requise
afin de résoudre cette situation.

Problème

Quand un hôte est à l'état Réseau isolé, vSphere HA applique la réponse d'isolation de l'hôte par l'arrêt ou la
mise hors tension des machines virtuelles s'exécutant sur l'hôte. vSphere HA continue de surveiller les
machines virtuelles qui sont laissées sous tension. Tandis qu'un hôte est dans cet état, la capacité de vSphere
HA à redémarrer les machines virtuelles après une défaillance est affectée. vSphere HA met hors tension ou
arrête uniquement une machine virtuelle si l'agent se trouvant sur l'hôte détermine qu'un hôte principal est
responsable de la machine virtuelle.

20 VMware, Inc.

Cause

Un hôte est réseau isolé si les deux conditions suivantes se rencontrent :

Des adresses d'isolation ont été configurées et l'hôte est dans l'impossibilité de leur envoyer un ping.

n

L'agent vSphere HA se trouvant sur l'hôte est dans l'impossibIlité d'accéder à l'un des agents

n

s'exécutant sur les autres hôtes du cluster.

REMARQUE Si Virtual SAN est activé sur votre cluster vSphere HA, un hôte est isolé s'il ne peut pas
communiquer avec les autres agents vSphere HA dans le cluster et ne peut pas atteindre les adresses
d'isolation configurées. Bien que les agents vSphere HA utilisent Virtual SAN pour la communication entre
les agents, l'adresse d'isolation par défaut est toujours la passerelle de l'hôte. Ainsi, dans la configuration par
défaut, les deux réseaux doivent échouer pour qu'un hôte soit déclaré isolé.

Solution

Corrigez le problème de réseau qui empêche l'hôte d'envoyer un ping à ses adresses d'isolation et de
communiquer avec d'autres hôtes.

Dépannage de la fonction Auto Deploy

Les rubriques de dépannage de la fonction Auto Deploy proposent des solutions à des situations dans
lesquelles le provisionnement des hôtes avec la fonction Auto Deploy ne fonctionne pas comme prévu.

Chapitre 2 Dépannage des hôtes

Erreur de dépassement du délai d'attente TFTP de la fonction Auto Deploy lors du démarrage

Un message d'erreur de dépassement du délai d'attente TFTP s'affiche lors du démarrage d'un hôte
provisionné par la fonction Auto Deploy. Le texte du message dépend du BIOS.

Problème

Un message d'erreur de dépassement du délai d'attente TFTP s'affiche lors du démarrage d'un hôte
provisionné par la fonction Auto Deploy. Le texte du message dépend du BIOS.

Cause

Le serveur TFTP est arrêté ou inaccessible.

Solution

Vérifiez si votre service TFTP fonctionne et est accessible par l'hôte que vous essayez de démarrer.

u

L'hôte disposant de la fonction Auto Deploy démarre avec la mauvaise configuration

Un hôte démarre avec une image ESXi différente, un profil d'hôte ou un emplacement de dossier différent
de ceux définis dans les règles.

Problème

Un hôte démarre avec un profil d'image ou une configuration ESXi différents de ceux que spécifient les
règles. Par exemple, vous modifiez les règles afin d'affecter un profil d'image différent, mais l'hôte continue
à utiliser l'ancien profil d'image.

Cause

Une fois que l'hôte a été ajouté au système vCenter Server, la configuration de démarrage est définie par le
système vCenter Server. Le système vCenter Server associe un profil d'image, un profil d'hôte ou un
emplacement de dossier à l'hôte.

VMware, Inc. 21

Dépannage vSphere

Solution

Utilisez les applets de commande PowerCLI Test-DeployRuleSetCompliance et Repair-

u

DeployRuleSetCompliance pour réévaluer les règles et associer le bon profil d'image, profil d'hôte ou

emplacement de dossier à l'hôte.

L'hôte n'est pas redirigé vers le serveur disposant de la fonction Auto Deploy

Pendant le démarrage, un hôte que vous souhaitez provisionner avec la fonction Auto Deploy charge iPXE.
L'hôte n'est pas redirigé vers le serveur disposant de la fonction Auto Deploy.

Problème

Pendant le démarrage, un hôte que vous souhaitez provisionner avec la fonction Auto Deploy charge iPXE.
L'hôte n'est pas redirigé vers le serveur disposant de la fonction Auto Deploy.

Cause

Le fichier tramp qui est inclus dans le fichier TFTP ZIP a la mauvaise adresse IP du serveur disposant de la
fonction Auto Deploy.

Solution

Corrigez l'adresse IP du serveur disposant de la fonction Auto Deploy au niveau du fichier tramp, tel

u

que cela est décrit dans la documentation Installation et configuration de vSphere.

Message d'avertissement du package lors de l'affectation d'un profil d'image à un hôte disposant de la fonction Auto Deploy

Lorsque vous exécutez l'applet de commande PowerCLI servant à affecter un profil d'image dont la fonction
Auto Deploy n'est pas prête, un message d'avertissement s'affiche.

Problème

Lorsque vous écrivez ou modifiez les règles pour attribuer un profil d'image à un ou plusieurs hôtes, cela
génère l'erreur suivante :

Avertissement : Image Profile <name-here> contains one or more software packages that are not
stateless-ready. You may experience problems when using this profile with Auto Deploy.

Cause

Chaque VIB se trouvant dans un profil d'image dispose d'une option sans état-prêt qui indique si le VIB
peut être utilisé avec la fonction Auto Deploy. Vous obtiendrez cette erreur si vous essayez d'écrire une
règle Auto Deploy utilisant un profil d'image dans lequel un ou plusieurs VIB ont cette option réglée sur
FALSE.

REMARQUE Vous pouvez utiliser les hôtes provisionnés avec Deploy Auto qui incluent les VIB qui ne sont
pas en mode sans état sans problèmes. Toutefois, le démarrage avec un profil d'image qui comprend des
VIB qui ne sont pas en mode sans état est traité comme une nouvelle installation. Chaque fois que vous
démarrez l'hôte, vous perdez toutes les données de configuration qui seraient autrement disponibles après
un redémarrage pour les hôtes provisionnés avec Deploy Auto.

Solution

1 Utilisez l'applet de commande PowerCLI Image Builder pour voir les VIB au niveau du profil d'image.

2 Supprimez tous les VIB qui ne sont pas dans le mode sans état-prêt.

3 Relancez l'applet de commande PowerCLI Auto Deploy.

22 VMware, Inc.

Chapitre 2 Dépannage des hôtes

L'hôte disposant de la fonction Auto Deploy et d'une clé USB intégrée n'envoie pas de vidage de mémoire au disque local

Si l'hôte disposant de la fonction Auto Deploy est doté d'une clé USB intégrée, et qu'une erreur se produit
dans un vidage de mémoire, le vidage de mémoire est perdu. Configurez votre système afin d'utiliser ESXi
Dump Collector pour stocker des vidages de mémoire au niveau d'un hôte mis en réseau.

Problème

Si votre hôte disposant de la fonction Auto Deploy est doté d'une clé USB intégrée, et s'il rencontre une
erreur qui provoque un vidage de mémoire, ce dernier n'est pas envoyé au disque local.

Solution

1 Installez ESXi Dump collector sur le système de votre choix.

ESXi Dump Collector est inclus avec le programme d'installation de vCenter Server.

2 Utilisez ESXCLI pour configurer l'hôte afin d'utiliser ESXi Dump Collector.

esxcli conn_options system coredump network set IP-addr,port
esxcli system coredump network set -e true

3 Utilisez ESXCLI pour désactiver des partitions de vidage de mémoire locales.

esxcli conn_options system coredump partition set -e false

L'hôte disposant de la fonction Auto Deploy redémarre au bout de cinq minutes

Un hôte disposant de la fonction Auto Deploy démarre et affiche l'information iPXE, mais redémarre au
bout de cinq minutes.

Problème

Un hôte à provisionner avec la fonction Auto Deploy démarre à partir de iPXE et affiche les informations
iPXE sur la console. Toutefois, au bout de cinq minutes, l'hôte affiche le message suivant sur la console et
redémarre.

Cet hôte essaye d'effectuer un démarrage-réseau à l'aide de VMware
AutoDeploy. Toutefois, il n'existe aucune image ESXi associée à cet hôte.
Détails : Aucune règle contenant un profil d'image ne correspond à cet
hôte. Vous pouvez créer une règle avec l'applet de commande PowerCLI New-DeployRule
et l'ajouter à la règle définie avec Add-DeployRule ou Set-DeployRuleSet.
La règle doit avoir un modèle qui correspond à un ou plusieurs des attributs
listés ci-après.

L'hôte peut également afficher les détails suivants :

Détails : Cet hôte a été ajouté à VC, mais aucun profil d'image
ne lui est associé. Vous pouvez utiliser Apply-ESXImageProfile dans le
PowerCLI pour associer un profil d'image à cet hôte.
Vous pouvez également réévaluer les règles de cet hôte avec les
applets de commande Test-DeployRuleSetCompliance et Repair-DeployRuleSetCompliance.

La console affiche ensuite les attributs machine de l'hôte, tels que le fournisseur, le numéro de série,
l'adresse IP, etc..

Cause

Aucun profil d'image n'est actuellement associé à cet hôte.

VMware, Inc. 23

Dépannage vSphere

Solution

Vous pouvez temporairement associer un profil d'image à l'hôte en lançant l'applet de commande Apply-

EsxImageProfile.

Vous pouvez affecter d'une manière permanente un profil d'image à l'hôte comme suit.

1 Exécutez l'applet de commande New-DeployRule pour créer une règle qui contienne un modèle

correspondant à l'hôte avec un profil d'image.

2 Exécutez l'applet de commande Add-DeployRule pour ajouter la règle à un ensemble de règles.

3 Exécutez l'applet de commande Test-DeployRuleSetCompliance et utilisez la sortie de cet applet de

commande comme entrée vers l'applet de commande Repair-DeployRuleSetCompliance.

L'hôte disposant de la fonction Auto Deploy ne peut contacter le serveur TFTP

L'hôte disposant de la fonction Auto Deploy ne peut contacter le serveur TFTP.

Problème

Lorsque vous essayez de démarrer un hôte disposant de la fonction Auto Deploy, l'hôte procède à un
démarrage réseau et se voit attribuer une adresse DHCP par le serveur DHCP, mais l'hôte ne peut contacter
le serveur TFTP.

Cause

Il est possible que l'exécution du serveur TFTP se soit interrompue ou qu'un pare-feu bloque le port TFTP.

Solution

Si vous avez installé le serveur TFTP WinAgents, ouvrez la console de gestion du serveur TFTP

n

WinAgents et vérifiez que le service est en cours d'exécution. Si c'est le cas, vérifiez les règles d'entrée
du pare-feu Windows pour vous assurer que le port TFTP port n'est pas bloqué. Désactivez
temporairement le pare-feu pour voir s'il est à l'origine du problème.

Pour tous les autres serveurs TFTP, consultez la documentation appropriée pour connaître les

n

procédures de débogage.

L'hôte disposant de la fonction Auto Deploy ne peut récupérer l'image ESXi du serveur Auto Deploy

L'hôte disposant de la fonction Auto Deploy s'arrête au niveau de l'écran de démarrage iPXE.

Problème

Lorsque vous essayez de démarrer un hôte disposant de la fonction Auto Deploy, le processus de
démarrage s'interrompt au niveau de l'écran de démarrage iPXE et le message d'état indique que l'hôte tente
d'obtenir l'image ESXi depuis le serveur Auto Deploy.

Cause

Le service Auto Deploy pourrait être interrompu ou le serveur Auto Deploy pourrait être inaccessible.

Solution

1 Connectez-vous au système sur lequel vous avez installé le serveur Auto Deploy.

24 VMware, Inc.

Chapitre 2 Dépannage des hôtes

2 Vérifiez que le serveur Auto Deploy est en cours d'exécution.

a Cliquez sur Démarrer > Configuration > Panneau de configuration > Outils d'administration.

b Double-cliquez sur Services pour ouvrir le panneau de gestion des services.

c Dans le champ Services, recherchez le service VMware vSphere Auto Deploy Waiter et

redémarrez-le s'il n'est pas en cours d'exécution.

3 Ouvrez un navigateur Web et saisissez l'URL suivante, puis vérifiez si le serveur Auto Deploy est

accessible.

https://Auto_Deploy_Server_IP_Address:Auto_Deploy_Server_Port/vmw/rdb

REMARQUE Utilisez cette adresse uniquement pour vérifier si le serveur est accessible.

4 Si le serveur n'est pas accessible, il est possible que le pare-feu pose problème.

a Essayez de définir des règles d'entrée TCP permissives pour le port du serveur Auto Deploy.

Le port est 6501 à moins que vous n'ayez précisé un port différent lors de l'installation.

b En dernier recours, désactivez temporairement le pare-feu puis réactivez-le après avoir vérifié s'il

bloque le trafic. Ne désactivez pas le pare-feu dans des environnements de production.

Pour désactiver le pare-feu, tapez la commande netsh firewall set opmode disable. Pour activer
le pare-feu, tapez la commande netsh firewall set opmode enable.

L'hôte disposant de la fonction Auto Deploy n'a pas reçu d'adresse DHCP

L'hôte disposant de la fonction Auto Deploy n'a pas pu obtenir d'adresse DHCP.

Problème

Lorsque vous essayez de démarrer un hôte disposant de la fonction Auto Deploy, l'hôte procède à un
démarrage réseau mais ne reçoit pas d'adresse DHCP. Le serveur Auto Deploy ne peut provisionner l'hôte
avec le profil d'image.

Cause

Il est possible que le service DHCP ou la configuration du pare-feu pose problème.

Solution

1 Vérifiez que le service du serveur DHCP est en cours d'exécution sur le système Windows sur lequel le

serveur DHCP est configuré pour provisionner les hôtes.

a Cliquez sur Démarrer > Configuration > Panneau de configuration > Outils d'administration.

b Double-cliquez sur Services pour ouvrir le panneau de gestion des services.

c Dans le champ Services, recherchez le service du serveur DHCP et redémarrez le service s'il n'est

pas en cours d'exécution.

2 Si le serveur DHCP est en cours d'exécution, revérifiez la portée et les réservations DHCP que vous

avez configurées pour vos hôtes cibles.

Si la portée et les réservations DHCP sont correctement configurées, il est possible que le problème
vienne du pare-feu.

VMware, Inc. 25

Dépannage vSphere

3 Désactivez temporairement le pare-feu pour voir si cela règle le problème.

a Ouvrez l'invite de commande en cliquant sur Démarrer > Programme > Accessoires > Invite de

commande.

b Tapez la commande suivante pour désactiver temporairement le pare-feu. Ne désactivez pas le

pare-feu dans un environnement de production.

netsh firewall set opmode disable

c Essayez de provisionner l'hôte avec Auto Deploy.

d Tapez la commande suivante pour réactiver le pare-feu.

netsh firewall set opmode enable

4 Configurez les règles pour autoriser le trafic réseau DHCP vers les hôtes cibles.

Pour plus d'informations, consultez la documentation relative au pare-feu pour le DHCP et le système
Windows sur lequel le serveur DHCP est exécuté.

L'hôte disposant de la fonction Auto Deploy ne procède pas au démarrage réseau

L'hôte disposant de la fonction Auto Deploy apparaît mais ne procède pas au démarrage réseau.

Problème

Lorsque vous essayez de démarrer un hôte disposant de la fonction Auto Deploy, l'hôte ne procède pas au
processus de démarrage réseau.

Cause

Vous n'avez pas activé votre hôte pour le démarrage réseau.

Solution

1 Redémarrez l'hôte et suivez les instructions qui s'affichent pour accéder à la configuration du BIOS.

Si vous disposez d'un hôte EFI, vous devez faire passer le système EFI en mode de compatibilité du
BIOS.

2 Dans la configuration du BIOS, activez le démarrage réseau dans la configuration du périphérique de

démarrage.

Problèmes pouvant survenir si vous mettez à niveau vCenter Server sans mettre à niveau le serveur Auto Deploy

Lorsque vous procédez à la mise à niveau de vCenter Server, vous pouvez mettre à niveau le serveur Auto
Deploy en même temps. Si vous retardez la mise à jour, cela risque d'entraîner des problèmes avec l'agent
vSphere HA

Problème

Lorsque vous mettez à niveau vCenter Server, vCenter Server remplace l'agent vSphere HA (vmware-fdm)
version 5.0 par l'agent vSphere HA version 5.1 sur chaque hôte ESXi. Sur les hôtes provisionnés avec Auto
Deploy, le remplacement n'est pas permanent, car aucun état ne s'applique sur l'hôte. Si vCenter Server n'est
pas disponible, les hôtes ESXi ne disposent pas de l'agent vSphere HA correct et ne peuvent pas rejoindre le
cluster.

26 VMware, Inc.

Chapitre 2 Dépannage des hôtes

Cause

Le serveur Auto Deploy 5.0 n'effectue pas automatiquement la mise à niveau de FDM VIB vers la version 5.1
ou ultérieure. À moins que vous n'ayez créé une nouvelle image qui intègre VIB, Auto Deploy revient à la
FDM VIB version 5.0 après le redémarrage.

Solution

Mise à niveau du serveur Auto Deploy.

Si vous ne pouvez pas mettre à niveau le serveur Auto Deploy, vous pouvez utiliser cmdlets Image Builder
PowerCLI, incluses dans vSphere PowerCLI pour créer un profil d'image ESXi 5.0 qui inclut le nouveau
vmware-fdm VIB. Vous pouvez provisionner vos hôtes avec ce profil d'image.

1 À l'invite de PowerCLI, ajouter le dépôt de logiciels ESXi 5.0 et ajouter le dépôt de logiciels qui contient

le nouveau VIB vmware-fdm.

Add-EsxSoftwareDepot
C:\Path\VMware-Esxi-5.0.0-buildnumber-depot.zip

Add-EsxSoftwareDepot http://vcenter_server/vSphere-HA-depot

2 Créer une règle qui attribue le nouveau profil d'image à vos hôtes, et ajouter la règle à la base de règles.

New-DeployRule -Name "Rule Name"

-Item "ImageName"

-Pattern "my host pattern"
Add-DeployRule -DeployRule "Rule Name"

3 Effectuer une opération de test et de réparation de conformité pour les hôtes afin d'inclure de manière

permanente l'agent vSphere HA sur les hôtes.

$result = Test-DeployRuleSetCompliance Host_list
Repair-DeployRuleSetCompliance -TestResult $result

Erreur de manipulation du jeton d'authentification

La création d'un mot de passe ne satisfaisant pas les exigences d'authentification de l'hôte provoque une
erreur.

Problème

Lorsque vous créez un mot de passe sur l'hôte, le message d'erreur suivant s'affiche : A general system

error occurred: mot de passe : Erreur de manipulation de jeton d'authentification.

Le message suivant est inclus : Impossible de définir le mot de passe. Il est possible que votre mot

de passe ne réponde pas aux critères de complexité définis par le système.

Cause

L'hôte contrôle la conformité du mot de passe à l'aide du plug-in d'authentification par défaut,

pam_passwdqc.so. Si le mot de passe n'est pas conforme, l'erreur s'affiche.

Solution

Lorsque vous créez un mot de passe, composez-le d'un mélange de caractères de quatre classes différentes :
des lettres minuscules, des lettres majuscules, des chiffres et des caractères spéciaux tels qu'un caractère de
soulignement ou un tiret.

Votre mot de passe doit être conforme aux conditions de longueur suivantes.

Le mot de passe comportant des caractères d'une ou deux classes doit contenir au moins huit caractères.

n

Le mot de passe comportant des caractères de trois classes doit contenir au moins sept caractères.

n

VMware, Inc. 27

Dépannage vSphere

Le mot de passe comportant des caractères des quatre classes doit contenir au moins six caractères.

n

REMARQUE Un caractère en majuscule au début d'un mot de passe ne compte pas dans le nombre de classes
de caractères utilisées. Un chiffre à la fin d'un mot de passe ne compte pas dans le nombre de classes de
caractères utilisées.

Vous pouvez aussi vous servir d'une phrase de passe, qui est une phrase composée d'au moins trois mots,
ayant une longueur de 8 à 40 caractères chacun.

Pour plus d'informations, voir la documentation Sécurité vSphere.

Une erreur de l'ensemble de règles Active Directory provoque une défaillance de conformité du profil d'hôte dans Client Web vSphere

L'application d'un profil d'hôte qui spécifie un domaine Active Directory à associer provoque une
défaillance de conformité.

Problème

Lorsque vous appliquez un profil d'hôte qui spécifie un domaine Active Directory à associer, mais que vous
n'activez pas l'ensemble de règles activeDirectoryAll au niveau de la configuration du pare-feu, une
défaillance de conformité se produit. Client Web vSphere affiche le message d'erreur Échecs par rapport au

profil d'hôte : L'ensemble de règles activedirectoryAll ne correspond pas à la spécification. La

défaillance de conformité se produit également lorsque vous appliquez un profil d'hôte pour laisser un
domaine Active Directory, mais que vous ne désactivez pas l'ensemble de règles activeDirectoryAll au
niveau du profil d'hôte.

Cause

Active Directory requiert l'ensemble de règles de pare-feu intitulé activeDirectoryAll. Vous devez activer
l'ensemble de règles au niveau de la configuration du pare-feu. Si vous omettez ce paramètre, le système
ajoute les règles de pare-feu nécessaires lors de l'association de l'hôte au domaine, mais l'hôte ne sera pas
conforme en raison d'une discordance des règles de pare-feu. De même, l'hôte ne sera pas conforme si vous
le supprimez du domaine sans avoir désactivé l'ensemble de règles Active Directory.

Solution

1 Accédez au profil de l'hôte dans Client Web vSphere.

Pour trouver un profil d'hôte, cliquez sur Règles et profils > Profils d'hôte sur la page d'accueil de
Client Web vSphere.

2 Cliquez-droit sur le profil d'hôte et sélectionnez Modifier le profil d'hôte.

3 Cliquez sur Suivant.

4 Sélectionnez Sécurité et services > Configuration du pare-feu > Configuration du pare-feu >

Configuration des ensembles de règles > activeDirectoryAll.

5 Dans le panneau droit, sélectionnez la case à cocher Indicateur qui signale si l'ensemble de règles doit

être activé.

Décochez la case si l'hôte quitte le domaine.

6 Cliquez sur Terminer .

28 VMware, Inc.

Chapitre 2 Dépannage des hôtes

Impossible d'accéder au domaine lorsque les ressources Likewise sont faibles

Vous êtes dans l'impossibilité d'ajouter un hôte à un domaine Active Directory ou de répertorier les
utilisateurs du domaine lorsque vous ajoutez des autorisations utilisateur si le pic de réservation de
mémoire pour les démons Likewise est dépassée.

Problème

Lorsque vous tentez d'ajouter un hôte à un domaine Active Directory, l'opération échoue. Similairement,
l'opération réussit, mais vous ne pouvez pas répertorier les utilisateurs du domaine lorsque vous ajoutez des
autorisations d'utilisateurs.

Cause

Lorsqu'il existe plus de trois domaines Active Directory approuvés, le pic de réservation de mémoire du
plug-in Likewise dépasse la limite par défaut spécifiée dans Client Web vSphere. Il se peut que vous soyez
dans l'impossibilité d'ajouter un hôte à un domaine Active Directory ou de répertorier les utilisateurs du
domaine lorsque vous ajoutez des autorisations d'utilisateurs et ce, jusqu'à ce que vous augmentiez la limite
de mémoire pour le plug-in Likewise dans le pool de ressources système.

Solution

1 Accédez à l'hôte dans le navigateur d'objets de Client Web vSphere.

2 Sélectionnez Gérer > Paramètres > Allocation de ressource système.

3 Cliquez sur Avancé pour ouvrir la liste des pools de ressource système.

4 Sélectionnez host > vim > vmvisor > plugins > likewise.

5 Cliquez sur likewise, puis cliquez sur Modifier.

6 Sélectionnez Ressources mémoire > Limite et augmentez la limite.

7 Cliquez sur OK.

VMware, Inc. 29

Dépannage vSphere

30 VMware, Inc.

Dépannage de vCenter Server et

Client Web vSphere 3

Les rubriques de dépannage de vCenter Server et Client Web vSphere fournissent des solutions aux
problèmes pouvant éventuellement survenir lors de l'installation et de la configuration de vCenter Server et
Client Web vSphere, y compris vCenter Single Sign-On.

Ce chapitre aborde les rubriques suivantes :

« Dépannage de vCenter Server », page 31

n

« Dépannage de Client Web vSphere », page 34

n

« Dépannage de Linked Mode », page 36

n

« Dépannage des certificats d'hôte ESXi et vCenter Server », page 39

n

« Dépannage des plug-ins vCenter Server », page 40

n

Dépannage de vCenter Server

Ces rubriques de dépannage fournissent des solutions aux problèmes pouvant éventuellement survenir
lorsque vous installez et utilisez vCenter Server sur le système d'exploitation Windows ou que vous
déployez vCenter Server Appliance sur un système Linux.

Configuration de la journalisation de VMware Inventory Service

Avant de générer une requête de bundle de support, servant à faciliter un meilleur dépannage, vous devez
reconfigurer le niveau de journalisation de VMware Inventory Service à TRACE.

Problème

Vous devrez éventuellement changer la configuration de la journalisation de vCenter Server si l'un des
problèmes répertoriés se produit lors de l'utilisation de Client Web vSphere. Voici plusieurs problèmes
possibles :

Le chargement de l'arborescence d'inventaire ne fonctionne pas.

n

Le client est incapable de se connecter à vCenter Server.

n

Des propriétés ou des objets du client apparaissent périmés ou manquants.

n

Solution

1 Ouvrez <Inventory Service install location>\lib\server\config\log4j.properties.

VMware, Inc.

31

Dépannage vSphere

2 Changez les clés log4j.logger.com.vmware.vim et log4j.appender.LOGFILE.Threshold du nouveau

niveau de journalisation.

Par exemple, log4j.logger.com.vmware.vim = TRACE (or log4j.appender.LOGFILE.Threshold = TRACE)
définit la journalisation de l'Inventory Service à trace.

Les niveaux de journalisation valides sont TRACE, DEBUG, INFO, WARN, ERROR, dans l'ordre
croissant de verbosité.

3 Redémarrez le VMware Inventory Service afin de relever le nouveau niveau de journalisation.

La mise à niveau de vCenter Server échoue lorsqu'il est impossible d'arrêter le service Tomcat

Une mise à niveau de vCenter Server peut échouer lorsque le programme d'installation est incapable
d'arrêter le service Tomcat.

Problème

Si le programme d'installation de vCenter Server ne peut pas arrêter le service Tomcat pendant une mise à
niveau, la mise à niveau échoue et affiche un message d'erreur similaire à Impossible de supprimer le

service Tomcat VC. Ce problème est susceptible de se produire même si vous arrêtez le service Tomcat

manuellement avant la mise à niveau, si certains fichiers utilisés par le processus Tomcat sont verrouillés.

Solution

1 À partir du menu Windows Démarrer, sélectionnez Paramètres > Panneau de configuration > Outils

d'administration > Services.

2 Cliquez avec le bouton droit sur VMware VirtualCenter Server et sélectionnez Manuel.

3 Cliquez avec le bouton droit sur VMware vCenter Management Webservices et sélectionnez Manuel.

4 Redémarrez la machine de vCenter Server avant de procéder à la mise à niveau.

Cela permettra de déverrouiller tous les éventuels fichiers verrouillés par le processus Tomcat, et
permettra au programme d'installation de vCenter Server d'arrêter le service Tomcat en vue de la mise
à niveau.

Vous pouvez également redémarrer la machine de vCenter Server et relancer le processus de mise à niveau.
Vous devrez alors sélectionner l'option garantissant que les données de vCenter Server ne seront pas
écrasées.

Microsoft SQL Database configuré dans un mode de compatibilité non pris en charge provoque l'échec de l'installation et de la mise à niveau de vCenter Server

L'installation de vCenter Server avec une base de données SQL Microsoft échoue lorsque la base de données
est définie sur le mode de compatibilité avec une version non prise en charge.

Problème

Le message d'erreur suivant apparaît : L'utilisateur de base de données saisi ne dispose pas des

autorisations nécessaires à l'installation et à la configuration de vCenter Server avec la base
de données sélectionnée. Veuillez corriger la ou les erreur(s) suivante(s) : %s

Cause

La version de la base de données doit être prise en charge pour vCenter Server. Pour SQL, même si la base
de données est une version prise en charge, si elle est définie pour être exécutée en mode compatibilité avec
une version non prise en charge, cette erreur se produit. Par exemple, si SQL 2008 est défini pour être
exécuté en mode compatibilité SQL 2000, cette erreur se produit.

32 VMware, Inc.

Chapitre 3 Dépannage de vCenter Server et Client Web vSphere

Solution

Assurez-vous que la base de données vCenter Server est une version prise en charge et qu'elle n'est pas

u

définie sur le mode compatibilité avec une version non prise en charge. Reportez-vous au document
Matrices d’interopérabilité des produits VMware à l'adresse suivante :

http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php?.

Erreur lors de la modification du nom d'hôte de vCenter Server Appliance

Lorsque vous modifiez le nom d'hôte de vCenter Server Appliance, une erreur Lookup Service apparaît
lorsque vous redémarrez le dispositif.

Problème

Après la modification du nom d'hôte de vCenter Server Appliance, l'erreur suivante apparaît lorsque vous
redémarrez le dispositif : Failed to connect to VMware Lookup Service. SSL certificate verification

failed.

Cause

Vous devez mettre le certificat vCenter Server à jour avec le nouveau nom d'hôte.

Solution

1 Ouvrez une session sur l'interface Web de vCenter Server Appliance.

2 Cliquez sur l'onglet Réseau, puis cliquez sur Adresse.

3 Modifiez le nom d'hôte, puis cliquez sur Enregistrer les paramètres.

Vous ne pouvez pas modifier le nom d'hôte si le dispositif utilise DHCP pour obtenir une adresse.

4 Cliquez sur l’onglet Admin, puis cliquez sur Basculer le paramétrage de certificat.

vCenter Server génère de nouveaux certificats pour les systèmes utilisant des certificats par défaut.
Pour les systèmes utilisant des certificats personnalisés, vous devez régénérer les certificats
manuellement.

5 Cliquez sur l'onglet Système, puis cliquez sur Redémarrer pour redémarrer vCenter Server Appliance.

Vous devez redémarrer le dispositif, pas uniquement les services s'exécutant sur lui.

Suivant

Si vous utilisez des certificats personnalisés, générez manuellement les certificats tel que décrit dans la
documentationSécurité vSphere .

Échec du démarrage de VMware vCenter Management Webservices Service

Lorsque vous redémarrez la machine vCenter Server après avoir installé vCenter Server, le service VMware
VirtualCenter Management Webservices ne démarre pas.

Problème

Le service VMware VirtualCenter Management Webservices ne démarre pas automatiquement.

Cause

Ce problème apparaît lorsque vCenter Server et la base de données sont installés sur la même machine.

VMware, Inc. 33

Dépannage vSphere

Solution

Démarrez le service manuellement.

u

Sélectionnez Paramètres > Panneau de configuration > Outils d'administration > Services > VMware
VirtualCenter Management Webservices et démarrez le service. La machine peut mettre plusieurs

minutes à démarrer le service.

Dépannage de Client Web vSphere

Les rubriques Client Web vSphere fournissent des solutions aux problèmes pouvant éventuellement
survenir lors de l'utilisation de Client Web vSphere dans le cadre de la gestion des composants vSphere, y
compris vCenter Single Sign-On et vCenter Server.

Le système vCenter Server ne s'affiche pas dans l'inventaire Client Web vSphere

Client Web vSphere n'affiche pas les systèmes vCenter Server que vous vous attendiez à voir dans
l'inventaire.

Problème

Lorsque vous vous connectez à Client Web vSphere, l'inventaire apparaît vide ou le système vCenter Server
que vous vous attendiez à voir ne s'affiche pas.

Cause

Dans les éditions de vSphere antérieures à vSphere 5.1, vous vous connectiez aux systèmes vCenter Server à
l'aide de vSphere Client. À moins que vous ne travailliez en Linked Mode, seule une instance de vCenter
Server s'affiche dans l'inventaire.

Dans vSphere 5.1 et 5.5, vous vous connectez à Client Web vSphere pour afficher et gérer plusieurs instances
de vCenter Server. Chaque système vCenter Server sur lequel vous possédez une autorisation s'affiche, si le
serveur est enregistré avec le même service de recherche que Client Web vSphere.

Solution

Connectez-vous à Client Web vSphere en tant qu'utilisateur possédant des autorisations sur le système

n

vCenter Server.

Le système vCenter Server n'apparaîtra pas dans l'inventaire si vous n'avez pas d'autorisations sur lui.
Par exemple, si vous ouvrez une session en tant qu'utilisateur administrateur sur vCenter Single Sign
On, il se peut que vous n'ayez pas d'autorisations sur quelque système vCenter Server que ce soit.

Vérifiez que le système vCenter Server est enregistré avec le même service de recherche que

n

Client Web vSphere.

Client Web vSphere ne détecte que les systèmes vCenter Server enregistrés avec le même service de
recherche.

34 VMware, Inc.

Chapitre 3 Dépannage de vCenter Server et Client Web vSphere

Impossible de démarrer la console de machine virtuelle dans Client Web vSphere

Lorsque vous tentez d'ouvrir la console de machine virtuelle dans Client Web vSphere, celle-ci ne s'ouvre
pas.

Problème

Lorsque vous tentez d'ouvrir la console de machine virtuelle dans Client Web vSphere, celle-ci ne s'ouvre
pas. Le message d'erreur suivant s'affiche :

ERREUR HTTP 404
Problème d'accès /. Raison :
Non trouvé

Des erreurs semblables à celles indiquées ci-dessous s'affichent dans le fichier virgo-server.log :

[2012-10-03 18:34:19.170] [ERROR] Thread-40
System.err
2012-10-03
18:34:19.167:WARN:oejuc.AbstractLifeCycle:FAILED org.eclipse.jetty.server.Server@315b0333:
java.net.BindException: Adresse déjà utilisée
[2012-10-03 18:34:19.170] [ERROR] Thread-40 System.err java.net.BindException: Adresse déjà
utilisée

Cause

Un autre programme ou un autre processus utilise le port 7331, qui est le port utilisé par défaut par la
console de machine virtuelle HTML5.

Solution

Ajoutez la ligne html.console.port=port au fichier webclient.properties, où port désigne le nouveau

u

numéro de port.

Le fichier webclient.properties se trouve à l'un des emplacements suivants, suivant le système
d'exploitation exécuté par la machine sur laquelle Client Web vSphere est installé :

Windows 2008

vCenter Server Appliance

C:\ProgramData\VMware\vSphere Web Client\

/var/lib/vmware/vsphere-client/

Impossible d'afficher l'onglet Définitions des alarmes d'un centre de données

Il peut arriver que les définitions des alarmes d'un centre de données ne soient pas accessibles dans
Client Web vSphere.

Problème

Lorsque vous cliquez sur l'onglet Définitions des alarmes d'un centre de données, l'onglet est recouvert
d'une couche sombre translucide et aucun message d'erreur ne s'affiche.

Cause

L'impossibilité d'afficher les définitions des alarmes peut être liée à une insuffisance de mémoire. Les
problèmes survenant du côté vCenter Server génèrent en principe un message d'erreur. En revanche,
l'insuffisance de mémoire disponible pour Adobe Flash Player sur la machine cliente empêche l'affichage de
la boîte de dialogue de notification de l'erreur.

VMware, Inc. 35

Dépannage vSphere

Solution

Vérifiez que vos instances de vCenter Server et de Client Web vSphere s'exécutent sur un système

u

possédant suffisamment de ressources.

Pour plus d'informations sur la configuration matérielle requise, consultez Installation et configuration de
vSphere.

La connexion à Client Web vSphere a échoué en raison d'une erreur de session dupliquée

Lorsque vous essayez de vous connecter à vCenter Server à l'aide de Client Web vSphere, la connexion
échoue en raison d'une erreur de session dupliquée.

Problème

Lorsque vous tentez de vous connecter à l'aide de Client Web vSphere, un message d'erreur semblable au
suivant s'affiche :

4/19/2012 15:48:45.416 [ERROR] ErrorNotificationManager:
faultCode:Server.Processing.DuplicateSessionDetected faultString:'Detected duplicate HTTP-based
FlexSessions, generally due to the remote host disabling session cookies. Session cookies must
be enabled to manage the client connection correctly.' faultDetail:'null'

Cause

Cette erreur se produit si le service Client Web vSphere est redémarré ou mis à niveau lorsque l'interface
utilisateur de Client Web vSphere est ouverte dans un navigateur Web.

Solution

1 Fermez complètement le navigateur Web.

2 Relancez le navigateur Web.

3 Accédez à l'URL de Client Web vSphere et connectez-vous.

Dépannage de Linked Mode

Si vous rencontrez des difficultés avec votre groupe Linked Mode, considérez les points suivants.

Lorsque vous avez plusieurs instances vCenter Server, chaque instance doit avoir une relation qui
fonctionne avec le contrôleur de domaine et aucun conflit avec une des autres machines de ce domaine. Des
conflits peuvent survenir, par exemple, lorsque vous clonez une instance de vCenter Server en cours
d'exécution dans une machine virtuelle, et que vous ne vous servez pas de sysprep ou d'un utilitaire
similaire pour garantir que l'instance vCenter Server clonée possède un identificateur globalement unique
(GUID).

Si le contrôleur de domaine est injoignable, vCenter Server peut être incapable de démarrer. Vous pouvez
vous retrouver dans l'impossibilité de modifier la configuration Linked Mode du système vCenter Server
affecté. Si cela se produit, résolvez le problème avec le contrôleur de domaine et redémarrez vCenter Server.
Si la résolution du problème est impossible avec le contrôleur de domaine, vous pouvez redémarrer vCenter
Server en retirant le système vCenter Server du domaine, et en isolant le système de son groupe Linked
Mode actuel.

36 VMware, Inc.

Chapitre 3 Dépannage de vCenter Server et Client Web vSphere

Le nom DNS de la machine doit correspondre au nom actuel de la machine. Les symptômes de noms de
machines ne correspondant pas au nom DNS se révèlent par des problèmes de réplication de données, des
erreurs de tickets en essayant de faire une recherche, et des résultats de recherche à partir d'instances
distantes manquants.

REMARQUE Assurez-vous que vos pare-feu Windows et ceux ceux ceux basés sur réseau sont configurés
pour autoriser Linked Mode.

Rejoindre un groupe Linked Mode

Il y a un ordre d'opérations précis pour rejoindre un groupe Linked Mode.

Procédure

1 Vérifiez si le nom du domaine vCenter Server correspond au nom de la machine. Si les noms ne

correspondent pas, modifiez l'un d'eux ou les deux pour qu'ils coïncident.

2 Mettez l'URL à niveau pour que ces noms soient compatibles avec le nouveau nom de domaine et le

nouveau nom de la machine.

Si vous ne mettez pas à niveau les URL, les instances distantes de vCenter Server ne peuvent pas
atteindre le système vCenter Server, car les entrées d'URL par défaut de vCenter Server ne sont plus
exactes.

3 Joignez le système vCenter Server à un groupe Linked Mode.

Si une instance de vCenter Server ne peut plus être joignable par les instances distantes de
vCenter Server, on peut constater les symptômes suivants :

Les clients se connectant aux autres systèmes vCenter Server du groupe ne peuvent afficher les

n

informations appartenant au système vCenter Server sur lequel vous avez modifié le nom de
domaine parce que les utilisateurs ne peuvent pas se connecter au système.

Tous les utilisateurs actuellement connectés au système vCenter Server risquent d'être déconnectés.

n

Les requêtes de recherche ne retournent aucun résultat du système vCenter Server.

n

Pour résoudre ces problèmes, assurez-vous que la clé Virtualcenter.VimApiUrl pointe vers
l'emplacement où les clients peuvent accéder au système vCenter Server, et que les clés de
Virtualcenter.VimWebServicesUrl pointent vers l'emplacement où les services Web vCenter Server sont
installés. Pour la clé Virtualcenter.Instancename, modifiez la valeur de sorte que le nom modifié
apparaisse dans la vue d'inventaire de vCenter Server.

Suivant

Si vous ne pouvez pas rejoindre une instance de vCenter Server, vous pouvez résoudre le problème avec les
actions suivantes :

Assurez-vous que la machine est groupée dans la bonne unité organisationnelle du contrôleur de

n

domaine correspondant.

Lorsque vous installez vCenter Server, assurez-vous que le compte utilisateur connecté possède les

n

privilèges d'administrateur sur la machine.

Pour résoudre les problèmes de confiance entre une machine et le contrôleur de domaine, retirez la

n

machine du domaine puis rajoutez-la à nouveau au domaine.

Assurez-vous que le cache de stratégues Windows est à jour, exécutez la commande gpupdate /force à

n

partir de la ligne de commande Windows. Cette commande effectue une mise à niveau des stratégies de
groupes.

Si l'hôte local ne peut pas atteindre l'hôte distant pendant l'opération pour le rejoindre, vérifiez ce qui suit :

L'adresse IP du système vCenter Server distant ou le nom de domaine complet est correct.

n

VMware, Inc. 37

Dépannage vSphere

Le port LDAP du système vCenter Server distant est correct.

n

Le service VMwareVCMSDS est en cours d'exécution.

n

Configurer un pare-feu Windows pour autoriser un accès programme spécifié

vCenter Server utilise Microsoft ADAM/AD LDS pour activer Linked Mode, qui se sert du mappeur de port
Windows RPC pour ouvrir les ports de réplication RPC. Lorsque vous installez vCenter Server en Linked
Mode, vous devez modifier la configuration du pare-feu sur la machine locale .

Une configuration incorrecte des pare-feu peut entraîner une incohérence des licences et des rôles entre les
instances.

Prérequis

La version de Windows doit être antérieure à Windows Server 2008. Pour Windows Server 2008,

n

Windows configure automatiquement le pare-feu pour permettre l'accès.

Aucun pare-feu basé sur réseau ne peut exister entre les instances Linked Mode de vCenter Server.

n

Pour les environnements avec des pare-feux basés sur réseau, voir « Configurer l'accès via pare-feu en

ouvrant les ports sélectionnés », page 38.

Procédure

1 Sélectionnez Démarrer > Exécuter.

2 Saisissez firewall.cpl et cliquez sur OK.

3 Assurez-vous que le pare-feu est paramétré pour autoriser les exceptions.

4 Cliquez sur l'onglet Exceptions.

5 Cliquez sur Ajouter un programme.

6 Ajoutez une exception pour C:\Windows\ADAM\dsamain.exe et cliquez sur OK.

7 Cliquez sur OK.

Configurer l'accès via pare-feu en ouvrant les ports sélectionnés

vCenter Server utilise Microsoft ADAM/AD LDS pour activer Linked Mode, qui se sert du mappeur de port
Windows RPC pour ouvrir les ports de réplication RPC. Lorsque vous installez vCenter Server en Linked
Mode, la configuration de tous les pare-feu basés sur réseau doit être modifiée.

Une configuration incorrecte des pare-feu peut entraîner une incohérence des licences et des rôles entre les
instances.

Procédure

Configurez les ports Windows RPC pour qu'ils autorisent génériquement les ports sélectifs pour les

u

communications RPC machine à machine.

Choisissez l'une des méthodes suivantes.

Modifiez les paramètres du registre. Reportez-vous à la section

n

http://support.microsoft.com/kb/154596/en-us.

Utilisez l'outil RPCCfg.exe de Microsoft. Reportez-vous à la section

n

http://support.microsoft.com/kb/908472/en-us.

38 VMware, Inc.

Chapitre 3 Dépannage de vCenter Server et Client Web vSphere

Dépannage des certificats d'hôte ESXi et vCenter Server

Des certificats sont automatiquement générés lorsque vous installez vCenter Server. Ces certificats définis
par défaut ne sont pas signés par une autorité de certification (CA) privée et peuvent ne pas offrir une
sécurité importante. Vous pouvez remplacer les certificats vCenter Server définis par défaut par des
certificats signés par une autorité de certification CA privée. Lorsque vous remplacez des certificats vCenter
Server et ESXi, des erreurs peuvent survenir.

vCenter Server ne peut pas se connecter à la base de données

Après avoir remplacé les certificats vCenter Server définis par défaut, vous pouvez être dans l'impossibilité
de vous connecter à la base de données vCenter Server.

Problème

vCenter Server ne peut pas se connecter à la base de données vCenter Server après le remplacement des
certificats vCenter Server par défaut et les services Web de gestion ne démarrent pas.

Cause

Le mot de passe de la base de données doit être mis à jour sous sa forme chiffrée.

Solution

Mettez à jour le mot de passe de la base de données en exécutant la commande suivante : vpxd -P pwd.

vCenter Server ne peut pas se connecter aux hôtes gérés

Après avoir remplacé les certificats vCenter Server définis par défaut et redémarré le système, vCenter
Server peut être dans l'impossibilité de se connecter aux hôtes gérés.

Problème

vCenter Server n'a pu se connecter aux hôtes gérés après le remplacement des certificats du serveur et le
redémarrage du système.

Solution

Connectez-vous à l'hôte en tant qu'utilisateur racine et reconnectez l'hôte à vCenter Server.

Aucun nouveau certificat vCenter Server n'apparaît pour être chargé

Après avoir remplacé les certificats vCenter Server définis par défaut, les nouveaux certificats sont dans
l'impossibilité d'apparaître pour être chargés.

Problème

Lorsque vous installez de nouveaux certificats vCenter Server, vous pouvez ne pas voir les nouveaux
certificats.

Cause

Les connexions ouvertes existantes à vCenter Server ne sont pas forcément fermées et peuvent encore
utiliser l'ancien certificat.

Solution

Pour forcer toutes les connexions à utiliser le nouveau certificat, utilisez l'une des méthodes suivantes :

Redémarrez la pile réseau ou les interfaces réseau sur le serveur.

n

Redémarrez le service vCenter Server.

n

VMware, Inc. 39

Dépannage vSphere

Impossible de configurer vSphere HA lors de l'utilisation des certificats SSL personnalisés

Après avoir installé les certificats SSL personnalisés, les tentatives d'activation de vSphere High Availability
(HA) échouent.

Problème

Lorsque vous tentez d'activer vSphere HA sur un hôte avec les certificats SSL personnalisés installés, le
message d'erreur suivant s'affiche : vSphere HA ne peut pas être configuré sur cet hôte, car son

empreinte SSL n'a pas été vérifiée.

Cause

Lorsque vous ajoutez un hôte à vCenter Server, et que vCenter Server approuve déjà le certificat SSL de
l'hôte, VPX_HOST.EXPECTED_SSL_THUMBPRINT n'est pas renseigné dans la base de données vCenter Server.
vSphere HA obtient l’empreinte SSL de l'hôte à partir de ce champ dans la base de données. Sans
l'empreinte, vous ne pouvez pas activer vSphere HA.

Solution

1 Dans Client Web vSphere, déconnectez l'hôte dont les certificats SSL personnalisés sont installés.

2 Reconnectez l'hôte à vCenter Server.

3 Acceptez le certificat SSL de l'hôte.

4 Activez vSphere HA sur l'hôte.

Dépannage des plug-ins vCenter Server

Dans le cas où les plug-ins vCenter Server ne fonctionnent pas, vous disposez de plusieurs options pour
corriger le problème.

Les plug-ins vCenter Server exécutés sur le serveur Tomcat comprennent des fichiers extension.xml, qui
contiennent l'URL permettant d'accéder à l'application Web correspondante. Ces fichiers sont situés dans

C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions. Les installateurs d'extension

remplissent ces fichiers XML à l'aide du nom DNS de l'ordinateur.

Exemple avec le fichier de statistiques extension.xml : <url>https://SPULOV-XP-VM12.vmware.com:

8443/statsreport/vicr.do</url>.

vCenter Server, les serveurs de plug-in et les clients qui les utilisent doivent se trouver sur des systèmes
sous le même domaine. S'ils ne le sont pas ou si le nom DNS du serveur de plug-ins est modifié, les clients
des plug-ins ne pourront pas accéder à l'URL et les plug-ins ne fonctionneront pas.

Vous pouvez modifier manuellement les fichiers de XML en remplaçant le nom DNS par une adresse IP.
Réenregistrez le plug-in après avoir édité son fichier extension.xml.

40 VMware, Inc.

Résolution des problèmes de

disponibilité 4

Les rubriques de résolution des problèmes de disponibilité proposent des solutions aux problèmes
potentiels qui peuvent apparaître lors de l'utilisation de vos hôtes et banques de données dans les clusters
vSphere HA.

Vous pouvez avoir un message d'erreur lorsque vous essayez d'utiliser vSphere HA ou vSphere FT. Pour
plus d'informations sur ces messages d'erreur, voir l'article dans la base de connaissances VMware
accessible à l'adresse http://kb.vmware.com/kb/1033634.

Ce chapitre aborde les rubriques suivantes :

« Dépannage du contrôle d'admission vSphere HA », page 41

n

« Dépannage des banques de données de signaux de pulsation », page 43

n

« Dépannage des problèmes de protection de basculement vSphere HA », page 45

n

« Dépannage de vSphere Fault Tolerance dans des partitions réseau », page 47

n

Dépannage du contrôle d'admission vSphere HA

vCenter Server utilise le contrôle d'admission pour garantir que suffisamment de ressources d'un cluster
vSphere HA sont réservées pour la récupération de la machine virtuelle dans le cas d'une défaillance d'hôte.
Si le contrôle d'admission vSphere HA ne fonctionne pas correctement, il n'existe aucune garantie pour que
toutes les machines virtuelles du cluster puissent être redémarrées après une défaillance d'hôte.

Cluster rouge dû à des ressources de basculement insuffisantes

Lorsque vous utilisez les règles de contrôle d'admission Défaillances d'hôte tolérées par le cluster, les
clusters vSphere HA peuvent devenir non valides (rouges) en raison de ressources de basculement
insuffisantes.

Problème

Si vous sélectionnez les règles de contrôle d'admission Défaillances d'hôte tolérées par le cluster et que
certains problèmes surgissent, le cluster devient rouge.

Cause

Ce problème peut survenir lorsque des hôtes du cluster sont déconnectés, en mode maintenance, ne
répondent pas ou ont une erreur vSphere HA. Les hôtes déconnectés et en mode maintenance sont en
général le résultat d'une action utilisateur. Les hôtes ne répondant pas ou ayant une erreur de possession
sont en général le résultat d'un problème plus grave, par exemple, des hôtes ou des agents ayant échoué ou
suite à l'existence d'un problème de mise en réseau.

VMware, Inc.

41

Dépannage vSphere

Ce problème peut également provenir d'une autre cause éventuelle si votre cluster contient une machine
virtuelle ayant beaucoup plus de de réservations de CPU ou de mémoire que les autres. Les règles de
contrôle d'admission Défaillances d'hôte tolérées par le cluster sont basées sur le calcul de la taille du slot à
partir de deux composants, les réservations de mémoire et de CPU d'une machine virtuelle. Si le calcul de
cette taille de slot est faussé par des machines virtuelles déviantes, les règles de contrôle d'admission
peuvent devenir trop restrictives et avoir comme résultat un cluster rouge.

Solution

Vérifiez que tous les hôtes du cluster sont sains, c'est à dire, connectés, pas en mode maintenance et libres
d'erreurs vSphere HA. Le contrôle d'admission vSphere HA prend en considération des ressources
uniquement à partir d'hôtes sains.

Mise sous tension impossible de la machine virtuelle due à des ressources de basculement insuffisantes

Vous pouvez avoir une panne de type ressources de basculement insuffisantes lors d'une tentative de
mise sous tension d'une machine virtuelle dans un cluster vSphere HA.

Problème

Si vous sélectionnez les Règles de contrôle d'admission Défaillances d'hôte tolérées par le cluster et que
certains problèmes apparaissent, vous pouvez être empêché de mettre sous tension une machine virtuelle en
raison de ressources insuffisantes.

Cause

Ce problème peut avoir plusieurs causes.

Des hôtes du cluster sont déconnectés, en mode maintenance, ne répondent pas ou ont une erreur

n

vSphere HA.

Les hôtes déconnectés et en mode maintenance sont en général le résultat d'une action utilisateur. Les
hôtes ne répondant pas ou ayant une erreur de possession sont en général le résultat d'un problème
plus grave, par exemple, des hôtes ou des agents qui ont échoué ou suite à l'existence d'un problème de
mise en réseau.

Le cluster contient des machines virtuelles qui ont beaucoup plus de réservations CPU ou de mémoire

n

que les autres.

Les règles de contrôle d'admission Défaillances d'hôte tolérées par le cluster sont basées sur le calcul de
la taille d'emplacement à partir de deux composants, les réservations de mémoire et de CPU d'une
machine virtuelle. Si le calcul de cette taille d'emplacement est faussé par des machines virtuelles
déviantes, les règles de contrôle d'admission peuvent devenir trop restrictives et avoir comme résultat
une incapacité à mettre sous tension des machines virtuelles.

aucun emplacementlibre dans le cluster.

n

Des problèmes se produisent s'il n'y a aucun emplacementde libre dans le cluster ou si la mise sous
tension d'une machine virtuelle provoque une augmentation de la taille d'emplacement en raison d'une
réservation plus importante que celle des machines virtuelles existantes. Dans les deux cas, vous devez
utiliser les fonctions avancées de vSphere HA pour réduire la taille d'emplacement, utiliser d'autres
règles de contrôle d'admission ou modifier les règles afin de tolérer des défaillances d'hôte moindres.

Solution

Affichez le volet Infos d'exécution avancées qui apparaît dans la section vSphere HA de l'onglet Surveiller
du cluster dans Client Web vSphere. Ce volet d'informations affiche la taille d'emplacement et le nombre
d'emplacements disponibles dans le cluster. Si la taille d'emplacement apparaît trop grande, cliquez sur
l'onglet Allocation des ressources du cluster et triez les machines virtuelles par réservation afin de
déterminer laquelle a le plus de réservations de mémoire et de CPU. S'il existe des machines virtuelles
déviantes ayant beaucoup plus de réservations que les autres, choisissez d'utiliser d'autres règles de contrôle

42 VMware, Inc.

Chapitre 4 Résolution des problèmes de disponibilité

d'admission vSphere HA (comme par exemple les règles de contrôle d'admission Pourcentage de ressources
de cluster réservées) ou utilisez les options avancées de vSphere HA pour définir une limite absolue au
niveau de la taille d'emplacement. Ces deux options, néanmoins, augmentent le risque de fragmentation des
ressources.

Moins d'emplacements disponibles affichés que prévus

La zone Informations d'exécution avancées peut afficher un nombre d'emplacements disponibles dans le
cluster plus petit que prévu.

Problème

Lorsque vous sélectionnez la règle de contrôle d'admission des pannes d'hôtes tolérées par le cluster,
consultez le volet Infos d’exécution avancées qui apparaît dans la section vSphere HA de l'onglet Surveiller
du cluster, dans Client Web vSphere. Ce volet affiche des informations sur le cluster, notamment le nombre
d'emplacements disponibles pour mettre d'autres machines virtuelles sous tension dans le cluster. Ce
nombre peut être plus petit que celui prévu sous certaines conditions.

Cause

La taille d'emplacement est calculée en utilisant les plus grosses réservations et le dépassement de mémoire
de n'importe quelle machine virtuelle mise sous tension dans le cluster. Toutefois, le contrôle d'admission de
vSphere HA prend en considération uniquement les ressources qui sont disponibles sur un hôte pour des
machines virtuelles. Cette quantité est inférieure à la quantité totale de ressources physiques disponibles sur
l'hôte, puisqu'il existe certains dépassements de mémoire.

Solution

Réduisez si possible les réservations de la machine virtuelle, utilisez les options avancées de vSphere HA
afin de réduire la taille d'emplacement ou utilisez d'autres règles de contrôle d'admission.

Dépannage des banques de données de signaux de pulsation

Lorsque l'hôte principal d'un cluster vSphere HA ne peut plus communiquer avec un hôte secondaire sur le
réseau de gestion, l'hôte principal utilise le signal de pulsation de la banque de données afin de déterminer
si l'hôte secondaire peut avoir échoué ou se trouve dans une partition réseau. Si l'hôte secondaire a arrêté le
signal de pulsation de la banque de données, cet hôte est considéré comme ayant échoué et ses machines
virtuelles sont redémarrées ailleurs.

vCenter Server sélectionne automatiquement un ensemble préféré de banques de données pour le signal de
pulsation. Cette sélection est effectuée avec l'objectif de maximiser le nombre d'hôtes ayant accès à une
banque de données particulière et de minimiser la vraisemblance de sauvegarde des banques de données
sélectionnées au niveau de la même baie de stockage ou du même serveur NFS. Dans la plupart des cas,
cette sélection ne doit pas être changée. Pour afficher les banques de données que vSphere HA a décidé
d'utiliser, dans Client Web vSphere, allez à l'onglet Surveiller du cluster et sélectionnez vSphere HA et
signal de pulsation. Seules les banques de données montées par au moins deux hôtes sont disponibles ici.

REMARQUE Si le seul stockage partagé accessible à tous les hôtes dans le cluster est Virtual SAN, aucune
banque de données de signaux de pulsation n'est disponible.

VMware, Inc. 43

Dépannage vSphere

La banque de données préférée de l'utilisateur n'a pas été choisie

vCenter Server peut ne pas choisir la banque de données à laquelle vous donnez votre préférence pour le
signal de pulsation du stockage vSphere HA.

Problème

Vous pouvez spécifier les banques de données préférées pour le signal de pulsation du stockage, et en
fonction de cette préférence, vCenter Server détermine l'ensemble final des banques de données à utiliser.
Toutefois, vCenter Server peut ne pas choisir les banques de données que vous spécifiez.

Cause

Ce problème peut se produire dans les cas suivants :

Le nombre spécifié de banques de données est supérieur à celui demandé. vCenter Server choisit le

n

nombre optimal de banques de données nécessaires parmi la préférence utilisateur établie et ignore le
reste.

Une banque de données spécifiée n'est pas optimale pour l'accessibilité des hôtes et la redondance des

n

sauvegardes de stockage. D'une manière plus précise, la banque de données peut ne pas être choisie si
elle n'est accessible qu'à un ensemble réduit d'hôtes dans le cluster. Une banque de données peut
également ne pas être choisie si elle se trouve sur le même LUN ou le même serveur NFS que les
banques de données ayant déjà été choisies par vCenter Server.

Une banque de données spécifiée est inaccessible en raison de défaillances de stockage, par exemple, un

n

arrêt de tous les chemins des baies de stockage ou une perte définitive des périphériques.

Si le cluster contient une partition réseau, ou si un hôte est inaccessible ou isolé, l'hôte continue à

n

utiliser les banques de données à signal de pulsation existantes même si les préférences utilisateur
changent.

Solution

Vérifiez que tous les hôtes du cluster sont accessibles et ont l'agent vSphere HA en cours d'exécution.
Assurez-vous également que les banques de données spécifiées sont pour la plupart accessibles, et si toutes
ne le sont pas, que les hôtes du cluster et que ces banques de données se trouvent sur différents serveurs
NFS ou LUN.

Échec du démontage ou de la suppression de la banque de données

Lors de votre tentative de démontage ou de suppression d'une banque de données, l'opération échoue.

Problème

L'opération de démontage ou de suppression d'une banque de données échoue si la banque de données a
des fichiers ouverts. Pour ces opérations utilisateur, l'agent vSphere HA ferme tous les fichiers qu'il a ouvert,
par exemple, les fichiers à signal de pulsation. Si l'agent est inaccessible par vCenter Server ou si l'agent ne
peut pas purger les E/S en attente afin de fermer les fichiers, une défaillance de type L'agent HA de l'hôte

'{hostName}' a échoué à mettre au repos l'activité des fichiers de la banque de données '{dsName}

est déclenchée.

44 VMware, Inc.

Chapitre 4 Résolution des problèmes de disponibilité

Cause

Si la banque de données à démonter ou supprimer est utilisée pour le signal de pulsation, vCenter Server
l'exclut du signal de pulsation et en choisit une nouvelle. Toutefois, l'agent ne reçoit pas les banques de
données à signal de pulsation mises à jour s'il n'est pas accessible, c'est à dire, si l'hôte est isolé ou dans une
partition réseau. Dans de tels cas, les fichiers à signal de pulsation ne sont pas fermés et l'opération
utilisateur échoue. L'opération peut également échouer si la banque de données est inaccessible suite à des
défaillances de stockage telles que l'arrêt de tous les chemins.

REMARQUE Lorsque vous supprimez une banque de données VMFS, cette dernière l'est de tous les hôtes de
l'inventaire. Ainsi s'il existe des hôtes dans un cluster vSphere HA qui sont inaccessibles ou qui ne peuvent
accéder à la banque de données, l'opération échoue.

Solution

Assurez-vous que la banque de données est accessible, ainsi que les hôtes concernés.

Dépannage des problèmes de protection de basculement vSphere HA

vSphere HA assure la disponibilité élevée des machines virtuelles en les plaçant avec leurs hôtes respectifs
dans un cluster. Les hôtes du cluster sont surveillés et, en cas de défaillance, les machines virtuelles d'un
hôte défectueux sont redémarrées sur d'autres hôtes.

État de protection de la machine virtuelle incorrect

Une machine virtuelle se trouvant dans un cluster vSphere HA est signalé par vSphere HA comme étant
non protégée malgré sa mise sous tension pendant quelques minutes.

Problème

Lorsqu'une machine virtuelle est mise sous tension pendant plusieurs minutes et que son état de protection
vSphere HA est toujours non protégé, vSphere HA pourrait ne pas essayer de redémarrer la machine
virtuelle.

Cause

vCenter Server signale une machine virtuelle comme étant non protégée une fois que l'hôte principal
vSphere HA qui est responsable de la machine virtuelle a enregistré vers le disque l'information que la
machine virtuelle doit être redémarrée suite à une défaillance. Ce processus peut échouer pour différentes
raisons.

L'hôte principal vSphere HA n'a pas été choisi ou vCenter Server n'est pas capable de communiquer

n

avec lui.

Dans ce cas, vCenter Server signale l'état de l'hôte vSphere HA des hôtes du cluster en tant qu'Agent
inaccessible ou Agent non initialisé et signale un problème de configuration du cluster n'ayant pu être
trouvé par un hôte principal.

De nombreux hôtes principaux existent et celui avec lequel vCenter Server communique n'est pas

n

responsable de la machine virtuelle.

Des problèmes se produisent lorsque vCenter Server est en contact avec un hôte principal, mais suite à
la partition d'un réseau de gestion, il existe de nombreux hôtes principaux, et l'agent avec qui vCenter
Server communique n'est pas responsable de la machine virtuelle. Ce cas est vraisemblable si vCenter
Server signale l'état vSphere HA de certains hôtes comme ayant un réseau partitionné.

L'agent est dans l'incapacité d'accéder à la banque de données sur laquelle est stocké le fichier de

n

configuration de la machine virtuelle.

VMware, Inc. 45

Dépannage vSphere

vCenter Server peut être en contact avec l'hôte principal vSphere HA qui détient la machine virtuelle,
mais l'agent est incapable d'accéder à la banque de données sur laquelle est stocké le fichier de
configuration de la machine virtuelle. Ce cas peut se produire si une condition d'arrêt de tous les
chemins affecte tous les hôtes du cluster.

Solution

1 Évaluez si vCenter Server est en contact avec un hôte principal vSphere HA, et si ce n'est pas le cas,

corrigez ce problème.

2 Si vCenter Server est en contact avec un hôte principal, évaluez s'il existe une partition réseau, et si tel

est le cas, corrigez ce problème.

3 Si le problème persiste, évaluez si d'autres machines virtuelles utilisant la même banque de données

pour leurs fichiers de configuration sont également non protégées.

4 Si ces machines virtuelles ne sont pas protégées, vérifiez que l'hôte principal vSphere HA puisse

accéder à la banque de données.

5 Si aucune des précédentes étapes n'a résolu le problème, restaurez la protection en reconfigurant

vSphere HA au niveau de l'hôte sur lequel la machine virtuelle s'exécute.

Échec de redémarrage de la machine virtuelle

Suite à une défaillance de la machine virtuelle ou d'un hôte, une machine virtuelle ne peut être redémarrée.

Problème

Lorsqu'un hôte échoue ou qu'une machine virtuelle échoue alors que son hôte continue à s'exécuter, la
machine virtuelle peut ne pas redémarrer ou redémarre seulement après un long moment.

Cause

vSphere HA peut ne pas redémarrer une machine virtuelle suite à une défaillance ou peut retarder son
redémarrage pour plusieurs raisons.

La machine virtuelle n'est pas protégée par vSphere HA au moment de la survenance de la défaillance.

n

La capacité disponible est insuffisante sur des hôtes avec lesquels la machine virtuelle est compatible.

n

vSphere HA a essayé de redémarrer la machine virtuelle mais cette dernière a rencontré une erreur

n

fatale à chacune de ses tentatives.

Le stockage partagé de votre cluster est Virtual SAN et l'un des fichiers de la machine virtuelle est

n

devenu inaccessible car le nombre d'échecs d'hôte est supérieur au nombre spécifié.

Le redémarrage a en fait réussi.

n

Solution

Pour éviter les défaillances de redémarrage de machine virtuelle, vérifiez que ces machines virtuelles sont
protégées par vSphere HA après leur mise sous tension. Assurez-vous également que vos paramètres de
contrôle d'admission correspondent à vos attentes de redémarrage en cas de défaillance. Maximiser la
compatibilité entre les machines virtuelles et les hôtes du cluster peut également réduire la vraisemblance
des défaillances de redémarrage.

46 VMware, Inc.

Chapitre 4 Résolution des problèmes de disponibilité

La configuration de vSphere HA sur les hôtes arrive à expiration

La configuration d'un cluster vSphere HA peut arriver à expiration sur certains des hôtes qui lui ont été
ajoutés.

Problème

Lorsque vous activez vSphere HA sur un cluster existant pourvu d'un grand nombre d'hôtes et de machines
virtuelles, la configuration de vSphere HA sur certains hôtes peut échouer.

Cause

Cet échec est le résultat d'une expiration survenant avant que l'installation de vSphere HA sur l' (les) hôte(s)
soit terminée.

Solution

Définissez l'option avancée vCenter Server config.vpxd.das.electionWaitTimeSec sur la valeur=240. Une fois
cette modification effectuée, les expirations cessent.

Dépannage de vSphere Fault Tolerance dans des partitions réseau

Lorsqu'un cluster vSphere HA rencontre une défaillance du réseau que vSphere utilise pour des
communications inter-agents (le réseau de gestion), un sous-ensemble d'hôtes du cluster peut être dans
l'impossibilité de communiquer avec d'autres hôtes du cluster. Dans ce cas, tous les hôtes qui peuvent
communiquer entre eux sont considérés comme étant dans une partition réseau.

Une partition de cluster gêne des fonctions de gestion des clusters comme vMotion et peuvent affecter la
capacité de vSphere HA à surveiller et redémarrer les machines virtuelles suite à une défaillance. Cette
condition doit être corrigée le plus rapidement possible.

Les partitions réseau dégradent également la fonctionnalité de vSphere Fault Tolerance. Par exemple, dans
un cluster partitionné, une machine virtuelle principale (ou sa machine virtuelle secondaire) peut s'arrêter
dans une partition gérée par un hôte principal qui n'est pas responsable de la machine virtuelle. Lorsqu'une
machine virtuelle secondaire doit être redémarrée, vSphere HA le fait seulement si la machine virtuelle
principale se trouve dans une partition gérée par l'hôte principal qui en est responsable. Finalement, vous
devez corriger la partition réseau, mais tant que cela est possible, vous devez dépanner et corriger tous les
problèmes qui apparaissent avec vos machines tolérantes aux pannes afin de garantir qu'elles sont
correctement protégées.

La machine virtuelle principale reste à l'état Secondaire nécessaire

Une machine virtuelle principale tolérante aux pannes peut rester à l'état secondaire nécessaire même si
suffisamment de ressources sont disponibles pour démarrer la machine virtuelle secondaire.

Problème

vSphere HA peut ne pas redémarrer la machine virtuelle secondaire d'une paire de machines virtuelles
vSphere Fault Tolerance (FT) même si suffisamment de ressources sont disponibles.

Cause

Pour redémarrer une machine virtuelle secondaire, vSphere HA a besoin que la machine virtuelle principale
s'exécute sur un hôte qui est dans la même partition que celle contenant l'hôte principal vSphere HA
responsable de la paire FT. Par ailleurs, l'agent vSphere HA se trouvant sur l'hôte de la machine virtuelle
principale doit fonctionner correctement. Si ces conditions sont remplies, FT a également besoin qu'il y ait
au moins un autre hôte dans la même partition qui soit compatible avec la paire FT et qui dispose d'un agent
vSphere HA en fonctionnement.

VMware, Inc. 47

Dépannage vSphere

Solution

Pour réparer cette condition, vérifiez les états de l'hôte vSphere HA rapportés par vCenter Server. Si les
hôtes sont identifiés comme étant partitionnés, isolés ou injoignables, corrigez le problème avant de
poursuivre. Dans certains cas, vous pouvez résoudre un problème de redémarrage en reconfigurant vSphere
HA sur l'hôte que vCenter Server rapporte en tant qu'hôte principal. Toutefois, dans la plupart des cas, cette
étape est insuffisante et vous devez corriger tous les problèmes d'état de l'hôte.

Après avoir adressé tous les problèmes d'état de l'hôte, vérifiez si d'autres hôtes du cluster que celui de la
machine virtuelle principale sont incompatibles avec la paire de machine virtuelle FT. Vous pouvez évaluer
la compatibIlité en essayant de migrer la machine virtuelle principale vers d'autres hôtes. Traitez toutes les
incompatibilités qui sont découvertes.

Problèmes de comportement de changement de rôle

vCenter Server peut rapporter que la machine virtuelle principale d'une paire de machines virtuelles
vSphere Fault Tolerance est mise hors tension, alors que la machine virtuelle secondaire est mise sous
tension.

Problème

Suite à la survenance d'un basculement, vCenter Server peut d'une manière incorrecte rapporter que la
machine virtuelle principale est mise hors tension, et que la machine virtuelle secondaire est mise sous
tension et enregistrée au niveau de son hôte d'origine.

Cause

Cette erreur se produit lorsque vCenter Server est dans l'impossibilité de communiquer avec les hôtes sur
lesquels les machines virtuelles principales et secondaires s'exécutent. vCenter Server rapporte que ces hôtes
ne répondent pas et le problème persiste jusqu'à ce que vCenter Server soit capable de communiquer avec
les hôtes.

Solution

Pour résoudre ce problème, corrigez le problème de mise en réseau qui empêche vCenter Server de
communiquer avec les hôtes dans le cluster.

48 VMware, Inc.

Dépannage de gestion des

ressources 5

Les rubriques de dépannage de gestion des ressources proposent des solutions aux problèmes potentiels qui
peuvent apparaître lors de l'utilisation de vos hôtes et banques de données dans vSphere DRS ou dans le
cluster vSphere Storage DRS.

Ce chapitre aborde les rubriques suivantes :

« Informations de dépannage de DRS », page 49

n

« Dépannage du DRS de stockage », page 58

n

« Dépannage du contrôle d'E/S de stockage », page 65

n

Informations de dépannage de DRS

Ces informations décrivent les problèmes rencontrés par vSphere® Distributed Resource Scheduler (DRS)
pour les catégories particulières suivantes : problèmes de cluster, d'hôte et de machine virtuelle.

Problèmes de cluster

Les problèmes de cluster peuvent empêcher le DRS de fonctionner de façon optimale ou d'effectuer des
rapports d'erreurs.

VMware, Inc.

Déséquilibre de charge sur le cluster

Un cluster a un déséquilibre de charge de ressources.

Problème

Un cluster peut devenir déséquilibré en raison de demandes inégales de ressources provenant des machines
virtuelles et des capacités inégales des hôtes.

Cause

Voici les raisons possibles d'un déséquilibre de charge du cluster :

Le seuil de migration est trop élevé.

n

Un seuil plus élevé fait du cluster un candidat plus probable au déséquilibre de charge.

Les règles de VM/VM ou VM/Host DRS empêchent le déplacement des machines virtuelles.

n

Le DRS est désactivé pour une ou plusieurs machines virtuelles.

n

Un périphérique est monté sur une ou plusieurs machines virtuelles, ce qui empêche le DRS de

n

déplacer la machine virtuelle afin d'équilibrer la charge.

49

Dépannage vSphere

Les machines virtuelles ne sont pas compatibles avec les hôtes vers lesquels DRS pourrait les déplacer.

n

Au moins l'un des hôtes du cluster est incompatible pour les machines virtuelles qui seraient migrées.
Par exemple, si le processeur de l'hôte A n'est pas compatible vMotion avec le processeur de l'hôte B,
l'hôte A devient incompatible pour les machines virtuelles sous tension exécutées sur l'hôte B.

Il serait préjudiciable pour les performances de la machine virtuelle de la déplacer plutôt que de

n

l'exécuter à son emplacement actuel. Cela peut se produire quand les charges sont instables ou lorsque
le coût de migration est élevé par rapport au bénéfice du déplacement de la machine virtuelle.

vMotion n'est pas activé ni configuré pour les hôtes du cluster.

n

Solution

Traitez le problème provoquant le déséquilibre de charge.

Le cluster est jaune

Un cluster devient jaune pour cause de pénurie de ressources.

Problème

Si le cluster n'a pas assez de ressources pour satisfaire les réservations de tous les pools de ressources et
machines virtuelles, mais qu'il en a assez pour satisfaire les réservations de toutes les machines virtuelles en
cours d'exécution, DRS continue à fonctionner et le cluster est jaune.

Cause

Il se peut qu'un cluster devienne jaune s'il est privé des ressources de l'hôte (par exemple, si l'hôte connait
une défaillance).

Solution

Augmentez les ressources de l'hôte allouées au cluster ou réduisez les réservations de pool de ressources.

Le cluster est rouge car le pool de ressources est incohérent

Un cluster DRS devient rouge quand il est incorrect. Il se peut qu'il devienne rouge parce que l'arborescence
du pool de ressources manque de cohérence interne.

Problème

Si l'arborescence de pool de ressources de cluster manque de cohérence interne (par exemple, la somme des
réservations des enfants est supérieure à la réservation non expansible du pool parent), le cluster n'a pas
assez de ressources pour satisfaire les réservations de toutes les machines virtuelles en cours d'exécution, ce
qui rend le cluster rouge.

Cause

Cette situation peut se produire si vCenter Server est indisponible ou si les paramètres du pool de
ressources sont modifiés lorsqu'une machine virtuelle est en état de basculement.

Solution

Revenez aux modifications associées ou vérifiez les paramètres de pool de ressources.

50 VMware, Inc.

Chapitre 5 Dépannage de gestion des ressources

Le cluster est rouge car la capacité de basculement n'est pas respectée

Un cluster DRS devient rouge quand il est incorrect. Il se peut qu'il devienne rouge parce que la capacité de
basculement n'est pas respectée.

Problème

Le cluster tente de basculer les machines virtuelles en cas de défaillance d'un hôte, mais il n'est pas assuré
d'avoir assez de ressources disponibles pour basculer toutes les machines virtuelles couvertes par les
conditions de basculement.

Cause

Si un cluster activé pour HA détruit tellement de ressources qu'il ne peut plus remplir ses conditions de
basculement, un message apparaît et l'état du cluster devient rouge.

Solution

Examinez la liste des problèmes de configuration dans le cadre jaune située en haut de la page Résumé du
cluster et traitez le problème à sa source.

Aucun hôte n'est mis hors tension quand la charge totale de cluster est basse

Les hôtes ne sont pas mis hors tension lorsque la charge totale de cluster est basse.

Problème

Les hôtes ne sont pas mis hors tension lorsque la charge de cluster est faible car une capacité supplémentaire
est nécessaire pour les réservations de basculement HA.

Cause

Les hôtes peuvent ne pas être mis hors tension pour les raisons suivantes :

Les paramètres des options avancées MinPoweredOn{Cpu|Memory}Capacity doivent être respectés.

n

Les machines virtuelles ne peuvent pas être consolidées sur un nombre inférieur d'hôtes en raison de

n

leurs réservations de ressources, des règles DRS VM/hôte, des règles de DRS VM/VM, du défaut
d'activation de DRS ou du manque de compatibilité avec les hôtes ayant une capacité disponible.

Les charges sont instables.

n

Le seuil de migration DRS a la valeur maximale et permet uniquement d'exécuter des transferts

n

obligatoires.

vMotion ne peut pas être exécuté, car il n'est pas configuré.

n

DPM est désactivé sur les hôtes qui pourraient être mis hors tension.

n

Les hôtes ne sont pas compatibles pour les machines virtuelles à transférer vers un autre hôte.

n

L'hôte ne dispose pas de la technologie reveil par le réseau, IPMI ou iLO. Ni l'une ni l'autre n'est

n

nécessaire pour permettre à DPM de mettre un hôte en standby.

Solution

Traitez le problème empêchant les hôtes d'être mis hors tension lorsque la charge totale de cluster est basse.

VMware, Inc. 51

Dépannage vSphere

Les hôtes sont mis hors tension quand la charge totale de cluster est élevée

Les hôtes sont mis hors tension lorsque la charge totale de cluster est élevée.

Problème

DRS a déterminé que des machines virtuelles pouvaient être exécutées sur un nombre inférieur d'hôtes sans
incidence sur les performances de l'hôte ou de la machine virtuelle. DRS est également empêché de déplacer
les machines virtuelles fonctionnant sur les hôtes très utilisés vers des hôtes programmés pour être mis hors
tension.

Cause

Cela survient lorsque la charge totale de cluster est trop élevée.

Solution

Réduisez la charge de cluster.

Le DRS effectue rarement ou jamais les migrations vMotion

Le DRS effectue rarement ou jamais les migrations vMotion.

Problème

Le DRS n'effectue pas les migrations vMotion.

Cause

Le DRS n'effectue jamais les migrations vMotion lorsqu'un ou plusieurs des problèmes suivants surviennent
sur le cluster.

DRS est désactivé dans le cluster.

n

Les hôtes n'ont pas de stockage partagé.

n

Les hôtes dans le cluster ne contiennent pas un réseau vMotion.

n

Le DRS est manuel et personne n'a validé la migration.

n

Le DRS n'effectue que rarement les migrations vMotion lorsqu'un ou plusieurs des problèmes suivants
surviennent sur le cluster :

Les charges sont instables ou vMotion met longtemps, ou les deux. Un déplacement n'est pas

n

approprié.

DRS migre rarement ou jamais les machines virtuelles.

n

Le seuil de migration DRS défini est trop élevé.

n

DRS déplace les machines virtuelles pour les raisons suivantes :

L'évacuation d'un hôte qu'un utilisateur a demandée entre en mode maintenance ou veille.

n

Règle DRS VM/hôte ou règles DRS VM/VM.

n

Non respect des réservations.

n

Déséquilibre de charge.

n

Gestion de l'alimentation.

n

Solution

Traitez les problèmes amenant le DRS à éviter d'effectuer les migrations vMotion.

52 VMware, Inc.

Chapitre 5 Dépannage de gestion des ressources

Problèmes d'hôte

Des problèmes d'hôte peuvent empêcher DRS de fonctionner normalement.

DRS recommande que l'hôte soit mis sous tension pour augmenter la capacité quand la charge totale de cluster est basse

L'hôte doit être mis sous tension pour aider à fournir plus de capacité pour le cluster ou pour aider les hôtes
qui sont surchargés.

Problème

Le DRS recommande que l'hôte soit mis sous tension pour augmenter la capacité lorsque la charge totale de
cluster est basse.

Cause

La recommandation peut être faite pour les raisons suivantes :

Le cluster est un cluster HA DRS. Des hôtes sous tension supplémentaires sont nécessaires afin

n

d'augmenter la capacité de basculement.

Certains hôtes sont surchargés et des machines virtuelles sur des hôtes sous tension peuvent être

n

déplacées vers des hôtes en mode veille pour équilibrer la charge.

La capacité est nécessaire pour respecter les options avancées MinPoweredOn{Cpu|Memory}Capacity.

n

Solution

Mettez l'hôte sous tension.

La charge totale de cluster est élevée

La charge totale de cluster est élevée.

Problème

Lorsque la charge totale de cluster est élevée, DRS ne met pas l'hôte sous tension.

Cause

Voici quelques raisons pouvant expliquer pourquoi le DRS ne met pas l'hôte sous tension :

Les règles DRS VM/VM ou les règles DRS VM/hôte empêchent la machine virtuelle d'être déplacée vers

n

cet hôte.

Les machines virtuelles sont liées à leurs hôtes actuels et DRS ne peut donc pas transférer ces machines

n

virtuelles vers des hôtes en veille pour équilibrer la charge.

DRS ou DPM est en mode manuel et les recommandations n'ont pas été appliquées.

n

Aucune machine virtuelle sur les hôtes utilisés intensivement ne sera transférée vers cet hôte.

n

DPM est désactivé sur l'hôte en raison d'un paramètre utilisateur ou d'un hôte ayant échoué à sortir du

n

mode veille.

Solution

Traitez ce problème empêchant le DRS de mettre l'hôte sous tension.

VMware, Inc. 53

Dépannage vSphere

La charge totale de cluster est faible

La charge totale de cluster est basse.

Problème

Quand la charge totale de cluster est faible, DRS ne met pas l'hôte hors tension.

Cause

Voici quelques raisons pouvant expliquer pourquoi le DRS ne met pas l'hôte hors tension :

Gestion de l'alimentation distribuée (DPM) a détecté de meilleurs candidats à la mise hors tension.

n

vSphere HA a besoin de capacité supplémentaire pour le basculement.

n

La charge n'est pas assez basse pour déclencher la mise hors tension de l'hôte.

n

DPM prévoit que la charge augmentera.

n

DPM n'est pas activé pour l'hôte.

n

Le seuil DPM est défini trop haut.

n

Lorque DPM est activé pour l'hôte, aucun mécanisme de mise sous tension adéquat n'est présent pour

n

l'hôte.

DRS ne peut pas évacuer l'hôte.

n

Le seuil de migration DRS est à la valeur maximale et ne permet d'exécuter que les transferts

n

obligatoires.

Solution

Traitez le problème empêchant le DRS de mettre l'hôte hors tension.

DRS n'évacue pas un hôte auquel il a été demandé de passer en mode maintenance ou Standby

Le DRS n'évacue pas un hôte auquel il a été demandé de passer en mode maintenance ou veille.

Problème

Lorsque vous essayez de faire passer un hôte en mode maintenance ou veille, le DRS n'évacue pas l'hôte
comme prévu.

Cause

vSphere HA est activé et l'évacuation de cet hôte pourrait ne pas respecter la capacité de basculement de
HA.

Solution

Il n'y a pas de solution. Le cas échéant, désactivez vSphere HA avant d'essayer de faire passer l'hôte en
mode maintenance ou veille.

DRS ne déplace aucune machine virtuelle vers un hôte

Le DRS ne déplace aucune machine virtuelle vers un hôte.

Problème

Le DRS ne recommande pas la migration d'une machine virtuelle vers un hôte ajouté à un cluster activé par
le DRS.

54 VMware, Inc.

Chapitre 5 Dépannage de gestion des ressources

Cause

Une fois qu'un hôte a été ajouté à un cluster activé par DRS, les machines virtuelles déployées sur l'hôte font
partie du cluster. DRS peut recommander la migration de certaines machines virtuelles vers cet hôte qui
vient d'être ajouté au cluster. Si cela ne se produit pas, il peut y avoir des problèmes avec vMotion, la
compatibilité d'hôte ou les règles d'affinité. Voici plusieurs raisons possibles :

vMotion n'est ni configuré ni activé sur cet hôte.

n

Les machines virtuelles sur d'autres hôtes ne sont pas compatibles avec cet hôte.

n

L'hôte n'a pas les ressources suffisantes pour une quelconque machine virtuelle.

n

Le déplacement de machines virtuelles vers cet hôte enfreindrait une règle DRS VM/VM ou une règle

n

DRS VM/hôte.

Cet hôte est réservé pour la capacité de basculement HA.

n

Un périphérique est monté sur la machine virtuelle.

n

Le seuil vMotion est trop élevé.

n

DRS étant désactivé pour les machines virtuelles, la machine virtuelle ne pourrait pas être déplacée vers

n

l'hôte de destination.

Solution

Traitez le problème empêchant le DRS de déplacer des machines virtuelles vers un hôte.

DRS ne déplace aucune machine virtuelle depuis un hôte

Le DRS ne déplace aucune machine virtuelle depuis un hôte.

Problème

Les machines virtuelles ne sont pas déplacées depuis cet hôte.

Cause

Cela peut se produire en raison de problèmes avec vMotion, DRS ou la compatibilité d'hôte. Raisons
possibles :

vMotion n'est ni configuré ni activé sur cet hôte.

n

DRS est désactivé pour les machines virtuelles sur cet hôte.

n

Les machines virtuelles sur cet hôte ne sont compatibles avec aucun autre hôte.

n

Aucun autre hôte n'a les ressources suffisantes pour une quelconque machine virtuelle sur cet hôte.

n

Le déplacement de machines virtuelles depuis cet hôte enfreindrait une règle DRS VM/VM ou une règle

n

DRS VM/hôte.

DRS est désactivé pour une ou plusieurs machines virtuelles sur l'hôte.

n

Un périphérique est monté sur la machine virtuelle.

n

Solution

Traitez les problèmes empêchant le DRS de déplacer des machines virtuelles depuis l'hôte.

VMware, Inc. 55

Dépannage vSphere

Problèmes de machine virtuelle

Des problèmes de machine virtuelle peuvent empêcher DRS de fonctionner normalement.

Ressources de mémoire ou de CPU insuffisantes

La machine virtuelle ne reçoit pas assez de ressources de CPU ou de mémoire.

Problème

Dans certains cas, la demande de la machine virtuelle est supérieure à sa dotation en ressources. Lorsque
que cette situation survient, la machine virtuelle ne reçoit pas assez de ressources de CPU ou de mémoire.

Cause

Les sections suivantes décrivent les facteurs qui influencent la dotation pour une machine virtuelle.

Le cluster est jaune ou
rouge

La limite de ressources
est trop restrictive

Le cluster est surchargé

L'hôte est surchargé

Si le cluster est jaune ou rouge, la capacité est insuffisante pour respecter les
réservations de ressources configurées pour toutes les machines virtuelles et
les pools de ressources dans le cluster. La machine virtuelle particulière peut
ne pas recevoir sa réservation. Vérifiez l'état du cluster (rouge ou jaune) et
corrigez la situation.

La machine virtuelle, son pool de ressources parent, ou ses ancêtres de pool
de ressources peuvent avoir une limite configurée de ressources trop
restrictive. Vérifiez si la demande est égale ou supérieure aux limites
configurées.

Le cluster sur lequel la machine virtuelle est en cours d'exécution peut
disposer de ressources insuffisantes. En outre, la valeur de part de la
machine virtuelle est telle qu'on accorde proportionnellement plus de
ressources aux autres machines virtuelles. Pour déterminer si la demande est
supérieure à la capacité, vérifiez les statistiques du cluster.

Pour déterminer si les ressources de l'hôte sont trop utilisées, vérifiez les
statistiques de l'hôte. Si tel est le cas, considérez pourquoi DRS ne déplace
aucune des machines virtuelles en cours d'exécution sur l'hôte vers d'autres
hôtes. Cela peut se produire pour les raisons suivantes :

Les règles DRS VM/VM et les règles DRS VM/hôte requièrent le

n

mappage virtuel machine-vers-hôte actuel. Si ces règles sont configurées
dans le cluster, envisagez de mettre hors tension une ou plusieurs
d'entre elles. Exécutez ensuite DRS et vérifiez si la situation est corrigée.

DRS ne peut pas déplacer cette machine virtuelle ou suffisamment

n

d'autres machines virtuelles vers d'autres hôtes pour libérer de la
capacité. DRS ne déplace pas une machine virtuelle pour l'une des
raisons suivantes :

DRS est désactivé pour la machine virtuelle.

n

Un périphérique hôte est monté sur la machine virtuelle.

n

L'une ou l'autre de ses réservations de ressources est tellement

n

importante que la machine virtuelle ne peut fonctionner sur aucun
autre hôte dans le cluster.

La machine virtuelle n'est compatible avec aucun autre hôte dans le

n

cluster.

56 VMware, Inc.

Chapitre 5 Dépannage de gestion des ressources

Vérifiez si l'une de ces conditions existe pour la machine virtuelle. Si
aucune n'est présente, les conditions peuvent exister pour d'autres
machines virtuelles dans le cluster. Si tel est le cas, DRS ne peut pas
équilibrer le cluster pour répondre à la demande de la machine virtuelle.

Réduisez le seuil de migration DRS et vérifiez si le problème est résolu.

n

Augmentez la réservation de la machine virtuelle.

n

Solution

Traitez le problème faisant que la machine virtuelle ne reçoit pas assez de ressources de CPU ou de
mémoire.

Règle DRS VM/VM ou DRS VM/Hôte enfreinte

Les règles du DRS spécifient sur quel hôte une machine virtuelle doit ou non résider, mais aussi quelles
machines virtuelles doivent ou non être sur le même hôte.

Problème

Une règle DRS VM/VM ou une règle DRS VM/Hôte est enfreinte.

Cause

Les règles DRS VM/VM spécifient que les machines virtuelles sélectionnées doivent être placées sur le même
hôte (affinité) ou que des machines virtuelles doivent être placées sur différents hôtes (anti-affinité). Les
règles VM/Host DRS stipulent que les machines virtuelles sélectionnées doivent être placées sur les hôtes
définis (affinité) ou ne doivent pas être placées sur ces hôtes (non-affinité).

La violation d'une règle DRS VM/VM ou VM/Hôte peut être due au fait que le DRS ne peut déplacer tout ou
partie des machines virtuelles dans la règle. La réservation de la machine virtuelle ou d'autres machines
virtuelles dans la règle d'affinité ou leurs pools de ressources parents pourraient empêcher le DRS de
localiser toutes les machines virtuelles sur le même hôte.

Solution

Recherchez dans le panneau de défaillances DRS des défaillances liées aux règles d'affinité.

n

Calculer la somme des réservations de toutes les machines virtuelles dans la règle d'affinité. Si cette

n

valeur est supérieure à la capacité disponible sur un des hôtes, la règle ne peut être respectée.

Calculez la somme des réservations de leurs pools de ressources parents. Si cette valeur est supérieure à

n

la capacité disponible de n'importe quel hôte, la règle ne peut pas être respectée si les ressources sont
obtenues à partir d'un seul hôte.

La mise sous tension de la machine virtuelle a échoué

Un message d'erreur signalant l'échec de l'activation de la machine virtuelle s'affiche.

Problème

Échec de l'activation de la machine virtuelle.

Cause

L'échec de l'activation d'une machine virtuelle peut provenir de ressources insuffisantes ou de l'absence
d'hôtes compatibles avec elle.

VMware, Inc. 57

Dépannage vSphere

Solution

Si le cluster n'a pas suffisamment de ressources pour activer une machine virtuelle individuelle (ou l'une des
machines virtuelles lors d'une tentative d'activation d'un groupe), comparez les ressources exigées par la
machine virtuelle à celles disponibles dans le cluster ou son pool de ressources parent. Si nécessaire,
réduisez les réservations de la machine virtuelle à activer, réduisez celles de ses machines virtuelles sœurs
ou augmentez les ressources disponibles dans le cluster ou son pool de ressources parent.

DRS ne déplace pas la machine virtuelle

Le DRS ne déplace pas la machine virtuelle lors de son activation initiale, en dépit de ressources
insuffisantes sur l'hôte.

Problème

Lorsque vous activez une machine virtuelle, le DRS ne la migre pas comme il est prévu lorsque les
ressources de l'hôte sur lequel la machine virtuelle est enregistrée sont insuffisantes.

Cause

Voici quelques raisons pouvant expliquer pourquoi le DRS ne déplace pas la machine virtuelle.

DRS est désactivé sur la machine virtuelle.

n

La machine virtuelle a un périphérique monté.

n

La machine virtuelle n'est compatible avec aucun autre hôte.

n

Aucun autre hôte n'a un nombre suffisant de CPU physiques ni une capacité suffisante pour chaque

n

CPU pour la machine virtuelle.

Aucun autre hôte n'a les ressources suffisantes en CPU ou en mémoire pour satisfaire les réservations et

n

la mémoire requise de cette machine virtuelle.

Le déplacement de la machine virtuelle enfreindra une règle d'affinité ou d'anti-affinité.

n

Le niveau d'automatisation DRS de la machine virtuelle est manuel et l'utilisateur n'approuve pas la

n

recommandation de migration.

DRS ne déplace pas les machines virtuelles pour lesquelles la tolérance aux défaillances est activée.

n

Solution

Traitez le problème empêchant le DRS de déplacer une machine virtuelle.

Dépannage du DRS de stockage

Les rubriques de dépannage du DRS de stockage proposent des solutions aux problèmes potentiels qui
peuvent apparaître lorsque vous utilisez des banques de données sur lesquelles le DRS de stockage est
activé dans un cluster de banques de données.

Le DRS de stockage est désactivé sur un disque virtuel

Même si le DRS de stockage est activé pour un cluster de banques de données, il peut être désactivé sur
certains disques virtuels du cluster de banques de données.

Problème

Vous avez activé le DRS de stockage pour un cluster de banques de données, mais il est désactivé sur un ou
plusieurs disques de machine virtuelle dans le cluster de banques de données.

58 VMware, Inc.

Chapitre 5 Dépannage de gestion des ressources

Cause

Le DRS de stockage peut être désactivé sur un disque virtuel dans les cas suivants.

Le fichier d'échange d'une machine virtuelle est local sur l'hôte (il est stocké dans une banque de

n

données spécifiée qui se trouve sur l'hôte). Le fichier d'échange ne peut pas être déplacé et le DRS de
stockage est désactivé pour le disque du fichier d'échange.

Un certain emplacement est défini pour le fichier d'échange .vmx d'une machine virtuelle. Le fichier

n

d'échange ne peut pas être déplacé et le DRS de stockage est désactivé sur le disque du fichier
d'échange .vmx.

Le déplacement ou l'opération Storage vMotion sont actuellement désactivés pour la machine virtuelle

n

dans vCenter Server (parce que, par exemple, d'autres opérations vCenter Server sont en cours sur la
machine virtuelle). Le DRS de stockage DRS est désactivé jusqu'à ce que le déplacement ou l'opération
Storage vMotion soient réactivés dans vCenter Server.

Le disque de base d'une machine virtuelle est protégée par vSphere HA et son déplacement entraînera

n

la perte de la protection HA vSphere.

Le disque est un fichier CD-ROM/ISO.

n

Si le disque est un disque indépendant, le DRS de stockage est désactivé (sauf en cas de déplacement ou

n

de placement d'un clone).

Si la machine virtuelle dispose de fichiers système dans une banque de données autre que la banque de

n

données de base (héritée), le DRS de stockage est désactivé sur le disque de base. Si vous utilisez
Storage vMotion pour migrer manuellement le disque de base et les fichiers système dans les
différentes banques de données seront tous placés dans la banque de données cible et le DRS de
stockage sera activé sur le disque de base.

Si la machine virtuelle dispose d'un disque dont les fichiers de base/rétablissement sont répartis dans

n

différentes banques de données (héritées), le DRS de stockage du disque est désactivé. Si vous utililsez
Storage vMotion pour migrer manuellement le disque, les fichiers dans les différentes banques de
données seront tous placés dans la banque de données cible et le DRS de stockage sera activé sur le
disque.

La machine virtuelle dispose de disques masqués (tels que des disques dans des snapshots précédents

n

et non pas dans le snapshot actuel). Dans ce cas, le DRS de stockage est désactivé sur la machine
virtuelle.

La machine virtuelle est un modèle.

n

vSphere Fault Tolerance est activé sur la machine virtuelle.

n

La machine virtuelle partage des fichiers entre ses disques.

n

La machine virtuelle est placée dans le DRS de stockage avec des banques de données définies

n

manuellement.

Solution

Résolvez le problème qui entraîne la désactivation du DRS de stockage sur le disque.

VMware, Inc. 59

Dépannage vSphere

La banque de données ne peut pas passer en mode maintenance dans Client Web vSphere

Vous placez une banque de données en mode maintenance lorsque vous devez la mettre hors service pour
en effectuer la maintenance. Une banque de données passe en mode maintenance ou quitte le mode
uniquement à la demande de l'utilisateur.

Problème

Une banque de données dans un cluster de banques de données ne peut pas passer en mode maintenance.
L'état d'Entrée en mode maintenance reste 1%.

Cause

Les disques de la banque de données ne peuvent pas être migrés avec Storage vMotion. Cette situation peut
se produire dans les cas suivants.

Le DRS de stockage est désactivé sur le disque.

n

Les règles du DRS de stockage l'empêchent de faire des recommandations de migration pour le disque.

n

Solution

Le DRS de stockage est désactivé. Activez-le ou déterminez pourquoi il est désactivé. Reportez-vous à

n

la section « Le DRS de stockage est désactivé sur un disque virtuel », page 58 pour déterminer les
raisons pour lesquelles le DRS de stockage peut être désactivé.

Si des règles du DRS de stockage l'empêchent de faire des recommandations de migration, vous pouvez

n

supprimer ou désactiver certains règles.

a Accédez au cluster de la banque de données dans le navigateur d'objets de Client Web vSphere.

b Cliquez sur l'onglet Gérer puis sur Paramètres.

c Dans Configuration, sélectionnez Règles, puis cliquez sur la règle.

d Cliquez sur Supprimer.

Si les règles du DRS de stockage l'empêchent de faire des recommandations de migration, vous pouvez

n

également affecter à l'option avancée IgnoreAffinityRulesForMaintenance du DRS de stockage la valeur

1.

a Accédez au cluster de la banque de données dans le navigateur d'objets de Client Web vSphere.

b Cliquez sur l'onglet Gérer puis sur Paramètres.

c Sélectionnez SDRS, puis cliquez sur Modifier.

d Dans Options avancées > Paramètres de configuration, cliquez sur Ajouter.

e Dans la colonne Option, saisissez IgnoreAffinityRulesForMaintenance.

f Dans la colonne Valeur, saisissez 1 pour activer l'option.

g Cliquez sur OK.

Le DRS de stockage ne fonctionne pas sur une banque de données

Le DRS de stockage génère une alarme pour indiquer qu'il ne peut pas fonctionner dans la banque de
données.

Problème

Le DRS de stockage génère un événement et une alarme et il ne peut pas fonctionner.

60 VMware, Inc.

Chapitre 5 Dépannage de gestion des ressources

Cause

vCenter Server peut désactiver le DRS de stockage pour une banque de données dans les cas suivants.

La banque de données est partagée dans plusieurs centres de données.

n

Le DRS de stockage n'est pas pris en charge dans les banques de données partagées dans plusieurs
centres de données. Cette configuration peut exister lorsqu'un hôte dans un centre de données monte
une banque de données dans un autre centre de données ou qu'un hôte utilisant la banque de données
est transféré vers un autre centre de données. Lorsqu'une banque de données est partagée dans
plusieurs centres de données, l'équilibrage de charge E/S du DRS de stockage est désactivé pour
l'ensemble du cluster de banques de données. Toutefois, l'équilibrage de l'espace du DRS de stockage
reste actif pour l'ensemble des banques de données du cluster de banques de données qui ne sont pas
partagées dans des centres de données.

La banque de données est connectée à un hôte non pris en charge.

n

Le DRS de stockage n'est pas pris en charge sur les hôtes ESX/ESXi 4.1 et versions antérieures.

La banque de données est connectée à un hôte qui n'exécute pas le contrôle d'E/S de stockage.

n

Solution

La banque de données doit être visibible dans un seul centre de données. Transférez les hôtes vers le

n

même centre de données ou démontez la banque de données sur les hôtes qui résident dans d'autres
centres de données.

Vérifiez que tous les hôtes associés au cluster de banques de données correspondent à la version ESXi

n

5.0 ou une version supérieure.

Assurez-vous que tous les hôtes associés au cluster de banques de données activent le contrôle d'E/S de

n

stockage.

Le déplacement de plusieurs machines virtuelle dans un cluster de banques de données échoue

La migration de plusieurs banques de données dans un cluster de banques de données échoue avec un
message d'erreur une fois que la première machine virtuelle a été déplacée dans le cluster de banques de
données.

Problème

Lorsque vous tentez de migrer plusieurs machines virtuelles dans un cluster de banques de données, la
migration de certaines machines virtuelles réussit, mais la migration des machines suivantes échoue.
vCenter Server affiche le message d'erreur : Espace disque insuffisant dans la banque de données.

Cause

Jusqu'à ce que chaque recommandation sur le placement ait été appliquée, les ressources d'espace
apparaissent comme étant disponibles dans le DRS de stockage. Le DRS de stockage peut donc réallouer les
ressources d'espace aux demandes d'espace suivantes.

Solution

Effectuez à nouveau les opérations de migration ayant échoué une par une et assurez-vous que chaque
recommandation a été appliquée avant de demander la migration suivante.

VMware, Inc. 61

Dépannage vSphere

Le DRS de stockage génère une défaillance lors de la création d'une machine virtuelle

Lorsque vous créez ou clonez une machine virtuelle dans un cluster de banques de données, le DRS de
stockage peut générer une défaillance.

Problème

Lorsque vous tentez de créer ou de cloner une machine virtuelle dans un cluster de banques de données,
vous pouvez recevoir le message d'erreur, Opération non autorisée dans l'état actuel.

Cause

Le DRS de stockage vérifie s'il y a des violations de règle lorsque vous créez une machine virtuelle dans une
banque de données dont le DRS de stockage est activé. Si le DRS de stockage ne peut pas créer les disques
de la nouvelle machine virtuelle en respectant les règles, il génère une défaillance. La défaillance est générée
car le DRS de stockage ne peut pas référencer la machine virtuelle, qui est en cours de création et n'existe
pas.

Solution

Vérifiez ou supprimez les règles, puis réessayez de créer ou de cloner la machine virtuelle.

Le DRS de stockage est activé sur une machine virtuelle déployée depuis un modèle OVF dans Client Web vSphere

Le DRS de stockage est activé sur une machine virtuelle qui est déployée depuis un modèle OVF pour
laquelle le DRS de stockage est désactivé. Ceci peut se produire lorsque vous déployez un modèle OVF dans
un cluster de banques de données.

Problème

Lorsque vous déployez un modèle OVF avec le DRS de stockage désactivé dans un cluster de banques de
données, le DRS de stockage est activé pour la machine virtuelle résultante.

Cause

Client Web vSphere applique le niveau d'automatisation par défaut du cluster de banques de données aux
machines virtuelles déployées à partir d'un modèle OVF.

Solution

1 Pour modifier manuellement le niveau d'automatisation de la machine virtuelle, accédez au cluster de

la banque de données, dans le navigateur d'objets de Client Web vSphere.

2 Cliquez sur l'onglet Gérer, puis sélectionnez Paramètres.

3 Sélectionnez Remplacements VM , puis cliquez sur Ajouter.

4 Sélectionnez la machine virtuelle, puis cliquez sur OK.

5 Dans le menu déroulant Conserver les VMDK ensemble sélectionnez Non, puis cliquez sur OK.

62 VMware, Inc.

Chapitre 5 Dépannage de gestion des ressources

Une défaillance de violation de règle de DRS de stockage s'affiche plusieurs fois

Lorsque vous tentez de mettre une banque de données en mode maintenance, la même défaillance de
violation de règle d'affinité ou d'anti-affinité peut apparaître plusieurs fois dans la boîte de dialogue
Défaillances.

Problème

La boîte de dialogue Défaillances affiche plusieurs instances de défaillances identiques mais, en réalité,
chaque défaillance se rapporte à une banque de données différente. La boîte de dialogue Défaillances
n'indique pas les noms des banques de données, et c'est pourquoi les défaillances apparaissent plusieurs
fois.

Solution

La boîte de dialogue Défaillances affiche toujours une défaillance de violation de règle pour chaque banque
de données prise en compte pour le placement. Si vous souhaitez que la banque de données passe en mode
maintenance, supprimez la règle qui empêche la migration de la machine virtuelle.

Les règles du DRS de stockage ne sont pas supprimées du cluster de banques de données dans Client Web vSphere

Les règles d'affinité ou d'anti-affinité qui s'appliquent à une machine virtuelle ne sont pas supprimées
lorsque vous supprimez une machine virtuelle d'un cluster de banques de données.

Problème

Lorsque vous supprimez une machine virtuelle d'un cluster de banques de données, et que cette machine
virtuelle est soumise à une règle d'affinité ou d'anti-affinité dans un cluster de banques de données, la règle
subsiste. Ceci vous permet de stocker des configurations de machine virtuelle dans des clusters de banques
de données différents. Si la machine virtuelle est placée à nouveau dans le cluster de banques de données, la
règle est appliquée. Vous ne pouvez pas supprimer la règle après avoir supprimé la machine virtuelle du
cluster de banques de données.

Cause

vCenter Server conserve les règles pour une machine virtuelle qui est supprimée d'un cluster de banques de
données si la machine virtuelle reste dans l'inventaire de vCenter Server.

Solution

Pour supprimer une règle d'une configuration de cluster de banques de données, vous devez la supprimer
avant de supprimer la machine virtuelle à laquelle elle s'applique du cluster de banques de données.

1 Dans Client Web vSphere, accédez au cluster de banques de données.

2 Cliquez sur l'onglet Gérer, puis sélectionnezParamètres.

3 Dans Configuration, cliquez sur Règles.

4 Sélectionnez la règle à supprimer et cliquez sur Supprimer.

5 Cliquez sur OK.

VMware, Inc. 63

Dépannage vSphere

Aucune autre recommandation de placement du DRS de stockage n'est générée

Lorsque vous créez, clonez ou déplacez une machine virtuelle, le DRS de stockage génère une seule
recommandation de placement.

Problème

Le DRS de stockage génère une seule recommandation de placement lorsque vous créez, clonez ou déplacez
une machine virtuelle. Aucune autre recommandation n'est fournie lorsque de nombreuses autres
recommandations sont attendues.

Cause

Si l'hôte de destination indique d'une manière explicite l'emplacement du fichier d'échange de la machine
virtuelle au niveau de la banque de données appartenant au cluster de la banque de données cible, les
disques à mettre dans ce cluster ne forment pas de groupe d'affinité unique. Le DRS de stockage génère
d'autres recommandations de placement seulement dans le cas d'un élément unique ou d'un groupe
d'affinité unique. groupe.

Solution

Acceptez la recommandation unique. Pour obtenir de nombreuses recommandations, choisissez un hôte de
destination qui n'indique pas que l'emplacement du fichier d'échange de la machine virtuelle se trouve sur
une banque de données appartenant au cluster de la banque de données cible.

L'application des recommandations du DRS de stockage échoue

Le DRS de stockage génère des recommandations d'espace ou d'équilibrage de charge E/S, mais les
tentatives pour appliquer les recommandations échouent.

Problème

Lorsque vous appliquez des recommandations du DRS de stockage pour l'espace ou l'équilibrage de charge
des E/S, l'opération échoue.

Cause

Les scénarios suivants peuvent vous empêcher d'appliquer les recommandations du DRS de stockage.

Une alarme de dépassement de seuil d'allocation dynamique peut avoir été déclenchée pour une

n

banque de données de destination, ce qui indique que la banque de données manque d'espace et
qu'aucune machine virtuelle ne sera migrée vers elle.

La banque de données de destination peut être en mode maintenance ou passer en mode maintenance.

n

Solution

Abordez le problème qui a déclenché le seuil de l'alarme de dépassement de seuil d'allocation

n

dynamique.

Vérifiez que la banque de données de destination n'est pas en mode de maintenance ou en train de

n

passer en mode de maintenance.

64 VMware, Inc.

Dépannage du contrôle d'E/S de stockage

Les rubriques de dépannage du contrôle d'E/S de stockage proposent des solutions aux problèmes potentiels
qui peuvent apparaître lors de l'utilisation du contrôle d'E/S de stockage avec des banques de données.

Hôte non pris en charge connecté à la banque de données

Dans Client Web vSphere, une alarme se déclenche lorsque vCenter Server détecte que la charge de travail
d'un hôte peut avoir une incidence sur les performances.

Problème

L'alarme Hôte antérieur à la version 4.1 connecté à la banque de données ayant la fonction SIOC activée
se déclenche.

Cause

La banque de donnée dispose de la fonction de contrôle d'E/S de stockage, mais n'est pas entièrement
contrôlée par cette fonction en raison de la charge de travail externe.

Cette condition peut se produire si la banque de données ayant la fonction Contrôle d'E/S de stockage
activée est connectée à un hôte qui ne prend pas en charge la fonction Contrôle d'E/S de stockage.

Chapitre 5 Dépannage de gestion des ressources

Solution

Vérifiez que tous les hôtes connectés à la banque de données prennent à charge la fonction Contrôle d'E/S de
stockage.

Charge de travail non gérée détectée sur la banque de données

Dans Client Web vSphere, une alarme se déclenche lorsque vCenter Server détecte que la charge de travail
d'un hôte peut avoir une incidence sur les performances.

Problème

L'alarme Une charge de travail non gérée est détectée sur la banque de données se déclenche.

Cause

La baie est partagée avec des charges de travail non-vSphere ou la baie exécute des tâches système telles que
la réplication.

Solution

Il n'existe pas de solution. vCenter Server ne réduit pas la quantité totale d'E/S envoyée à la baie, mais
continue à renforcer les partages.

Impossible d'afficher les diagrammes de performances d'une banque de données dans Client Web vSphere

Les graphiques de performances d'une banque de données n'apparaissent pas dans l'onglet Performance.

Problème

Vous ne pouvez pas afficher les graphiques de performances d'une banque de données dans l'onglet
Performance deClient Web vSphere.

Cause

Le contrôle des E/S de stockage est désactivé pour la banque de données.

VMware, Inc. 65

Dépannage vSphere

Solution

1 Accédez à la banque de données dans le navigateur d'objets de Client Web vSphere.

2 Cliquez-droit sur la banque de données et sélectionnez Configurer le Storage I/O Control.

3 Sélectionnez la case à cocher Activer Storage I/O Control.

4 Cliquez sur OK.

Impossible d'activer le contrôle d'E/S de stockage sur la banque de données

Le contrôle de stockage d'E/S est désactivé sur une banque de données et ne peut pas être activé.

Problème

Vous ne pouvez pas activer le contrôle d'E/S de stockage sur une banque de données.

Cause

Les raisons suivantes peuvent vous empêcher d'activer le contrôle d'E/S de stockage sur une banque de
données.

Au moins un hôte connecté à la banque de données n'exécute pas ESX/ESXi 4.1 ou une version plus

n

récente.

Vous n'avez pas la licence appropriée pour activer le contrôle d'E/S de stockage.

n

Solution

Vérifiez que les hôtes connectés à la banque de données sont ESX/ESXi 4.1 ou une version plus récente.

n

Vérifiez que vous disposez de la licence appropriée pour activer le contrôle d'E/S de stockage.

n

66 VMware, Inc.

Dépannage du stockage 6

Les rubriques de dépannage du stockage proposent des solutions potentielles qui peuvent apparaître lors de
l'utilisation de vos hôtes dans l'environnement SAN. Pour plus d'informations sur la configuration du
stockage SAN et le travail avec des banques de données, voir la documentation Stockage vSphere.

Ce chapitre aborde les rubriques suivantes :

« Résolution des problèmes d'affichage de stockage SAN », page 68

n

« Résolution des problèmes de performance de SAN », page 70

n

« Les machines virtuelles dotées de RDM doivent ignorer la mise en cache SCSI INQUIRY », page 73

n

« L'adaptateur iSCSI logiciel est désactivé lorsqu'il n'est pas nécessaire », page 74

n

« Echec dans le montage des banques de données NFS », page 74

n

« Les fichiers journaux VMkernel contiennent des codes de détection SCSI », page 75

n

« Dépannage des adaptateurs de stockage », page 76

n

« Vérification de la cohérence des métadonnées avec VOMA », page 77

n

« Dépannage des disques SSD (Solid-State Drives) », page 78

n

« Dépannage de Virtual SAN », page 82

n

VMware, Inc.

67

Dépannage vSphere

Résolution des problèmes d'affichage de stockage SAN

Lorsque vous utilisez Client Web vSphere pour afficher les périphériques de stockage, vous risquez de ne
pas pouvoir voir tous les périphériques auxquels votre hôte a accès. Plusieurs tâches de dépannage pouvant
être exécutées existent afin de résoudre les problèmes d'affichage du stockage.

Résolution des problèmes d'affichage de stockage Fibre Channel

Si les périphériques de stockage Fibre Channel ne s'affichent pas correctement dans Client Web vSphere,
effectuez les tâches de résolution de problèmes suivantes.

Tableau 6‑1. Résolution des problèmes d'affichage de LUN Fibre Channel

Tâche de résolution des
problèmes Description

Vérifiez la connectivité du
câble.

Vérifiez le zonage. Le zonage limite l'accès à des périphériques de stockage spécifiques, augmente la

Vérifiez la configuration du
contrôle d'accès.

Vérifiez la configuration du
processeur de stockage.

Réanalysez votre HBA. Réanalysez à chaque fois que vous aurez achevé les tâches suivantes :

Si vous ne voyez pas de port, le problème peut venir de la connectivité du câble. vérifiez
les câbles en priorité. Assurez-vous que les câbles sont connectés aux ports et que la LED
indique une bonne connexion. Si une extrémité d'une câble ne montre pas de LED
positive, remplacez le câble.

sécurité, et diminue le trafic sur le réseau. Certains fournisseurs de stockage n'autorisent
que des zones à initiateur unique. Dans ce cas, un HBA peut se trouver en de multiples
zones vers une cible unique. D'autres fournisseurs autorisent les zones à initiateurs
multiples. Consultez la documentation de votre fournisseur de stockage pour connaître
les conditions de zonage. Utilisez le logiciel du commutateur SAN pour configurer et
administrer le zonage.

Le plug-in MASK_PATH vous permet d'empêcher votre hôte d'accéder à une baie de

n

stockage particulière ou des LUN spécifiques sur une baie de stockage. Si votre hôte
détecte des périphériques et des chemins auxquels vous voulez lui interdire l'accès, il
se peut que le masquage de chemins ne soit pas bien configuré.

Pour démarrer depuis un SAN, assurez-vous que chaque hôte voit uniquement les

n

LUN requis. N'autorisez pas un hôte à voir tout LUN de démarrage autre que le
sien. Utilisez le logiciel du système de stockage pour vérifier que l'hôte ne voit que
les LUN qu'il est censé voir.

Assurez-vous que le paramètre Disk.MaxLUN vous permet de voir les LUN

n

attendus. Pour plus d'informations sur le paramètre, voir la documentation Stockage
vSphere.

Si une baie de disques possède plus d'un seul processeur de stockage (SP), assurez-vous
que le commutateur SAN possède une connexion vers le SP qui gère les LUN auxquels
vous voulez accéder. Dans certaines baies de disques, seul un SP est actif et l'autre reste
passif jusqu'à ce qu'une panne survienne. Si vous êtes connecté au SP incorrect (celui
avec le chemin passif), il est alors possible que vous ne voyiez pas les LUN attendus, ou
que vous voyiez les LUN mais avec des erreurs en tentant d'y accéder.

Créer de nouveaux LUN sur un SAN

n

Modification de la configuration du masquage de chemin sur l'hôte.

n

Reconnecter un câble

n

Modifier un hôte dans un cluster.

n

Pour plus d'informations, voir la documentation Stockage vSphere.

68 VMware, Inc.

Chapitre 6 Dépannage du stockage

Résolution des problèmes d'affichage de stockage iSCSI

Effectuez des tâches de dépannage si les périphériques de stockage iSCSI ne s'affichent pas correctement
dans Client Web vSphere.

Tableau 6‑2. Résolution des problèmes d'affichage de LUN iSCSI

Tâche de résolution des
problèmes Description

Vérifiez la connectivité du
câble.

Vérifiez les paramètres de
routage.

Vérifiez la configuration du
contrôle d'accès.

Vérifiez la configuration du
processeur de stockage.

Pour un iSCSI logiciel et
matériel dépendant, vérifiez
la configuration du réseau.

Réanalysez votre initiateur
iSCSI.

Si vous ne voyez pas de port, le problème peut venir de la connectivité du câble ou du
routage. vérifiez les câbles en priorité. Assurez-vous que les câbles sont connectés aux
ports et que la LED indique une bonne connexion. Si une extrémité d'une câble ne
montre pas de LED positive, remplacez le câble.

Contrôlez la connectivité entre les différents sous-réseaux de votre configuration
ethernet. Si votre système ESXi et votre stockage iSCSI ne se trouvent pas sur le même
sous-réseau, assurez-vous qu'un routage approprié a lieu entre les différents sous­réseaux. Par ailleurs, assurez-vous que le masque de sous-réseau et l'adresse de la
passerelle sont correctement paramétrés sur le stockage iSCSI et l'initiateur iSCSI sur
l'hôte ESXi.

Si les LUN attendus ne s'affichent pas après réanalyse, il se peut que le contrôle d'accès
ne soit pas correctement configuré du côté du système de stockage :

Si CHAP est configuré, assurez-vous qu'il est activé sur l'hôte ESXi, et qu'il

n

correspond à la configuration du système de stockage.
Si un filtrage à base d'IP est utilisé, vérifiez que les adresses IP du HBA iSCSI ou du

n

groupe de ports VMkernel sont autorisées.
Si vous utilisez un filtrage basé sur les noms d'initiateurs, vérifiez que le nom est

n

bien un nom iSCSI qualifié, et qu'il correspond à la configuration du côté stockage.
Pour démarrer depuis un SAN, assurez-vous que chaque hôte voit uniquement les

n

LUN requis. N'autorisez pas un hôte à voir tout LUN de démarrage autre que le
sien. Utilisez le logiciel du système de stockage pour vérifier que l'hôte ne voit que
les LUN qu'il est censé voir.

Assurez-vous que le paramètre Disk.MaxLUN vous permet de voir les LUN

n

attendus. Pour plus d'informations, voir la documentation Stockage vSphere.

Si un système de stockage possède plus d'un seul processeur de stockage, assurez-vous
que le commutateur SAN possède une connexion vers le SP qui gère les LUN auxquels
vous voulez accéder. Dans Certains systèmes de stockage, seul un SP est actif et l'autre
reste passif jusqu'à ce qu'une panne survienne. Si vous êtes connecté au SP incorrect
(celui avec le chemin passif), il est alors possible que vous ne voyiez pas les LUN
attendus, ou que vous voyiez les LUN mais avec des erreurs en tentant d'y accéder.

L'iSCSI logiciel et les adaptateurs dépendants du matériel de ESXi nécessite qu'un port
réseau VMkernel ait accès au stockage iSCSI. Les adaptateurs utilise le VMkernel pour le
transfert des données entre le système ESXi et le stockage iSCSI.

Réanalysez à chaque fois que vous aurez achevé les tâches suivantes :

Créer de nouveaux LUN sur un SAN

n

Modifier le masquage LUN.

n

Reconnecter un câble

n

Modifier un hôte dans un cluster.

n

Modifier les paramètres CHAP ou ajouter de nouvelles adresses à découvrir.

n

Pour plus d'informations, voir la documentation Stockage vSphere.

VMware, Inc. 69

Dépannage vSphere

Résolution des problèmes de performance de SAN

Plusieurs facteurs peuvent affecter d'une manière négative la performance de stockage dans
l'environnement SAN ESXi. Parmi ces facteurs, on trouve trop de réservations SCSI, un écroulement de
chemin et une profondeur de file d'attente LUN inadéquate.

Pour surveiller les performances de stockage en temps réel, utilisez les utilitaires de ligne de commande

resxtop et esxtop. Pour plus d'informations, consultez la documentation Surveillance et performances vSphere .

Trop de réservations iSCSI provoquent une baisse de la performance de l'hôte

Les opérations nécessitant l'obtention d'un verrouillage de fichier ou un verrouillage de métadonnées dans
VMFS provoquent des réservations iSCSI à durée de vie limitée. Les réservations iSCSI verrouillent un LUN
entier. Trop de réservations iSCSI demandées par un hôte peuvent provoquer une dégradation de la
performance sur d'autres serveurs accédant au même VMFS.

Problème

Trop de réservations iSCSI provoquent une dégradation de la performance et des conflits de réservation
iSCSI.

Cause

Plusieurs opérations nécessitent que VMFS utilise des réservations iSCSI.

Création, re-signature ou développement d'une banque de données VMFS

n

Mise sous tension d'une machine virtuelle

n

Création ou suppression d'un fichier

n

Création d'un modèle

n

Déploiement d'une machine virtuelle à partir d'un modèle

n

Création d'une nouvelle machine virtuelle

n

Migration d'une machine virtuelle avec vMotion

n

Extension d'un fichier, tel qu'un disque virtuel légèrement provisionné

n

REMARQUE Les hôtes ESXi utilisent le mécanisme des réservations iSCSI seulement lorsque des
périphériques de stockage ne prennent pas en charge l'accélération matérielle. Dans le cas de périphériques
de stockage qui prennent en charge l'accélération matérielle, les hôtes utilisent le test atomique et définissent
l'algorithme (ATS) afin de verrouiller le LUN. Pour plus d'informations sur l'accélération matérielle, voir la
documentation Stockage vSphere.

Solution

Pour supprimer des sources éventuelles de conflits de réservation iSCSI, respectez les directives suivantes :

Sérialiser les opérations des LUN partagés, si possible, limiter le nombre d'opérations sur différents

n

hôtes qui nécessitent une réservation iSCSI en même temps.

Augmenter le nombre de LUN et limiter le nombre d'hôtes qui accèdent au même LUN.

n

Réduire le nombre d'instantannés. Les instantannés provoquent de nombreuses réservations iSCSI.

n

Réduire le nombre de machines virtuelles par LUN. Suivre les recommandations disponibles dans

n

Configurations maximales.

Vérifier que le dernier microprogramme HBA est installé sur tous les hôtes.

n

Vérifier que l'hôte dispose du dernier BIOS.

n

70 VMware, Inc.

Chapitre 6 Dépannage du stockage

Garantir un bon paramétrage du Host Mode au niveau de la baie SAN.

n

L'écroulement de chemin provoque un ralentissement de l'accès au LUN

Si votre hôte ESXi est dans l'impossibilité d'accéder à un LUN, ou si l'accès est très lent, vous pouvez avoir
un problème avec la fonction d'écroulement de chemin, appelée également écroulement de LUN.

Problème

Votre hôte est dans l'impossibilité d'accéder à un LUN, ou l'accès est très lent. Les fichiers journaux de l'hôte
peuvent indiquer de fréquents changements d'état des chemins.

Cause

Le problème peut provenir de la fonction d'écroulement de chemin. L'écroulement de chemin peut se
produire lorsque deux hôtes accèdent au même LUN par le biais de différents processeurs de stockage (SP)
et, par conséquent, le LUN n'est jamais disponible.

L'écroulement de chemin se produit en général sur des baies actives-passives. L'écroulement de chemin peut
également se produire sur une baie directement connectée au basculement HBA sur un ou plusieurs nœuds.
Les baies actives-actives ou les baies qui offrent des basculements transparents ne provoquent pas
d'écroulement de chemin.

Solution

1 Vérifiez que tous les hôtes qui partagent le même ensemble de LUN sur les baies actives-passives

utilisent le même processeur de stockage.

2 Corrigez toutes les incohérences de câblage ou de masquage entre différents hôtes et cibles SAN de

sorte que tous les HBA voient les mêmes cibles.

3 Vérifiez que les règles de réclamation définies sur tous les hôtes qui partagent les LUN soient

exactement les mêmes.

4 Configurez le chemin pour qu'il utilise le PSP le plus récemment utilisé, qui est celui défini par défaut.

L'augmentation de la latence des demandes d'E/S ralentit les performances de la machine virtuelle

Si l'hôte ESXi génère plus de commandes vers un LUN que la profondeur de la file d'attente du LUN le
permet, le trop plein de commandes est mis en attente dans VMkernel. Cette action augmente la latence ou
le délai de traitement des demandes d'E/S.

Problème

L'hôte met plus de temps pour traiter les demandes d'E/S et les machines virtuelles affichent une
performance non satisfaisante.

Cause

L'origine du problème peut provenir d'une profondeur de file d'attente insuffisante. Les pilotes de
périphérique iSCSI disposent d'un paramètre configurable appelé la profondeur de file d'attente du LUN
qui détermine combien de commandes destinées à un LUN donné peuvent être actives en même temps. Si
l'hôte génère plus de commandes vers un LUN, le trop plein de commandes est mis en attente dans le
VMkernel.

Solution

1 Si la somme des commandes actives provenant de toutes les machines virtuelles dépasse d'une manière

importante la profondeur du LUN, augmentez la profondeur de file d'attente.

La procédure que vous utilisez afin d'augmenter la profondeur de file d'attente dépend du type de
l'adaptateur de stockage qu'utilise l'hôte.

VMware, Inc. 71

Dépannage vSphere

2 Ajustez le paramètre Disk.SchedNumReqOutstanding pour qu'il corresponde à la valeur de la profondeur

de file d'attente.

Ajustement de la profondeur de la file d'attente des HBA Emulex et QLogic

Si vous n'êtes pas satisfait par la performance de votre hôte, modifiez la profondeur de file d'attente
maximale des HBA QLogic ou Emulex.

Pour ajuster le paramètre de profondeur de file d'attente maximale , utilisez les commandes vCLI.

Dans la procédure, --server=server_name spécifie le serveur cible. Le serveur cible spécifié vous invite à
saisir un nom de serveur et un mot de passe. D'autres options de connexion, telles qu'un fichier de
configuration ou de session, sont prises en charge. Pour obtenir la liste des options de connexion, reportez­vous à la rubrique Initiation aux interfaces de ligne de commande vSphere.

Prérequis

Installez vCLI ou déployez la machine virtuelle vSphere Management Assistant (vMA). Reportez-vous à la
section Initiation aux interfaces de ligne de commande vSphere. Pour le dépannage, exécutez les commandes

esxcli dans ESXi Shell.

Procédure

1 Vérifiez le module HBA actuellement chargé en entrant une des commandes suivantes :

Pour QLogic : esxcli --server=server_name system module list |grep qla

n

Pour Emulex : esxcli --server=server_name system module list |grep lpfc

n

2 Ajustez la profondeur de file d'attente du module approprié.

REMARQUE Les exemples présentent les modules QLogic qla2xxx et Emulex lpfc820. Utilisez le module
approprié, selon les résultats de la commande précédente.

Pour QLogic :

n

esxcli --server=server_name system module parameters set -m qla2xxx -p
ql2xmaxqdepth=value

Pour Emulex :

n

esxcli --server=server_name system module parameters set -m lpfc820 -p
lpfc0_lun_queue_depth=value

3 Redémarrez l'hôte.

4 Vérifiez vos modifications en lançant la commande suivante :

esxcli --server=server_name system module parameters list -m=module.

module est votre module QLogic ou Emulex, tel que lpfc820 ou qla2xxx.

Ajustement de la profondeur maximale de file d'attente pour le logiciel iSCSI

Si vous remarquez des performances peu satisfaisantes sur les LUN de votre logiciel iSCSI, vous pouvez
modifier la profondeur maximale de leur file d'attente à l'aide des commandes esxcli.

Prérequis

Installez vCLI ou déployez la machine virtuelle vSphere Management Assistant (vMA). Voir Initiation

n

aux interfaces de ligne de commande vSphere. Pour effectuer des dépannages, vous pouvez exécuter les
commandes esxcli dans ESXi Shell.

72 VMware, Inc.

Chapitre 6 Dépannage du stockage

Au niveau de la procédure, l'option de connexion --serveur=server_name définit le serveur cible. Soyez

n

prêt à entrer un nom utilisateur et un mot de passe lorsque le serveur cible vous y invite. Pour connaître
la liste des autres options de connexion éventuelles, voir Initiation aux interfaces de ligne de commande
vSphere.

Procédure

1 Exécutez la commande suivante :

esxcli --server=server_name system module parameters set -m iscsi_vmk -p
iscsivmk_LunQDepth=value

Le paramètre iscsivmk_LunQDepth définit le nombre maximum de commandes en attente, ou la
profondeur de file d'attente, pour chaque LUN accessible par l'adaptateur iSCSI logiciel. La valeur par
défaut est 128.

2 Redémarrez votre système.

3 Vérifiez vos modifications en exécutant la commande

esxcli --server=server_name system module parameters list -m iscsi_vmk.

AVERTISSEMENT Définir une profondeur de file d'attente supérieure à celle par défaut peut diminuer le
nombre total de LUN pris en charge.

Modifier le nombre maximum de requêtes de disque en attente dans Client Web vSphere

Si vous avez ajusté la longueur de la file d'attente LUN, modifiez la valeur du paramètre

Disk.SchedNumReqOutstanding afin qu'elle corresponde à la profondeur de file d'attente. Le paramètre

contrôle le nombre maximal de demandes en attente que toutes les machines virtuelles peuvent émettre vers
la LUN.

Modifiez ce paramètre uniquement lorsque vous avez plusieurs machines virtuelles actives sur un LUN. Le
paramètre ne s'applique pas lorsqu'une seule machine virtuelle est active. Dans ce cas, la bande passante est
contrôlée par la longueur de la file d'attente de l'adaptateur de stockage.

Procédure

1 Accédez à l'hôte dans le navigateur d'objets de Client Web vSphere.

2 Cliquez sur l'onglet Gérer puis sur Paramètres.

3 Dans Système, cliquez sur Paramètres système avancés.

4 Accédez à Disk.SchedNumReqOutstanding et cliquez sur l'icône Modifier.

5 Modifiez sa valeur selon vos besoins, puis cliquez sur OK.

Les machines virtuelles dotées de RDM doivent ignorer la mise en cache SCSI INQUIRY

Les fournisseurs de stockage peuvent demander que les machines virtuelles dotées de RDM (matériel
version 8) ignorent les données SCSI INQUIRY mises en cache par ESXi.

Problème

Certains systèmes d'exploitation invités ou certaines applications s'exécutant sur des machines virtuelles
dotées de RDM font état d'un comportement imprévisible.

VMware, Inc. 73

Dépannage vSphere

Cause

Ce comportement peut provenir des données SCSI INQUIRY mises en cache qui interfèrent avec les
applications et les systèmes d'exploitation invités particuliers.

Lorsque l'hôte ESXi se connecte d'abord à un périphérique de stockage sur un SAN, il lance la commande
SCSI INQUIRY pour obtenir des données d'identification de base à partir du périphérique. Par défaut ESXi
met en cache les données SCSI INQUIRY reçues (Standard, page 80 et page 83) et les données restent par la
suite inchangées.

Solution

Configurez la machine virtuelle dotée de RDM afin d'ignorer la mise en cache de SCSI INQUIRY en

u

ajoutant le paramètre suivant au fichier .vmx.

scsix:y.ignoreDeviceInquiryCache = "true"

où x est le nombre de contrôleurs SCSI et y le nombre cible SCSI du RDM.

Ce paramètre étant configurable uniquement sur des machines virtuelles dotées de matériel version 8,
mettez à niveau la machine virtuelle avant d'ajouter le paramètre.

Activez ce paramètre seulement lorsque votre fournisseur de stockage vous recommande de le faire. Ce
paramètre est nécessaire juste pour un nombre limité de baies de stockage et uniquement pour des
systèmes d'exploitation invités particuliers.

L'adaptateur iSCSI logiciel est désactivé lorsqu'il n'est pas nécessaire

Lorsque votre hôte utilise un adaptateur réseau avec iBFT, l'adaptateur iSCSI logiciel est toujours par défaut
désactivé.

Problème

Après le premier démarrage de votre hôte ESXi, l'adaptateur iSCSI logiciel est activé et apparaît dans
Client Web vSphere sur la liste des adaptateurs de stockage.

Cause

L'adaptateur réseau iBFT activé sur votre hôte induit la présence continue du logiciel iSCSI. Cette condition
se produit même lorsque vous n'utilisez pas iBFT pour le démarrage d'iSCSI.

Solution

Si vous n'utilisez pas l'adaptateur réseau iBFT activé pour le démarrage d'iSCSI et ne souhaitez pas que
l'adaptateur iSCSI logiciel soit activé, supprimez la configuration iBFT de l'adaptateur réseau. Ce processus
étant propre au fournisseur, consultez la documentation de votre fournisseur pour de plus d'informations.

Echec dans le montage des banques de données NFS

Les tentatives de montage des banques de données NFS avec des noms en langues étrangères se soldent par
des échecs.

Problème

L'utilisation de caractères non-ASCII pour désigner des noms de fichier et de dossier au niveau du stockage
NFS peut provoquer un comportement imprévisible. Par exemple, vous pouvez ne pas réussir à monter une
banque de données ou mettre sous tension une machine virtuelle.

74 VMware, Inc.

Chapitre 6 Dépannage du stockage

Cause

ESXi prend en charge l'utilisation de caractères non-ASCII pour désigner les noms de dossier et de fichier au
niveau du stockage NFS, ainsi vous pouvez créer des banques de données et des machines virtuelles en
utilisant des noms en langues étrangères. Toutefois, lorsque le serveur NFS sous-jacent n'offre pas de
support d'internationalisation, des échecs imprévisibles peuvent se produire.

Solution

Vérifiez toujours que le serveur NFS sous-jacent offre un support d'internationalisation. Si le serveur ne le
peut pas, utilisez uniquement des caractères ASCII.

Les fichiers journaux VMkernel contiennent des codes de détection SCSI

Certains messages VMkernel associés au stockage peuvent contenir des codes de détection SCSI.

Problème

Lorsque vous analysez les fichiers journaux des hôtes ESXi(/var/log/vmkernel), vous rencontrez des
événements ou des messages d'erreur qui contiennent des codes de détection SCSI.

Solution

La compréhension de ces codes de détection SCSI permet de mieux maîtriser les problèmes dans votre
environnement de stockage. Comme les valeurs des codes de détection SCSI sont attribuées par le comité
T10, consultez la documentation relative aux normes T10 pour connaître la signification des codes. Cette
rubrique explique comment utiliser la documentation T10 pour interpréter les codes de détection SCSI.

Exemple : Interprétation des codes de détection SCSI

Voici un exemple de message d'erreur SCSI qui apparaît dans le fichier journal ESXi :

2011-04-04T21:07:30.257Z cpu2:2050)ScsiDeviceIO: 2315: Cmd(0x4124003edb00) 0x12, CmdSN 0x51 to
dev "naa.600508XXXXXXXXXXXXX" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0

Dans cet exemple, les codes de détection SCSI sont représentés par deux champs, H:0x0 D:0x2 P:0x0 et 0x5

0x25 0x0.

Le premier champ, H:0x0 D:0x2 P:0x0, est une combinaison de codes d'état SCSI pour les trois composants
de l'environnement de stockage, à savoir l'hôte, le périphérique et le plug-in. Le code d'état SCSI est utilisé
pour déterminer le succès ou l'échec d'une commande SCSI. Pour interpréter chaque code d'état SCSI,
consultez http://www.t10.org/lists/2status.htm.

REMARQUE Les valeurs hexadécimales dans la documentation T10 utilisent le format NNNh, alors que les
codes de détection SCSI dans les fichiers journaux ESXi ESXi ont le format 0xNNN. Par exemple, 0x2 = 02h.

Vous obtenez l'interprétation suivante pour le champ d'état de l'exemple ci-dessus : H:0x0 D:0x2 P:0x0 =

H(host):GOOD D(device):CHECK CONDITION P(plug-in):GOOD.

Le second champ dans un message d'erreur SCSI typique fournit des informations plus détaillées sur
l'erreur. Il s'agit d'une combinaison des paramètres clé de détection (sense), code de détection
supplémentaire (asc) et qualificateur du code de détection supplémentaire (ascq).

Par exemple, le champ 0x5 0x25 0x0 du message d'erreur ci-dessus peut être représenté sous la forme

sense=5 asc=25 ascq=0.

Pour interpréter les clés de détection, consultez http://www.t10.org/lists/2sensekey.htm.

VMware, Inc. 75

Dépannage vSphere

Pour connaître la signification du code de détection supplémentaire (asc) et du qualificateur du code de
détection supplémentaire (ascq), utilisez les codes ensemble. Consultez http://www.t10.org/lists/2asc.htm
pour plus d'informations.

Vous devez obtenir l'interprétation suivante pour le champ 0x5 0x25 0x0 :

sense=5 (ILLEGAL REQUEST), ASC=25 ASCQ=0 (LOGICAL UNIT NOT SUPPORTED)

Dépannage des adaptateurs de stockage

Si vos adaptateurs de stockage rencontrent des problèmes de performance, utilisez les commandes esxcli

storage san pour identifier les problèmes.

Problème

Les adaptateurs de stockage rencontrent un problème de performance et d'E/S.

Solution

Utilisez les commandes esxcli storage san pour obtenir et afficher des événements et des statistiques
concernant les adaptateurs. Vous pouvez analyser la sortie des commandes pour identifier les problèmes
d'adaptateur et trouver des solutions adéquates.

Tableau 6‑3. Commandes esxcli storage san

Commande Description Options

esxcli storage san [FC |
iSCSI | FCoE | SAS] list

esxcli storage san [FC |
iSCSI | FCoE | SAS] stats
get

esxcli storage san [FC |
FCoE | SAS] reset

esxcli storage san fc
events get

Répertorier les attributs des adaptateurs.
REMARQUE iSCSI ne s'applique qu'aux logiciels iSCSI.

Récolter des statistiques relatives aux adaptateurs.
REMARQUE iSCSI ne s'applique qu'aux logiciels iSCSI.

Réinitialiser un adaptateur particulier. -- adaptateur | -A

Récupérer des événements pour les adaptateurs Fibre
Channel.

-- adapter | -A
Nom de l'adaptateur

(vmhbaX), ou aucun, pour
répertorier les informations
relatives à tous les
adaptateurs de ce type
particulier.

-- adaptateur | -A
Nom de l'adaptateur

(vmhbaX), ou aucun, pour
répertorier les informations
relatives à tous les
adaptateurs de ce type
particulier.

Nom de l'adaptateur
(vmhbaX).

-- adaptateur | -A
Nom de l'adaptateur

(vmhbaX), ou aucun, pour
répertorier les informations
relatives à tous les
adaptateurs Fibre Channel
du système.

76 VMware, Inc.

Chapitre 6 Dépannage du stockage

Vérification de la cohérence des métadonnées avec VOMA

Utilisez VMware Ondisk Metadata Analyser (VOMA) lorsque vous rencontrez des problèmes avec votre
banque de données VMFS et que vous avez besoin de vérifier la cohérence des métadonnées de VMFS ou un
volume logique qui prend en charge le volume VMFS.

Problème

Les exemples suivants montrent les circonstances dans lesquelles vous pouvez avoir besoin d'effectuer une
vérification des métadonnées :

Vous rencontrez des pannes SAN.

n

Après avoir reconstruit RAID ou effectué un remplacement de disque.

n

Vous constatez des erreurs de métadonnées dans le fichier vmkernel.log.

n

Vous ne parvenez pas à accéder aux fichiers de la banque de données VMFS qui ne sont pas utilisés par

n

un autre hôte.

Solution

Pour vérifier la cohérence des métadonnées, exécutez VOMA à partir de l'interface de ligne de commande
d'un hôte ESXi version 5.1 ou ultérieure. VOMA peut vérifier à la fois le volume logique et le VMFS pour les
incohérences de métadonnées. Vous pouvez utiliser VOMA sur les banques de données VMFS3 et VMFS5.
VOMA fonctionne dans un mode lecture seule et ne sert qu'à identifier les problèmes. VOMA ne corrige pas
les erreurs qu'il détecte. Consultez le support VMware pour résoudre les erreurs signalées par VOMA.

Suivez ces directives lors de l'utilisation de l'outil VOMA :

Assurez-vous que les banques de données VMFS que vous analysez ne s'étendent pas sur plusieurs

n

extensions. Vous ne pouvez exécuter VOMA que sur une extension unique de la banque de données.

Mettez hors tension les machines virtuelles en cours d'exécution ou déplacez-les vers une autre banque

n

de données.

Suivez ces étapes lorsque vous utilisez l'outil VOMA pour vérifier la cohérence des métadonnées VMFS.

1 Obtenez le nom et le numéro de la partition du périphérique qui prend en charge la banque de données

VMFS que vous devez vérifier.

Liste étendue vmfs de stockage #esxcli

Les colonnes Nom périphérique et Partition dans la sortie identifient le périphérique. Par exemple :

Volume Name XXXXXXXX Device Name Partition
1TB_VMFS5 XXXXXXXX naa.600508e000000000b367477b3be3d703 3

2 Exécutez VOMA pour vérifier les erreurs VMFS.

Indiquez le chemin absolu de la partition du périphérique qui prend en charge la banque de données
VMFS et entrez un numéro de partition avec le nom du périphérique. Par exemple :

# voma -m vmfs -f check -d /vmfs/devices/disks/naa.600508e000000000b367477b3be3d703:3

La sortie répertorie les erreurs possibles. Par exemple, la sortie suivante indique que l'adresse de signal
de pulsation n'est pas valide.

XXXXXXXXXXXXXXXXXXXXXXX
Phase 2: Checking VMFS heartbeat region
ON-DISK ERROR: Invalid HB address
Phase 3: Checking all file descriptors.

VMware, Inc. 77

Dépannage vSphere

Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.

Total Errors Found: 1

L'outil VOMA utilise les options suivantes.

Tableau 6‑4. Options de commande VOMA

Option de commande Description

-m | --module Module à exécuter : vmfs ou lvm. Si vous spécifiez vmfs,

-f | --func

-d|--device

-s | --logfile

-v | --version

-h|--help

les vérifications minimales sont également effectuées pour
LVM. Le module par défaut est vmfs.

Fonctions à exécuter :

query - fonctions de liste prises en charge par le module.
check - recherche des erreurs.

Périphérique ou disque à inspecter. Assurez-vous de
fournir le chemin absolu de la partition du périphérique
qui prend en charge la banque de données VMFS. Par
exemple, /vmfs/devices/disks/naa.
00000000000000000000000000:1.

Spécifiez le fichier journal pour générer les résultats.

Afficher la version de VOMA.

Afficher le message d'aide de la commande VOMA.

Dépannage des disques SSD (Solid-State Drives)

vSphere utilise des disques SSD (Solid-State Drives) pour les fonctionnalités de stockage telles que Virtual
SAN, le cache d'échange d'hôte et Flash Read Cache.

Les rubriques de dépannage des SSD peuvent vous aider à éviter d'éventuels problèmes et à trouver des
solutions aux problèmes que vous pouvez rencontrer lors de la configuration de SSD.

Les SSD locaux ne sont pas disponibles pour une utilisation avec Virtual SAN ou Virtual Flash

Un SSD local n'est plus disponible pour la configuration d'une ressource Virtual Flash ou d'un réseau
Virtual SAN lorsqu'il est formaté avec VMFS ou un autre système de fichiers.

Problème

Lorsque vous tentez de configurer un réseau Virtual SAN ou une ressource Virtual Flash, un disque SSD
local n'apparaît pas dans la liste des disques à utiliser.

Cause

Ce problème peut se produire lorsqu'un SSD local conçu pour être utilisé avec l'une de ces fonctionnalités a
déjà été formaté avec VMFS. Un réseau Virtual SAN et une ressource Virtual Flash ne peuvent pas partager
le disque SSD avec VMFS ou avec un autre système de fichiers.

De plus, étant donné que Virtual Flash et Virtual SAN sont des consommateurs mutuellement exclusifs de
disques SSD, les deux fonctionnalités ne peuvent pas partager le même disque SSD. Si le SSD est déjà
réclamé par une fonctionnalité, par exemple par Virtual SAN, vous ne pouvez pas l'utiliser pour une autre
fonctionnalité, telle que Virtual Flash, sauf si vous libérez le disque.

78 VMware, Inc.

Chapitre 6 Dépannage du stockage

Solution

Utilisez uniquement des disques SSD non formatés pour configurer des ressources Virtual Flash et des
réseaux Virtual SAN.

Évitez de formater le disque SSD avec VMFS pendant l'installation d'ESXi ou avec Auto Deploy.

n

Reportez-vous à la section « Empêcher le formatage du SSD lors du partitionnement automatique »,
page 79.

Si le SSD est déjà formaté avec VMFS, supprimez la banque de données VMFS. Pour plus

n

d'informations, consultez la documentation Stockage vSphere.

Pour utiliser le disque SSD en tant que ressource Virtual Flash, ne réclamez pas ce disque pour Virtual

n

SAN. Si le disque est réclamé par Virtual SAN, supprimez-le de Virtual SAN. Le SSD, libéré par Virtual
SAN, devient alors disponible dans la liste des disques à utiliser avec Virtual Flash. Pour plus
d'informations sur la suppression de disques de Virtual SAN, consultez la documentation Stockage
vSphere.

Si vous prévoyez d'utiliser le SSD avec Virtual SAN, n'utilisez pas le disque pour une ressource Virtual

n

Flash. Si le SSD est utilisé comme ressource Virtual Flash, supprimez la configuration de la ressource
Virtual Flash. Le disque devient alors disponible pour Virtual SAN. Voir la documentation Stockage
vSphere.

Il est possible qu'un disque SSD ne soit pas disponible, car ESXi ne le reconnaît pas. Reportez-vous à

« Impossible de détecter les SSD locaux », page 80.

Empêcher le formatage du SSD lors du partitionnement automatique

Lorsque vous installez ESXi ou que vous utilisez Auto Deploy pour provisionner les hôtes, vous pouvez
activer l'option de démarrage avec partitionnement automatique afin de créer des partitions sur l'hôte. Il
existe plusieurs possibilités pour éviter que le partitionnement automatique ne formate des disques SSD
locaux en VMFS.

Problème

Par défaut, le partitionnement automatique déploie les systèmes de fichiers VMFS sur tous les disques de
stockage locaux inutilisés sur l'hôte, y compris les disques SSD.

Cependant, si un disque SSD est au format VMFS, il devient indisponible pour des fonctionnalités telles que
Virtual Flash et Virtual SAN. Ces dernières requièrent un disque SSD non formaté et ne permettent pas le
partage du disque avec un autre système de fichiers.

Solution

Pour utiliser le partitionnement automatique tout en vous assurant que les disques SSD locaux ne sont pas
partitionnés, utilisez les options de démarrage suivantes lors de la première installation d'ESXi ou du
premier démarrage de l'hôte ESXi :

autoPartition=TRUE

n

skipPartitioningSsds=TRUE

n

Si vous utilisez Auto Deploy, définissez ces paramètres sur un hôte de référence.

1 Dans vSphere Web Client, sélectionnez l'hôte à utiliser en tant qu'hôte de référence et cliquez sur Gérer.

2 Cliquez sur Paramètres.

3 Cliquez sur Système pour ouvrir les options système, puis cliquez sur Paramètres système avancés.

4 Faites défiler jusqu'à VMkernel.Boot.autoPartition et définissez la valeur sur True.

5 Faites défiler jusqu'à VMkernel.Boot.skipPartitioningSsds et définissez la valeur sur True.

VMware, Inc. 79

Dépannage vSphere

6 Redémarrez l'hôte.

Si des disques SSD que vous prévoyez d'utiliser avec Flash Read Cache et Virtual SAN disposent déjà de
banques de données VMFS, supprimez ces dernières.

Impossible de détecter les SSD locaux

Si vous recherchez des SSD locaux lors de la création d'une ressource Virtual Flash ou d'une configuration
Virtual SAN, il se peut que l'hôte ESXi ne renvoie pas la liste complète des SSD locaux.

Problème

Il se peut qu'ESXi ne parvienne pas à détecter automatiquement les SSD ni à les reconnaître comme disques
locaux.

Cause

ESXi ne reconnaît pas certains périphériques comme des SSD lorsque leurs fournisseurs ne prennent pas en
charge la détection automatique des SSD. Dans d'autres cas, certains SSD SAS non-SATA peuvent ne pas
être détectés en tant que disques locaux. Lorsque des disques ne sont pas reconnus en tant que SSD locaux,
ils sont exclus de la liste des SSD disponibles pour les fonctionnalités qui ne requièrent que des SSD locaux.

Solution

Il peut être nécessaire de marquer manuellement des disques comme disques SSD ou locaux.

Si ESXi ne reconnaît pas automatiquement ses disques en tant que disques SSD, marquez-les comme

n

disques SSD. Reportez-vous à « Marquer les périphériques comme SSD », page 80.

Si ESXi ne détecte pas les disques SSD comme étant locaux, définissez-les manuellement comme

n

disques locaux. Reportez-vous à « Marquer les périphériques comme local », page 81.

Marquer les périphériques comme SSD

Vous pouvez utiliser des règles de réclamation PSA SATP pour marquer des périphériques SSD qui ne sont
pas détectés automatiquement.

Seuls les périphériques qui sont consommés par le plugin NMP (Native Multipathing) PSA peuvent être
marqués.

Si vous avez besoin d'autres informations sur les commandes répertoriées dans cette rubrique, consultez la
documentation Initiation aux interfaces de ligne de commande vSphere et Concepts et exemples de l'interface de ligne
de commande vSphere.

Procédure

1 Identifiez le périphérique à marquer et son SATP.

esxcli storage nmp device list

La commande donne l'information suivante.

naa.6006016015301d00167ce6e2ddb3de11
Device Display Name: DGC Fibre Channel Disk (naa.6006016015301d00167ce6e2ddb3de11)
Storage Array Type: VMW_SATP_CX
Storage Array Type Device Config: {navireg ipfilter}
Path Selection Policy: VMW_PSP_MRU
Path Selection Policy Device Config: Current Path=vmhba4:C0:T0:L25
Working Paths: vmhba4:C0:T0:L25

2 Noter le SATP associé au périphérique.

80 VMware, Inc.

Chapitre 6 Dépannage du stockage

3 Ajoutez une règle de réclamation PSA pour marquer le périphérique comme SSD.

Vous pouvez ajouter une règle de réclamation en spécifiant le nom du périphérique.

u

esxcli storage nmp satp rule add -s SATP --device device_name --option="enable_ssd"

Vous pouvez ajouter une règle de réclamation en spécifiant le nom du fournisseur et le nom du

u

modèle.

esxcli storage nmp satp rule add -s SATP -V vendor_name -M model_name -­option="enable_ssd"

Vous pouvez ajouter une règle de réclamation basée sur le protocole de transport.

u

esxcli storage nmp satp rule add -s SATP --transport transport_protocol -­option="enable_ssd"

Vous pouvez ajouter une règle de réclamation basée sur le nom du pilote.

u

esxcli storage nmp satp rule add -s SATP --driver driver_name --option="enable_ssd"

4 Réclamer le périphérique.

esxcli storage core claiming reclaim --device device_name

5 Vérifiez si les périphériques sont marqués comme SSD.

esxcli storage core device list -d device_name

Le résultat de la commande indique si un périphérique répertorié est marqué comme SSD.

Is SSD: true

Suivant

Si le périphérique SSD que vous voulez marquer est partagé entre de multiples hôtes, vérifiez si vous
marquez le périphérique depuis tous les hôtes qui partagent le périphérique.

Marquer les périphériques comme local

ESXi vous permet de marquer des périphériques comme local. Cela est utile dans les cas où ESXi ne peut
pas déterminer si certains périphériques SAS sont locaux ou distants.

Pour plus d'informations sur les commandes répertoriées dans cette rubrique, consultez les documentations

Initiation aux interfaces de ligne de commande vSphere et Concepts et exemples de l'interface de ligne de commande
vSphere.

Prérequis

Assurez-vous que le périphérique n'est pas partagé.

n

Mettez hors tension les machines virtuelles résidant sur le périphérique et démontez une banque de

n

données associée.

VMware, Inc. 81

Dépannage vSphere

Procédure

1 Identifiez le périphérique à marquer et son SATP :

esxcli storage nmp device list

Vous pouvez obtenir un résultat semblable à ce qui suit :

naa.000000000000000001234
Device Display Name: DGC Fibre Channel Disk (naa.000000000000000001234)
Storage Array Type: VMW_SATP_CX
Storage Array Type Device Config: {navireg ipfilter}
Path Selection Policy: VMW_PSP_MRU
Path Selection Policy Device Config: Current Path=vmhba4:C0:T0:L25
Working Paths: vmhba4:C0:T0:L25

2 Noter le SATP associé au périphérique.

3 Exécutez cette commande pour ajouter une règle de réclamation PSA permettant de marquer les

périphériques comme locaux. Utilisez le SATP associé au périphérique à partir du résultat dans Étape 1.

esxcli storage nmp satp rule add -s SATP_name --device device_name --option="enable_local"

Par exemple,

esxcli storage nmp satp rule add -s VMW_SATP_CX --device naa.000000000000000001234 -­option="enable_local"

4 Réclamer le périphérique. Par exemple,

esxcli storage core claiming reclaim --device naa.000000000000000001234

5 Vérifiez l'état en exécutant la commande suivante :

esxcli storage core device list -d device_name

Le résultat de la commande indique que le disque est local.

Is Local: true

Dépannage de Virtual SAN

En cas de problème lors de l'utilisation de Virtual SAN, vous pouvez utiliser les rubriques de dépannage.
Elles vous aident à comprendre le problème et vous apportent une solution, s'il en existe une.

Utilisation des commandes esxcli avec Virtual SAN

Utilisez les commandes esxcli pour obtenir des informations sur Virtual SAN et dépanner votre
environnement de Virtual SAN.

Voici les commandes disponibles :

Commande Description

esxcli vsan network list Permet de vérifier quels sont les adaptateurs VMkernel utilisés pour la communication avec

Virtual SAN.

esxcli vsan storage list Permet d'obtenir la liste des disques de stockage réclamés par Virtual SAN.

esxcli vsan cluster get Permet d'obtenir des informations sur le cluster de Virtual SAN.

82 VMware, Inc.

Chapitre 6 Dépannage du stockage

La configuration de Virtual SAN sur un hôte ESXi peut échouer

Dans certaines circonstances, la configuration de Virtual SAN peut échouer sur un hôte particulier.

Problème

La configuration de Virtual SAN échoue sur un hôte ESXi rejoignant un cluster de Virtual SAN.

Cause

Si un hôte ne remplit pas les conditions matérielles requises ou rencontre d'autres problèmes, il est possible
que la configuration de Virtual SAN échoue sur cet hôte. Par exemple, cela peut se produire si l'hôte dispose
d'une mémoire insuffisante.

Solution

1 Placez l'hôte qui pose problème en mode de maintenance.

2 Retirez l'hôte du cluster de Virtual SAN.

3 Corrigez le problème qui empêche la configuration de Virtual SAN sur l'hôte.

4 Quittez le mode de maintenance

5 Réintégrez l'hôte dans le cluster de Virtual SAN.

Les objets de machines virtuelles non conformes ne deviennent pas conformes immédiatement

Lorsque vous utilisez le bouton Vérifier la conformité, un objet de machine virtuelle ne change pas son état
de Non conforme à Conforme même si des ressources de Virtual SAN sont devenues disponibles et
répondent au profil de la machine virtuelle.

Problème

Lorsque vous utilisez une option de provisionnement forcé, vous pouvez provisionner un objet de machine
virtuelle même lorsque la stratégie spécifiée dans le profil de la machine virtuelle est impossible à satisfaire
avec les ressources actuellement disponibles dans le cluster de Virtual SAN. L'objet est créé, mais demeure
dans l'état non conforme.

Le Virtual SAN doit normalement rétablir la conformité de l'objet dès que les ressources de stockage dans le
cluster deviennent disponibles, par exemple lorsque vous ajoutez un hôte. Cependant, l'état de l'objet ne
change pas à Conforme immédiatement après l'ajout de ressources.

Cause

Cela se produit car le Virtual SAN régule le rythme de la reconfiguration pour éviter de surcharger le
système. Le temps requis pour obtenir la conformité varie selon le nombre d'objets dans le cluster, la charge
d'E/S sur le cluster et la taille de l'objet concerné. Dans la plupart des cas, la conformité est obtenue dans un
délai raisonnable.

VMware, Inc. 83

Dépannage vSphere

Problèmes de configuration du cluster de Virtual SAN

Après avoir modifié la configuration de Virtual SAN, vCenter Server effectue des contrôles de validation
pour la configuration de Virtual SAN. Les contrôles de validation sont également effectués dans le cadre
d'un processus de synchronisation des hôtes. Si vCenter Server détecte des problèmes de configuration, il
affiche des messages d'erreur.

Problème

Un certain nombre de messages d'erreur indiquent que vCenter Server a détecté un problème de
configuration de Virtual SAN.

Solution

Utilisez les méthodes suivantes pour corriger les problèmes de configuration de Virtual SAN.

Tableau 6‑5. Erreurs de configuration de Virtual SAN et solutions

Erreur de configuration de Virtual SAN Solution

L'hôte sur lequel le service VSAN est activé n'est pas dans
le cluster vCenter

L'hôte est dans un cluster VSAN, mais n'a pas le service
VSAN activé

Le réseau VSAN n'est pas configuré Configurez Virtual SAN. Consultez la section Configurer la

L'hôte ne peut communiquer avec aucun des autres nœuds
du cluster pour lequel VSAN est activé

Un autre hôte participant au service VSAN a été détecté
comme n'étant pas membre du cluster vCenter de cet hôte.

Ajoutez l'hôte au cluster de Virtual SAN.
1 Cliquez avec le bouton droit de la souris sur l'hôte et

sélectionnez Déplacer vers.

2 Sélectionnez le cluster de Virtual SAN, puis cliquez sur

OK.

Vérifiez si Virtual SAN est correctement configuré et activé
sur l'hôte. Consultez la section Conditions requises et
meilleures pratiques pour la mise en réseau Virtual SAN
dans la documentation Stockage vSphere.

mise en réseau pour Virtual SAN dans la documentation
Stockage vSphere.

Peut provenir de l'isolement réseau. Consultez la section
Conditions requises et meilleures pratiques pour la mise en
réseau Virtual SAN dans la documentation Stockage
vSphere.

Assurez-vous que la configuration du cluster de Virtual
SAN est correcte et que tous les hôtes de Virtual SAN se
trouvent dans le même sous-réseau. Consultez la section
Conditions requises et meilleures pratiques pour la mise en
réseau Virtual SAN dans la documentation Stockage
vSphere.

84 VMware, Inc.

Résolution des problèmes de mise en

réseau 7

Les rubriques de dépannage concernant la mise en réseau dans vSphere proposent des solutions aux
problèmes potentiels qui peuvent apparaître avec la connectivité des hôtes ESXi, vCenter Server et des
machines virtuelles.

Ce chapitre aborde les rubriques suivantes :

« Adresses MAC dupliquées de machines virtuelles appartenant à un même réseau », page 86

n

« Échec de la conversion vers la prise en charge étendue du protocole LACP », page 88

n

« Impossible de supprimer un hôte d'un vSphere Distributed Switch », page 89

n

« Les hôtes d'un vSphere Distributed Switch 5.1 (et versions ultérieures) perdent la connectivité à

n

vCenter Server », page 90

« Les hôtes de vSphere Distributed Switch 5.0 et versions antérieures perdent leur connectivité à

n

vCenter Server », page 92

« Alarme indiquant une perte de redondance du réseau sur un hôte », page 93

n

« Les machines virtuelles perdent leur connectivité après la modification de l'ordre de basculement

n

des liaisons montantes d'un groupe de ports distribués », page 94

VMware, Inc.

« Une machine virtuelle exécutant un client VPN provoque un déni de service pour les machines

n

virtuelles sur l'hôte ou sur un cluster vSphere HA », page 95

« Faible débit pour les charges de travail UDP sur des machines virtuelles Windows », page 97

n

« Des machines virtuelles situées dans un même groupe de ports distribués, mais sur des hôtes

n

différents, ne peuvent pas communiquer entre elles », page 99

« Une machine virtuelle qui utilise une fonction virtuelle SR-IOV est mise hors tension, car l'hôte n'a

n

plus de vecteurs d'interruption », page 99

« Les tentatives de mise sous tension d'un vApp migré échouent, car le profil de protocole associé est

n

manquant », page 100

« Restauration d'une opération de configuration de mise en réseau et déconnexion d'un hôte de

n

vCenter Server », page 101

85

Dépannage vSphere

Adresses MAC dupliquées de machines virtuelles appartenant à un même réseau

Vous rencontrez des problèmes de pertes de paquets et de connectivité, car vCenter Server génère des
adresses MAC dupliquées pour les machines virtuelles.

Problème

Les adresses MAC des machines virtuelles d'un même domaine de diffusion ou sous-réseau IP sont en
conflit ou vCenter Server génère une adresse MAC dupliquée pour une machine virtuelle récemment qui
vient d'être créée.

Une machine virtuelle se met sous tension et fonctionne correctement, mais partage son adresse MAC avec
une autre machine virtuelle. Ce cas de figure peut entraîner des pertes de paquets et d'autres problèmes.

Cause

La duplication des adresses MAC des machines virtuelles peut être causée par plusieurs raisons.

Deux instances de vCenter Server dont les ID sont identiques provoquent un chevauchement des

n

adresses MAC des adaptateurs réseau des machines virtuelles.

Chaque instance de vCenter Server dispose d'un ID compris entre 0 et 63 qui est généré de manière
aléatoire lors de l'installation, mais qui peut être reconfiguré une fois celle-ci terminée. vCenter Server
utilise l'ID de l'instance pour générer des adresses MAC pour les adaptateurs réseau de la machine.

Une machine virtuelle a été transférée d'une instance de vCenter Server vers une autre au sein d'un

n

même réseau, et un nouvel adaptateur réseau de machine virtuelle sur la première instance de
vCenter Server reçoit l'adresse MAC libérée.

Solution

Modifiez manuellement l'adresse MAC de l'adaptateur réseau de machine virtuelle.

n

Si une machine virtuelle existante comporte une adresse MAC qui est en conflit, vous devez fournir une
adresse MAC unique dans les paramètres Matériel virtuel.

Mettez la machine virtuelle hors tension, configurez l'adaptateur de sorte à utiliser une adresse

n

MAC manuelle, puis entrez la nouvelle adresse.

Si vous ne pouvez pas mettre la machine virtuelle hors tension pour la configurer, recréez

n

l'adaptateur réseau qui est en conflit en activant l'attribution manuelle d'adresses MAC, puis entrez
la nouvelle adresse. Dans le système d'exploitation invité, attribuez la même adresse IP statique
qu'avant à l'adaptateur que vous venez de créer.

Pour plus d'informations sur la configuration des adaptateurs réseau des machines virtuelles, reportez­vous à la documentation Mise en réseau vSphere et Administration d'une machine virtuelle vSphere.

86 VMware, Inc.

Chapitre 7 Résolution des problèmes de mise en réseau

Si l'instance de vCenter Server génère les adresses MAC des machines virtuelles en fonction de leur

n

allocation par défaut, VMware OUI, modifiez l'ID de l'instance de vCenter Server ou utilisez une autre
méthode d'allocation pour résoudre les conflits.

REMARQUE La modification de l'ID de l'instance de vCenter Server ou l'utilisation d'un autre modèle
d'allocation ne résout pas les conflits d'adresses MAC sur les machines virtuelles existantes. Seules les
machines virtuelles créées ou les adaptateurs réseau ajoutés après la modification reçoivent des
adresses conformes au nouveau modèle.

Pour plus d'informations sur la configuration et les modèles d'allocation d'adresses MAC, reportez­vous à la documentation Mise en réseau vSphere.

Solution Description

Modifier l'ID de vCenter Server

Passer à l'allocation par préfixe

Vous pouvez continuer à utiliser le modèle d'allocation VMware OUI si
votre déploiement concerne un petit nombre d'instances de
vCenter Server. Selon ce modèle, le format d'une adresse MAC est le
suivant :

00:50:56:XX:YY:ZZ

où 00:50:56 représente le VMware OUI, XX est une valeur calculée selon
la formule « 80 + ID de vCenter Server » et YY:ZZ est un nombre aléatoire.

Pour modifier l'ID de vCenter Server, configurez l'option ID unique de
vCenter Server, située dans la section Paramètres d'exécution des
paramètres Général de l'instance de vCenter Server, puis redémarrez cette
dernière.

L'allocation VMware OUI fonctionne avec un maximum de 64 instances de
vCenter Server et convient aux déploiements à petite échelle.

Vous pouvez utiliser un OUI personnalisé. Par exemple, pour une plage
d'adresses administrées localement 02:12:34, les adresses MAC sont au
format 02:12:34:XX:YY:ZZ. Vous pouvez utiliser le quatrième octet XX
pour répartir l'espace d'adresses OUI entre les différentes instances de
vCenter Server. Cette structure engendre 255 clusters d'adresse, chacun
d'eux étant géré par une instance de vCenter Server, et environ
65 000 adresses MAC par vCenter Server. Par exemple,
02:12:34:01:YY:ZZ pour vCenter Server A, 02:12:34:02:YY:ZZ pour
vCenter Server B, et ainsi de suite.

L'allocation par préfixe convient aux déploiements à plus grande échelle.
Si vous souhaitez des adresses MAC qui soient uniques au niveau

mondial, il faut enregistrer l'OUI auprès de l'association IEEE.

a Configurez l'allocation d'adresses MAC.

b Appliquez le nouveau modèle d'allocation d'adresses MAC à une machine virtuelle existante dans

les paramètres Matériel virtuel.

Mettez la machine virtuelle hors tension, configurez l'adaptateur de sorte à utiliser une adresse

n

MAC manuelle, rétablissez l'allocation automatique d'adresses MAC, puis remettez la machine
sous tension.

Si la machine virtuelle est en production et que vous ne pouvez pas la mettre hors tension

n

pour la configurer, après avoir changé l'ID de vCenter Server ou le modèle d'allocation
d'adresses, recréez l'adaptateur réseau qui est en conflit en activant l'attribution manuelle
d'adresses MAC. Dans le système d'exploitation invité, attribuez la même adresse IP statique
qu'avant à l'adaptateur que vous venez de créer.

VMware, Inc. 87

Dépannage vSphere

Appliquez la régénération des adresses MAC au cours du transfert d'une machine virtuelle entre des

n

instances de vCenter Server en utilisant les fichiers de la machine virtuelle provenant d'une banque de
données.

a Mettez une machine virtuelle hors tension, supprimez-la de l'inventaire, puis définissez le

b Importez la machine virtuelle d'un système vCenter Server à un autre en enregistrant la machine

c Mettez pour la première fois les machines virtuelles sous tension.

d Cliquez avec le bouton droit sur la machine virtuelle et sélectionnez Toutes les actions vCenter >

paramètre ethernetX.addressType de son fichier de configuration (.vmx) sur generated.

Le signe X à côté d'ethernet représente le numéro séquentiel de la carte réseau virtuelle de la
machine.

virtuelle provenant d'une banque de données dans le système vCenter Server cible.

Les fichiers de la machine virtuelle peuvent se trouver dans une banque de données partagée entre
les deux instances de vCenter Server ou être téléchargés vers une banque de données accessible
uniquement à partir du système vCenter Server cible.

Pour plus d'informations sur l'enregistrement d'une machine virtuelle depuis une banque de
données, reportez-vous à Administration d'une machine virtuelle vSphere.

Au cours du démarrage, une icône d'information s'affiche sur la machine virtuelle dans
Client Web vSphere.

SE client > Répondre à une question.

e Choisissez l'option Je l'ai copié.

Le système vCenter Server cible génère de nouveau l'adresse MAC de la machine virtuelle. La nouvelle
adresse MAC commence par le préfixe VMware OUI 00:0c:29 et se base sur l'UUID BIOS de la machine
virtuelle. L'UUID BIOS de la machine virtuelle est calculé à partir de celui de l'hôte.

Échec de la conversion vers la prise en charge étendue du protocole LACP

Sous certaines conditions, la conversion d'une configuration LACP existante vers la prise en charge étendue
du protocole LACP sur vSphere Distributed Switch 5.5 peut échouer.

Problème

Après la mise à niveau d'un vSphere Distributed Switch vers la version 5.5, lorsque vous initiez la
conversion vers la prise en charge étendue du protocole LACP à partir d'une configuration LACP existante,
la conversion échoue en cours de processus.

Cause

La conversion d'une configuration LACP existante vers la prise en charge étendue du protocole LACP inclut
plusieurs tâches de reconfiguration du commutateur distribué. La conversion peut échouer si un autre
utilisateur reconfigure le commutateur distribué pendant la conversion. Par exemple, les cartes réseau
physiques des hôtes peuvent avoir été réaffectées à d'autres liaisons montantes ou la configuration
d'association et de basculement des groupes de ports distribués a peut-être été modifiée.

L'échec peut également provenir de la déconnexion de certains hôtes pendant la conversion.

Solution

Lorsque la conversion vers la prise en charge étendue du protocole LACP échoue à un certain stade, elle
n'est effectuée que partiellement. Vous devez vérifier la configuration du commutateur distribué et des
hôtes participants pour identifier les objets ayant une configuration LACP incomplète.

88 VMware, Inc.

Chapitre 7 Résolution des problèmes de mise en réseau

Vérifiez la configuration cible devant résulter de chaque étape de conversion dans l'ordre indiqué dans le
tableau. Après avoir déterminé l'étape à laquelle la conversion a échoué, terminez manuellement sa
configuration cible, puis exécutez les étapes suivantes.

Tableau 7‑1. Procédure d'exécution manuelle de la conversion vers le protocole LACP étendu

État de la configuration

Étape de conversion

1. Créez un nouveau LAG. Un LAG venant d'être créé

2. Créez une configuration
d'association et de
basculement LACP
intermédiaire sur les
groupes de ports distribués.

3. Réattribuez les cartes
réseau physiques des
liaisons montantes
autonomes aux ports LAG.

4. Créez la configuration
d'association et de
basculement LACP finale
sur les groupes de ports
distribués.

cible Solution

Vérifiez la configuration LACP du commutateur
doit être présent sur le
commutateur distribué.

Le LAG nouvellement créé
doit être en veille pour vous
permettre de migrer les cartes
réseau physiques vers le LAG
sans perte de connectivité.

Toutes les cartes réseau
physiques des ports LAG
doivent être réaffectées des
liaisons montantes autonomes
aux ports LAG.

La configuration d'association
et de basculement LACP
finale se présente comme suit.

Actif(ve) : uniquement le

n

nouveau LAG
En veille : vide

n

Inutilisé : toutes les

n

liaisons montantes
autonomes

distribué et créez un LAG si ce n'est pas déjà fait.

Vérifiez la configuration d'association et de basculement

du groupe de ports distribués. Configurez le nouveau

LAG en veille si ce n'est pas déjà fait.

Si vous ne souhaitez pas utiliser un LAG pour gérer le

trafic de tous les groupes de ports distribués, remettez la

configuration d'association et de basculement à un état

où les liaisons montantes autonomes sont actives et le

LAG est inutilisé.

Vérifiez si les cartes réseau physiques sont attribuées aux

ports LAG. Attribuez une carte réseau physique à chaque

port LAG.

REMARQUE Le LAG doit rester en veille dans l'ordre

d'association et de basculement des groupes de ports

distribués pendant que vous réaffectez les cartes réseau

physiques aux ports LAG.

Vérifiez la configuration d'association et de basculement

du groupe de ports distribués. Créez une configuration

d'association et de basculement LACP valide pour tous

les groupes de ports distribués auxquels vous souhaitez

appliquer le protocole LACP.

Par exemple, supposons que vous vérifiez qu'un nouveau LAG a été créé sur le commutateur distribué et
qu'une configuration d'association et de basculement intermédiaire a été créée pour les groupes de ports
distribués. Vous continuez à vérifier si des cartes réseau physiques sont attribuées aux ports LAG. Vous
découvrez que les cartes réseau physiques de certains hôtes n'ont pas été attribuées aux ports LAG, et vous
attribuez les cartes réseau manuellement. Vous terminez la conversion en créant la configuration
d'association et de basculement LACP finale pour les groupes de ports distribués.

Impossible de supprimer un hôte d'un vSphere Distributed Switch

Dans certains cas, il se peut que vous ne puissiez pas supprimer un hôte du vSphere Distributed Switch.

Problème

Les tentatives de suppression d'un hôte d'un vSphere Distributed Switch échouent et vous recevez une

n

notification indiquant que des ressources sont toujours en cours d'utilisation. La notification que vous
recevez peut être similaire à la suivante :

La ressource « 16 » est en cours d’utilisation.
Le port vDS DSwitch 16 est toujours sur l'hôte 10.23.112.2 connecté à MyVM nic=4000
type=vmVnic

VMware, Inc. 89

Dépannage vSphere

Les tentatives de suppression d'un commutateur proxy hôte qui existe encore sur l'hôte d'une

n

configuration de mise en réseau précédente échouent. Par exemple, vous avez déplacé l'hôte vers un
autre centre de données ou système vCenter Server, ou vous avez mis à niveau les logiciels ESXi et
vCenter Server et créé une nouvelle configuration de mise en réseau. Lors d'une tentative de
suppression du commutateur proxy hôte, l'opération échoue car des ressources du commutateur proxy
sont toujours en cours d'utilisation.

Cause

Vous ne pouvez supprimer ni l'hôte du commutateur distribué ni le commutateur proxy hôte pour les
raisons suivantes.

Des adaptateurs VMkernel sont en cours d'utilisation sur le commutateur.

n

Des adaptateurs réseau de machines virtuelles sont connectés au commutateur.

n

Solution

Problème Solution

Impossible de
supprimer un hôte d'un
commutateur distribué

Impossible de
supprimer un
commutateur proxy
hôte

1 Dans Client Web vSphere, accédez au commutateur distribué.
2 Sélectionnez Gérer > Ports.
3 Localisez tous les ports qui sont encore en cours d'utilisation et déterminez les adaptateurs

réseau VMkernel ou de machines virtuelles qui sont encore rattachés aux ports sur l'hôte.

4 Migrez ou supprimez les adaptateurs VMkernel et les adaptateurs réseau des machines

virtuelles qui sont encore connectés au commutateur.

5 Utilisez l'assistant Ajoutez et gérez les hôtes dans Client Web vSphere pour supprimer

l'hôte du commutateur.

Une fois l'hôte supprimé, le commutateur proxy hôte est automatiquement supprimé.

1 Dans Client Web vSphere, accédez à l'hôte.
2 Supprimez ou migrez tous les adaptateurs réseau VMkernel ou adaptateurs de machines

virtuelles qui sont encore connectés au commutateur.

3 Supprimez le commutateur proxy hôte de la vue Mise en réseau sur l'hôte.

Les hôtes d'un vSphere Distributed Switch 5.1 (et versions ultérieures) perdent la connectivité à vCenter Server

Les hôtes d'un vSphere Distributed Switch 5.1 (et versions ultérieures) ne peuvent pas se connecter à
vCenter Server après la configuration d'un groupe de ports.

Problème

Après la modification de la configuration de la mise en réseau d'un groupe de ports sur un vSphere
Distributed Switch 5.1 et versions ultérieures contenant les adaptateurs VMkernel du réseau de gestion, les
hôtes du commutateur perdent la connectivité à vCenter Server. Dans Client Web vSphere, les hôtes ne
répondent pas.

Cause

Si un vSphere Distributed Switch 5.1 et versions ultérieures fonctionne dans vCenter Server et que sa
fonction de restauration de mise en réseau est désactivée, le groupe de ports contenant les adaptateurs
VMkernel du réseau de gestion est mal configuré dans vCenter Server et cette erreur se propage sur les
hôtes du commutateur.

90 VMware, Inc.

Chapitre 7 Résolution des problèmes de mise en réseau

Solution

1 Dans l'interface utilisateur de la console directe (DCUI) d'un hôte affecté, utilisez l'option Restaurer

vDS du menu Options de restauration réseau pour configurer les liaisons montantes et l'ID du VLAN

du réseau de gestion.

L'interface DCUI crée un port local éphémère et lui applique la configuration des liaisons montantes et
du réseau VLAN. L'interface DCUI modifie l'adaptateur VMkernel du réseau de gestion pour qu'il
utilise le nouveau port local de l'hôte afin de restaurer la connectivité à vCenter Server.

Une fois l'hôte reconnecté à vCenter Server, Client Web vSphere affiche un avertissement indiquant que
la configuration de mise en réseau de certains hôtes du commutateur est différente de celle stockée sur
le vSphere Distributed Switch.

2 Dans Client Web vSphere, configurez le groupe de ports distribués du réseau de gestion avec les

paramètres appropriés.

Situation Solution

Vous avez modifié la configuration
du groupe de ports une seule fois

Vous avez sauvegardé une
configuration valide du groupe de
ports

Vous avez effectué plusieurs étapes
de la configuration et vous n'avez
pas de fichier de sauvegarde

Vous pouvez retourner en arrière et récupérer la configuration précédente
du groupe de ports. Cliquez avec le bouton droit sur le groupe de ports,
cliquez sur Toutes les actions vCenter > Restaurer la configuration, puis
sélectionnez Restaurer vers une configuration antérieure.

Vous pouvez restaurer la configuration du groupe de ports en utilisant le
fichier de sauvegarde. Cliquez avec le bouton droit sur le groupe de ports,
cliquez sur Toutes les actions vCenter > Restaurer la configuration, puis
sélectionnez Restaurer une configuration depuis un fichier.

Vous pouvez également restaurer la configuration de l'intégralité du
commutateur, y compris du groupe de ports, à partir d'un fichier de
sauvegarde du commutateur.

Vous devez indiquer manuellement les paramètres valides pour le groupe
de ports.

Pour plus d'informations sur la restauration et la récupération de la mise en réseau, reportez-vous à la
documentation Mise en réseau vSphere.

3 Migrez l'adaptateur VMkernel du réseau de gestion à partir du port local éphémère de l'hôte vers un

port distribué du commutateur à l'aide de l'assistant Ajouter et gérer les hôtes.

À la différence des ports distribués, le port local éphémère du VMKernel dispose d'un ID non
numérique.

Pour plus d'informations sur la gestion des adaptateurs VMkernel à l'aide de l'assistant Ajouter et gérer
les hôtes , reportez-vous à la documentation Mise en réseau vSphere.

4 Appliquez la configuration du groupe de ports et de l'adaptateur VMkernel de vCenter Server à l'hôte.

Envoyez la configuration correcte du groupe de ports et de l'adaptateur VMkernel de

n

vCenter Server à l'hôte. Accédez à l'hôte, puis sous Gérer, cliquez sur Mise en réseau. Sélectionnez
le commutateur distribué approprié dans Commutateurs virtuels, puis cliquez sur Rectifier.

Patientez pendant les prochaines vingt-quatre heures pour que vCenter Server applique les

n

paramètres.

VMware, Inc. 91

Dépannage vSphere

Les hôtes de vSphere Distributed Switch 5.0 et versions antérieures perdent leur connectivité à vCenter Server

Les hôtes de vSphere Distributed Switch 5.0 et versions antérieures ne peuvent pas se connecter à
vCenter Server après une configuration de groupe de ports.

Problème

Suite à la modification de la configuration de mise en réseau d'un groupe de ports sur vSphere Distributed
Switch 5.0 ou versions antérieures contenant les adaptateurs VMkernel du réseau de gestion, les hôtes du
commutateur perdent leur connectivité à vCenter Server. Dans Client Web vSphere, les hôtes ne répondent
pas.

Cause

Sur un vSphere Distributed Switch 5.0 et versions antérieures dans vCenter Server, le groupe de ports qui
contient les adaptateurs VMkernel du réseau de gestion est mal configuré dans vCenter Server et cette
configuration non valide se propage aux hôtes du commutateur.

Solution

1 Connectez-vous à un hôte concerné à l'aide de vSphere Client.

2 Sous Configuration, sélectionnez Mise en réseau.

3 Dans la vue Commutateur standard vSphere, créez un commutateur standard si l'hôte n'en a pas un

adapté au réseau de gestion.

a Cliquez sur Ajouter une mise en réseau.

b Dans l'assistant Ajouter un réseau, sélectionnez Machine virtuelle dans Types connexion, puis

cliquez sur Suivant.

c Sélectionnez Créer un commutateur standard vSphere et cliquez sur Suivant.

d Dans la section Propriétés groupe de ports, entrez une étiquette de réseau qui identifie le groupe de

ports que vous créez et éventuellement un ID VLAN.

e Cliquez sur Terminer .

f Dans la vue Commutateur standard vSphere, cliquez sur Propriétés du commutateur créé.

g Cliquez sur Adaptateurs réseau et sur Ajouter, puis sélectionnez un adaptateur physique inoccupé

pour prendre en charge le trafic de gestion.

Si tous les adaptateurs physiques sont déjà occupés par le trafic provenant d'autres commutateurs,
supprimez l'adaptateur physique du réseau de gestion dans le commutateur proxy du
commutateur distribué et ajoutez-le à ce commutateur standard.

h Cliquez sur l'onglet Ports et fournissez une configuration valide du groupe de ports de l'adaptateur

VMkernel.

i Cliquez sur Fermer.

4 Dans la vue vSphere Distributed Switch, migrez l'adaptateur VMkernel du réseau vers un commutateur

standard.

a Sélectionnez la vue vSphere Distributed Switch, puis pour le commutateur distribué, cliquez sur

Gérer adaptateurs virtuels.

b Dans l'assistant Gérer adaptateurs virtuels, sélectionnez l'adaptateur VMkernel dans la liste et

cliquez sur Migrer.

92 VMware, Inc.

Chapitre 7 Résolution des problèmes de mise en réseau

c Sélectionnez le nouveau commutateur standard ou un autre commutateur standard vers lequel

vous voulez migrer l'adaptateur et cliquez sur Suivant.

d Tapez une étiquette de réseau et éventuellement un ID VLAN pour le réseau de gestion, puis

cliquez sur Suivant.

5 Dans Client Web vSphere, configurez le groupe de ports distribués du réseau de gestion avec les

paramètres appropriés.

6 Migrez l'adaptateur VMkernel du réseau de gestion du commutateur standard vers un port du

commutateur distribué à l'aide de l'assistant Ajouter et gérer des hôtes.

Pour plus d'informations sur l'assistant Ajouter et gérer les hôtes, consultez la documentation Mise en
réseau vSphere.

7 Si vous avez déplacé l'adaptateur physique du commutateur proxy vers le commutateur standard, vous

pouvez de nouveau le rattacher au commutateur distribué à l'aide de l'assistant Ajouter et gérer les
hôtes.

Alarme indiquant une perte de redondance du réseau sur un hôte

Une alarme signale une perte de redondance de la liaison montante sur un commutateur standard ou un
vSphere Distributed Switch d'un hôte.

Problème

Aucune carte réseau physique redondante d'un hôte n'est connectée à un commutateur standard ou
distribué particulier et l'alarme suivante s'affiche :

Host name or IP Perte de redondance de la liaison montante

Cause

Une seule carte réseau physique de l'hôte est connectée au commutateur standard ou distribué particulier.
Les cartes réseau physiques redondantes sont hors service ou ne sont pas attribuées au commutateur.

Par exemple, supposons qu'un hôte de votre environnement dispose des cartes réseau physiques vmnic0 et
vmnic1 connectées à vSwitch0 ; vmnic1 se déconnecte, ce qui ne laisse que vmnic0 connectée à vSwitch0. Cela
entraîne la perte de la redondance de la liaison montante de vSwitch0 sur l'hôte.

Solution

Déterminez le commutateur qui a perdu la redondance de la liaison montante sur l'hôte. Connectez au
moins une carte réseau physique supplémentaire de l'hôte à ce commutateur, puis réinitialisez l'alarme sur
la couleur verte. Vous pouvez utiliser Client Web vSphere ou Shell ESXi.

Si une carte réseau physique est hors service, tentez de la récupérer à l'aide d'Shell ESXi sur l'hôte.

Pour plus d'informations sur l'utilisation des commandes de mise en réseau dans Shell ESXi, reportez-vous
à Référence de l'interface de ligne de commande de vSphere. Pour plus d'informations sur la configuration de la
mise en réseau sur un hôte dans Client Web vSphere, reportez-vous à Mise en réseau vSphere.

VMware, Inc. 93

Dépannage vSphere

Les machines virtuelles perdent leur connectivité après la modification de l'ordre de basculement des liaisons montantes d'un groupe de ports distribués

Si l'ordre de basculement des cartes réseau sur un groupe de ports distribués est modifié, les machines
virtuelles associées au groupe se déconnectent du réseau externe.

Problème

Après la réorganisation des liaisons montantes dans les groupes de basculement d'un groupe de ports
distribués dans vCenter Server, à l'aide de Client Web vSphere par exemple, certaines machines virtuelles
du groupe de ports ne peuvent plus accéder au réseau externe.

Cause

Après la modification de l'ordre de basculement, de nombreuses raisons peuvent provoquer la perte de
connectivité des machines virtuelles au réseau externe.

L'hôte qui exécute les machines virtuelles ne dispose pas de cartes réseau physiques associées aux

n

liaisons montantes actives ou en veille. Toutes les liaisons montantes associées aux cartes réseau
physiques de l'hôte pour le groupe de ports passent à l'état Inutilisé.

Un groupe d'agrégation de liens (LAG) qui ne dispose pas de cartes réseau physiques de l'hôte est

n

défini comme la seule liaison montante active selon les conditions d'utilisation de LACP dans vSphere.

Si le trafic des machines virtuelles est séparé dans les réseaux VLAN, les adaptateurs physiques hôtes

n

des liaisons montantes actives peuvent être connectés aux ports du tronc sur le commutateur physique
qui ne gère pas le trafic de ces réseaux VLAN.

Si le groupe de ports est configuré avec une stratégie d'équilibrage de charge basée sur le hachage IP,

n

un adaptateur de liaison montante active est connecté à un port de commutateur physique qui n'est pas
nécessairement dans une configuration EtherChannel.

Vous pouvez vérifier la connectivité des machines virtuelles du groupe de ports aux liaisons montantes
hôtes et aux adaptateurs de liaison montante associés dans le diagramme de topologie central du
commutateur distribué ou dans le diagramme du commutateur proxy de l'hôte.

Solution

Restaurez à l'état actif l'ordre de basculement et la liaison montante associée à une carte réseau

n

physique unique sur l'hôte.

Créez un groupe de ports avec des paramètres identiques, faites-lui utiliser le nombre de liaisons

n

montantes valide pour l'hôte et migrez la mise en réseau des machines virtuelles vers le groupe de
ports.

Déplacez la carte réseau vers une liaison montante qui participe au groupe de basculement actif.

n

Vous pouvez utiliser Client Web vSphere pour déplacer la carte réseau physique hôte vers une autre
liaison montante.

Utilisez l'assistant Ajouter et gérer des hôtes sur le commutateur distribué.

n

a Accédez au commutateur distribué dans Client Web vSphere.

b Dans le menu Actions, sélectionnez Ajouter et gérer les hôtes.

c Sélectionnez l'option Gérer la mise en réseau de l'hôte et sélectionnez l'hôte.

94 VMware, Inc.

Chapitre 7 Résolution des problèmes de mise en réseau

d Pour attribuer la carte réseau de l'hôte à une liaison montante active, sélectionnez l'option

Gérer adaptateurs physiques et associez la carte réseau à la liaison montante du commutateur
sur la page Gérer adaptateurs physiques.

Déplacez la carte réseau au niveau de l'hôte.

n

a Accédez à l'hôte dans Client Web vSphere, puis dans Gérer, cliquez sur Mise en réseau.

b Sélectionnez Commutateurs virtuels, ainsi que le commutateur proxy distribué.

c Cliquez sur Gérer adaptateurs physiques et déplacez la carte réseau vers la liaison montante

active.

Une machine virtuelle exécutant un client VPN provoque un déni de service pour les machines virtuelles sur l'hôte ou sur un cluster vSphere HA

Si une machine virtuelle envoie des trames BPDU (Bridge Protocol Data Unit), par exemple, un client VPN,
certaines machines connectées au même groupe de ports peuvent perdre la connectivité. La transmission de
trames BPDU peut aussi provoquer une perte de connexion de l'hôte ou du cluster vSphere HA parent.

Problème

Une machine virtuelle qui est censée envoyer des trames BPDU entraîne le blocage du trafic vers le réseau
externe des machines virtuelles du même groupe de ports.

Si cette machine virtuelle s'exécute sur un hôte qui fait partie d'un cluster vSphere HA et que cet hôte
devient, dans certaines conditions, isolé du réseau, vous observez un déni de service (DoS) sur les hôtes du
cluster.

Cause

Il est recommandé d'activer les fonctions PortFast et BPDU Guard sur un port de commutateur physique
connecté à un hôte ESXi afin d'appliquer la limite du protocole STP (Spanning Tree Protocol). Un
commutateur standard ou distribué ne prend pas en charge le protocole STP et n'envoie aucune trame
BPDU au port de commutateur. Cependant, si une trame BPDU issue d'une machine virtuelle compromise
atteint un port de commutateur physique accessible par un hôte ESXi, la fonction BPDU Guard désactive le
port afin d'empêcher les trames d'affecter la topologie STP du réseau.

Dans certains cas, on attend d'une machine virtuelle qu'elle envoie des trames BPDU ; par exemple,
lorsqu'elle déploie un client VPN connecté via un périphérique pont Windows ou une fonction de pont. Si la
fonction BPDU Guard du port de commutateur physique couplé avec l'adaptateur physique qui gère le
trafic à partir de cette machine virtuelle est activée, l'état du port est « error-disabled » et les machines
virtuelles et adaptateurs VMkernel qui utilisent l'adaptateur physique de l'hôte ne peuvent plus
communiquer avec le réseau externe.

Si la stratégie d'association et de basculement du groupe de ports contient d'autres liaisons montantes
actives, le trafic BPDU est déplacé vers l'adaptateur de la liaison montante active suivante. Le nouveau port
de commutateur physique est alors désactivé et la charge de travail supplémentaire ne parvient plus à
échanger des paquets avec le réseau. En fin de compte, il est possible que presque toutes les entités de l'hôte
ESXi deviennent inaccessibles.

Si cette machine virtuelle s'exécute sur un hôte qui fait partie d'un cluster vSphere HA et que cet hôte est
isolé du réseau en raison de la désactivation de la plupart des ports de commutateur physique qui y sont
connectés, l'hôte maître actif du cluster déplace la machine virtuelle dont est issu le trafic BPDU vers un
autre hôte. La machine virtuelle commence alors à désactiver les ports de commutateur physique connectés
au nouvel hôte. La migration à travers le cluster vSphere HA entraîne finalement un cumul de dénis de
service (DoS) dans tout le cluster.

VMware, Inc. 95

Dépannage vSphere

Solution

Si le logiciel VPN doit continuer son travail sur la machine virtuelle, autorisez le trafic sortant de la

n

machine virtuelle et configurez individuellement le port de commutateur physique afin de l'autoriser à
transmettre les trames BPDU.

Périphérique
réseau Configuration

Commutateur
standard ou
distribué

Commutateur
physique

Pour déployer un périphérique pont entre deux cartes réseau de machine virtuelle connectées au même

n

réseau de couche 2, autorisez le trafic BPDU sortant des machines virtuelles et désactivez les fonctions
de prévention des boucles PortFast et BPDU.

Choisissez l'option Accepter pour la propriété de sécurité Transmission forgée du groupe de
ports afin de permettre aux trames BPDU de quitter l'hôte et d'atteindre le port de
commutateur physique.

Vous pouvez isoler les paramètres et l'adaptateur physique du trafic VPN en plaçant la
machine virtuelle dans un groupe de ports séparé et en attribuant l'adaptateur physique au
groupe.

Ne désactivez pas la fonction PortFast.

n

Activez le filtre BPDU sur le port individuel. Lorsqu'une trame BPDU atteint le port, elle

n

est éliminée par le filtre.

REMARQUE N'activez pas le filtre BPDU de manière globale. Si ce filtre est activé de manière
globale, le mode PortFast se désactive et tous les ports de commutateur physique appliquent
les fonctions STP au complet.

Périphérique
réseau Configuration

Commutateur
standard ou
distribué

Commutateur
physique

Protégez l'environnement de toute attaque de déni de service (DoS) en activant le filtre BPDU sur

n

Choisissez l'option Accepter pour la propriété Transmission forgée de la stratégie de sécurité
des groupes de ports afin de permettre aux trames BPDU de quitter l'hôte et d'atteindre le
port de commutateur physique.

Vous pouvez isoler les paramètres, ainsi qu'un ou plusieurs adaptateurs physiques du trafic
de pont, en plaçant la machine virtuelle dans un groupe de ports séparé et en attribuant les
adaptateurs physiques au groupe.

Désactivez la fonction PortFast des ports du périphérique pont virtuel afin de pouvoir

n

exécuter le protocole STP sur ces ports.
Désactivez le filtre BPDU et la fonction BPDU Guard sur les ports accessibles au

n

périphérique pont.

l'hôteESXi ou sur le commutateur physique.

Sur un hôte exécutant ESXi 4.1 Update 3, ESXi 5.0 Patch 04 (et ultérieurs) et les versions ultérieures

n

à 5.0 ou ESXi 5.1 Patch 01 (et ultérieurs), activez le filtre Invité BPDU de l'une des manières
suivantes, puis redémarrez l'hôte :

Dans le tableau Paramètres système avancés situé sous l'onglet Gérer de Client Web vSphere,

n

définissez la valeur de la propriété Net.BlockGuestBPDU sur 1 pour l'hôte.

96 VMware, Inc.

Chapitre 7 Résolution des problèmes de mise en réseau

Dans un service Shell ESXi de l'hôte, entrez la commande vCLI suivante :

n

esxcli system settings advanced set -o /Net/BlockGuestBPDU -i 1

Sur un hôte auquel le filtre Invité BPDU n'est pas appliqué, activez le filtre BPDU sur le port de

n

commutateur physique du périphérique pont virtuel.

Périphérique réseau Configuration

Commutateur
standard ou distribué

Commutateur
physique

Choisissez l'option Rejeter pour la propriété Transmission forgée de la stratégie de
sécurité du groupe de ports.

Conservez la configuration PortFast.

n

Activez le filtre BPDU sur le port de commutateur physique. Lorsqu'une trame

n

BPDU atteint le port physique, elle est éliminée par le filtre.

REMARQUE N'activez pas le filtre BPDU de manière globale. Si ce filtre est activé de
manière globale, le mode PortFast se désactive et tous les ports de commutateur
physique appliquent les fonctions STP au complet.

Faible débit pour les charges de travail UDP sur des machines virtuelles Windows

Lorsqu'une machine virtuelle Windows dans vSphere 5.1 et versions ultérieures transmet de grands paquets
UDP, le débit est inférieur à celui attendu ou oscille même en l'absence d'un trafic significatif.

Problème

Lorsqu'une machine virtuelle Windows transmet des paquets UDP d'une taille supérieure à 1 024 octets,
vous obtenez un débit plus faible que prévu ou oscillant même en l'absence d'un trafic significatif. Dans le
cas d'un serveur de flux vidéo, la lecture vidéo marque des pauses.

Cause

Pour chaque paquet UDP d'une taille supérieure à 1 024 octets, la pile réseau de Windows attend une
interruption de fin de transmission avant d'envoyer le paquet suivant. Contrairement aux versions
précédentes, vSphere 5.1 et versions ultérieures ne fournit pas de solution transparente pour ce problème.

Solution

Augmentez le seuil en octets auquel Windows change son comportement pour les paquets UDP en

n

modifiant le Registre du système d'exploitation Windows invité.

a Localisez la clé de Registre HKLM\System\CurrentControlSet\Services\Afd\Parameters.

b Ajoutez une valeur sous le nom FastSendDatagramThreshold de type DWORD égale à 1500.
Pour obtenir des informations sur la résolution de ce problème dans le Registre Windows, reportez-

vous à l'article http://support.microsoft.com/kb/235257.

Modifiez les paramètres de fusion de la carte réseau de machine virtuelle.

n

Si la machine virtuelle Windows dispose d'un adaptateur vNIC VMXNET3, configurez l'un des
paramètres suivants du fichier .vmx de la machine virtuelle. Utilisez Client Web vSphere ou modifiez
directement le fichier .vmx.

VMware, Inc. 97

Dépannage vSphere

Action Paramètre Valeur

Augmentez le taux d'interruptions de la machine virtuelle à une
valeur supérieure au taux de paquets attendu. Par exemple, si le taux
de paquets attendu est de 15 000 interruptions par seconde, réglez le
taux d'interruptions à 16 000 interruptions par seconde. Définissez le
paramètre ethernetX.coalescingScheme sur rbc et le paramètre
ethernetX.coalescingParams sur 16000. Le taux d'interruptions
par défaut est de 4 000 interruptions par seconde.

Désactivez la fusion pour un faible débit ou pour les charges de
travail sensibles à la latence.

Rétablissez l'algorithme de fusion des versions antérieures d'ESXi.
REMARQUE La possibilité de rétablir un algorithme antérieur ne sera

pas disponible dans les versions ultérieures à vSphere 5.5.

X près d'ethernet représente le numéro de séquence de la vNIC dans la machine virtuelle.

Pour obtenir des informations sur la configuration des paramètres dans le fichier .vmx, reportez-vous à
la documentation Administration d'une machine virtuelle vSphere.

Modifiez les paramètres de fusion d'hôte d'ESXi.

n

Cette approche affecte toutes les machines virtuelles et toutes les cartes réseau de machine virtuelle sur
l'hôte.

ethernetX.coalescingScheme
ethernetX.coalescingParams

ethernetX.coalescingScheme

ethernetX.coalescingScheme

rbc
16000

désactivé

étalonner

Vous pouvez modifier la liste des paramètres système avancés pour l'hôte dans Client Web vSphere ou
en utilisant une commande de console vCLI sur l'hôte à partir d'Shell ESXi.

Paramètre pour la
commande esxcli system

settings sdvanced set

Valeur

Par exemple,
définissez-le à 16000 si
15000 interruptions par
seconde sont attendues.

Définissez-le à 0.

Définissez-le à 1.

Action

Définissez un taux
d'interruptions supérieur
au taux de paquets
attendu.

Désactivez la fusion pour
un faible débit ou pour
les charges de travail
sensibles à la latence.

Rétablissez le schéma de
fusion de versions
antérieures d'ESXi.

REMARQUE La possibilité
de rétablir un algorithme
antérieur ne sera pas
disponible dans les
versions ultérieures à
vSphere 5.5.

Paramètre dans
Client Web vSphere

Net.CoalesceRBCRate /Net/CoalesceRBCRate

Net.CoalesceDefaultOn /Net/CoalesceDefaultOn

Net.CoalesceVersion /Net/CoalesceVersion

Pour obtenir des informations sur la configuration d'un hôte dans Client Web vSphere, reportez-vous à
la documentation Gestion de vCenter Server et des hôtes. Pour obtenir des informations sur la définition
des propriétés d'hôte à l'aide d'une commande vCLI, reportez-vous à la documentation Référence de
l'interface de ligne de commande de vSphere.

98 VMware, Inc.

Chapitre 7 Résolution des problèmes de mise en réseau

Des machines virtuelles situées dans un même groupe de ports distribués, mais sur des hôtes différents, ne peuvent pas communiquer entre elles

Sous certaines conditions, les machines virtuelles résidant sur le même groupe de ports distribués mais sur
des hôtes différents ne peuvent pas communiquer entre elles.

Problème

Des machines virtuelles se trouvant sur des hôtes différents, mais dans le même groupe de ports, ne
parviennent pas à communiquer. Les commandes ping envoyées depuis une machine virtuelle vers une
autre restent sans effet. Vous ne parvenez pas à migrer les machines virtuelles entre les hôtes avec vMotion.

Cause

Sur certains hôtes, aucune carte réseau physique n'est attribuée à des liaisons montantes actives ou en

n

veille dans l'ordre d'association et de basculement du groupe de ports distribués.

Sur les hôtes, les cartes réseau physiques qui sont attribuées aux liaisons montantes actives ou en veille

n

se trouvent sur différents réseaux VLAN sur le commutateur physique. Les cartes réseau physiques
dans des VLAN différents ne peuvent pas se voir et ne peuvent donc pas communiquer entre elles.

Solution

Dans la topologie du commutateur distribué, vérifiez quel est l'hôte sur lequel aucune carte réseau

n

physique n'est attribuée à une liaison montante active ou en veille dans le groupe de ports distribués.
Sur cet hôte, attribuez au moins une carte réseau physique à une liaison montante active dans le groupe
de ports.

Dans la topologie du commutateur distribué, vérifiez les ID VLAN des cartes réseau physiques

n

attribuées aux liaisons montantes actives dans le groupe de ports distribués. Sur tous les hôtes,
attribuez des cartes réseau physiques provenant du même réseau VLAN à une liaison montante active
dans le groupe de ports distribués.

Une machine virtuelle qui utilise une fonction virtuelle SR-IOV est mise hors tension, car l'hôte n'a plus de vecteurs d'interruption

Sur un hôte ESXi, une ou plusieurs machines virtuelles qui utilisent des fonctions virtuelles SR-IOV pour la
mise en réseau sont mises hors tension.

Problème

Sur un hôte ESXi, une ou plusieurs machines virtuelles qui utilisent des fonctions virtuelles SR-IOV pour la
mise en réseau sont mises hors tension lorsque le nombre total de fonctions virtuelles attribuées s'approche
du nombre maximal de fonctions virtuelles spécifié dans le guide Configurations maximales pour vSphere.

Le fichier journal de la machine virtuelle vmware.log contient le message suivant sur la fonction virtuelle :

PCIPassthruChangeIntrSettings: vf_name failed to register interrupt (error code 195887110)

Le fichier journal VMkernel vmkernel.log contient les messages suivants sur la fonction virtuelle attribuée à
la machine virtuelle :

VMKPCIPassthru: 2565: BDF = vf_name intrType = 4 numVectors: 3
AVERTIS: IntrVector: 233: Out of interrupt vectors

VMware, Inc. 99

Dépannage vSphere

Cause

Chaque hôte ESXi dispose d'un total de 256 vecteurs d'interruption. Lorsque l'hôte démarre, les
périphériques sur l'hôte (contrôleurs de stockage, adaptateurs réseau physiques et contrôleurs USB)
consomment un sous-ensemble des 256 vecteurs. Si ces périphériques nécessitent plus de 128 vecteurs, le
nombre maximal de fonctions virtuelles potentiellement prises en charge est réduit.

Lorsqu'une machine virtuelle est mise sous tension et que le pilote de la fonction virtuelle du système
d'exploitation invité démarre, des vecteurs d'interruption sont consommés. Si le nombre de vecteurs
d'interruption n'est pas disponible, le système d'exploitation invité s'arrête de façon inattendue sans
message d'erreur.

Il n'existe actuellement aucune méthode pour déterminer le nombre de vecteurs d'interruption consommés
ou disponibles sur un hôte. Ce nombre dépend de la configuration matérielle de l'hôte.

Solution

Pour pouvoir mettre sous tension les machines virtuelles, réduisez le nombre de fonctions virtuelles
attribuées aux machines virtuelles sur l'hôte. Par exemple, remplacez l'adaptateur réseau SR-IOV d'une
machine virtuelle par un adaptateur connecté à un commutateur standard vSphere ou un commutateur
vSphere Distributed Switch.

Les tentatives de mise sous tension d'un vApp migré échouent, car le profil de protocole associé est manquant

Vous ne pouvez pas mettre sous tension un vApp ou une machine virtuelle que vous avez transféré vers un
centre de données ou un système vCenter Server, car un profil de protocole réseau est manquant.

Problème

Après avoir migré à froid un vApp ou une machine virtuelle vers un autre centre de données ou système
vCenter Server, sa mise sous tension échoue. Un message d'erreur indique qu'une propriété ne peut être ni
initialisée ni allouée, car le réseau du vApp ou de la machine virtuelle n'est associé à aucun profil de
protocole réseau.

Impossible d'initialiser la propriété 'property', car le réseau 'port group' n'est associé à
aucun profil de protocole réseau.

Impossible d'allouer une adresse IP pour la propriété 'property', car le réseau 'port group'
n'est associé à aucun profil de protocole réseau.

Cause

À l'aide de l'environnement OVF, le vApp ou la machine virtuelle récupère les paramètres réseau d'un profil
de protocole réseau associé au groupe de ports du vApp ou de la machine virtuelle.

vCenter Server crée un profil de protocole réseau pour vous lorsque vous installez l'environnement OVF
d'un vApp et associe le profil au groupe de ports que vous avez spécifié au cours de l'installation.

Le mappage entre le profil de protocole et le groupe de ports est valide uniquement dans l'étendue d'un
centre de données. Lorsque vous déplacez le vApp, le profil de protocole n'est pas transféré vers le centre de
données cible pour les raisons suivantes :

Les paramètres réseau du profil de protocole peuvent ne pas être valides dans l'environnement réseau

n

du centre de données cible.

Un groupe de ports portant le même nom et associé à un autre profil de protocole peut déjà exister dans

n

le centre de données cible, et les vApps et les machines virtuelles peuvent être connectés à ce groupe. Le
remplacement des profils de protocole pour le groupe de ports peut affecter la connectivité de ces vApp
et machines virtuelles.

100 VMware, Inc.