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

Nous contacter

VMware vCenter Site Recovery Manager 5.1.1.1 | 22 sept 2013 | Build 1290726

VMware vCenter Site Recovery Manager 5.1.1 | 25 avril 2013 | Build 1082082

Dernière mise à jour : 9 mars 2016

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

Pour des informations sur Site Recovery Manager 5.1.1.1, consultez l'article Version Express Patch de Site Recovery Manager 5.1.1.1 (KB 2057972).

Contenu des notes de mise à jour

Ces mises à jour contiennent les rubriques suivantes :

Nouveautés dans SRM 5.1.1

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

Localisation

VMware vCenter Site Recovery Manager 5.1.1 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.1 est capable de protéger des machines virtuelles résidant dans vSphere Storage Appliance (VSA) en utilisant vSphere Replication. VSA ne nécessite pas d'adaptateur de réplication de stockage (SRA) pour fonctionner avec SRM  5.1.1.

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.1, consultez la section Ressources VMware vCenter Site Recovery Manager relatives à la continuité d'activité.

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.

Installer SRM  5.1.1

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

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

Mettre à niveau une installation existante de SRM 4.1.2 vers SRM 5.1.1

Effectuez une mise à niveau de SRM  4.1.2 vers SRM  5.0.2 avant d'installer SRM  5.1.1.

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 ou 5.1u1 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.1 n'est pas un chemin de mise à niveau pris en charge. Lors de la mise à niveau d'une instance vCenter Server 4.1.2 qui inclut une installation de SRM  4.1.2, vous devez mettre à niveau vCenter Server vers la version 5.0 ou 5.0 u1 avant de mettre à niveau SRM vers la version 5.0.2. Si vous mettez à niveau vCenter Server depuis la version 4.1.2 vers la version 5.1 ou 5.1u1 directement, lorsque vous tentez de mettre à niveau SRM depuis la version 4.1.2 vers la version 5.0.2, la mise à niveau de SRM échoue. SRM 5.0.2 ne peut pas se connecter à une instance vCenter Server 5.1.

Mettre à niveau une installation existante de SRM 5.0.2 vers SRM 5.1.1

Pour mettre à niveau une installation existante de SRM 5.0.2 vers SRM 5.1.1, téléchargez et exécutez le programme d'installation VMware-srm-5.1.1-1082082.exe.

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

Mettre à niveau une installation existante de SRM 5.1 ou 5.1.0.1 vers SRM 5.1.1

Afin de mettre à niveau une installation existante de SRM 5.1 ou 5.1.0.1 vers SRM  5.1.1, vous devez effectuer les étapes suivantes.

  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.1-1082082.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.1.
  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.

Mettre à niveau vSphere Replication vers vSphere Replication 5.1.1

Si vous avez installé une précédente version de vSphere Replication et si vous effectuez une mise à niveau vers SRM  5.1.1, vous devez également mettre à niveau vSphere Replication vers la version  5.1.1. Vous devez aussi mettre à niveau les serveurs vSphere Replication vers la version  5.1.1.

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

Pour mettre à niveau le dispositif vSphere Replication et le serveur vSphere Replication vers la version 5.1.1 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.1.0

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 est 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.1 sont disponibles sur 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.1 n'est prise en charge ni avec Storage vMotion (SVmotion) ni avec SDRS (Storage Distributed Resource Scheduler), de même que l'utilisation des clusters de banque de données.

  • Interopérabilité avec vCloud Director
    Site Recovery Manager 5.1.1 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.1 prend en charge 2 nœuds Microsoft Cluster Server (MSCS)
    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.

  • 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 lors de l'utilisation de vSphere Replication.
    La récupération d'une machine virtuelle DC Windows Server 2012 est possible en utilisant une réplication basée sur la baie. Cependant, lors d'une récupération à l'aide de vSphere Replication dans un plan de récupération que vous exécutez depuis l'interface utilisateur SRM, vSphere Replication ne supprime pas vm.genid et vm.genidX du fichier VMX. La récupération à l'aide de vSphere Replication depuis vSphere Web Client a réussi.

Problèmes résolus

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

  • Les opérations de récupération test, de migration planifiée ou de reprotection peuvent échouer avec l'erreur : Expiration du délai de l’opération.

    Cette erreur peut survenir lors de l'exécution de plusieurs opérations avec plusieurs sites principaux. Ce problème a été résolu.

  • L'opération de reprotection pour plusieurs machines virtuelles ciblant plusieurs sites distants échoue avec l'erreur Impossible d'inverser la réplication pour la machine virtuelle vm_name. Opération expirée.

    vSphere Replication cesse de répondre aux requêtes SRM lors de la reprotection de plusieurs machines virtuelles pour plusieurs sites distants. Ce problème a été résolu.

  • La personnalisation des IP échoue lors du test d'un plan de récupération avec un nom en japonais.

    Si le nom d'un plan de récupération utilise des caractères japonais, et si vous configurez la personnalisation des IP sur une machine virtuelle Windows exécutée avec les paramètres régionaux japonais, l'étape de personnalisation échoue avec une erreur de script. Ce problème a été résolu.

  • Des volumes dupliqués apparaissent dans l'onglet Périphériques de la vue Gestionnaires de baies de l'interface utilisateur SRM.

    Ce problème se produit lorsque le numéro cible d'un LUN est le même que le numéro source d'un autre LUN. Ce problème d'interface utilisateur a été résolu.

  • L'exécution d'une récupération à l'aide de l'interface vSphere Replication échoue avec l'erreur Traitement de la machine virtuelle récupérée... Le fichier de configuration a échoué... La requête HTTP a échoué : org.apache.http.conn.HttpHostConnectException: Connexion à https:// vCenter_Server_hostname refusée.

    Lorsque vCenter Server est installé avec un port personnalisé pour HTTPS, le port 444 par exemple, la récupération échoue lorsque vous essayez de mettre à jour le fichier VMX répliqué. Ce problème a été résolu.

  • La configuration de la réplication en mode avancé lorsque l'emplacement cible se trouve sur une banque de données NFS génère le message d'erreur Sélectionner un format de disque virtuel.

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

  • Sur le site de récupération, les réanalyses des banques de données échouent en raison de périphériques de stockage non prêts.

    Les SRA peuvent envoyer des réponses à SRM avant qu'un périphérique de stockage promu sur le site de récupération ne soit disponible pour les hôtes ESXi. Lorsque SRM reçoit une réponse d'un SRA, il effectue une réanalyse des périphériques de stockage. Si les périphériques de stockage ne sont pas encore totalement disponibles, ESXi Server ne les détecte pas et SRM ne trouve pas les périphériques dupliqués lorsqu'il effectue des réanalyses. Les banques de données ne sont pas créées et les machines virtuelles récupérées sont introuvables.

    Solution : si vous rencontrez des problèmes liés à des banques de données indisponibles, SRM 5.1.1 propose un nouveau paramètre vous permettant de retarder le début des réanalyses après la promotion d'un périphérique de stockage par un SRA.

    1. Cliquez avec le bouton droit sur un site SRM et sélectionnez Paramètres avancés.
    2. Cliquez sur storageProvider.
    3. Définissez le paramètre storageProvider.hostRescanDelaySec pour retarder le début des réanalyses du stockage d'un certain nombre de secondes. Une valeur comprise entre 20 et 180 est raisonnable.
    4. Redémarrez le service SRM.

    REMARQUE : dans les versions précédentes, vous avez peut-être utilisé le paramètre storageProvider.hostRescanRepeatCnt pour introduire un délai dans les récupérations. Utilisez plutôt le nouveau paramètre storageProvider.hostRescanDelaySec.

  • SRM s'arrête de façon inattendue durant une migration planifiée si ESXi Server est déconnecté de vCenter Server sur le site protégé.

    Si ESXi Server est déconnecté de vCenter Server sur le site protégé ou s'il perd la connexion avec vCenter Server en raison d'un problème, SRM s'arrête de façon inattendue si vous tentez d'effectuer une migration planifiée. Ce problème a été résolu, si bien que SRM ne s'arrête pas lorsque vous exécutez une migration planifiée. La migration planifiée échoue avec une erreur.

    Solution :

    1. supprimez ESXi Server de l'inventaire vCenter Server.
      Si l'hôte a été intentionnellement mis sous tension ou a été placé en mode maintenance, aucune machine virtuelle ne doit s'exécuter sur lui. Dans ce cas, seuls les pools de ressources et les dossiers sont perdus. Si l'hôte faisait partie d'un cluster, les pools de ressources et les dossiers seront recréés après sa restauration.
    2. Restaurez l'hôte et reconnectez-le à vCenter Server.
    3. Exécutez une récupération d'urgence pour faire migrer les machines virtuelles vers le site de récupération.

  • Des délais d'expiration surviennent avec l'erreur « Cannot find replicated datastore due to timeout of HBA rescan operation ».

    Ce problème a été résolu pour améliorer la détection de l'erreur et du message d'erreur pour les délais d'expiration durant les opérations de réanalyse de l'hôte.

  • L'installation ou la mise à niveau vers SRM 5.1 au moyen d'un certificat importé échoue.

    Si vous tentez d'installer SRM 5.1 ou de mettre à niveau vers cette version au moyen d'un certificat PKCS12 importé plutôt que d'un certificat généré automatiquement, le programme d'installation s'exécute jusqu'à la fin, mais échoue avec l'erreur Échec de l'installation du certificat. Ce problème a été résolu.

  • Sur le site de récupération, le serveur SRM s'arrête de façon inattendue durant le nettoyage d'un test du plan de récupération basé sur les baies.

    Lors de l'exécution d'une opération de nettoyage après le test d'un plan de récupération basé sur les baies, le serveur SRM s'arrête de façon inattendue sur le site de récupération. Les journaux contiennent l'erreur Panic : Win32 exception: Access Violation. Ce problème a été résolu.

  • La procédure de récupération personnalisée n'empêche pas la mise sous tension des machines virtuelles avant la personnalisation IP.

    Si vous insérez une étape de récupération personnalisée après l'étape « Créer un snapshot de stockage inscriptible » dans une récupération de test ou après l'étape « Modifier le stockage du site de récupération en inscriptible » dans une récupération réelle et si vous avez configuré la machine virtuelle pour la personnalisation IP, le plan de récupération n'attend pas la fin de l'étape de récupération personnalisée pour mettre sous tension la machine virtuelle. Ce problème a été résolu.

  • Le couplage des serveurs SRM échoue lorsque des certificats personnalisés sont utilisés avec VCVA.

    Le couplage des serveurs SRM lorsque des certificats personnalisés pour le serveur SRM et le dispositif virtuel vCenter Server sont utilisés échoue avec l'erreur suivante : Permission to perform this operation was denied. Ce problème a été résolu.

  • Si SRM s'arrête de façon inattendue durant le test d'un plan de récupération, il s'arrête de nouveau lorsque vous tentez de réexécuter le test.

    L'arrêt inattendu de SRM lors du test d'un plan de récupération entraîne toujours son arrêt lorsque vous tentez de réexécuter le plan. Cela est dû à une vérification d'assertion de l'état d'une machine virtuelle qui, suite à la récupération de test arrêtée prématurément, est dans un état non valide. Ce problème a été résolu.

  • L'exécution d'une reprotection au moyen de vSphere Replication échoue avec une erreur d'authentification.

    L'exécution d'une reprotection au moyen de vSphere Replication s'exécute à environ 89 %, est suivie d'un temps d'attente, puis échoue avec l'erreur runHbrReprotect : com.vmware.vim.binding.vim.fault.NotAuthenticated. Les machines virtuelles du site secondaire restent dans un état non valide. Ce problème a été résolu.

  • SRM échoue au cours de la récupération lors de la préparation des machines virtuelles à la migration sur le site protégé.

    Si une machine virtuelle protégée se trouve sur une banque de données partagée entre plusieurs hôtes et que ceux-ci résident dans des centres de données différents, SRM peut échouer pendant une récupération au cours de l'étape Préparer les VM du site protégé pour la migration. Le journal affiche le message SRM Panic: Assert Failed "ok" @ path/deactivateStorage.cpp:1170. 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.

      • SRM pourrait éventuellement se heurter à des erreurs lors de l'installation de banques de données durant les récupérations

        Lors d'une récupération test ou d'un basculement réel, SRM attend que les banques de données récupérées soient disponibles. Lorsque les banques de données sont disponibles, SRM tente d'installer toutes celles qui ne le sont pas encore. En de rares occasions, l'installation de ces banques de données s'effectue automatiquement avant que SRM ait le temps d'agir. Si tel est le cas pendant un basculement test, ce basculement n'aboutit pas. S'il s'agit d'une récupération réelle, cette dernière aboutit mais avec une erreur. Pour résoudre ce problème, relancez la récupération.

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

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

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

      • La récupération ne réussit pas à progresser après l'échec de la connexion au site protégé

        Si le site de protection devient inaccessible durant une opération de désactivation ou durant RemoteOnlineSync ou RemotePostReprotectCleanup, les deux opérations se produisant durant la reprotection, il se pourrait alors que le plan de récupération ne réussisse pas à progresser. Dans un tel cas, le système attend que les machines virtuelles ou les groupes qui faisaient partie du site de protection achèvent ces tâches interrompues. Si ce problème se produit durant une opération de reprotection, vous devez reconnecter le site de protection d'origine puis annuler et redémarrer le plan de reprise d'activité. Si ce problème se produit durant une récupération, il suffit d'annuler et de redémarrer le plan de récupération.

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

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

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

      • Lors de la reprotection d'une machine virtuelle, l'erreur suivante peut se produire au cours de l'étape « Configurer la protection pour inverser le sens » : Erreur - L'opération n'a été terminée que de manière partielle pour le groupe de protection 'pg_name', une machine virtuelle protégée lui étant attachée n'ayant en effet pas réussi à achever l'opération. La VM 'vm_name' n'est pas répliquée par VR.

        Cette erreur se produit pendant la deuxième exécution de la reprotection si la première exécution a échoué avec l'erreur Opération expirée au cours de l'étape « Configurer le stockage pour inverser le sens ».

        Solution : Configurez manuellement la réplication inverse pour les machines virtuelles affectées et exécutez à nouveau la reprotection. Pour obtenir des informations sur la réplication inverse, référez-vous à Administration de vSphere Replication : Restauration automatique des machines virtuelles dans vSphere Replication.

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

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

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

        Solution : Exécutez à nouveau le plan de récupération. Si l'erreur persiste, configurez le DRS du cluster du site de récupération en mode manuel et relancez 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.
      • 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.

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

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

      • L'inclusion d' un signe du pourcentage (%) dans le nom d'un dossier sur un site de récupération crée un nouveau dossier pendant la réplication.

        Si vous insérez le signe du pourcentage (%) dans le nom d'un dossier sur un site de récupération et essayez de configurer la réplication vers ce dossier, cette opération peut être générée dans un dossier inapproprié contenant des codes supplémentaires. Si, par exemple, vous créez un dossier %3dTest, vSphere Replication crée un nouveau dossier %253dTest et y place la réplication.

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

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

      • La reprotection échoue avec l'erreur : Opération expirée : Échec de la synchronisation VR 7200 secondes pour le groupe VRM &ltUnavailable&gt. Opération expirée : 7  200  secondes.

        Lorsque vous exécutez la reprotection, SRM effectue une synchronisation en ligne pour le groupe de réplication qui pourrait faire expirer l'opération. La valeur de délai d'expiration par défaut est 2 heures.

        Solution : Augmentez la valeur du délai d'expiration dans Paramètres avancés dans SRM.

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

      • L'état du dispositif vSphere Replication est Déconnecté lorsque le plug-in du client SRM est exécuté sur Windows XP ou Windows 2003.

        L'état du dispositif vSphere Replication apparaît comme Déconnecté dans l'onglet Synthèse pour un site vSphere Replication. Une tentative de reconfiguration de la connexion produit l'erreur Connexion au serveur VRMS local perdue à adresse_serveur:8043. (Le client n'a pas pu envoyer une demande complète au serveur 'adresse_serveur'. (La connexion sous-jacente a été fermée : Une erreur inattendue s'est produite lors d'un envoi.)). Ce problème se produit parce que le plug-in client SRM et vSphere Client ne parviennent pas à négocier la cryptographie lorsque le plug-in client SRM est exécuté sur d'anciennes versions de Windows. Si vous exécutez la version de poste de travail de vSphere Client et du plug-in client SRM sous Windows XP 64 bits ou Windows Server 2003 SP2, il se peut que vous rencontriez des incompatibilités entre le serveur et le support de cryptographie du client.

        Solution : Téléchargez et installez le correctif logiciel Microsoft en vous aidant de l'article Microsoft KB 948963. Ce correctif logiciel n'est appliqué sur aucune mise à jour normale de Windows, vous devez donc télécharger et appliquer le correctif manuellement.

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

      • Le couplage des sites échoue en raison des différentes méthodes de confiance du certificat

        Lors du couplage des sites SRM, l'erreur Les serveurs locaux et distants utilisent différentes méthodes de confiance du certificatapparaît. Ce problème se produit lorsque le certificat racine pour l'autorité de certification (CA) qui signe le certificat manque sur le serveur SRM. Pour résoudre ce problème, installez le certificat pour l'autorité de certification signant le certificat SRM en utilisant la console de gestion Microsoft. Après avoir installé le certificat, effectuez une opération Modifier de l'installation de SRM de façon à fournir de nouveau le certificat généré par l'utilisateur.

      • É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.

      • 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é.

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

        Solution : Utilisez un hôte doté d'une seule NIC virtuelle sélectionnée pour le trafic de gestion des banques de données du site secondaire. Vous pouvez également reconfigurer les paramètres réseau de l'hôte, afin que l'adresse de la première NIC virtuelle de gestion provienne d'un réseau auquel vSphere Replication peut accéder.

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

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

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

        Solution : utilisez le Panneau de configuration de Windows pour lancer le programme d'installation de SRM en mode modification.

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

      • 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 est dû à des conflits de noms.

        Solution : Réexécutez les récupérations de test ou les opérations de nettoyage de manière séquentielle sur la même instance de vCenter Server. Exécutez un seul flux de travail à la fois pour toutes les instances enregistrées du serveur SRM sur la même instance de vCenter Server. Ce problème ne se produit pas dans tous les environnements de site de récupération partagé et il n'est généralement pas nécessaire de n'exécuter qu'une seule opération à la fois. Les conflits de noms sont relativement rares.

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