Notes de mise à jour VMware vSphere 4.1 — ESXi Edition

Nous contacter
 

ESXi 4.1 Installable | 13 Juil 2010 | Build 260247

ESXi 4.1 Embedded | 13 Juil 2010 | Build 260247

vCenter Server 4.1 | 13 Juillet 2010 | Build 259021

Dernière mise à jour : 15 Septembre 2010

Vérifiez l'existence d'ajouts et de mises à jour pour ces notes de mise à jour.

Contenu des Notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

VMware vSphere™ 4.1 inclut VMware ESXi™ 4.1 Installable, VMware ESXi™ 4.1 Embedded et VMware vCenter Server™ 4.1. Reportez-vous à Nouveautés de VMware vSphere 4.1 pour découvrir les nouvelles fonctions et améliorations de cette édition.

Internationalisation

VMware vSphere 4.1 est disponible dans les langues suivantes :

  • Anglais
  • Français
  • Allemand
  • Japonais
  • Chinois simplifié

Mode localisation forcée de vSphere Client

Avec vSphere 4.1, vous pouvez configurer VMware vSphere Client™ pour fournir l'interface textuelle en anglais, même si la machine sur laquelle il fonctionne n'est pas en anglais. Vous pouvez régler cette configuration pour la durée d'une seule session en utilisant un commutateur à ligne de commande. Cette configuration s'applique au texte de l'interface et n'affecte pas les autres paramètres de langue comme les formats horaires ou numériques.

Par exemple, la commande vSphere Client suivante affichera la session individuelle en anglais :

vpxClient -locale en_US

Installation et compatibilité

Compatibilité de version ESXi, vCenter Server et vSphere Client

Les Matrices de compatibilité vSphere fournissent des détails sur la compatibilité des versions actuelles et précédentes des composants VMware vSphere dont ESXi, vCenter Server, vSphere Client et les produits VMware optionnels. Consultez également les Matrices de compatibilité vSphere 4.1 pour des informations sur les agents de gestion et de sauvegarde supportés avant d'installer ESXi ou vCenter Server.

Compatibilité matérielle pour ESXi

Pour savoir quels processeurs, périphériques de stockage, étalages SAN et périphériques E/S sont compatibles avec vSphere 4.1, utilisez les informations ESXi 4.1 du Guide de compatibilité matérielle.

Connexions de vSphere Client aux environnements Linked Mode avec vCenter Server 4.1

vCenter Server 4.1 peut exister en Linked Mode avec d'autres instances de vCenter Server 4.1 ou vCenter Server 4.0 et ultérieures. Si le vSphere Client correspondant à la version de vCenter Server à laquelle vous essayez de vous connecter n'est pas installé sur votre système, il vous est proposé de télécharger et d'installer cette version de vSphere Client. Une fois les deux versions de vSphere Client installées, vous pouvez accéder aux objets liés de vCenter Server avec l'un ou l'autre client. Pour les environnements Linked Mode avec vCenter Server 4.0 et vCenter Server 4.1, vous devez avoir vSphere Client 4.0 Update 1 et vSphere Client 4.1. Pour télécharger vSphere Client 4.0 Update 1, allez à Télécharger VMware vSphere 4.

Compatibilité vSphere 4.1 et VMware View

Pour plus d'informations sur les configurations vSphere prises en charge avec VMware View 4.0.x, voir le Centre d'assistance produit pour VMware View.

Notice d'installation pour cette édition

Lisez le Guide d'installation d'ESXi Installable et vCenter Server pour une aide étape par étape sur l'installation et la configuration d'ESXi Installable et vCenter Server ou le Guide d'installation d'ESXi Embedded et vCenter Server pour une aide étape par étape sur celles d'ESXi Embedded et vCenter Server.

Après l'installation réussie d'ESXi Installable ou le démarrage réussi d'ESXi Embedded, plusieurs étapes de configuration s'avèrent essentielles. Plus précisément, des configurations de licence, de mise en réseau et de sécurité sont nécessaires. Pour vous guider dans ces tâches de configuration, reportez-vous aux guides suivants de la documentation vSphere.

vCenter Server 4.1 supporte l'installation sur plateformes Windows 64 bits uniquement. Si vous avez installé VMware VirtualCenter 2.x, voir le Guide de mise à niveau vSphere pour plus d'informations sur l'installation de vCenter Server sur un système d'exploitation 64 bits en conservant la base de données VirtualCenter.

Les futures éditions de VMware vSphere ne devraient pas supporter VMFS version 2 (VMFS2). VMware recommande la mise à niveau ou la migration vers VMFS version 3 ou ultérieure. Reportez-vous au Guide de mise à niveau vSphere.

vCenter Server 4.1 inclut les fichiers MIB (Management Information Base) relatifs à vCenter Server. Vous pouvez télécharger les fichiers MIB relatifs à ESXi sur le site de VMware : http://www.vmware.com/download/vsphere/drivers_tools.html.

Mises à niveau pour cette édition

Mises à niveau vCenter Server

vCenter Server 4.1 doit être installé sur un système 64 bits. Vous pouvez mettre à niveau vCenter Server 4.0 vers vCenter Server 4.1 sur le même système si celui-ci est 64 bits. Pour effectuer la mise à niveau, vérifiez que la base de données est prise en charge avec vCenter Server 4.1 et sauvegardez la base de données prise en charge, les certificats SSL et la configuration vCenter Server. Puis lancez le programme d'installation de vCenter Server. Le programme d'installation vous informe qu'une version plus ancienne de vCenter Server est sur l'ordinateur et va être mise à niveau.

Vous pouvez également mettre à niveau VirtualCenter Server 2.5 ou vCenter Server 4.0 sur système 32 bits vers vCenter Server 4.1 sur 64 bits en installant vCenter Server 4.1 sur un système 64 bits et en gardant la base de données de VirtualCenter Server 2.5 ou vCenter Server 4.0. Vous pouvez utiliser l'outil de migration de données pour déplacer la configuration de vCenter Server du système 32 bits vers le système 64 bits. Voir le Guide de mise à niveau vSphere.

Mises à niveau ESXi

vSphere 4.1 offre les outils suivants pour mettre à niveau les hôtes ESXi :

Si vous avez ESXi 3.5 mais pas vCenter Update Manager 4.1, vous devez mettre à niveau vers ESXi 4.0 ou une édition ESXi 4.0 Update en utilisant vSphere Host Update Utility 4.0 ou vCenter Update Manager 4.0. Vous pouvez ensuite mettre à niveau vers ESXi 4.1 en utilisant vCenter Update Manager 4.1 ou l'utilitaire vihostupdate. Pour des instructions détaillées, voir le Guide de mise à niveau vSphere.

Éditions Test de vSphere 4.1

Les mises à niveau des éditions vSphere 4.1 Beta et vSphere 4.1 Release Candidate vers vSphere 4.1 ne sont pas supportées. Dsinstallez ESXi 4.1 Beta ou Release Candidate et vCenter Server 4.1 Beta ou Release Candidate puis lancez de nouvelles installations de vCenter Server 4.1 et ESXi 4.1. Si vous testiez les versions Beta ou Release Candidate de vSphere 4.1, VMware recommande de recréer les données de ces installations que vous souhaitez conserver sur vSphere 4.1.

La migration de machines virtuelles en utilisant vMotion depuis un hôte Beta ou Release Candidate vers un hôte vSphere 4.1 n'est pas supportée.

Les SDK VMware vSphere

VMware vSphere fournit des SDK pour services Web et systèmes d'exploitation client :

  • vSphere Web Services SDK. Cette édition de vSphere Web Services SDK inclut le support de nouvelles fonctions disponibles dans les systèmes de serveurs ESX 4.1 et vCenter Server 4.1. Vous pouvez également utiliser ce SDK avec les anciennes versions d'ESX et vCenter Server. Pour plus d'informations, voir la Documentation VMware vSphere Web Services SDK.

  • vSphere Guest SDK. Le VMware vSphere Guest SDK 4.0 est supporté sur ESX 4.1. Pour plus d'informations, voir la Documentation VMware vSphere Guest SDK.

Composants open source pour vSphere

Les composants Open Source et leurs licences respectives de la dernière version généralement disponible de vSphere sont accessibles sur le site http://www.vmware.com/download/vsphere/open_source.html dans l'onglet Open Source. Vous pouvez également télécharger le fichiers source pour une licence GPL ou LGPL ou pour d'autres licences similaires pour lesquelles le code source ou des modifications du code source doivent être disponibles pour la dernière version généralement disponible, en cliquant sur ce lien.

Remarques sur le support plateforme, fonction et produit vSphere 4.1

VMware vSphere 4.1 est la dernière édition pour les plateformes, fonctions et produits suivants. VMware continuera de fournir un support technique pour ces plateformes et fonctions au-delà de leurs cycles de vie.

  • VMware ESX. VMware vSphere 4.1 et ses mises à jour et correctifs ultérieurs sont les dernières éditions à inclure les architectures d'hyperviseurs ESX et ESXi. Les futures éditions importantes de VMware vSphere incluront uniquement l'architecture VMware ESXi.

    • VMware recommande à ses clients de commencer la migration vers l'architecture ESXi en déployant VMware vSphere 4.1.
    • VMware continuera d'apporter son assistance technique pour VMware ESX suivant les règles de garantie VMware vSphere disponibles sur la page Support VMware Enterprise Infrastructure.
    • Pour plus d'informations au sujet de l'architecture ESXi et de la migration d'ESX vers ESXi, voir la rubrique Centre de mise à niveau de VMware ESX vers ESXi.

  • Plug-in VMware vCenter Converter. VMware vSphere 4.1 et ses mises à jour et correctifs ultérieurs sont les dernières éditions du plug-in VMware vCenter Converter pour vSphere Client. VMware continuera de mettre à jour et de supporter le produit gratuit Converter Standalone, qui permet les conversions depuis les machines physiques, les formats de machine virtuelle VMware et Microsoft et les formats d'image disque de certains éditeurs tiers.

  • VMware vCenter Guided Consolidation. VMware vSphere 4.1 et ses mises à jour et correctifs ultérieurs sont les dernières éditions majeures pour VMware Guided Consolidation. Les utilisateurs souhaitant consolider leurs serveurs physiques disposent des options de service VMware vSphere suivantes :
    • VMware vSphere avec P2V Migration Jumpstart
    • VMware Virtualization Assessment (évaluation de la virtualisation)
    • VMware P2V Accelerator Services

  • Fonctions de VMware vCenter Update Manager. vCenter Update Manager 4.1 et ses mises à jour ultérieures sont les dernières éditions supportant l'analyse et la correction des correctifs pour les systèmes d'exploitation client Windows et Linux et les applications fonctionnant sur une machine virtuelle. La possibilité d'effectuer des opérations sur machine virtuelle comme la mise à niveau de VMware Tools et du matériel de machine virtuelle continuera d'être supportée et améliorée.

  • VMware Consolidated Backup. VMware a étendu la limite de disponibilité pour VCB et a ajouté le support de VCB pour vSphere 4.1. VMware continuera de supporter VCB 1.5 Update 2 pour vSphere 4.1 et ses mises à jour et correctifs ultérieurs au-delà de leurs cycles de vie. Le support est étendu en accord avec les règles de support VMware pour la plateforme VMware Infrastructure 3. Les nouvelles versions majeures ou mineures de plateforme vSphere au-delà de vSphere 4.1 ne seront pas supportées avec VCB.

  • Support de système d'exploitation client paravirtualisé VMI. vSphere 4.1 est la dernière édition supportant l'interface de paravirtualisation de système d'exploitation client VMI. Pour des informations sur la migration de machines virtuelles activées pour VMI en vue de leur fonctionnement sur les futures éditions de vSphere, voir l' Article 1013842 de la base de connaissances.

  •  

    vSphere Web Access. vSphere 4.1 est la dernière version de vSphere Web Access. Comme meilleure pratique, VMware recommande d'utiliser vSphere Client qui contient toute la fonctionnalité de Web Access. Étant donné que vSphere Web Access n'est plus développé, le support de ce produit est fourni dans la mesure du possible.

  • Personnalisation de système d'exploitation client Linux. vSphere 4.1 est la dernière édition supportant la personnalisation pour les systèmes d'exploitation client Linux suivants :

    • RedHat Enterprise Linux (AS/ES) 2,1
    • RedHat Desktop 3
    • RedHat Enterprise Linux (AS/ES) 3.0
    • SUSE Linux Enterprise Server 8
    • Ubuntu 8.04
    • Ubuntu 8.10
    • Debian 4.0
    • Debian 5.0

    VMware continuera de supporter la personnalisation pour les nouvelles versions des systèmes d'exploitation client Linux des familles RedHat Enterprise Linux et SUSE Linux Enterprise Server.

  • Microsoft Windows 2000 MSCS. MSCS avec Windows 2000 n'est pas supporté dans vSphere 4.1. Voir le site de Microsoft pour plus d'informations.

Pour les règles de support VMware pour la plateforme vSphere, voir la page Support VMware Enterprise Infrastructure.

Problèmes connus

La section Problèmes connus regroupe les Avertissements de fonctionnalité et fournit une Liste des problèmes connus.

Avertissements de fonctionnalité

 

IPv6 désactivé par défaut. IPv6 est désactivé par défaut lors de l'installation d'ESXi 4.1.

 

Matériel iSCSI. Le matériel iSCSI Broadcom ne prend pas en charge les trames Jumbo ni IPv6. Le matériel dépendant iSCSI ne supporte pas l'accès iSCSI au même LUN lorsqu'un hôte utilise simultanément des adaptateurs matériels dépendants ou indépendants iSCSI.

Liste des problèmes connus

Les problèmes connus suivants ont été rencontrés lors de tests rigoureux.Nous espérons qu'ils vous aideront à comprendre certains désagréments que vous pourriez rencontrer dans cette édition. La liste des problèmes concerne cette version de vSphere 4.1 uniquement. Certains problèmes connus des éditions précédentes peuvent aussi s'appliquer à cette édition. Si vous rencontrez un problème non répertorié ici, vous pouvez étudier les problèmes connus des éditions précédentes, fouiller la Base de connaissances VMware ou encore nous contacter.

Les fonctions et problèmes connus des précédentes éditions de vSphere 4.0, incluant ESX/ESXi 4.0 et vCenter Server 4.0, sont décrits dans les notes de mise à jour correspondantes. Pour consulter les notes de mise à jour de vSphere 4.0 et ses mises à jour ultérieures, voir la page Documentation VMware vSphere 4.0.

Les problèmes connus sont classés comme suit :

Problèmes d'installation

  • Les paramètres serveur DNS sont perdus après le deuxième démarrage d'ESXi
    Après l'installation d'ESXi avec la méthode d'installation scriptée, les paramètres de serveur DNS sont perdus lorsque ESXi redémarre pour la deuxième fois. Les paramètres sont corrects après le premier démarrage suivant l'installation mais sont perdus après le deuxième redémarrage.

    Solution : Définissez /etc/resolv.conf avec la commande kickstart %firstboot lorsque vous exécutez l'installation scriptée d'ESXi. Cette méthode est préférable si vous avez de nombreux hôtes. Vous pouvez également réinitialiser le DNS par l'intermédiaire de l'interface utilisateur console directe pour chaque instance d'ESXi.

  • L'installation échoue lorsque vous désinstallez puis réinstallez vCenter Server
    L'installation échoue avec l'erreur Création des services de répertoire vCenter Server impossible lorsque vous désinstallez puis réinstallez vCenter Server sur le même système.

    Solution : Après la désinstallation de vCenter Server, redémarrez le système avant de réinstaller vCenter Server.

  • Lorsque vous désinstallez vCenter Server 4.1 sans arrêter le service vCenter Server, l'instance ADAM locale ne devrait pas être supprimée
    Vous devez arrêter le service vCenter Server avant de désinstaller vCenter Server 4.1 ou l'instance ADAM restera sur le système. Cela s'applique aux installations et mises à niveau de vCenter Server 4.1, ainsi qu'aux systèmes liés ou autonomes vCenter Server.

    Solution : Arrêtez le service VMware VirtualCenter Server avant de désinstaller vCenter Server 4.1.

  • Les instances vCenter Server qui utilisent une base de données DB2 v9.5.0 ne permettent pas d'ajouter un hôte
    Si vous utilisez un système vCenter Server avec un pilote ODBC 64 bits IBM DB2 v9.5.0, vous ne pouvez pas gérer les hôtes pour ce serveur vCenter Server.

    Solution : Appliquez DB2 9.5 Fix Pack 5.

  • L'installation ou la mise à niveau de vCenter Server change sans notification les paramètres Microsoft SQL Server pour activer des canaux nommés
    Lorsque vous installez vCenter Server 4.1 ou passez de vCenter Server 4.0.x à vCenter Server 4.1 sur un hôte qui utilise Microsoft SQL Server avec le paramètre "Utilisation de TCP/IP uniquement", le programme d'installation remplace le paramètre par "Utilisation de TCP/IP et de canaux nommés" et ne signale pas le changement.

    Solution : Cette modification n'affecte pas le fonctionnement de vCenter Server. Toutefois, vous pouvez procéder comme indiqué ci-dessous pour restaurer le paramètre par défaut "Utilisation de TCP/IP uniquement".

    1. Sélectionnez Démarrer > Programmes > Microsoft SQL Server 2005 > Outils de Configuration > Configuration de la surface d'exposition SQL Server.
    2. Sélectionnez Configuration de la surface d'exposition pour les services et connexions.
    3. Sous l'instance SQL Server utilisée pour vCenter Server, sélectionnez Connexions distantes.
    4. Changez l'option sous Connexions locales et distantes et cliquez sur Appliquer.

  • L'installation vCenter Server échoue en générant une erreur indiquant qu'il est impossible de créer l'instance vCenter Directory Services
    Si l'autorisation Tout le monde est supprimée du registre HKLM, l'installation vCenter Server échoue en générant l'erreur Setup cannot create vCenter Directory Services instance.

    Solution : Ajoutez l'autorisation élargie au registre HKLM :

    1. Dans la ligne de commande de Windows, tapez regedit.
    2. Dans l'éditeur de registre, cliquez avec le bouton droit de la souris sur HKEY_LOCAL_MACHINE et sélectionnez Autorisations.
    3. Cliquez sur Ajouter.
    4. Cliquez sur Paramètres avancés.
    5. Sélectionnez Tout le monde dans la liste et cliquez sur OK.
    6. Cliquez sur Appliquer puis sur OK.

  • L'installation de vSphere Client peut échouer en générant l'erreur The Microsoft Visual J# 2.0 Second Edition installer returned error code '4113'
    Lorsque vous installez vSphere Client, le programme d'installation peut tenter de mettre à niveau une exécution Microsoft Visual J# obsolète. La mise à niveau échouera de même que l'installation de vSphere Client.

    Solution : Désinstallez toutes les versions précédentes de Microsoft Visual J# et installez vSphere Client. L'installation inclut un pack mis à jour de Microsoft Visual J#.

  • L'installation de vCenter Server 4.1 utilisant une base de données existante IBM DB2 échoue parfois avec un message d'erreur DB2
    Si vous installez vCenter Server 4.1 en utilisant une base de données vCenter Server DB2 existante, vous devriez recevoir un message d'erreur semblable à celui-ci :

    Erreur de base de données : "Erreur ODBC : (5UA01) - [IBM][CLI Driver][DB2/NT64] SQL20453N La tâche "RULE_TOPN1_DB2USER1" ne peut être supprimée car elle est en cours d'exécution. SQLSTATE=5UA01" de retour lors de l'exécution de l'instruction SQL "CALL CREATE_TOPN_JOB1_PROC()"

    Ce message apparaît quand DB2 rencontre un problème connu IBM. Elle indique qu'une tâche DB2 est en cours d'exécution et que le programme d'installation vCenter Server ne peut pas initialiser la base de données vCenter.

    Solution : pour éliminer le conflit afin d'installer vCenter Server, procédez comme suit :

    1. Si vCenter Server fonctionne, éteignez-le soigneusement.
    2. Utilisez le panneau de contrôle Services pour arrêter et redémarrer le service db2.
    3. Redémarrez l'installation en prenant soin de sélectionner l'option d'écrasement de la base de données existante.

  • L'installation de vCenter Server échoue si le compte utilisateur utilisé pour installer vCenter Server et écraser la base de données DB2 existante n'est pas membre du groupe db2user ou du groupe db2admin
    Erreur 25003 : Création de référentiel impossible s'affiche quand le compte utilisateur utilisé pour installer vCenter Server et écraser la base de données DB2 existante n'est pas membre du groupe db2user ou du groupe db2admin. Cliquer sur OK dans la boîte de dialogue du message d'erreur la ferme et restaure l'installation.

    Solution : Ajoutez l'utilisateur de la base de données aux groupes db2user ou db2admin. Consultez votre administrateur de base de données.

  • Après l'installation ou la mise à niveau vers vCenter Server 4.1 avec une base de données Oracle utilisant un pilote Oracle 64-bit ODBC, vCenter Server peut ne pas se lancer
    Quand vous effectuez une nouvelle installation ou mise à niveau vers vCenter Server 4.1 avec une base de données Oracle utilisant un pilote Oracle 64-bit ODBC, vous pouvez recevoir un message d'erreur, Base de données version id '0' incompatible avec cette édition de VirtualCenter, et le service vCenter Server ne se lance pas.

    Solution : Mettre à niveau vers le pilote 10.2.0.4 ou 11.1 Oracle 64-bit ODBC.

Problèmes de mise à niveau

  • La mise à niveau de vCenter Server se poursuit malgré le changement de port Web Services HTTP ou HTTPS en utilisant un port établi
    Quand vous changez le port Web Services HTTP ou HTTPS en utilisant un port établi sur la page de Configuration des ports, la mise à niveau de vCenter Server se poursuit sans erreur.

    Solution : Aucune.

  • Quand vous mettez à niveau un hôte ESXi 4.0 vers ESXi 4.1 puis que vous le repassez à ESXi 4.0, les versions ESXi 4.1 de VMware Tools et de vSphere Client restent sur l'hôte
    Quand vous mettez à niveau un hôte ESXi 4.0 vers ESXi 4.1, VMware Tools et vSphere Client pour ESXi 4.0 sont supprimés et remplacés par la version ESXi 4.1 de ces composants. Si vous repassez l'hôte à ESXi 4.0, les versions ESXi 4.0 de VMware Tools et vSphere Client ne sont pas restaurées.

    Solution :

    Pour ESXi Embedded :

    1. Sauvegardez la configuration ESXi en utilisant la commande vicfg-cfgbackup.
    2. Réinitialisez la clé USB avec une copie vierge d'ESXi 4.0.
    3. Restaurez la configuration en utilisant la commande vicfg-cfgbackup.
    4. Réenregistrez les machines virtuelles.

    Pour ESXi Installable :

    1. Sauvegardez la configuration ESXi en utilisant la commande vicfg-cfgbackup.
    2. Sauvegardez les banques de données VMFS.
    3. Réinstallez ESXi 4.0.
    4. Restaurez la configuration en utilisant la commande vicfg-cfgbackup.
    5. Restaurez les banques de données VMFS.
    6. Réenregistrez les machines virtuelles.

  • Quand vous redémarrez un hôte ESXi après une mise à niveau réussie vers la version 4.1, un message d'erreur apparaît
    Quand vous redémarrez un hôte ESXi après une mise à niveau réussie par l'utilitaire vihostupdate, le message d'erreur suivant peut apparaître : La nouvelle image de mise à niveau semble corrompue, risque d'échec.

    Cela arrive uniquement lorsque vous mettez à niveau les versions ESXi 4.0 ou 4.0 U1 vers la version 4.1. Cela ne s'applique pas aux mises à niveau depuis 4.0 U2.

    Solution : Vous pouvez ignorer ce message d'erreur et continuer le redémarrage. La mise à niveau sera réussie.

Problèmes de mise en réseau

  • Conflits d'adresse MAC de machine virtuelle
    Chaque système vCenter Server comporte un ID d'instance vCenter Server. Cet ID est un chiffre entre 0 et 63 généré de manière aléatoire lors de l'installation mais il peut être reconfiguré après l'installation.

    vCenter Server utilise l'ID d'instance vCenter pour générer les adresses MAC et les UUID pour les machines virtuelles. Si deux systèmes vCenter Server comportent le même ID d'instance vCenter, ils peuvent générer des adresses MAC identiques pour les machines virtuelles. Ceci peut causer des conflits si les machines virtuelles sont sur le même réseau, entraînant perte de paquets et autres problèmes.

    Solution : Si vous déployez des machines virtuelles des systèmes vCenter Server multiples sur le même réseau, vous devez vous assurer que ces systèmes vCenter Server ont des ID d'instance uniques.

    Pour afficher ou modifier l'ID d'instance vCenter Server :

    1. Ouvrez une session sur vCenter Server à l'aide de vSphere Client, et sélectionnez Administration > Paramètres de vCenter Server.
    2. Sélectionnez Paramètres d'exécution.
      La zone de texte ID unique de vCenter Server affiche l'ID d'instance de vCenter Server en cours.
    3. Si cet ID n'est pas unique, entrez une nouvelle valeur entre 0 et 63 dans la zone de texte ID unique de vCenter et cliquez sur OK.
    4. Si vous modifiez l'ID d'instance de vCenter Server, vous devez redémarrer vCenter Server pour que le changement prenne effet.

    Si vous avez des machines virtuelles existantes dont les adresses MAC sont en conflit, modifiez les adresses MAC pour les rendre uniques :

    1. Assurez-vous que la machine virtuelle est hors tension.
    2. Dans l'inventaire de vSphere Client, cliquez avec le bouton droit sur la machine virtuelle et choisissez Modifier les paramètres.
    3. Dans l'onglet Matériel, sélectionnez l'adaptateur de réseau virtuel de la machine virtuelle.
    4. Dans Adresse MAC, sélectionnez Manuel et entrez une adresse MAC unique.
    5. Cliquez sur OK.

    Vous pouvez également forcer vCenter Server à générer une nouvelle adresse MAC pour l'adaptateur réseau virtuel en configurant l'adaptateur réseau virtuel pour qu'il utilise l'adresse MAC manuelle, puis en le reconfigurant sur Automatique.

  • L'ajout de plusieurs hôtes à un commutateur Cisco Nexus 1000v en une seule fois risque d'échouer
    Si vous essayez d'ajouter plusieurs hôtes avec différents niveaux de mise à jour ou de correction à un commutateur Cisco Nexus 1000v, l'opération risque d'échouer.

    Solution : Ajoutez les hôtes aux niveaux de mise à jour ou de correction différents au commutateur individuellement.

  • Les machines virtuelles perdent leur connexion réseau après ajout ou suppression d'un vmxnet3 NIC avec Wake-On-LAN activé
    Reconfigurer un vmxnet3 NIC pendant que Wake-on-LAN est activé et que la machine virtuelle est en veille cause un mauvais fonctionnement du périphérique, entraînant une perte de connexion réseau pour ce NIC.

    Solution : Modifiez la configuration pour vmxnet3 NIC uniquement quand la machine virtuelle est active.

  • Perte de connectivité réseau et crash du système lors d'opérations de contrôle sur des NIC physiques
    Dans certains cas, quand plusieurs NIC X-Frame II s2io partagent le même bus pci-x, les opérations de contrôle comme le changement de MTU sur le NIC physique provoquent une perte de connectivité réseau et un crash du système.

    Solution : Évitez d'avoir plusieurs NIC X-Frame II s2io dans des emplacements partageant le même bus pci-x. Si une telle configuration est nécessaire, évitez les opérations de contrôle sur les NIC physiques quand les machines virtuelles effectuent des E/S réseau.

  • Problèmes de mémoire lorsqu'un hôte utilise plus de 1 016 dvPorts sur un vDS
    Le nombre maximal de dvPorts par hôte sur vDS est de 4096, mais des problèmes de mémoire peuvent survenir lorsque le nombre de dvPorts d'un hôte est proche de 1600. Dans ce cas, vous ne pouvez pas ajouter des machines virtuelles ni des adaptateurs virtuels au vDS.

    Solution : Configurez un maximum de 1016 dvPorts par hôte sur un vDS.

  • Le clonage échoue sur une machine virtuelle avec une sauvegarde vDS invalide
    Si l'un des adaptateurs réseau d'une machine virtuelle est connecté à un vDS ou un groupe dvPort invalide ou manquant, cette machine virtuelle ne peut pas être clonée.

    Solution : Assurez-vous que tous les adaptateurs réseau d'une machine virtuelle ont une sauvegarde valide avant de cloner la machine virtuelle.

  • Les nouveaux utilisateurs ajoutés avec un rôle en lecture seule peuvent ajouter des NIC VMkerne aux hôtes ESX/ESXi
    Les nouveaux utilisateurs ajoutés avec un rôle en lecture seule ne peuvent pas modifier la configuration des hôtes ESX/ESXi, mais ils peuvent ajouter des NIC VMkernel, ce qui est possible actuellement.

    Solution : Aucune. Ne vous préoccupez pas de ce problème car les utilisateurs en lecture seule ne seront pas en mesure d'ajouter des NIC VMkernel à l'avenir.

  • L'opération de destruction échoue sur les machines virtuelles avec sauvegarde vDS invalide
    Si l'un des périphériques d'une machine virtuelle est connecté à un vDS invalide, une opération de destruction risque de ne pas réussir. La machine virtuelle est détruite sur l'hôte mais reste dans l'inventaire vSphere Client.

    Solution : Pour supprimer la machine virtuelle de l'inventaire vCenter, faites un clic droit sur la machine virtuelle et sélectionnez Supprimer de l'inventaire.

  • De mauvaises performances TCP peuvent survenir sur les machines virtuelles à fort trafic avec LRO activé
    Certains modules Linux ne supportent pas les paquets générés par LRO. De ce fait, avoir LRO activé sur un périphérique VMXNET 2 ou VMXNET 3 sur une machine virtuelle à fort trafic sous système d'exploitation client Linux peut entraîner de mauvaises performances TCP. LRO est activé par défaut sur ces périphériques.

    Solution : Dans les machines virtuelles de réacheminement du trafic qui exécutent des clients Linux, incluez disable_lro=1 dans le paramètre de délai de chargement de module du pilote Linux VMXNET 2 ou VMWNET 3.

Problèmes de stockage

  • Les machines peuvent fonctionner en lecture seule lorsqu'elles sont exécutées sur une banque de données iSCSI déployée sur la solution de stockage EqualLogic
    Les machines virtuelles peuvent fonctionner en lecture seule si vous utilisez un module EqualLogic avec une ancienne version du microprogramme. Le microprogramme peut éventuellement supprimer l'E/S de la file d'attente du module et amener les machines virtuelles à indiquer que l'E/S a échoué et à passer en mode Lecture seule.

    Solution : mettez à niveau le microprogramme du module EqualLogic vers la version 4.1.4 ou une version ultérieure.

  • Après la mise à niveau de l'étalage de stockage, l'état d'accélération matérielle dans vSphere Client passe à supporté après un court délai
    Quand vous mettez à niveau le firmware d'un étalage de stockage vers une version supportant la fonctionnalité VAAI, vSphere 4.1 n'enregistre pas immédiatement le changement. vSphere Client affiche temporairement l'état Inconnu pour l'Accélération Matérielle.

    Solution : Ce délai est sans incidence. L'état d'accélération matérielle passe à Supporté après une courte période.

  • Grand nombre de messages relatifs au stockage dans le fichier de connexion vmkernel
    Quand ESX ou ESXi démarre sur un hôte avec plusieurs chemins physiques vers les périphériques de stockage, le fichier de connexion vmkernel enregistre un grand nombre de messages relatifs au stockage, similaires au suivant :

    Nov 3 23:10:19 vmkernel: 0:00:00:44.917 cpu2:4347)Vob: ImplContextAddList:1222: Vob add (@&!*@*@(vob.scsi.scsipath.add)Add path: %s) failed: VOB context overflow

    Le système peut consigner des messages similaires au cours des réanalyses du stockage. Ces messages sont normaux et n'indiquent pas de mauvais fonctionnement. Ils sont sans incidence et peuvent être tranquillement ignorés.

    Solution : Désactivez leur affichage si vous ne souhaitez plus les voir.

  • Les conflits permanents de réservations sur des LUN partagés peuvent rendre le démarrage des hôtes ESX et ESXi plus long
    Vous pourriez ressentir un temps conséquent lors du démarrage de vos hôtes partageant les LUN sur un SAN. Cette situation peut être provoquée par des conflits entre les réservations LUN SCSI.

    Solution : Pour résoudre ce problème et rendre le démarrage plus rapide, changez le délai de commandes synchronisées lors du démarrage à 10 secondes. Pour ce faire, réglez le paramètre Scsi.CRTimeoutDuringBoot à 10000.

    Pour modifier le paramètre depuis le vSphere Client :

    1. Dans le panneau d'inventaire de vSphere Client, sélectionnez l'hôte, cliquez sur l'onglet Configuration, puis sur Paramètres avancés sous Software.
    2. Sélectionnez SCSI.
    3. Changez la valeur Scsi.CRTimeoutDuringBoot pour 10000.
Problèmes de configuration de serveur

  • L'application de profils et la vérification de la conformité des profils échouent pour les profils d'hôte après la mise à niveau de la règle PnicsByName dans DvsProfile
    Après la mise à jour de la règle PnicsByName de DvsProfile, l'application de profils d'hôte et la vérification de la conformité des profils d'hôte échouent. Cet échec se produit lorsque plusieurs NIC physiques sont entrés. Bien que l'interface utilisateur permette d'utiliser plusieurs NIC physiques, une seule NIC physique peut être ajoutée pour la règle PnicsByName dans DvsProfile.

    Solution : ajoutez une seule NIC physique pour la règle.

Problèmes vCenter Server et vSphere Client

  • Les données de performance antérieures à un jour ne sont pas disponibles pour certaines entités quand vCenter Server est configuré pour utiliser DB2
    Les données de performance antérieures à un jour ne sont pas disponibles pour certaines entités quand vCenter Server est configuré pour utiliser DB2.

    REMARQUE : Le paramètre UTIL_HEAP_SZ attribue de la mémoire. Ce paramètre peut être réglé pour augmenter l'attribution de mémoire pour DB2. Réduisez diaglevel à 3 pour réduire la taille de diag.log et la génération excessive. Cela permet à DB2 de travailler en arrière-plan. Reportez-vous à http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/c0005389.htm pour les paramètres spécifiques DB2.

    Solution : Si vous utilisez DB2 9.5, mettez à niveau vers DB2 9.5 Fix Pack 5.

  • Les connexions à chaud échouent après la relocation du fichier échange
    Les connexions à chaud échoueront pour les machines virtuelles actives sur un cluster DRS, ou sur un hôte autonome, avec une erreur échec de la recherche de destination ; VM introuvable après le changement de location du fichier échange.

    Solution : Essayez ceci :

    • Redémarrez les machines virtuelles affectées pour y enregistrer le nouvel emplacement du fichier échange, puis effectuez les connexions à chaud.
    • Déplacez les machines virtuelles affectées en utilisant vMotion.
    • Interrompez les machines virtuelles affectées.

  • Les caractères composés et accentués ne s'affichent pas dans l'index de l'Aide en ligne en français
    Les caractères composés et accentués comme Æ et Œ ne s'affichent pas dans les index de l'Aide en ligne en français de vSphere Client, du Dépannage DRS, des diagrammes de performances de présentation et de Web Access.

    Solution : Aucune.

  • Dans Windows Vista, toutes les touches d'Aide dans Update Manager Client ouvrent la page d'aide par défaut de Update Manager
    Si vous utilisez les navigateurs Internet Explorer 7 installés sur les machines Windows Vista, l'aide contextuelle de vCenter Update Manager n'affiche pas les pages d'aide demandées. À la place, l'aide affiche la page d'aide Introduction à Update Manager.

    Solution : Appliquez le Service Pack 2 à Windows Vista. Pour plus de détails, voir l'article de la base de connaissance Microsoft suivant http://support.microsoft.com/kb/942172.

  • Erreur lors du chargement des données de diagrammes de performances quand vCenter Server utilise une base de données SQL Server personnalisée avec un port JDBC personnalisé
    Si une instance personnalisée SQL Server est installée avec vCenter Server et configurée pour utiliser un port JDBC personnalisé, le système affiche l'erreur Erreur interne du service de diagrammes de performances au lieu des données graphiques.

    Solution :

    1. Sur le système vCenter Server, naviguez vers C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter.
    2. Ouvrez le fichier vcdb.properties.
    3. Commentez la ligne usevcdb = true.
    4. Assurez-vous que les valeurs url, driver et dbtype sont comme suit :
      url = jdbc:sqlserver://:;integratedSecurity=true
      driver = com.microsoft.sqlserver.jdbc.SQLServerDriver
      dbtype = mssql
    5. Réglez le paramètre integratedSecurity sur true si la base de données se trouve sur la machine locale ou sur false si la base de données est distante.
    6. Redémarrez le service VMware VirtualCenter Management WebServices.

     

    REMARQUE : Ce problème ne se pose pas avec les bases de données Oracle ou DB2 configurées avec des ports JDBC personnalisés.

  • Le diagramme de performances de banque de données montre des données incorrectes
    Si vous ouvrez l'onglet Performance dans l'inventaire de banque de données de vSphere Client, quatre diagrammes s'affichent. Les titres de ces graphiques ne sont pas corrects et devraient se lire ainsi :

    • Latence Max par Hôte
    • Attente Max par Hôte
    • Nombre de lectures par Hôte
    • Nombre d'écritures par hôte

    Dans certains cas le résumé n'affiche pas tous les hôtes, ce qui est un problème connu.

    Solution : Pour voir les informations correctes pour chaque hôte associé à une banque de données, passez sur l'inventaire Hôte et Clusters, sélectionnez l'onglet Performance et regardez le compteur correspondant.

  • Problèmes lors de l'installation ou de l'exécution de vCenter Server, VMware Update Manager ou VMware Converter sur un système d'exploitation utilisant l'environnement local tchèque
    Si vous tentez d'installer vCenter Server, Update Manager ou VMware Converter sur un système d'exploitation en utilisant l'environnement tchèque, vous ne pouvez pas installer le produit ou des problèmes de fonctionnement apparaissent lorsque vous tentez d'utiliser le produit.

    Solution : Aucune pour les systèmes d'exploitation utilisant le tchèque. Utilisez le système d'exploitation en anglais pour évaluer le produit.

  • Échec en essayant de rejoindre une instance vCenter Server invitée sur un système fonctionnant avec Windows Server 2008 avec le contrôle des comptes utilisateurs activé via Linked Group
    Si vous rejoignez ou isolez un système Windows Server 2008 avec contrôle des comptes utilisateurs (UAC) de groupe Linked Mode, l'opération échoue sans message d'erreur.

    Solution : Suivez les étapes :

    1. Désactivez le contrôle des comptes utilisateurs (UAC) avant de rejoindre un groupe Linked Mode de la façon suivante :
      1. Ouvrez le Panneau de configuration Windows.
      2. Sélectionnez Démarrer > Paramètres > Panneau de configuration > Comptes utilisateur.
      3. Réglez le contrôle des comptes utilisateurs.
      4. Décochez contrôle des comptes utilisateurs (UAC) pour protéger votre ordinateur et cliquez sur OK.
      5. Redémarrez la machine.

      2.  

    2. Démarrer la configuration Linked Mode comme suit :
      1. Sélectionnez Démarrer > Tous les programmes > VMware > Configuration vCenter Server Linked Mode et cliquez sur Suivant.
      2. Sélectionnez Modifier la configuration Linked-Mode et cliquez sur Suivant.
      3. Cliquez sur Joindre cette instance vCenter Server à un groupe Linked-Mode existant ou à une autre instance et cliquez sur Suivant.
      4. Entrez le nom de serveur et les informations de port LDAP et cliquez sur Suivant.
      5. Cliquez sur Terminer.
      6. Cliquez sur Continuer et suivez les invites d'installation.

      3.  

    3. Connectez-vous à l'un des serveurs vCenter Server et vérifiez que les serveurs sont liés.
    4. Une fois les serveurs vCenter Server liés, activez l'UAC.
      1. Sélectionnez Démarrer > Paramètres > Panneau de configuration > Comptes utilisateur.
      2. Sélectionnez Activation ou désactivation contrôle des comptes utilisateurs.
      3. Sélectionnez contrôle des comptes utilisateurs (UAC) pour protéger votre ordinateur et cliquez sur OK.
      4. Redémarrez la machine.

      5.  

  • Une erreur se produit lors du redémarrage du service VMware VirtualCenter ou Web VMware Web depuis le panneau des services Windows
    Lorsque vous redémarrez le service VMware VirtualCenter ou Web VMware depuis le panneau de configuration Windows, le message suivant s'affiche :
    Error 1053: Le service ne répond pas à la demande de démarrage ou de contrôle.

    Solution : Modifiez deux clés de registre sur l'hôte vCenter Server affecté en procédant comme suit :

    1. Lancez regedit et localisez la clé suivante dans le registre :

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\vctomcat\Parameters

    2. Ajoutez les valeurs de registre (DWORD) suivantes :

      Value Name: WaitHintStart
      Value: < Durée du démarrage du service en millisecondes>

      Value Name: WaitHintStop
      Value: < Durée de fermeture du service en millisecondes>

      Dans les deux cas, la durée devrait être supérieure à 40 secondes.

    3. Localisez la clé suivante dans le registre :

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\vpxd\Parameters

    4. Ajoutez les valeurs de registre (DWORD) suivantes :

      Value Name: WaitHintStart
      Value: < Durée du démarrage du service en millisecondes>

      Value Name: WaitHintStop
      Value: < Durée de fermeture du service en millisecondes>

      Dans les deux cas, la durée devrait être supérieure à 40 secondes.

  • Changer les paramètres réseau d'un hôte ESXi empêche certains logiciels de surveillance du matériel de le détecter automatiquement
    Après le changement des paramètres réseau d'un hôte ESXi, les outils de gestion tiers basés sur l'interface CIM (généralement : les outils de surveillance du matériel) sont incapables de détecter automatiquement l'hôte à travers le Service Location Protocol (SLP).

    Solution : entrez manuellement le nom ou l'adresse IP de l'hôte dans l'outil de gestion tiers. Vous pouvez aussi redémarrer slpd et sfcbd-watchdog en utilisant l'une des méthodes suivantes :

    • Passez en mode Support technique et exécutez les commandes suivantes :

      • /etc/init.d/slpd restart
      /etc/init.d/sfcbd-watchdog restart
    • Redémarrez les agents de gestion sur l'interface utilisateur de la console directe (DCUI). Cela redémarrera les autres agents sur l'hôte en plus de ceux affectés par ce défaut et risque d'être davantage perturbateur.

  • Lors de l'utilisation de DB2, le service vCenter Server ne redémarre pas automatiquement après restauration de la connectivité du réseau
    Si vous perdez la connexion réseau à un système vCenter Server configuré avec une base de données IBM DB2, vous ne serez pas en mesure de démarrer le service vCenter Server après restauration de la connectivité du réseau.

    Solution :

    1. Fermez toutes les connexions existantes entre la machine vCenter Server et la base de données IBM DB2 en utilisant l'utilitaire Application List.
    2. Connectez-vous à la base de données DB2 UDB en tant que dbadm, propriétaire de l'instance, ou en tant que propriétaire de la base de données.
    3. Exécutez la commande suivante pour obtenir des informations sur l'utilisateur que vous souhaitez déconnecter de la base de données : db2 list applications

      Un message de ce type apparaît :
      Auth Id         Application     Appl.           Application Id
                      Name            Handle
      --------        --------------  ----------      --------------------------
      VPX             db2bp.exe       3428            *LOCAL.DB2.100225221240
    4. Notez le numéro de descripteur d'application et utilisez-le pour résoudre la commande de déconnexion suivante : force application <application_handle_number>
Problèmes de migration

  • La migration d'une machine virtuelle éteinte ou interrompue ESX 3.x avec des snapshots vers une autre banque de données risque de rendre la machine virtuelle cible inutilisable
    Si vous essayez de déplacer une machine virtuelle éteinte ou interrompue ESX 3.x avec des snapshots vers une autre banque de données, vous risquez de voir le message d'avertissement suivant :
    Cette machine virtuelle a des snapshots. La déplacer vers une autre banque de données risque de la rendre inutilisable. Consultez la Base de connaissances VMware pour plus d'informations.

    Si vous avez terminé la migration de la machine virtuelle, vous devriez voir le message d'erreur suivant en essayant de mettre la machine virtuelle sous tension :
    Fichier introuvable

    Solution : Voir KB 1020709.

  • Après migration d'une machine virtuelle, les périphériques USB sur l'hôte de destination peuvent assignés à tort à la machine virtuelle
    Après la migration d'une machine virtuelle avec des périphériques USB connectés à l'hôte et l'ajout de périphériques USB à la machine virtuelle déplacée vers l'hôte de destination, les périphériques USB sur l'hôte de destination peuvent être assignés à tort à la machine virtuelle.

    Solution : Assignez les périphériques USB à une machine virtuelle locale non déplacée depuis un autre hôte pour les empêcher d'apparaître comme assignés à la machine virtuelle déplacée. Il n'existe pas de solution pour permettre à ces périphériques d'être assignés à la machine virtuelle déplacée.

Problèmes VMware HA et tolérance aux pannes

  • L'hôte ESXi peut signaler des erreurs VMware HA s'il est redémarré dans les 10 minutes qui suivent la configuration HA
    Une erreur logique existe dans la persistance de l'état HA. Quand l'hôte redémarre peu au terme de la configuration HA, il ne trouve par les informations de configuration de cluster et ne parvient pas à lancer l'agent HA.

    Solution : Attendez plus de 10 minutes avant de mettre l'hôte hors tension après la fin de la configuration HA.

Problèmes de système d'exploitation client

  • La compilation de modules VMware kernel est supportée uniquement pour le kernel fonctionnant
    VMware supporte actuellement la compilation de modules kernel uniquement pour le kernel en fonctionnement.

    Solution : Démarrez le kernel avant de compiler les modules pour ce kernel.

  • Le programme d'installation RPM pour VMware Tools pour RHEL3, RHEL4 et SLES9 échoue à la vérification de la signature de package
    Quand vous utilisez le programme d'installation RPM pour installer VMware Tools pour RHEL3, RHEL4 et SLES9, la vérification de signature échoue avec le message V3 RSA/MD5 signature: NOKEY, key ID 66fd4949. Cette situation se produit, car les anciennes versions de RPM ne peuvent pas vérifier les signatures RSA créées par les nouvelles versions de RPM. L'échec de la vérification de signature de package n'empêche pas VMware Tools de s'installer avec succès.

    Solution : Utilisez RPM 4.4.2 ou ultérieur pour vérifier les packages.

  • L'installation de VMware Tools Operating System Specific Packages (OSPs) sur SUSE Linux 9 provoque une erreur de résolution écran
    Lorsque vous installez VMware Tools OSP dans SUSE Linux 9, le système d'exploitation configure le fichier du système X Window /etc/X11/XF86Config et remplace le pilote vidéo vesa par celui de VMware. Si vous utilisez un autre pilote vidéo que vesa, VMware Tools OSP ne le remplace pas. Les tentatives pour changer la résolution d'écran en utilisant la commande GUI ou Linux xrandr échouent.

    Solution : Modifiez le fichier /etc/X11/XF86Config pour utiliser le pilote vidéo VMware.

    1. Connectez-vous au fichier du système X Window /etc/X11/XF86Config en tant que racine.
    2. Recherchez la section des périphériques.
    3. Recherchez l'entrée de pilote ou créez-la si elle n'existe pas.
    4. Définissez l'entrée de pilote vesa.
      Après la modification, le pilote apparaît dans la section des périphériques comme Driver vesa.
    5. Redémarrez le système X Window pour sauvegarder les changements et appliquez les nouveaux paramètres.

  • L'installation des packages VMware Tools OSP sur les systèmes d'exploitation client SLES 11 produit un message "Packages non pris en charge"
    L'installation des packages VMware Tools OSP sur un système d'exploitation client SUSE Linux Enterprise Server 11 produit un message d'erreur, Les packages suivants ne sont pas supportés par leur fournisseur.

    Solution : Ignorez ce message. Les packages OSP ne contiennent pas de balise signalant qu'ils sont supportés par le fournisseur. Cependant, ces packages sont supportés.

  • Le système d'exploitation client ne répond pas après l'ajout à chaud de mémoire pour la faire passer de moins 3 Go à plus de 3 Go
    Le système d'exploitation client Redhat5.4-64 peut ne pas répondre s'il est démarré avec un périphérique IDE connecté et que vous faites passer la mémoire de moins de 3 Go à plus de 3 Go.

    Solution : N'utilisez pas d'ajout de mémoire à chaud pour modifier la taille de la machine virtuelle de moins de 3072 Mo à plus de 3072 Mo. Éteignez la machine virtuelle pour effectuer cette reconfiguration.

    Si l'OS client ne répond déjà plus, redémarrez la machine virtuelle. Ce problème ne se produit que lorsque le repère de 3 Go est franchi pendant que le système d'exploitation fonctionne.

  • Erreur d'installation du système d'exploitation client Windows NT avec le matériel des machines virtuelles version 7
    Quand vous installez Windows NT 3.51 sur une machine virtuelle de matériel version 7, la procédure d'installation s'interrompt. Cela arrive immédiatement après l'écran de démarrage bleu avec l'apparition de la version Windows NT 3.51. Il s'agit d'un problème connu dans le kernel Windows NT 3.51. Les machines virtuelles de matériel version 7 ont plus de 34 bus PCI et le kernel Windows NT supporte les hôtes limités à 8 bus PCI.

    Solution : S'il s'agit d'une nouvelle installation, effacez la machine virtuelle existante et créez-en une nouvelle. Au cours de la création de la machine virtuelle, sélectionnez la version matérielle 4. Vous devez utiliser l'assistant de nouvelle machine virtuelle pour sélectionner un chemin personnalisé pour changer la version matérielle.

    Si vous avez créé la machine virtuelle avec la version 4 puis mis à niveau vers la version 7, utilisez VMware vCenter Converter pour rétrograder la machine virtuelle au matériel version 4.

Problèmes de matériel supporté

  • Nouveauté : L'installation ou la mise à niveau échoue avec un écran diagnostic violet sur les hôtes ESX/ESXi équipés de cartes réseau HP NC522SFP
    Sur certains hôtes ESX/ESXi équipés de cartes réseau NC522SFP, le pilote de boîte de réception NetXen échoue le chargement du microprogramme entraînant l'échec de l'hôte avec un écran diagnostic violet pendant le processus d'installation ou de mise à niveau ESX/ESXi. L'hôte affiche un message comme suit loading 32.networking-drivers.

    Solution : Exécutez une des procédures suivantes comme il se doit :

    • ESX. À l'invite du pilote au moment de l'installation ou de la mise à niveau, installez le pilote async fournit sur cette page : CD Pilote VMware ESX/ESXi 4.0 pour les Adaptateurs Ethernet QLogic Intelligent. Vous devez sélectionner la version 507 ou supérieure pour le pilote.

    • ESXi Embedded. Contactez votre fournisseur d'hôte pour obtenir une image système personnalisée qui comprend le pilote approprié.

    • ESXi Installable. ESXi Installable prend en charge la carte NC522SFP seulement si l'hôte comporte au moins une autre carte réseau d'un type différent. Si votre hôte répond à ce critère, exécutez les étapes suivantes :

      1. Désactivez la carte réseau NC522SFP ou supprimez-la de l'hôte.
      2. Installez ou mettez à niveau ESXi Installable sur l'hôte.
      3. À la fin de l'installation ou de la mise à niveau, installez le pilote async fournit sur cette page : CD Pilote VMware ESX/ESXi 4.0 pour les Adaptateurs Ethernet QLogic Intelligent. Vous devez sélectionner la version 507 ou supérieure pour le pilote.
      4. Réactivez ou réinstallez la carte réseau NC522SFP dans l'hôte.

      Si votre hôte ESXi Installable ne comporte pas de carte réseau autre qu'une NC522SFP, il n'y a aucune solution.

    Voir aussi KB 1026431.

  • Erreurs de mappage de périphérique PCI sur le serveur HP 370 G6
    Lorsque vous exécutez des opérations E/S sur le serveur HP 370 G6, un écran violet ou des alertes peuvent s'afficher sur la console au sujet de l'interruption Lint1 ou de NMI. Le serveur HP ProLiant DL370 G6 a deux hub E/S Intel (IOH) et un défaut de BIOS dans les définitions de structure ACPI Direct Memory Access Rempang (DMAR), entraînant une description incorrecte de certains périphériques PCI sous la mauvaise unité de remappage DMA. Tout accès DMA par ces périphériques incorrectement décrits provoque une faute IOMMU et le périphérique recevra une erreur E/S. Selon le périphérique, cette erreur E/S peut provoquer un message d'alerte NMI ou Lint1 Interrupt sur la console ou le système peut se figer sur un écran pourpre.

    Solution : Consultez le site HP pour la disponibilité d'un correctif BIOS pour le serveur HP ProLiant DL370 G6. Si aucun correctif n'est disponible, désactivez 'Intel(R) VT-d' dans le BIOS pour que le BIOS ne publie par des structures DMAR dans les tables ACPI.

  • Les installations ESXi sur les systèmes HP nécessitent le pilote HP NMI
    Les instances ESXi 4.1 sur les systèmes HP nécessitent le pilote HP NMI pour assurer le bon fonctionnement des NMI. Le pilote NMI garantit que les NMI sont bien détectés et connectés. Sans ce pilote, les NMI signalant des erreurs matérielles sont ignorés par les systèmes HP avec ESXi.

    ATTENTION : L'échec de l'installation de ce pilote risque de provoquer une discrète corruption des données.

    Solution : Téléchargez et installez le pilote NMI. Le pilote est disponible en tant que package hors-ligne sur le site Web HP. Voir aussi KB 1021609.

Problèmes d'internationalisation

  • Les options de menu déroulant de l'écran d'interface utilisateur des règles DRS ne sont pas traduites correctement.
    Quand vous créez une règle DRS VM/Hôte avec une interface utilisateur qui n'est pas en anglais, les options de listes déroulantes sont incompréhensibles.

    Solution : Aucune.

Problèmes vSphere Command-Line Interface

  • Longueur d'ID de groupe dans vSphere Client plus courte que dans vCLI. Si vous spécifiez une ID de groupe en utilisant vSphere Client, seuls neuf caractères sont autorisés. Cela étant, vous pouvez spécifier jusqu'à dix caractères si vous spécifiez l'ID de groupe en utilisant vCLI vicfg-user.

    Solution : Aucune.

  • L'exécution de esxtop pendant de longues périodes peut générer des problèmes de mémoire
    L'utilisation de la mémoire par esxtop peut augmenter au fil du temps en fonction des opérations en cours sur le système ESX/ESXi surveillé. Parce que resxtop provoque également une large sollicitation du CPU sur ESXi, VMware vous recommande de ne pas laisser resxtop fonctionner sur une très longue période (comme plusieurs semaines).

    Le nombre total d'itérations d'ESXi 4.1 (-n) est réglé sur une valeur par défaut de 10 000. Après génération de 10 000 affichages par resxtop, celui-ci s'éteint automatiquement. Cela implique que si un délai par défaut de 5 secondes entre deux affichages est utilisé, resxtop devrait s'arrêter après environ 14 heures.

    Solution : Bien que vous puissiez utiliser l'option -n pour changer le nombre total d'itérations, il est préférable d'exécuter resxtop seulement si vous avez besoin des données. Si vous avez vraiment besoin de collecter les statistiques resxtop sur une longue période, éteignez et redémarrez resxtop régulièrement au lieu d'exécuter une instance resxtop pendant des semaines ou des mois.

Problèmes divers

  • Les règles DRS DVM/Hôte sont toujours de mise si DRS est désactivé
    Si vous avez spécifié une règle DRS VM/Hôtes DRS pour un cluster DRS, si DRS est désactivé, cette règle s'applique toujours. De la même façon, si vous mettez sous tension manuellement une machine virtuelle spécifiée dans ce genre de règle, une erreur surviendra si cette opération viole la règle.

    Solution : Désactivez manuellement la règle dans la boîte de dialogue Paramètres du cluster.