Accueil > KB, VMware > Top KB pour vSphere5

Top KB pour vSphere5

20/12/2011 Commenter Allez aux commentaires

Ca fait plus de 4 mois que vSphere 5 est sorti et même si la stabilité de cette plateforme n’est plus à démontrer, il est toujours bon de jeter un coup d’œil du coté des KB avant son installation ou son upgrade.

Faisant suite aux présentations du support francophone de VMware et d’après le contenu de la session VSP3867 du VMworld, voici le détails des 10 tops KB pour vSphere5:

  • Corruption des VMX/Snapshots d’une VM sous ESXi5 avec un ordre spécifique des opérations (2005740)
  • vMotion peut planter avec du virtual hardware 8 avec l’option 3D désactivé (2005741)
  • Le Service Status de vCenter 5.0 affiche une erreur avec la plugin Converter (2006132)
  • L’installation de l’agent HA (FDM) plante après une désinstallation manuelle (2006034)
  • Certains contrôleurs RAID locaux n’arrivent pas les volumes supérieurs à 2 To (2006942)
  • Le service vCenter Server plante après avoir été upgradé en version 5.0 (2007231)
  • Un serveur ESXi prend longtemps pour démarrer quand il contient des noeuds passifs MSCS (1016106)
  • Un serveur ESXi prend longtemps pour démarrer avec du stockage en iSCSI software (2007108)
  • Les serveurs ESXi 4.0 u2 plante avec un PSOD après mise à jour du vCenter (vpxa) en version 5 (2007269)
  • UpdateManager n’arrive pas à scanner les serveurs ESXi 5 après avoir importer un bundle incorrect (2006335)
  • plus quelques autres KB intéressantes…

Corruption des VMX/Snapshots d’une VM sous ESXi5 avec un ordre spécifique des opérations

Symphtomes:

Suite à l’ajout hot-plug d’un peripherique suivi d’un Snapshot, une VM plante au démarrage avec les erreurs suivantes:

File [] /<vmdkname>.vmdk was not found

VMware ESX cannot find the virtual disk « <vmdkname>.vmdk ».

Verify the path is valid and try again.

Reason: The system cannot find the file specified.

Le fichier « /var/log/hostd.log » contient ceci:

2011-08-25T10:02:04.312Z [21EF9B90 info 'Libs' opID=C629F9E4-00001115] VMHSVMLoadConfig: Not reading VM’s configuration due to migration-related poweroff

Le disque de base d’une VM peut contenir des données après qu’un Snapshot ai été pris – même avoir fait un « Revert to Snapshot ».

Cause:

2 scénarios peuvent provoquer ce type de corruption du fichier de configuration (.vmx) ou du Snapshots.

Corruption du .vmx:

  1. La VM est initialement éteinte
  2. Vous créez un Snapshot
  3. Vous allumez allumer la VM
  4. Vous ajoutez/supprimez un périphérique à chaud de la VM
  5. Vous faites un « Revert to Snapshot » de celui précédenment pris (la VM est repassée à l’état Power-Off)
  6. Vous ajoutez/supprimez un périphérique à froid de la VM
  7. => Il est alors impossible de démarrer la VM

Corruption du Snapshot:

  1. La VM est initialement éteinte
  2. Vous allumez allumer la VM
  3. Vous ajoutez/supprimez un périphérique à chaud de la VM
  4. Vous éteignez la VM
  5. Vous créez un Snapshot
  6. Vous changez la configuration de la VM (par exemple modification du hardware)
  7. => La configuration de la VM pointe maintenant vers le disk avant la Snapshot. Vous ne voyez pas de problème ici mais les données sont écrit sur le disques initial, si vous faite un « Revert to Snapshot » les données ne sont pas réinitialisées.
Résolution:

Ce problème est corrigé dans le correctif ESXi 5.0 patch 1 : ESXi500-201109401-BG. Si ce correctif n’est pas appliqué, il faut éviter les ajout/suppression de périphériques à chaud.
KB2005740

 

vMotion peut planter avec du virtual hardware 8 avec l’option 3D désactivé

Symphtomes:

Le vMotion plante pour une VM ayant les caractéristiques suivantes:

  • Virtual Harware en version 8
  • La 3D est désactivée
  • La résolution d’affichage est supérieur à 1280×1024 (ou moins s’il y a un double affichage)
  • Les drivers WDDM sont utilisés (Vista, 7, 2008, 2008 R2)

L’erreur est la suivante:

A general system error occurred: Failed to flush checkpoint data!

Le détail de la tache dans vCenter contient ceci:

An I/O error occurred while saving the checkpoint: 0 (Resource temporarily unavailable)

Failed to write checkpoint data (offset xxxxxxxx, size xxxxx): Failed to resume VM.

Le fichier « vmware.log » de la VM contient ceci:

vmx| MigrateSetState: Transitioning from state 9 to 11.
vmx| Migrate_SetFailure: Failed waiting for data. Error bad0006. Limit exceeded.
vmx|
vmx| Migrate: cleaning up migration state.
vmx| MigrateSetState: Transitioning from state 11 to 0.
vmx| Msg_Post: Error
vmx| [vob.vmotion.chkpt.toobig] vMotion migration [XXXXXXXX:xxxxxxxxxxxxxxxx] failed. The checkpoint data length (xxxxx bytes) or the offset (xxxxxxxx bytes) exceeds the maximum checkpoint data length (xxxxxxxx byte).
vmx| [msg.moduletable.powerOnFailed] Module Migrate power on failed.

Cause:

Les nouvelles fonctionnalités du driver WDDM le Virtual Hardware v8 ont augmenté les besoins en mémoires pour vMotion, le buffer utilisé n’est pas automatiquement ajusté quand la fonction 3D est désactivé.

Solution de contournement:
Soit:
  • Temporairement définir l’affichage à un écran ou une résolution de 1280 x 1024 (ou inférieur)
  • Ne pas upgrader en Virtual Hardware v8
  • Augmenter la taille du « base checkpoint cache » en fonction de la résolution d’écran utiliser. Par défaut il est à 8 Mo, 16 Mo est suffisant pour n’importe quel résolution en simple écran (20 Mo en dual). Pour cela éditer la configuation de la VM à froid (advanced settings ou dans le fichier .vmx) pour mettre migrate.baseCptCacheSize= »16777216″ (ou 20971520=20Mo). Ou mettre le paramètre dans le fichier /etc/vmware/config pour que cela soit global à l’ESXi.
  • Ou activer la 3D avec le paramètre mks.enable3d= »TRUE » (Nb: cela augmente l’overhead memoire de la VM de 256 Mo)

KB2005741

 

Le Service Status de vCenter 5.0 affiche une erreur avec la plugin Converter

Symphtome:

Après l’upgarde en vCenter 5.0 avec le plugin vCenter Converter précédement installé, une erreur apparait dans le vCenter Service Status:

Unable to retrieve health data from http://<ip>/converter/health.xml

Cause:

Le plugin vCenter Converter n’est plus disponible en v5 et n’est pas compatible dans son ancienne version avec vCenter Server 5.0.

Résolution:

Il faut désinstaller le plugin vCenter Converter depuis « ajout/suppression de programmes » puis nettoyer ces traces dans la base ADAM comme ceci:

  • Arrêter le service « VirtualCenter Server« 
  • Supprimer le répertoire Converter des extensions vCenter, généralement: « C:Program FilesVMwareInfrastructureVirtualCenter Serverextensionscom.vmware.converter« 
  • Lancer ADSI Edit pour éditer manuellement la base ADAM, pour cela aller dans le menu « Start > All Programs > Administrative Tools > ADSI Edit« .
  • d’un click-droit sur « ADSI Edit », sélec­tion­ner « connect to« 
  • Ren­sei­gner dans connec­tion point le naming context « dc=virtualcenter,dc=vmware,dc=int » et dans Com­pu­ter localhost:389 » et cli­quer sur « OK« .
  • Déplier l’arborescence « ADSI Edit > Default naming context (localhost:389) > DC=virtualcenter,dc=vmware,dc=int > OU=Health > OU=ComponentSpec > CN=<GUID>«   et d’un click-droit sélec­tion­ner « Pro­per­ties ».
  • Puis se pla­cer sur le com­po­sant « CN=com.vmware.converter » et d’un click-droit sélec­tion­ner « Delete« .
  • Fermer ADSI Edit et redémarrer le service « VirtualCenter Server« 

Note: vCenter Converter Standalone 5.0 peut toujours être utiliser en mode client/server si désiré, cependant il n’est pas enregistrer comme un plugin dans vCenter (voir le guide utilisateur de Converter Standalone 5).

KB2006132

 

L’installation de l’agent HA (FDM) plante après une désinstallation manuelle

Symphtomes:

Si vous essayez de désintaller manuellement l’agent FDM en utilisant le script « /opt/vmware/uninstaller/VMware-fdm-uninstall.sh« , le script semble s’être bien éxécuté mais la réinstallation plante à 24% (lors du chargement de l’agent) avec le message d’erreur suivant:

Cannot install the vCenter agent service.
Unknown installer error

Cause:

Le script de désinstallation n’est pas fait pour être éxécuter depuis son emplacement actuel.

Résolution:

Pour faire une bonne désintallation de l’agent FDM, utiliser l’une de ces méthodes:

  • Copier le script dans /tmp avant de l’éxécuter:

# cp /opt/vmware/uninstaller/VMware-fdm-uninstall.sh /tmp

# /tmp/VMware-fdm-uninstall.sh

  • Utiliser « esxcli » pour supprimer le paquage:

# esxcli software vib list | grep vmware-fdm

# esxcli software vib remove -n vmware-fdm

  • Ou désactiver HA au niveau du Cluster dans le client vSphere

KB2006034

 

Certains contrôleurs RAID locaux n’arrivent pas les volumes supérieurs à 2 To

Symphtomes:
L’installation d’ESXi 5.0 plante avec un contrôleur HP SmartArray.
La création d’un datastore VMFS plus grand que 2To-512 bytes plante.
ESXi n’arrive à utiliser un périphériques supérieurs à 2To-512 bytes.
Un volume logique de plus de 2To-512bytes n’est pas reconnu.
Le fichier de log vmkernel affiche des messages semblable à:

Partition: 484: Read of GPT header failed on « mpx.vmhba1:C0:T0:L0″: I/O error

WARNING: LinBlock: LinuxBlockCommand:1371:READ past end of device on major 104 – 0 + 1 > 0

LinBlock: LinuxBlockCompleteCommand:857: This message has repeated 55 times: Command 0×28 (0×412400743540) failed H:0×0 D:0×2

ScsiDeviceIO: 2316: Cmd(0x412400742d40) 0×28, CmdSN 0×305 to dev « mpx.vmhba1:C0:T0:L0″ failed H:0×0 D:0×2 P:0×0 Valid sense data: 0×5 0×20 0×0.

WARNING: Partition: 944: Partition table read from device mpx.vmhba1:C0:T0:L0 failed: I/O error

WARNING: LinBlock: LinuxBlockCommand:1371:READ past end of device on major 104 – 0 + 1 > 0

Cause:
ESXi 5.0 supporte les périphériques et les volumes de plus de 2 To. Cependant, le driver cciss embarqué avec ESXi 5.0 n’est pas de capable de les utiliser. Le problème a été observé avec la version 3.6.14-10vmw du driver cciss (HP Smart Array P400, P400i, P600, P800, E200, E200i, E500…).
Solution de contournement:
Configurer plusieurs volumes logiques d’une taille maximale de 2To – 512 bytes au niveau hardware de la carte Raid. Ensuite, utiliser des « Extents » afin d’augmenter la taille du premier datastore local jusqu’à un maximum de 64To (50To pour du VMFS3 avec une taille de bloc d’1Mo)

KB2006942

 

Le service vCenter Server plante après avoir été upgradé en version 5.0

Symphtomes:
Le service « vCenter Server » plante immédiatement après avoir été upgradé.
Au démarrage du service « vCenter Service », il plante avec une erreur « Win32 exception ».
Le fichier « vminst.log » (dans le répertoire %temp%) contient les messages suivants:
VMware VirtualCenter-build-455964: 10/12/11 19:16:22 Srvc_IsServiceRunning::done Service is NOT RUNNING
VMware VirtualCenter-build-455964: 10/12/11 19:16:22 OpenSrvcManagers
VMware VirtualCenter-build-455964: 10/12/11 19:16:22 OpenSrvcManager
VMware VirtualCenter-build-455964: 10/12/11 19:16:22 OpenSrvcs
VMware VirtualCenter-build-455964: 10/12/11 19:16:22 OpenSrvc
VMware VirtualCenter-build-455964: 10/12/11 19:16:22 StartSrvc::NumArgs: 0
VMware VirtualCenter-build-455964: 10/12/11 19:16:41 StartSrvc::ERROR_SERVICE_DEPENDENCY_FAIL The service depends on another service that has failed to start Error: 1068
VMware VirtualCenter-build-455964: 10/12/11 19:16:41 Service could not be started.
VMware VirtualCenter-build-455964: 10/12/11 19:16:41 Srvc_StartService::vctomcat service NOT STARTED Error: 1068
VMware VirtualCenter-build-455964: 10/12/11 19:16:41 End Logging
Le fichier « vim-im-msi.log » (dans le répertoire %temp%) contient les messages suivants
Getting hit by the below, on upgrade and fresh installation:
Action 19:16:22: VM_StartTomcatImmediate.
Action start 19:16:22: VM_StartTomcatImmediate.
MSI (c) (E0:C8) [19:16:22:142]: Invoking remote custom action. DLL: C:UsersADMINI~1AppDataLocalTemp2MSICA21.tmp, Entrypoint: VMStartTomcatImmediate
Action ended 19:16:41: VM_StartTomcatImmediate. Return value 3.
MSI (c) (E0:B0) [19:16:41:565]: Doing action: SetupCompleteError
Action 19:16:41: SetupCompleteError.
Le fichier « vpxd.log » contient les erreurs suivantes:

[AddAlarmToEntity] ALARM alarm-37 created on host-9

[VpxdMoAlarmManager] Found both stateful stateless event expressions in the same alarm

[02296 warning 'Default'] [VpxUnhandledException] Win32 Exception (0xe06d7363) detected at 7FEFD11CACD

Cause:

Ce problème est provoqué par une erreur d’entrée d’alarme dans la base de données vCenter. Dans ce cas l’alarme contient un état vrai et faux dans les événements. L’id de l’alarme posant problème est celle suivant l’alarme évoqué dans le fichier vpxd.log (alarm-38 dans notre exemple).

Résolution:
Pour cela, il faut supprimer l’alarme de la base de données vCenter, pour cela effectuer les opérations suivantes:
  • Faire une sauvegarde de la base vCenter
  • Exécuter les requètes SQL suivantes sur la base vCenter:

delete from VPX_ALARM_EXPRESSION where alarm_id = 38;

delete from VPX_ALARM_ACTION where alarm_id = 38;

delete from VPX_ALARM where alarm_id = 38;

  • Démarrer le service « vCenter Server »

KB2007231

 

Un serveur ESXi prend longtemps pour démarrer quand il contient des noeuds passifs MSCS

Symphtomes:
Un serveur ESXi 5.0 (ou même ESX/ESXi 4.x) prend logntemps pour démarrer alors qu’il contient des LUNs en RDM qui ont des réservations SCSI-2 ou SCSI-3 pour des noeuds passifs d’un cluster MSCS. Le temps varie en fonction du nombre de LUN RDM, cela peut prendre 10 minutes pour 3 LUNs RDM, 30 minutes pour 10 LUNs…
Pendant le démarrage l’hôte est long à l’étape « Loading module multiextent« .
Le fichier « vmkernel.log » contient ce type de messages:
Sep 24 12:25:37 cs-tse-d54 vmkernel: 0:00:08:58.811 cpu2:4098)WARNING: ScsiCore: 1353: Power-on Reset occurred on naa.600601604550250083489d914fbbdf11
Sep 24 12:25:37 cs-tse-d54 vmkernel: 0:00:08:58.814 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:9:0 (naa.600601604550250082489d914fbbdf11)
Sep 24 12:25:37 cs-tse-d54 vmkernel: 0:00:09:38.855 cpu2:4098)ScsiDeviceIO: 1672: Command 0x1a to device "naa.600601604550250083489d914fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
Sep 24 12:25:37 cs-tse-d54 vmkernel: 0:00:09:38.855 cpu1:4111)ScsiDeviceIO: 4494: Could not detect setting of QErr for device naa.600601604550250083489d914fbbdf11. Error Failure.
Sep 24 12:25:37 cs-tse-d54 vmkernel: 0:00:10:08.945 cpu1:4111)WARNING: Partition: 801: Partition table read from device naa.600601604550250083489d914fbbdf11 failed: I/O error
Sep 24 12:25:37 cs-tse-d54 vmkernel: 0:00:10:08.945 cpu1:4111)ScsiDevice: 2200: Successfully registered device "naa.600601604550250083489d914fbbdf11" from plugin "NMP" of type 0
Cause:
Ce problème existait déjà en vSphere 4.x. Mais la résolution est différentes, il est préférable d’appliquer la résolution avant l’upgrade.
Une nouvelle méthode permet de gérer les noeuds passifs MSCS en marquant les LUNs comme “perennially reserved”.
Résolution:
Cette méthode doit être faite manuellement pour chaque hôte et chaque LUN MSCS avec la commande:

esxcli storage core device setconfig -d <naa.id> –perennially-reserved=true

Vérifier l’état du flag « perennially reserved » avec la commande:

esxcli storage core device list -d <naa.id>

Nb: Pour le faire en PowerCLI, voir la KB.

KB1016106

 

Un serveur ESXi prend longtemps pour démarrer avec du stockage en iSCSI software

Symphtomes:
Un serveur ESXi 5.0 avec sotckage en iSCSI software met longtemps a démarrer. Pendant le démarrage l’hôte est long à l’étape « software-iscsi« .
Après le démarrage le fichier « sysboot.log » contient les messages:

[01:57:50.925338] sysboot: software-iscsi

[02:28:22.330320] sysboot: restore-paths

Le fichier « syslog.log » contient les messages:

iscsid: cannot make a connection to 192.168.1.20:3260 (101,Network is unreachable)

iscsid: Notice: Reclaimed Channel (H34 T0 C1 oid=3)

iscsid: session login failed with error 4,retryCount=3

iscsid: Login Target Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) err=4

iscsid: Login Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) Reason: 00040000 (Initiator Connection Failure)

Cause:
Le serveur ESXi 5.0 essaye de se connecter à toutes les Targets connues depuis tous les portails iSCSI. L’ESXi réessaye 9 fois les connections en erreur, chaque tentative est espacé de 30 secondes.
Résolution:

Ce problème est résolu en ESXi 5.0 Express Patch 01 (ESXi500-201111401-BG).

Solutions alternatives:
Réduire le nombre de permutations lors du démarrage iSCSI (portails et targets).
Pour connaitre les portails iSCSI, utiliser la commande « esxcli iscsi networkportal list »; et pour les targets, utiliser « vmkiscsi-tool –T vmhba## »

KB2007108

 

Les serveurs ESXi 4.0 u2 plante avec un PSOD après mise à jour du vCenter (vpxa) en version 5

Symphtomes:
Le serveur vCenter a été récément mise à jour en version 5.0 alors que l’inventaire contient des hôtes en ESXi 4.0 update 2, entre les version ESXi 4.0 patch3 (219382) et ESXi 4.0 patch9 (360236).
Lors que le serveur vCenter initialise la mise à jour des agents vCenter (vpxa), les hôtes ESXi 4.0 update 2 peuvent planter avec un écran violet (PSOD), avec le message suivant:

NOT_IMPLEMENTED bora/vmkernel/filesystems/visorfs/visorfsObj.c:3391

Cause:

Le problème vient de la manière de remplacer la package « vpxa.vgz » sur un ESXi 4.0 U2.

Résolution:
Ce problème est résolu avec la version ESXi 4.0 update 3 (398348). Faire la mise à jour des hôtes concernés avant de mettre à jour le serveur vCenter en 5.0.

KB2007269 / KB2009432 (fr)

 

UpdateManager n’arrive pas à scanner les serveurs ESXi 5 après avoir importer un bundle incorrect

Symphtomes:
Après avoir importer le patch « VMware-ESXi-5.0.0-469512-depot.zip » dans Update Manager. Il est impossible de faire un scan/stage/remediate sur des hôtes ESXi 5.0 avec le message d’erreur suivant:

  “Host cannot download files from VMware vSphere Update Manager patch store.  Check the network connectivity and firewall setup, and check esxupdate logs for details.”

Le fichier de log « esxupdate.log » contient le message d’erreur suivant:

MetadataDownloadError: (‘http://xxx.xxx.xxx.xxx:9084/vum/repository/hostupdate/VMW/vmw-ESXi-5.0.0)

Les hôtes ESX/ESXi 4.x ne sont pas affecter par le problème.

Cause:
Le patch « VMware-ESXi-5.0.0-469512-depot.zip » n’est pas un bundle pour VUM, il est fait pour être utiliser avec Auto Deploy.
Résolution:

Le patch ne doit pas être importer dans Update Manager, malgrés tous si cela a été fait suivre le mode opératoire suivant pour résoudre le problème:

  • Lancer le programme d’installation d’Update Manager
  • Choisir de réinitialiser la base de données Update Manager quand demandé
  • Les données incorrect seront supprimées
  • Re-créer/ré-importer les baselines utilisées autrement

KB2006335

 

Autres KB intéressantes pour vSphere5

Voici en complément une liste KB spéciale Best-Practices:

| | |

Articles complémentaires:
  1. nouveauté vSphere5: AutoDeploy & ImageBuilder
  2. Synthèse sur vSphere5
  3. nouveauté vSphere5: VSA
  4. catalogue des sessions disponible pour le VMworld 2010
Categories: KB, VMware Tags: