Notes de mise à jour de VMware vCenter Site Recovery Manager 5.1.2

Nous contacter

VMware vCenter Site Recovery Manager 5.1.2.2 | 01 octobre 2014 | Build 2170716

VMware vCenter Site Recovery Manager 5.1.2.1 | 22 juillet 2014 | Build 1964824

VMware vCenter Site Recovery Manager 5.1.2 | 16 janvier 2014 | Build 1527967

Dernière mise à jour : 9 mars 2016

Vérifiez les compléments et les mises à jour pour ces notes de mise à jour.

Pour obtenir des informations sur les versions de correctif Site Recovery Manager 5.1.2.x, notamment des détails sur n'importe quel correctif vSphere Replication 5.1.2.x requis, consultez les articles correspondants de la base de connaissances.

Contenu des notes de mise à jour

Ces mises à jour contiennent les rubriques suivantes :

Nouveautés dans SRM 5.1.2

VMware vCenter Site Recovery Manager 5.1.2 contient des corrections de bogue décrites dans Problèmes résolus.

Localisation

VMware vCenter Site Recovery Manager 5.1.2 est disponible dans les langues suivantes :

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

Compatibilité

Matrice de compatibilité SRM

Pour les informations sur l'interopérabilité et la compatibilité des produits, et notamment les systèmes d'exploitation clients pris en charge et la prise en charge de la personnalisation des systèmes d'exploitation clients, consultez la section Matrices de compatibilité de VMware vCenter Site Recovery Manager  5.1.

Baies de stockage et adaptateurs de réplication de stockage compatibles

Pour afficher la liste actuelle des baies de stockage et SRA compatibles pris en charge, référez-vous à la section Guide de compatibilité des partenaires de stockage de Site Recovery Manager.

Support de VSA de VMware

SRM 5.1.2 peut protéger des machines virtuelles résidant dans VSA (vSphere Storage Appliance) à l'aide de vSphere Replication. VSA ne nécessite pas d'adaptateur de réplication de stockage (SRA) pour fonctionner avec SRM 5.1.2.

Installation et mise à niveau

Pour obtenir un guide d'évaluation vous proposant une présentation technique des fonctions et capacités majeures de Site Recovery Manager 5.1.2, consultez la section Ressources VMware vCenter Site Recovery Manager.

Pour les chemins de mise à niveau pris en charge pour SRM, consultez la section Matrices d’interopérabilité des produits VMware et sélectionnez Solution chemin de mise à niveau et VMware vCenter Site Recovery Manager.

Installation de SRM 5.1.2

Pour créer une nouvelle installation de SRM 5.1.2, téléchargez et exécutez le programme d'installation VMware-srm-5.1.2-1527967.exe.

Voir la section Installation de SRM dans Installation et configuration de Site Recovery Manager 5,1.

Mise à niveau d'une installation existante de SRM 4.1.2 vers SRM 5.1.2

Effectuez une mise à niveau de SRM 4.1.2 vers SRM 5.0.x avant d'installer SRM 5.1.2.

Voir la section Mise à niveau de SRM dans le Guide d'administration de Site Recovery Manager  5.0.

IMPORTANT : La mise à niveau de vCenter Server directement depuis la version 4.1.2 vers la version 5.1.2 est un chemin de mise à niveau pris en charge. Cependant, la mise à niveau de SRM directement depuis la version 4.1.2 vers la version 5.1.2 n'est pas un chemin de mise à niveau pris en charge, et vous devez procéder à une mise à niveau vers SRM 5.0.x avant d'effectuer la mise à niveau vers 5.1.2. Lors de la mise à niveau d'une instance de vCenter Server 4.1.2 qui inclut une installation de SRM 4.1.2, vous devez également mettre à niveau vCenter Server vers la version 5.0.x avant de procéder à la mise à niveau de SRM vers la version 5.0.x. Si vous effectuez une mise à niveau de vCenter Server version 4.1.2 directement vers la version 5.1.x, lorsque vous tentez d'effectuer la mise à niveau de SRM version 4.1.2 vers la version 5.0.x, la mise à niveau de SRM échoue. SRM 5.0.x ne peut pas se connecter à une instance de vCenter Server 5.1.x.

Mise à niveau d'une installation existante de SRM 5.0.x vers SRM 5.1.2

Pour mettre à niveau une installation existante de SRM 5.0.x vers SRM 5.1.2, téléchargez et exécutez le programme d'installation VMware-srm-5.1.2-1527967.exe.

Voir la section Mise à niveau de SRM dans Installation et configuration de Site Recovery Manager  5,1.

Mise à niveau d'une installation existante de SRM 5.1.x vers SRM 5.1.2

Pour mettre à niveau une installation existante de SRM 5.1 vers SRM 5.1.2, procédez comme suit.

  1. Connectez-vous à la machine sur laquelle vous exécutez SRM Server sur le site protégé.
  2. Sauvegardez la base de données SRM en utilisant les outils fournis par votre logiciel de base de données.
  3. Téléchargez et exécutez le programme d'installation VMware-srm-5.1.2-1527967.exe.
  4. Cliquez sur Oui lorsque vous êtes invité à confirmer que vous souhaitez mettre à niveau SRM.
  5. Cliquez sur Oui pour confirmer que vous avez sauvegardé la base de données SRM.
  6. Cliquez sur Terminer une fois l'installation effectuée.
  7. Répétez le processus de mise à niveau sur le site de récupération.

Après la mise à niveau du serveur SRM, vous devez réinstaller le plug-in du client SRM.

  1. Connectez-vous à une machine sur laquelle vous exécutez une instance de vSphere Client que vous utilisez pour vous connecter à SRM.
  2. Désinstallez le plug-in du client SRM 5.1.
  3. Connectez-vous à une instance de vSphere Client et au vCenter Server auquel SRM Server est connecté.
  4. Sélectionnez Plug-ins > Gérer les plug-ins.
  5. Cliquez sur Télécharger et installer pour installer le plug-in du client SRM 5.1.2.
  6. Lorsque l'installation du plug-in a été effectuée, connectez-vous à SRM et vérifiez que la configuration de la version précédente a été conservée.
  7. Répétez le processus pour toutes les instances de vSphere Client que vous utilisez pour vous connecter à SRM Server.

Mise à niveau de vSphere Replication vers vSphere Replication 5.1.2

Si vous avez installé une version précédente de vSphere Replication et que vous effectuez la mise à niveau vers SRM 5.1.2, vous devez effectuer la mise à niveau de vSphere Replication vers la version 5.1.2. Vous devez également mettre à niveau les serveurs vSphere Replication vers la version 5.1.2 et vous assurer que vous avez effectué la mise à niveau vers SRM 5.1.2 avant de mettre à niveau vSphere Replication vers la version 5.1.2.

Voir la section Mise à niveau de vSphere Replication dans Installation et configuration de Site Recovery Manager.

Pour mettre à niveau le dispositif vSphere Replication et tout serveur vSphere Replication supplémentaire vers la version 5.1.2 via l'interface VAMI (Virtual Appliance Management Interface), utilisez l'URL suivante :

http://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/5.1.2.0

REMARQUE : Pour obtenir l'URL de la mise à niveau via l'interface VAMI pour une version de correctif vSphere Replication 5.1.2.x, consultez l'article de la base de connaissances sur la version de correctif Site Recovery Manager 5.1.2.x correspondante.

IMPORTANT : Ne sélectionnez pas l'option dans Mise à jour > Paramètres dans l'interface VAMI pour mettre à jour automatiquement vSphere Replication. Si vous optez pour les mises à jour automatiques, l'interface VAMI met à jour vSphere Replication vers la version 5.x la plus récente, qui peut être incompatible avec SRM et vCenter Server 5.1.x. Vous devez par conséquent laisser le paramètre de mise à jour défini sur Aucune mise à jour automatique.

Restrictions de fonctionnement pour SRM et vSphere Replication

Pour connaître les restrictions de fonctionnement de SRM 5,1.x et de vSphere Replication 5,1.x, voir http://kb.vmware.com/kb/2034768.

SRM SDK

Pour consulter un guide d'utilisation de l'API basée sur SRM SOAP, consultez la section API de VMware vCenter Site Recovery Manager.

Composants Open Source

Les déclarations de copyright et les licences applicables aux composants logiciels en libre accès distribués dans Site Recovery Manager 5.1.2 sont disponibles dans la page Télécharger VMware vCenter Site Recovery Manager. Vous pouvez également télécharger les fichiers sources pour toute licence GPL, toute licence LGPL, ou d'autres licences similaires qui nécessitent la mise à disposition du code source ou des modifications du code source pour la sortie la plus récente de vCenter Site Recovery Manager qui est disponible en général.

Mises en garde et limites

  • Interopérabilité avec Storage vMotion et Storage DRS
    En raison de certains cas spécifiques et limités où la récupérabilité peut être compromise durant le mouvement de stockage, l'utilisation de Site Recovery Manager 5.1.2 n'est prise en charge ni avec Storage vMotion (SVmotion) ni avec SDRS (Storage Distributed Resource Scheduler), notamment l'utilisation de clusters de banque de données.

  • Interopérabilité avec vCloud Director
    Site Recovery Manager 5.1.2 fournit une prise en charge limitée des environnements vCloud Director. Il n'est pas possible d'utiliser SRM pour protéger les machines virtuelles dans les pools de ressources vCloud (machines virtuelles déployées dans une organisation). Il est possible d'utiliser SRM pour protéger la structure de gestion de vCD. Pour plus d'informations sur l'utilisation de SRM pour protéger les instances vCD Server et vCenter Server, ainsi que les bases de données qui fournissent l'infrastructure de gestion pour vCloud Director, voir Étude de cas de résilience de l'infrastructure VMware vCloud Director.

  • Interopérabilité avec vSphere Replication
    vSphere Replication prend en charge une taille maximale de disque de 2 032 Go.

  • SRM 5.1.2 prend en charge 2 nœuds MSCS (Microsoft Cluster Server)
    vSphere 5.1.x prend en charge jusqu'à 5 nœuds MSCS. SRM 5.1.x prend en charge 2 nœuds MSCS. Consultez la section Protection de MSCS et des machines virtuelles à tolérance de panne dans Administration de Site Recovery Manager.

  • Le dispositif vSphere Replication et les dispositifs du serveur vSphere Replication sont soumis à l'avis de sécurité Novell CVE-2008-5161
    L'avis de sécurité Novell CVE-2008-5161 fait référence au SUSE Linux Enterprise Server (SLES) SP1, le système d'exploitation pour le dispositif vSphere Replication et les dispositifs du serveur vSphere Replication. Novell indique dans le document d'avis, disponible à l'adresse http://support.novell.com/security/cve/CVE-2008-5161.html, que les risques de sécurité sont faibles. Si nécessaire, afin de réduire davantage les risques de sécurité, vous pouvez suivre l'avis Novell pour modifier vos configurations SSH. Pour le dispositif vSphere Replication et les dispositifs du serveur vSphere Replication, vous pouvez simplement conserver les chiffrements AES en ajoutant la directive suivante dans les fichiers sshd_config et ssh_config :

    • Ciphers aes128-ctr,aes256-ctr

    Désactivez RC4 et tous les autres chiffrements  CBC, y compris arcfour256, arcfour, aes128-cbc et aes256-cbc.

  • Windows Server 2003 ne prend pas en charge les certificats SHA256RSA. Pour installer SRM 5.1.2 sur Windows Server 2003 et utiliser des certificats SHA256RSA personnalisés et signés, vous devez installer l'un des correctifs suivants de Microsoft :

  • ESXi Server 5.0.0 et 5.0.1 et ESXi Server 5.1.0 ne prennent pas en charge la personnalisation du système d'exploitation invité de machines virtuelles qui exécutent Windows 8 ou Windows Server 2012
    La prise en charge de la personnalisation du système d'exploitation invité de machines virtuelles Windows 8 et Windows Server 2012 est disponible avec ESXi Server 5.0 u2 et versions ultérieures, et avec ESXi Server 5.1 u1 et versions ultérieures. Si vous exécutez ESXi Server 5.0 ou 5.0.1 ou ESXi Server 5.1.0 sur le site de récupération, les tests de récupération et les récupérations réelles échouent, car le serveur ESXi sur le site de récupération ne peut pas exécuter le processus de démarrage de Windows 8 ou Windows Server 2012. La machine virtuelle sur le site de récupération n'affiche pas l'écran de connexion de Windows. SRM affiche un message d'erreur dans les étapes de récupération qui indique que VM Tools atteint l'expiration de son délai d'attente pendant la mise sous tension, avant l'étape de personnalisation IP.

    Solution : Mettez à niveau ESXi Server sur le site de récupération vers la version 5.0 u2 ou version ultérieure ou vers ESXi Server 5.1 u1 ou version ultérieure.

Problèmes résolus

Les problèmes suivants liés aux versions précédentes ont été résolus dans cette version.

  • SRM ne peut pas protéger les machines virtuelles qui disposent d'un ou plusieurs disques RDM si les machines virtuelles font partie d'un vApp.

    Si une machine virtuelle fait partie d'un vApp et si elle utilise des disques RDM, la configuration de la protection provoque l'erreur Périphérique introuvable : disque X dans l'état de protection. Dans cette erreur, disque X correspond au disque RDM connecté à la machine virtuelle. Ce problème a été résolu.

  • L'outil DR IP Customizer s'arrête de façon inattendue dans les systèmes d'exploitation invités Windows 2003, sans envoyer de notification.

    L'outil DR IP Customizer s'arrête de façon inattendue sur les systèmes d'exploitation invités Windows 2003. Aucune notification n'est envoyée, mais les journaux SRM indiquent l'erreur C:\WINDOWS\TEMP\vmware-SYSTEM\netshIPv6.vbs(279, 4) Microsoft VBScript runtime error: Object doesn't support this property or method: 'GUID'. Ce problème est causé par une erreur non gérée lors d'une tentative d'accès à une propriété GUID inexistante. Ce problème a été résolu.

  • SRM s'arrête de façon imprévue lorsqu'un système d'exploitation invité Windows envoie un message à SRM Server.

    Ce problème se produit lorsque SRM Server s'exécute sur un système d'exploitation Windows utilisant les paramètres régionaux JP, KO ou CN, et lorsque vCenter Server s'exécute avec les paramètres régionaux EN. Par exemple, lorsqu'un script lancé après la mise sous tension exécute une commande qui renvoie une erreur en caractères japonais, vCenter Server ne traduit pas ce message dans le codage approprié. SRM reçoit une exception non valide et s'arrête de façon inattendue. Ce problème a été résolu.

  • L'option de mise au repos du système d'exploitation invité n'est pas disponible pour les machines virtuelles exécutant Windows Server 2012.

    Lors de la configuration de vSphere Replication sur une machine virtuelle disposant du système d'exploitation invité Windows Server 2012, l'option permettant d'activer la mise au repos du système d'exploitation invité n'est pas disponible. Ce problème a été résolu.

  • La récupération d'une machine virtuelle Contrôleur de domaine (DC) Windows Server 2012 met fin au mécanisme de sauvegarde du DC.

    La récupération d'une machine virtuelle DC Windows Server 2012 est possible en utilisant une réplication basée sur la baie ou vSphere Replication. Cependant, l'exécution d'une opération de récupération sur ce type de machine virtuelle peut compromettre le mécanisme Windows Server 2012 DC SafeGuard. Ce problème a été résolu.

  • La personnalisation IP échoue pendant une récupération ou un test de récupération.

    Lors de l'exécution d'une récupération ou d'un test de récupération d'un plan de récupération, la personnalisation IP échoue pour une partie ou pour l'ensemble des machines virtuelles, pour l'une des raisons suivantes :

    • Sur certaines machines virtuelles Windows utilisant des chemins modifiés pour les dossiers temporaires, la personnalisation IP recherche au mauvais endroit les journaux de résultats. Pour plus de détails, reportez-vous à l'article KB 2021083. Ce problème a été résolu.
    • Si un journal de résultats intermédiaire était inaccessible lors de l'exécution de la personnalisation IP sur des machines virtuelles Windows, la personnalisation aboutit mais signale l'erreur Erreur - Impossible de terminer la personnalisation, probablement du fait d’une erreur d’exécution de script ou de paramètres de script non valides (Code d'erreur : -1). Les paramètres IP ont pu être appliqués en partie. Ce problème a été résolu. La personnalisation IP indique maintenant correctement l'aboutissement de l'opération.
  • Le service SRM s'arrête après vérification du gestionnaire de licences pendant la protection d'une machine virtuelle.

    Lorsque vous configurez la protection sur une machine virtuelle, SRM Server s'arrête de façon inattendue. Les journaux contiennent l'erreur Panic : Assert Failed "found == _reservations.get<by::vm>().end() (There is already a Reservation for VM [vim.VirtualMachine: virtual_machine])". Ce problème a été résolu.

  • SRM ne parvient pas à monter des volumes VMFS et l'erreur Déjà monté s'affiche.

    Lorsque SRM obtient des informations de vCenter Server, SRM indique que le volume qui contient une machine virtuelle n'est pas monté. Cependant, en même temps, ESXi Server parvient à monter le volume. SRM tente de monter le volume en se basant sur les informations précédentes de vCenter Server et indique que le volume se trouve dans un état non valide, et qu'il est déjà monté. Ce problème a été résolu.

  • L'exécution du programme d'installation de SRM en mode modification à partir de la ligne de commande avec l'option CUSTOM_SETUP entraîne une erreur.

    Si vous avez installé SRM au moyen de l'option CUSTOM_SETUP, par exemple pour créer une configuration de site de récupération partagé, toute tentative d'exécution du programme d'installation de SRM en mode modification à partir de la ligne de commande avec l'option CUSTOM_SETUP produit l'erreur CUSTOM_SETUP command line not supported when standard installation already exists. Ce problème a été résolu.

  • Un workflow test ou de récupération échoue pour une machine virtuelle avec le message suivant : Erreur - Erreur inattendue '3008' lors de la communication avec ESX ou la machine virtuelle cliente : Connexion impossible à la machine virtuelle.

    Dans de rares circonstances, cette erreur peut se produire lorsque vous configurez la personnalisation d'IP ou une légende d'invité pour la machine virtuelle et que le cluster du site de récupération est en mode DRS entièrement automatisé. Un vMotion inattendu peut provoquer une interruption de communication temporaire avec la machine virtuelle, entraînant l'erreur de script de personnalisation. Ce problème a été résolu.

  • La mise à niveau de SRM peut échouer lorsque les instances de vCenter Server associées sont en Linked Mode.

    La mise à niveau de SRM peut échouer lorsque les instances de vCenter Server associées sont en Linked Mode. Ce problème a été résolu.

  • Le service SRM échoue avec l'erreur Panic: Assert Failed "!vmKernelIp.empty()" @ d:/build/ob/bora-820150/srm/src/storage/vc/accessMapUtil.cpp:108.

    Lors de l'exécution d'un test de récupération, le service vCenter Site Recovery Manager (SRM) sur le site de récupération échoue dans les circonstances suivantes :

    • Les dispositifs de stockage réseau (NAS) sont configurés pour SRM uniquement à l'aide d'IPv6, et IPv4 est désactivé sur l'hôte ou les hôtes ESXi du site de récupération.
    • Les gestionnaires de baies utilisent uniquement des adresses IPv6.

    Ce problème, également décrit dans l'article KB 2057469, a été corrigé.

  • L'installation de SRM entraîne une erreur MsiExec sur Windows Server 2012, et peut échouer avec l'erreur ERREUR : Impossible d'ouvrir le service : ProtectedStorage.

    Le programme d'installation de SRM tente de démarrer le service de stockage protégé, qui n'existe pas sur Server 2012. Dans la plupart des cas, l'installation réussit, mais le journal d'événements de Windows enregistre une erreur MsiExec. Si le signalement d'erreur de Windows est défini sur « Je ne souhaite pas participer, ne plus me demander », l'installation de SRM échoue et est annulée. Ce problème a été résolu.

  • Le service SRM s'arrête à l'étape Attacher LUN SCSI pendant un test de récupération.

    Lors de l'exécution d'un test de plan de récupération, le service SRM s'arrête de façon inattendue pendant l'étape Attacher LUN SCSI. Le test du plan de récupération démarre correctement et continue jusqu'à l'étape Créer un snapshot de stockage inscriptible, étape à laquelle le test du plan ne progresse plus. Le système indique éventuellement que le service SRM n'est plus disponible. Les journaux SRM incluent l'erreur Panic: Assert Failed "_completions.find(tag) == _completions.end() (Operation added with duplicate tag)". Après redémarrage du service SRM, le test du plan de récupération est indiqué incomplet. Le redémarrage du test échoue et la seule option consiste à effectuer un nettoyage. Ce problème se produit lorsque des LUN SCSI ont des balises dupliquées, par exemple deux LUN sur des baies différentes ont le même ID. Ce problème a été corrigé.

  • L'opération de configuration de la réplication échoue avec l'erreur Caractère UTF-8 non valide ... (un caractère de substitution)pour toute machine virtuelle dont le nom comporte des caractères Unicode de substitution.

    Ce problème est résolu dans cette version.

  • Le serveur de gestion de vSphere Replication subit une fuite de mémoire et ne répond plus lors d'une connexion à vCenter Server ou vSphere Replication Server.

    Ce problème est résolu dans cette version.

  • La reconfiguration d'une réplication pour inclure un disque ayant été précédemment exclu et l'utilisation d'une racine de réplication pour ce disque entraînent la suppression par erreur de l'amorce de réplication par vSphere Replication.

    Si vous avez une réplication dans laquelle un disque est exclu et reconfigurez ultérieurement la réplication pour inclure ce disque, puis copiez manuellement un fichier de disque à utiliser comme amorce de réplication, vSphere Replication supprime le fichier copied .vmdk, ne tenant pas compte du fait qu'il s'agissait d'une copie initiale n'ayant pas été créée par vSphere Replication. Cela vous oblige à recopier le fichier .vmdk sur le site cible. Ce problème a été résolu.

  • vSphere Replication ne peut accéder aux banques de données par le biais des hôtes avec NIC virtuelles de gestion multiple et publie DatastoreInaccessibleEvent dans vCenter Server : vSphere Replication ne peut pas accéder à la banque de données.

    Si un hôte est configuré avec plusieurs NIC virtuelles et que vous sélectionnez plus d'une NIC pour la gestion du trafic, vSphere Replication enregistre seulement la première NIC et l'utilise pour accéder aux banques de données cibles. Si l'adresse du serveur vSphere Replication ne se trouve pas sur le premier réseau de gestion de l'hôte, vSphere Replication ne pourra pas communiquer avec l'hôte. Ce problème a été résolu.

  • L'exécution de récupérations de test simultanées dans une configuration de site de récupération partagé indique une erreur de nom dupliqué dans la vue Tâches récentes du site concerné.

    L'exécution de récupérations de test simultanées dans une configuration de site de récupération partagé (environnement N:1) peut entraîner les erreurs suivantes dans différentes circonstances :

    • The specified key, name, or identifier already exists, lors de l'ajout d'un commutateur virtuel ou d'un groupe de ports.
    • The object or item referred to could not be found, lors de la suppression d'un commutateur virtuel ou d'un groupe de ports durant le nettoyage de test.
    • The resource ' resoure_name' is in use, lors de la suppression d'un commutateur virtuel ou d'un groupe de ports durant le nettoyage de test.

    Ce problème a été résolu.

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 version.

  • NOUVEAU Une vulnérabilité dans la bibliothèque glibc autorise l'exécution de code distant

    Votre dispositif vSphere Replication peut être affecté par une vulnérabilité dans glibc qui autorise l'exécution de code distant.

    Solution : Pour plus d'informations sur la manière de résoudre le problème, reportez-vous à l'article http://kb.vmware.com/kb/2144289

  • L'exécution d'une récupération simultanée sur plusieurs LUN entraîne des erreurs et des dépassements de délai.

    Si vous disposez d'un grand environnement SRM 5.1.x, cela implique entre 50 et 255 LUN Fibre Channel, et si vous exécutez une récupération simultanée sur plus de 50 LUN, vous remarquerez peut-être des dépassements de délai de récupération, des erreurs et des échecs liés aux LUN et, dans certains cas, aux machines virtuelles. Dans certains cas, vous devrez peut-être exécuter le plan de récupération à plusieurs reprises pour qu'il aboutisse. Cela se produit si vous protégez les LUN dans un plan de récupération unique ou dans plusieurs plans de récupération.

    Solution : Consultez l'article KB 2059498.

  • L'adresse MAC de la carte réseau virtuelle d'une machine virtuelle est généralement préservée pendant la récupération.

    Dans de très rares circonstances, le test ou la récupération peut échouer dans la récupération d'une machine virtuelle spécifique, du fait que vCenter affecte de manière inattendue une nouvelle adresse MAC à la VNIC de la machine virtuelle sur le site de récupération. Le message d'erreur qui s'affiche dans la colonne de résultat dans les étapes de récupération est le suivant : Erreur - Impossible de terminer la personnalisation, probablement du fait d’une erreur d’exécution de script ou de paramètres de script non valides (Code d'erreur : 255). Les paramètres IP ont pu être appliqués en partie. Les journaux SRM contiennent un message : Erreur lors de la recherche de la NIC spécifiée pour l'adresse MAC = xx::xx:xx:xx:xx où xx::xx:xx:xx:xx correspond à l'adresse MAC attendue.

    Solution : Modifiez manuellement l'adresse MAC de la machine virtuelle affectée dans les propriétés de la machine virtuelle vSphere Client sur « xx::xx:xx:xx:xx » et redémarrez le plan de récupération.

  • Impossible de configurer une machine virtuelle à l'aide d'un disque RDM à mode physique, même si le disque est exclu de la réplication.

    Si vous configurez la réplication d'une machine virtuelle en mode physique, l'un des messages d'erreurs suivants risque d'apparaître :

    Erreur générique du serveur VRM. Consultez la documentation pour toutes les informations de dépannage. L'exception détaillée est la suivante : HMS ne peut pas définir UUID disque pour les disques de VM : MoRef: type = VirtualMachine, value = , serverGuid = null'.

    Solution : Aucune.

  • vSphere Replication signale que « la banque de données est inaccessible » pour les banques de données sur un hôte ajouté à l'inventaire vCenter Server lors de l'enregistrement d'un serveur vSphere Replication.

    vSphere Replication sélectionne l'ensemble des hôtes pris en charge dans l'inventaire vCenter et les active dans le cadre de l'enregistrement de vSphere Replication. Si vous ajoutez un hôte à vCenter alors que vSphere Replication est en cours d'enregistrement, vSphere Replication ne sélectionne pas cet hôte et il ne peut pas accéder aux banques de données sur le site de récupération.

    Solution : Déconnectez et reconnectez l'hôte dans l'inventaire vCenter pour que vSphere Replication puisse l'activer.

  • L'enregistrement du serveur vSphere Replication peut prendre un certain temps selon le nombre d'hôtes présents dans l'inventaire vCenter Server.

    Si l'inventaire vCenter Server contient une centaine d'hôtes, ou plus, la tâche Enregistrer le serveur VR prendra une heure ou plus, étant donné que vSphere Replication met à jour le registre d'empreinte SSL de chaque hôte. Le panneau Événements de vCenter Server affiche L'hôte est configuré pour vSphere Replication pour chaque hôte au fur et à mesure que la tâche d'enregistrement du serveur vSphere Replication progresse.

    Solution : Attendez que la tâche d'enregistrement soit terminée. Une fois terminée, vous pouvez utiliser vSphere Replication pour le trafic de réplication entrant.

  • L'enregistrement de vSphere Replication peut échouer avec l'erreur : Erreur générique du serveur VRM... La rangée a été mise à jour ou supprimée par une autre transaction ... HostEntity #<host-managed-object-id>.

    L'opération Enregistrer le serveur VR peut échouer avec cette erreur si vCenter Server compte un grand nombre d'hôtes dans son inventaire et si vous effectuez les actions suivantes alors que l'enregistrement est en cours :

    • Supprimer un hôte de l'inventaire vCenter Server.
    • Supprimer et reconnecter un hôte de l'inventaire.
    • Modifier l'empreinte SSL de l'hôte.

    Solution : Relancez l'opération Enregistrer le serveur VR.

  • Échec de la récupération avec Erreur lors de la création d'une image de bulle de test pour le groupe ... L'exception détaillée est Erreur lors de l'obtention de montages d'hôte pour la banque de données : managed-object-id...ou L'objet a déjà été supprimé ou n'a pas été complètement créé.

    Si vous exécutez une récupération test ou une récupération planifiée et si le plan de récupération échoue avec l'exception spécifique, le LUN utilisé pour stocker les données de réplication a été temporairement déconnecté d'ESXi. Une fois reconnectée, la réplication se poursuit normalement et aucune données de réplication n'est perdue. L'exception se produit au cours de ces scénarios :

    • vSphere Replication ne parvient pas à localiser le LUN car celui-ci a modifié son ID interne.
    • L'ID interne de la banque de données cible change lorsque l'hôte contenant la banque de données cible est supprimé de l'inventaire vCenter, puis y est ajouté ultérieurement.

    Vous devez reconfigurer manuellement la réplication pour actualiser le nouvel ID.

    Solution : Si le site principal n'est plus disponible, contactez l'assistance VMware pour obtenir des instructions sur l'ajout d'une entrée de configuration spéciale dans la base de données des dispositifs vSphere Replication qui déclenche une correction automatique de l'ID de la banque de données interne modifié afin de permettre la récupération. Si le site principal est encore disponible :

    1. Exécutez une opération de nettoyage sur le plan de récupération qui a échoué.
    2. Dans l'onglet Machines virtuelles de la vue vSphere Replication, cliquez avec le bouton droit de la souris sur une machine virtuelle et sélectionnez Configurer la réplication.
    3. Cliquez sur Suivant et Parcourir pour modifier l'emplacement des fichiers de la banque de données qui a été déconnectée et reconnectée, puis sélectionnez cette même banque de données et les mêmes emplacements de dossiers que précédemment.
    4. Réutilisez les disques existants et reconfigurez la réplication de la machine virtuelle. Le serveur de gestion de vSphere Replication relève l'identité de la banque de données modifiée (ID de l'objet géré) dans vCenter Server.
    5. Attendez que la synchronisation initiale soit terminée. Cette synchronisation utilise les disques existants et vérifie la cohérence des données.

  • État périmé de la réplication affiché si la banque de données devient indisponible

    Il est possible qu'après le commencement de la synchronisation de la machine virtuelle, la banque de données cible devienne indisponible. Dans un tel cas, l'état du groupe doit afficher des informations sur cet échec, mais l'état reste inchangé. Pour identifier les problèmes concernant l'indisponibilité de la banque de données, utilisez les événements générés par la banque de données cible. Les événements suivants sont générés dans un tel cas :

    • La banque de données n'est pas accessible pour le serveur VR...Généré immédiatement après que la banque de données devient inaccessible
    • L'objectif de point de récupération de vSphere Replication de la machine virtuelle est violé...Une réplique ne peut pas être générée dans l'objectif de point de récupération spécifié

  • Un message d'erreur générique s'affiche lorsque le couplage du serveur échoue en raison de la sévérité de la politique des certificats

    Les tentatives de couplage des serveurs entre les sites pourraient échouer, affichant le message d'erreur suivant : Échec de couplage ou de coupure du site. Détails : Erreur générique du serveur VRM.Cette erreur pourrait se produire lorsqu'un site est configuré pour utiliser une politique des certificats stricte et que l'autre site est configuré pour utiliser une politique des certificats tolérante. Dans un tel cas, le couplage doit échouer, comme cela se produit. Après un tel échec, modifiez la politique de certificats tolérante pour utiliser une politique des certificats stricte et fournir un certificat valide.

  • Une machine virtuelle ne peut pas être mise hors tension en raison d'une erreur de question en attente.

    Si vous créez une situation de perte permanente de périphérique (PDL), accidentellement ou délibérément, en abandonnant un initiateur du SAN sur l'hôte où est enregistrée la machine virtuelle, l'erreur suivante peut se produire :

    Erreur : Impossible d'effectuer cette opération actuellement car il y a une question en attente sur la machine virtuelle...

    Cette erreur se produit en cas de panne matérielle sur le site de récupération pendant une PDL lors de l'exécution d'un nettoyage après avoir exécuté un plan de récupération en mode de récupération test.

    Solution : Répondez à la question dans l'onglet Résumé de la machine virtuelle. Puis, exécutez à nouveau un nettoyage en mode de nettoyage forcé. Une fois l'opération de nettoyage terminée, il est possible que la machine virtuelle soit encore présente sur le site de récupération. Si c'est le cas, supprimez-la manuellement.

  • L'arrêt de la réplication de la banque de données pour les machines virtuelles protégées génère des messages d'erreur incorrects.

    Il est possible de protéger une machine virtuelle qui comporte des disques sur de nombreuses banques de données puis de désactiver ultérieurement la réplication pour une des banques de données. Dans un tel cas, l'état de la machine virtuelle dans le groupe de protection devient Invalide : La machine virtuelle 'VM' n'est plus protégée. Erreur interne : Impossible de créer un localisateur pour disk'2001'...Ces informations sont incorrectes. L'état doit passer à La banque de données '[ datastore name]' n'est plus répliquée.

  • Une erreur interne se produit au cours de la récupération.

    SRM récupère diverses informations à partir de vCenter au cours du processus de récupération. S'il ne reçoit pas les informations cruciales requises pour poursuivre, une erreur interne CannotFetchVcObjectPropertypeut se produire. Cette erreur peut survenir lorsque vCenter est soumis à de fortes contraintes ou qu'un hôte ESXi devient indisponible en raison de fortes contraintes. Cette erreur peut également survenir lorsque SRM tente de rechercher les informations d'un hôte ESXi qui est déconnecté ou a été supprimé de l'inventaire vCenter.

    Solution : Exécutez à nouveau le plan de récupération.

  • Une fois vCenter Server redémarré, lors de l'utilisation de vSphere Replication, les opérations de reprotection échouent avec Erreur - Impossible d'inverser la réplication pour la machine virtuelle ' virtual_machine'. La session n'est pas authentifiée.

    Après le redémarrage de vCenter Server, celui-ci ne parvient pas à actualiser certaines sessions utilisées par SRM pour communiquer avec vSphere Replication et provoque l'échec de la reprotection.

    Solution : Redémarrez les services SRM sur les deux sites.

  • La reprotection échoue avec une erreur lors de l'exécution simultanée de plusieurs plans de récupération.

    Lors de l'exécution simultanée de plusieurs plans de récupération, la reprotection peut échouer avec l'erreur Erreur - L'opération n'a été terminée que de manière partielle pour le groupe de protection 'protection_group', une machine virtuelle protégée lui étant attachée n'ayant en effet pas réussi à achever l'opération.

    Solution : Exécutez à nouveau l'opération de reprotection.

  • Une perte temporaire des connexions de vCenter Server pourrait être à l'origine de problèmes de récupération pour les machines virtuelles avec des mappages de disques bruts

    En cas de perte de la connexion de vCenter Server pendant une récupération, une des situations suivantes pourrait se produire :

    • vCenter Server demeure indisponible et la récupération échoue. Pour résoudre ce problème, rétablissez la connexion avec vCenter Server et réexécutez la récupération.
    • En de rares cas, vCenter Server est à nouveau disponible et la machine virtuelle est récupérée. Dans une telle situation, si la machine virtuelle a des mappages de disques bruts (RDM), ceux-ci risqueraient de ne pas être correctement mappés. Suite au mauvais mappage des RDM, il se pourrait qu'il soit impossible d'allumer la machine virtuelle, ou des erreurs liées au système d'exploitation client ou aux applications exécutées sur le système d'exploitation client pourraient survenir.
      • S'il s'agit d'une récupération test, procédez à une opération de nettoyage et relancez le test.
      • S'il s'agit d'une récupération réelle, vous devez manuellement joindre le bon RDM à la machine virtuelle récupérée.

    Consultez la rubrique relative à la modification des paramètres de la machine virtuelle dans la documentation de vSphere pour en savoir plus sur l'ajout de mappages de disques bruts.

  • Annulation du plan de récupération inachevée

    Lors de l'exécution d'un plan de récupération, une tentative de synchronisation des machines virtuelles est effectuée. Il est possible d'annuler le plan de récupération, mais les tentatives d'annulation de l'exécution du plan de récupération n'aboutissent pas tant que la synchronisation n'est pas terminée ou expirée. Par défaut, le délai d'expiration est de 60 minutes. Vous pouvez utiliser les options suivantes pour effectuer une annulation du plan de récupération :

    • Mettez vSphere Replication en pause pour déclencher l'échec de la synchronisation. Lorsque la récupération entre dans un état d'erreur, utilisez vSphere Client pour redémarrer vSphere Replication sous l'onglet vSphere Replication. Après le redémarrage de la réplication, vous pouvez, le cas échéant, réexécuter le plan de récupération.
    • Attendez que la synchronisation soit terminée ou expirée. L'opération pourrait éventuellement durer assez longtemps, mais finira par se terminer. Au terme ou à l'expiration de la synchronisation, l'annulation du plan de reprise d'activité continue.

  • Les mots de passe composés par des caractères autres que ASCII ne sont pas acceptés pour la connexion à l'interface VAMI (Virtual Appliance Management Infrastructure)

    Les utilisateurs peuvent gérer le dispositif vSphere Replication en utilisant l'interface VAMI. Toute tentative de connexion à l'interface VAMI avec un compte dont le mot de passe comporte des caractères non-ASCII échoue. Cette situation se produit même si les informations d'authentification fournies sont correctes. Ce problème survient dans tous les cas où des mots de passe non-ASCII sont utilisés avec l'interface VAMI. Pour éviter ce problème, utilisez des mots de passe ASCII ou connectez-vous via SSH.

  • La récupération d'une machine virtuelle échoue en raison d'une erreur de configuration sur le disque

    Il est possible de placer différents disques et fichiers de configuration pour une seule machine virtuelle protégée sur de nombreuses banques de données. Durant la récupération, SRM Server doit avoir accès au mappage du disque de données brutes et aux fichiers du disque parent. Sans cet accès, SRM Server ne peut pas déterminer les types de disque durant une récupération. Dans un tel cas, SRM Server pourrait supposer qu'un disque RDM (mappage du disque de données brutes) n'est pas un disque RDM, ce qui entraînerait l'échec de la reconfiguration. Pour éviter ce problème, vérifiez si tous les hôtes pouvant accéder aux fichiers de configuration de la machine virtuelle récupérée peuvent également accéder aux fichiers de mappage RDM et aux disques parents éventuels.

  • Le dispositif vSphere Replication ne parvient pas à prendre en charge les hôtes ESX valides

    Durant la configuration de vSphere Replication, lorsqu'une banque de données est sélectionnée sur une version prise en charge d'ESX, le message Le server VR Server Name n'a aucun hôte permettant d'accéder à la banque de données de destination...s'affiche. Cela se produit lors de l'ajout d'un nouvel hôte à vCenter Server ou durant l'enregistrement du serveur vSphere Replication, s'il y a une interruption temporaire de la communication entre le dispositif vSphere Replication et le serveur vSphere Replication. Les problèmes de communication surviennent généralement en raison d'une perte temporaire de la connectivité ou de l'arrêt des services du serveur.

    Pour résoudre ce problème, redémarrez le service du serveur de gestion vSphere Replication.

    1. Connectez-vous à l'interface VAMI (Virtual Appliance Management Interface) du dispositif vSphere Replication à l'adresse https://vr_applliance_address:5480.
    2. Cliquez sur Configuration > Redémarrer sous État du service.

  • Le démontage des banques de données ne réussit pas lorsque ces dernières se trouvent sur des clusters DPM (Distributed Power Management)

    Les migrations planifiées et les récupérations d'urgence ne permettent pas de démonter les banques de données depuis les hôtes qui sont attachés à un cluster DPM si l'hôte passe en mode de veille. L'erreur Erreur : Impossible de démonter la banque de données datastorename depuis l'hôte hostname. Impossible de communiquer avec l'hôte distant, puisqu'il est déconnectépourrait apparaître. Pour résoudre ce problème, désactivez DPM au site protégé avant d'exécuter les migrations planifiées ou les récupérations d'urgence. Vous pouvez choisir de réactiver DPM au terme des tâches de récupération.

  • SRM ne peut récupérer les machines virtuelles après des pannes RDM.

    Les LUN Raw Disk Mapping (RDM) peuvent échouer tandis que les LUN en charge de la sauvegarde des banques de données restent intacts. En pareille circonstance, SRM ne peut récupérer les machines virtuelles dotées de RDM.

    Solution : Procédez à la récupération manuelle des machines virtuelles affectées. Effectuez le basculement du LUN RDM et joignez-le à nouveau en tant que disk RDM de la machine virtuelle récupérée.

  • Erreur dans le plan de récupération lors de l'arrêt des machines virtuelles protégées : Erreur - Opération expirée : 900 secondes pendant l'étape Arrêt des machines virtuelles sur le site protégé.

    Si vous utilisez SRM pour protéger les banques de données sur des baies qui prennent en charge un échange dynamique, par exemple Clariion, l'exécution d'une récupération d'urgence lorsque le site protégé est partiellement arrêté ou l'exécution d'une récupération forcée peut conduire à des erreurs lors de la nouvelle exécution du plan de récupération pour terminer les opérations du site protégé. Une telle erreur se produit lorsque le site protégé revient en ligne, mais que SRM ne parvient pas à arrêter les machines virtuelles protégées. Cette erreur survient généralement lorsque certaines baies rendent les LUN protégés uniquement accessibles en lecture seule, ce qui empêche ESXi de terminer l'E/S pour les machines virtuelles protégées sous tension.

    Solution : Redémarrez les hôtes ESXi sur le site protégé qui sont affectés par les LUN en lecture seule.

  • La tâche Protéger les machines virtuelles semble rester à 100 %.

    Le panneau Tâches récentes de VI Client indique une machine virtuelle plafonnant à 100 % au cours de la tâche Protéger une VM. SRM marque la machine virtuelle comme étant Configurée, indiquant qu'elle était protégée. Aucune action n'est nécessaire car SRM protégeait parfaitement la machine virtuelle.

  • Le nettoyage échoue s'il a lieu dans les 10 minutes suivant le redémarrage des hôtes ESXi du site de récupération à partir du mode maintenance.

    L'opération de nettoyage tente d'échanger les espaces réservés et repose sur le cache de tolérance des hôtes qui a une période d'actualisation de 10 minutes. Si vous tentez une opération d'échange sur des hôtes ESXi ayant été redémarrés dans l'intervalle de 10 minutes, SRM ne met pas à jour les informations dans le cache de tolérance des hôtes SRM et l'opération d'échange échoue. L'opération de nettoyage échoue également.

    Solution : Patientez 10 minutes et tentez un nouveau nettoyage.

  • SRM s'arrête au cours d'une tentative de protection d'une machine virtuelle basée sur la baie déjà reprotégée à l'aide de vSphere Replication.

    Si vous exécutez une récupération, et que vous essayez ensuite d'utiliser vSphere Replication pour protéger une machine virtuelle déjà protégée par un groupe de protection basé sur la baie, SRM Server réagit.

    Solution : Redémarrez SRM Server et ôtez tout d'abord la protection de la machine virtuelle protégée basée sur la baie avant de protéger avec vSphere Replication. Vous pouvez également poursuivre avec une protection basée sur la baie et ne pas protéger avec vSphere Replication. SRM ne prend pas en charge la protection avec les deux fournisseurs.

  • La migration planifiée échoue avec Erreur : Impossible de copier le fichier de configuration...

    Si dans un cluster contenant deux hôtes ESXi, un des hôtes perd sa connectivité au stockage, l'autre hôte peut généralement récupérer les machines virtuelles répliquées. Dans certains cas, l'autre hôte peut ne pas récupérer les machines virtuelles et la récupération échoue avec l'erreur suivante : Erreur : Impossible de copier le fichier de configuration...

    Solution : Exécutez une nouvelle récupération.

  • Le montage du volume VMFS récupéré échoue avec l'erreur : Échec de récupération de la banque de données.

    Cette erreur peut se produire en raison d'une latence entre vCenter, ESXi et SRM Server.

    Solution : Exécutez à nouveau le plan de récupération.

  • Certaines tâches initiées par SRM qui échouent avec une erreur NoPermission et affichent Erreur interne : vim.fault.NoPermissionau lieu de L'autorisation d'effectuer cette opération a été refusée.

    Le vSphere Client réagit si une tâche en miroir contient une MoRef à un objet autre qu'un objet vCenter Server ou SRM.

    Solution : Si la tâche SRM échouée est une tâche de récupération, consultez le panneau de la tâche de récupération pour une erreur plus spécifique. Pour une défaillance de la tâche vCenter Server, consultez les sous-tâches qui contiennent plus d'informations.

  • La reprotection échoue avec un message d'erreur qui contient Impossible de communiquer avec l'hôte distant, puisqu'il est déconnecté.

    Cette erreur est probablement due au fait que le cluster latéral protégé a été configuré pour utiliser DPM (Distributed Power Management), et que l'un des hôtes ESX requis pour l'opération était en mode veille. Cela peut se produire si DPM a détecté que l'hôte était inactif et l'a placé en mode veille. SRM devait communiquer avec l'hôte afin d'accéder à la banque de données répliquée gérée par cet hôte. SRM ne gère pas l'état DPM sur le site protégé mais gère, cependant l'état DPM pendant la récupération, le test et le nettoyage sur le site de récupération.

    Solution : Si l'erreur persiste, désactivez temporairement DPM et vérifiez que les hôtes ESX gérant les banques de données répliquées du côté protégé sont activés avant de relancer une nouvelle reprotection.

  • Lorsque les LUN du site de protection rencontrent une condition APD (Tous chemins hors service) ou PDL (perte permanente de périphérique), dans certains cas, il est possible que SRM ne récupère pas les LUN de mappage de disque brut (RDM).

    Lors de la première tentative de migration planifiée, le message d'erreur suivant peut s'afficher lorsque SRM tente d'arrêter la machine virtuelle protégée :

    Erreur - Impossible d'effectuer cette opération actuellement car il y a une question en attente sur la machine virtuelle : 'msg.hbacommon.askonpermanentdeviceloss:Le disque virtuel de sauvegarde de stockage VM1-1.vmdk présente une perte permanente de périphérique. Il se peut que vous puissiez retirer à chaud ce périphérique virtuel de la machine virtuelle et continuer après avoir cliqué sur Réessayer. Cliquez sur Annuler pour mettre fin à cette session.

    Si les machines virtuelles protégées ont des périphériques RDM, dans certains cas, SRM ne récupère pas le LUN RDM.

    Solution :

    1. Lorsque des LUN accèdent à APD/PDL, le serveur ESXi marque toutes les machines virtuelles correspondantes avec une question qui bloque les opérations des machines virtuelles.
      1. Dans le cas de PDL, cliquez sur Annuler pour désactiver la machine virtuelle.
      2. Dans le cas d'APD, cliquez sur Réessayer.

      Si vous exécutez une migration planifiée, SRM ne parvient pas à désactiver les machines virtuelles de production.
    2. Si les machines virtuelles ont des périphériques RDM, SRM pourrait perdre la trace du périphérique RDM et pourrait ne pas le récupérer. Réanalysez tous les HBA et vérifiez que l'état, pour l'ensemble des LUN affectés a récupéré de l'état APD/PDL.
    3. Vérifiez l'inventaire vCenter Server et répondez à la question PDL qui bloque la machine virtuelle.
    4. Si vous répondez à la question PDL avant que les LUN reviennent en ligne, SRM Server sur le site protégé détecte de manière incorrecte que le périphérique RDM n'est plus attaché à cette machine virtuelle et supprime le périphérique RDM. Lors de la prochaine récupération, SRM ne récupérera pas ce LUN.
    5. Réanalysez tous les HBA pour vérifier que tous les LUN sont en ligne dans l'inventaire vCenter Server et mettez sous tension toutes les machines virtuelles affectées. vCenter Server associe les RDM perdus aux machines virtuelles protégées.
    6. Vérifiez l'onglet Gestionnaires de baies dans l'interface SRM. Si l'ensemble des banques de données et des périphériques RDM protégés ne s'affichent pas, cliquez sur Actualiser pour découvrir les périphériques et recalculer les groupes de banques de données.
    7. Vérifiez que Modifier les paramètres de groupe affiche l'ensemble des banques de données et des périphériques RDM protégés et que l'état de protection des machines virtuelles n'indique aucune erreur.
    8. Lancez une migration planifiée pour récupérer tous les LUN protégés, y compris les périphériques RDM.
  • Le nettoyage de la récupération test peut échouer si l'un des hôtes perd la connexion avec une banque de données à espace réservé.

    Si vous avez exécuté une récupération test sur un cluster avec deux hôtes sur un site de récupération et si un des hôtes du cluster perd la connexion avec une banque de données à espace réservé, le nettoyage de la récupération test peut échouer.

    Solution : Exécutez le nettoyage en mode forcé. Sur le site de récupération, supprimez manuellement les machines virtuelles à espace réservé créées sur l'hôte ayant perdu la connexion avec la banque de données à espace réservé. Supprimez la configuration de la réplication des machines virtuelles et reconfigurez la réplication. Reconfigurez la protection des machines virtuelles dans les propriétés du groupe de protection.

  • L'aide contextuelle n'est pas disponible sous Internet Explorer 7.

    Consultez l'article KB 1009801 .

  • La génération de bundles de support dans un environnement très chargé peut interrompre les opérations vSphere Replication en cours.

    La génération de bundles de support dans des environnements très chargés peut causer des problèmes de connexion de vSphere Replication pendant la récupération. Ces cas surviennent en particulier lorsque le stockage de la machine virtuelle de vSphere Replication est surchargé.

    Solution : Si une opération ne peut démarrer lorsque le serveur de vSphere Replication est bloqué par la génération du bundle de support, essayez d'exécuter à nouveau cette opération. Réévaluez les exigences projetées de bande passante de stockage du cluster, ainsi que la bande passante du réseau si le stockage est NAS.

  • La valeur Taille de la dernière synchronisation pour une machine virtuelle protégée par vSphere Replication correspond à la quantité de données modifiées depuis la dernière synchronisation.

    Même si vous effectuez une synchronisation complète sur une machine virtuelle protégée par vSphere Replication, la valeur Taille de la dernière synchronisation indique la quantité des données qui ont été modifiées depuis la dernière synchronisation, et non la taille de la machine virtuelle complète. Ceci peut être mal interprété dans le sens où la synchronisation n'était pas complète. Après la synchronisation initiale, lors d'une synchronisation complète d'une machine virtuelle, vSphere Replication compare tous les disques, mais ne transfère que les données ayant été modifiées, pas l'ensemble du disque.

    Pour afficher la taille et la durée de la synchronisation initiale, vous pouvez vérifier les événements que vSphere Replication poste sur vCenter Server. Le problème survient uniquement sur les hôtes ESXi 5.0.x. Ce comportement a été résolu sur les hôtes ESXi 5.1.

  • La récupération ou la récupération test peut échouer avec l'erreur « Aucun hôte avec la version matérielle '7' et banque de données 'ds_id' sous tension et hors mode de maintenance n'est disponible... » dans les cas où des modifications très récentes ont lieu dans l'inventaire de l'hôte.

    Le serveur SRM conserve un cache de l'état de l'inventaire de l'hôte. Parfois, lorsque de récentes modifications ont été apportées à l'inventaire, par exemple si un hôte devient inaccessible, est déconnecté ou perd sa connexion avec certaines banques de données, la mise à jour du cache du serveur SRM peut nécessiter jusqu'à 15 minutes. Si le serveur SRM a dans son cache le mauvais état d'inventaire de l'hôte, une récupération ou une récupération test peut échouer.

    Solution : Patientez 15 minutes avant d'exécuter une récupération si vous avez apporté des modifications à l'inventaire de l'hôte. Si vous observez l'erreur ci-dessus, patientez 15 minutes, puis relancez la récupération.

  • L'exécution de la récupération prend beaucoup de temps. La reprotection échoue et le message d'erreur suivant s'affiche : Impossible de vérifier les informations d'identification de connexion Échec de l'infrastructure des services d'authentification.

    Cette erreur se produit à cause de l'épuisement des ports éphémères de vCenter Server fonctionnant sous Windows 2003 server. Le serveur SRM ne peut pas communiquer avec vCenter Server.

    Solution :

    1. Installez le correctif logiciel Microsoft depuis l'article KB 979230 pour résoudre ce problème du pilote tcpip.sys.
    2. Paramétrez les valeurs regedit suivantes, en effectuant des modifications manuelles ou en important le fichier .reg suivant : 
      Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"MaxUserPort"=dword:00002710
"TcpTimedWaitDelay"=dword:0000001E
    3. Si les valeurs de registre n'existent pas, créez-les.
    4. Après avoir effectué ces modifications, redémarrez la machine Windows 2003 Server.

  • Les opérations de synchronisation, de récupération ou de reprotection de la machine virtuelle échouent avec vSphere Replication.

    Cette erreur peut se produire lorsque vous demandez une opération de synchronisation ou exécutez des opérations telles que la récupération ou la reprotection. Les erreurs signalées sont similaires aux suivantes :

    • Échec de synchronisation VR pour le groupe VRM groupe. Erreur générique du serveur VRM. Pour obtenir des informations sur la résolution des problèmes, consultez la documentation. L'exception détaillée est la suivante : 'L'instance demandée avec l'Id= ID est introuvable sur le site distant.'
    • Erreur - Échec de synchronisation VR pour le groupe VRM groupe. Le stockage est verrouillé pour le chemin de banque de données '[ chemin] *.vmdk.vmdk'.

    Cette erreur est plus susceptible de survenir lors de l'exécution de machines virtuelles avec une charge de travail élevée sur le site protégé.

    Solutions :

    • Réessayez. Cela peut ne pas réussir.
    • Étant donné que le problème est lié à la charge exécutée sur le site protégé, prévoyez des récupérations en dehors des heures de bureau.
    • Si vous effectuez un test de récupération, n'activez pas l'option « Répliquer les changements récents au site de récupération ».
    • Effectuez la mise à niveau vers SRM 5.5. SRM 5.5, avec vSphere 5.5, inclut un nombre de mises à jour résolvant ce problème.

  • La réexécution de la reprotection échoue avec l'erreur : Le groupe de protection '{protectionGroupName}' dispose de VM protégées avec des paramètres fictifs nécessitant une réparation.

    Si une opération ReloadFromPath échoue au cours de la première reprotection, les machines virtuelles protégées correspondantes entrent dans un état repairNeeded. Lorsque SRM exécute une reprotection sur un groupe de protection, SRM ne peut ni réparer les machines virtuelles protégées, ni restaurer les machines virtuelles à espace réservé. L'erreur survient lorsque la première opération de reprotection échoue pour une machine virtuelle du fait que l'opération ReloadFromPath correspondante a échoué.

    Solution : Exécutez à nouveau la reprotection avec l'option Forcer le nettoyage activée. Cette option termine l'opération de reprotection et active l'option Recréer l'espace réservé. Cliquez sur Recréer l'espace réservé pour réparer les machines virtuelles protégées et pour restaurer les machines virtuelles à espace réservé.

  • Le dispositif vSphere Replication sur un site de récupération partagé affiche l'état déconnecté dans l'interface utilisateur SRM pendant l'opération de reprotection.

    Pendant l'opération de reprotection, après avoir configuré les réplications dans le sens inverse, SRM et le dispositif vSphere Replication attendent les synchronisations initiales pour fonctionner en sens inverse. Si le plan de récupération compte plus de 100  machines virtuelles, les tâches de surveillance des synchronisations initiales entraînent l'arrêt des réponses du dispositif vSphere Replication aux appels de l'interface utilisateur SRM.

    Solution : Attendez la fin de la synchronisation initiale des réplications inverses. L'état de la réplication dans l'interface utilisateur SRM passe finalement de Sync à OK. Essayez à nouveau de vous connecter depuis l'interface utilisateur SRM au dispositif vSphere Replication sur le site partagé.

  • Le fait de se déconnecter du client  C# SRM pendant l'opération de reprotection entraîne l'échec de l'étape de synchronisation d'une opération de reprotection avec l'erreur Erreur lors de l'obtention de la vue VC locale.

    Pendant l'opération de reprotection, après avoir configuré les réplications dans le sens inverse, SRM et le dispositif vSphere Replication attendent les synchronisations initiales pour fonctionner en sens inverse. SRM déclenche une opération de synchronisation distincte pour vérifier qu'il n'y a aucun problème avec la réplication. Si vous vous déconnectez de l'interface utilisateur SRM pendant cette opération de synchronisation, l'opération de reprotection se poursuit, mais vSphere Replication ne peut pas emprunter l'identité de l'utilisateur et l'opération de synchronisation échoue.

    Solution : Ignorez l'erreur indiquée dans l'étape de synchronisation du workflow de reprotection ou utilisez l'interface utilisateur SRM pour déclencher manuellement une synchronisation une fois l'opération de reprotection terminée.

  • La modification ou la réparation d'une installation du serveur SRM requiert l'intervention de l'utilisateur Administrateur ou la désactivation d'UAC.

    Si vous êtes membre du groupe Administrateurs, mais non administrateur, vous devez désactiver le Contrôle de compte d'utilisateur ( UAC) Windows avant de tenter de modifier ou de réparer une installation de serveur SRM depuis le panneau de configuration Windows. Si vous avez installé le serveur SRM sur un hôte Windows Server 2012, désactivez l'UAC en modifiant le registre.

    Solution : Connectez-vous à la machine Windows Server 2012 en tant qu'administrateur lorsque vous exécutez le programme d'installation de SRM en mode de modification ou de réparation, ou déconnectez le Contrôle d’accès d’utilisateur (UAC). Pour désactiver l'UAC sur Windows Server 2012, consultez l'article http://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-uac.aspx.

  • SRM s'arrête de façon inattendue avec une alerte durant une récupération de test. Vous pouvez redémarrer le service SRM mais il s'arrête de nouveau lorsque vous poursuivez le test.

    Très rarement, SRM s'arrête de façon inattendue durant une récupération de test avec l'erreur Panic : Assert Failed "this->_childJobs.size() == this->_jobsToRemove.size() (Invalid state, job cannot complete while child jobs are pending. Les tentatives de réexécution du test après le redémarrage du service SRM entraînent l'arrêt de celui-ci avec la même erreur. Le problème survient si l'état de la base de données SRM est incorrect.

    Solution : contactez l'assistance VMware.

  • La reprotection échoue après la suppression de l'hôte déconnecté sur le site protégé.

    Si vous supprimez l'hôte déconnecté du site protégé et exécutez la reprotection, cette opération risque d'échouer avec l'erreur Internal error: std::exception 'class Vmacore::Exception".

    Solution : réexécutez la reprotection en sélectionnant l'option Forcer le nettoyage.

  • La personnalisation IP échoue en raison de l'expiration d'un délai d'attente lors du chargement de scripts de personnalisation sur des machines virtuelles via l'API VIX.

    Le chargement de scripts de personnalisation IP sur des machines virtuelles à l'aide de VIX lors de l'exécution de plans de récupération échoue avec une expiration de délai d'attente.

    Solution : Aucune.

  • La récupération de test d'une machine virtuelle avec RDM échoue à l'étape de configuration du stockage lors de la mise sous tension de la machine virtuelle.

    La récupération de test échoue dans les situations suivantes :

    • Une machine virtuelle configurée avec RDM est protégée sur le site principal.
    • Dans Sites > Mappages de ressources, la ressource du site protégé contenant la machine virtuelle est mappée à un vApp en tant que ressource de site secondaire.

    Solution : Mappez la machine virtuelle sur un type de ressource qui n'est pas un vApp, tel qu'un hôte, sur le site secondaire.

  • SRM Server s'arrête de façon imprévue si vous exécutez un test de nettoyage après une mise à niveau vers SRM 5.1.2 sans procéder à la mise à niveau des SRA.

    Si vous utilisez une réplication basée sur la baie et procédez à la mise à niveau de SRM vers la version 5.1.2 mais sans mettre à niveau les SRA, SRM Server s'arrête de façon imprévue lors de l'exécution d'un test de nettoyage.

    Solution : Mettez à niveau les SRA à la version appropriée pour la version 5.1.2.

  • Un test de nettoyage échoue avec une erreur de démontage des banques de données.

    L'exécution d'un nettoyage après un test de récupération peut échouer avec l'erreur Erreur - Impossible de démonter la banque de données ' nom_banque_données' de l'hôte ' nom_hôte'. L’opération n’est pas autorisée dans l’état actuel. Ce problème survient si l'hôte a déjà démonté la banque de données avant l'exécution de l'opération de nettoyage.

    Solution : Exécutez à nouveau l'opération de nettoyage.

      •