VMware vCenter Site Recovery Manager 5.5 | 22 sept 2013 | Version 1315893

Dernière mise à jour : 21 oct 2013

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

Contenu des notes de mise à jour

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés dans SRM 5.5

VMware vCenter Site Recovery Manager 5.5 comporte les nouvelles fonctions et améliorations suivantes :

Localisation

VMware vCenter Site Recovery Manager 5.5 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.5.

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

Installation et mise à niveau

Pour obtenir un guide d'évaluation sous la forme d'une présentation technique détaillée des principales fonctionnalités de Site Recovery Manager 5.x, reportez-vous à la section Ressources VMware vCenter Site Recovery Manager relatives à la continuité d'activité.

Pour obtenir des informations sur l'installation et la mise à niveau de SRM, reportez-vous à Installation et configuration de 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.

IMPORTANT : Lors de la mise à niveau de vSphere Replication, dans Mise à jour > Paramètres de l'interface de gestion des dispositifs virtuels (VAMI), ne sélectionnez pas l'option qui permet de mettre à jour automatiquement vSphere Replication. Si vous optez pour les mises à jour automatiques, l'interface VAMI met à jour vSphere Replication vers la version la plus récente qui peut ne pas être compatible avec SRM 5.5 et vCenter Server 5.5. Laissez la configuration de mise à jour mis définie sur Aucune mise à jour automatique.

Restrictions de fonctionnement pour SRM et vSphere Replication

Pour connaître les restrictions de fonctionnement de SRM 5.5 et de vSphere Replication 5.5, 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 relatives aux droits d'auteur et les licences applicables aux composants logiciels en libre accès distribués dans Site Recovery Manager 5.5 sont disponibles sur 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

  • vSphere 5.5 inclut VMware Virtual SAN en tant que fonction expérimentale. Vous pouvez effectuer des tests avec Virtual SAN, mais celui-ci n'est pas pris en charge pour une utilisation dans un environnement de production. L'utilisation de SRM et de vSphere Replication avec VMware Virtual SAN est possible, mais n'est pas prise en charge. Pour connaître les limitations de l'utilisation de Virtual SAN avec SRM et vSphere Replication, reportez-vous à Utilisation de vSphere Replication avec un stockage Virtual SAN. Pour obtenir des informations sur l'activation de Virtual SAN, consultez la communauté des utilisateurs de la version beta publique de Virtual SAN. VMware ne peut ni résoudre des problèmes, ni proposer des solutions, ni fournir des correctifs pour Virtual SAN. Si vous testez Virtual SAN, VMware recevra avec beaucoup d'intérêt tous les commentaires que vous souhaitez partager. Veuillez envoyer une demande d'assistance à l'aide des méthodes d'accès décrites dans les pages de la communauté des utilisateurs de la version beta publique de Virtual SAN :
  • SRM 5.5 offre 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.
  • Windows Server 2003 n'est pas une plate-forme prise en charge par SRM Server, mais le programme d'installation de SRM vous permet d'installer SRM sur Windows Server 2003.
  • SRM 5.5 ne prend plus en charge IBM DB2 comme base de données de SRM, conformément à la fin de la prise en charge de DB2 comme base de données de vCenter Server 5.5. Si vous utilisez DB2 comme base de données de SRM ou comme base de données externe de vSphere Replication, contactez l'assistance technique de VMware pour obtenir des instructions sur la migration de vos données vers une base de données prise en charge.
  • vSphere Flash Read Cache est désactivé sur les machines virtuelles après la récupération et la réservation est définie sur zéro. Avant d'effectuer une récupération sur une machine virtuelle configurée pour utiliser vSphere Flash Read Cache, prenez note de la réservation de cache de la machine virtuelle à partir de vSphere Web Client. Vous pouvez reconfigurer vSphere Flash Read Cache sur la machine virtuelle après la récupération.
  • Des limitations s'appliquent lorsque vous utilisez SRM 5.5 dans une configuration de site de récupération partagé (N:1). Reportez-vous à la section Problèmes connus lors de l'utilisation de SRM 5.5 dans une configuration de site de récupération partagé.
  • Vous pouvez utiliser une protection basée sur la baie avec SRM 5.5 pour protéger un maximum de 50 LUN. Reportez-vous à la section Limitations de l'utilisation de SRM avec une réplication basée sur la baie dans les grands environnements.

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.

  • 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 vSphere Replication sur une machine virtuelle avec un disque RDM en mode physique, le message d'erreur suivant peut s'afficher :

    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. Vous ne pouvez pas configurer vSphere Replication sur des machines virtuelles qui contiennent des disques RDM en mode physique.

  • Mots de passe non-ASCII non acceptés pour l'interface de gestion du dispositif virtuel (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 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.

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

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

  • 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, le serveur SRM réagit.

    Solution : Redémarrez le serveur SRM 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.

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

  • 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, le serveur SRM doit avoir accès au mappage du disque de données brutes et aux fichiers du disque parent. Sans cet accès, le serveur SRM ne peut pas déterminer les types de disque durant une récupération. Dans un tel cas, le serveur SRM 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é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é.

  • 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 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 le serveur SRM.

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

  • 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, le serveur SRM 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.
  • 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 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.

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

  • La réplication se bloque après la restauration d'un snapshot si ce dernier a été pris pendant la suspension de la réplication.

    Lorsque vous configurez une réplication pour une machine virtuelle et suspendez la réplication, que vous prenez un snapshot, puis reprenez la réplication et restaurez le snapshot, au lieu de passer à l'état suspendu, l'état de la réplication dans l'interface utilisateur ne change pas et ne progresse pas.

    Solution : Suspendez, puis reprenez la réplication.

  • Les opérations sur vSphere Replication échouent parfois avec une erreur d'expiration du délai de lecture.

    Les opérations sur vSphere Replication échouent parfois avec l'erreur de cause d'origine java.net.SocketTimeoutException: Read timed out. Cela peut se produire si l'hôte ESXi Server est lent ou exécute de nombreuses autres opérations, telles que Storage vMotion, en même temps que vSphere Replication configure, reconfigure, arrête ou inverse des réplications. L'erreur suivante se produit en cas de réplication inverse : Impossible d'inverser la réplication pour la machine virtuelle virtual_machine. 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 : 'java.net.SocketTimeoutException: Read timed out'

    Solution : Relancez l'opération une fois les autres opérations sur le serveur ESXi terminées.

  • Les opérations de vSphere Replication échouent avec une erreur d'authentification.

    Si vous démarrez une opération sur un site SRM, par exemple la configuration de vSphere Replication sur une machine virtuelle, puis redémarrez vCenter Server et le dispositif vSphere Replication sur l'autre site, les opérations de vSphere Replication peuvent échouer avec l'erreur 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 : 'com.vmware.vim.binding.vim.fault.NotAuthenticated'. Ce problème est dû au fait que le serveur vSphere Replication conserve dans son cache la session de connexion établie avant le redémarrage de vCenter Server et du dispositif vSphere Replication.

    Solution : Pour effacer le cache de connexion de vSphere Replication, déconnectez-vous du client SRM ou de vSphere Web Client, puis reconnectez-vous.

  • Le navigateur de banque de données n'affiche pas les dossiers de la banque de données si le nom de cette dernière contient certains caractères.

    Lors de la sélection d'un dossier de banque de données cible pour vSphere Replication, si le nom de la banque de données contient certains caractères (par exemple, des parenthèses ouvrantes ou fermantes, ou un espace), la fenêtre du navigateur de banque de données n'affiche pas les sous-dossiers de la banque de données.

    Solution : Pour sélectionner un sous-dossier d'une banque de données dont le nom contient un caractère de parenthèse ou un espace, sélectionnez la banque de données, puis cliquez sur le bouton Ouvrir dans le navigateur de banque de données. Cette action ouvre la banque de données et affiche les dossiers de cette dernière.

  • Le déplacement de plusieurs réplications d'un serveur vSphere Replication à un autre provoque une erreur.

    Les opérations de reconfiguration ou de déplacement de vSphere Replication échouent avec l'erreur SocketTimeoutException: Read timed out et les réplications passent à l'état Erreur. Lorsque le serveur vSphere Replication source ou cible et le stockage subissent une charge importante, le déplacement d'une réplication peut prendre plusieurs minutes et peut provoquer une erreur de délai d'expiration.

    Solution : Reconfigurez la réplication sur le nouveau serveur 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.

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

  • 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 migration planifiée échoue au cours d'une opération vSphere vMotion avec une erreur lors de l'étape « Arrêt des machines virtuelles sur le site protégé ».

    Pendant une migration planifiée, si une opération vSphere vMotion d'une machine virtuelle protégée est en cours lors du démarrage de l'étape « Arrêt des machines virtuelles sur le site protégé », l'étape peut échouer avec l'erreur Erreur - L'opération tentée ne peut pas être effectuée dans l'état actuel (sous tension). Cet incident se produit car hostd fait échouer les opérations de mise à l'arrêt et de mise hors tension pendant la migration de la machine virtuelle.

    Solution : Relancez la migration planifiée à la fin de l'opération vSphere vMotion de la machine virtuelle.

  • L'exécution d'un plan de récupération échoue avec une erreur de machine virtuelle à l'étape de configuration du stockage.

    Les exécutions suivantes du plan de récupération échouent à la même étape de configuration du stockage pour la même machine virtuelle avec l'erreur La clé, le nom ou l'identificateur défini existe déjà. Si vous regardez dans l'inventaire vCenter Server, vous voyez deux machines virtuelles portant le même nom que celle qui a échoué. L'une d'elles se trouve dans le dossier Machines virtuelles découvertes. Ce problème est dû à un problème de communication connu entre vCenter Server et l'instance ESXi Server.

    Solution : annulez l'enregistrement de la copie de la machine virtuelle dans le dossier Machines virtuelles découvertes à partir de vCenter Server. Après avoir terminé cette opération pour toutes les machines virtuelles affectées, exécutez à nouveau le plan de récupération.

  • Lors de la réplication de plusieurs machines virtuelles, il est possible qu'un serveur vSphere Replication entre dans un état ne permettant aucune autre connexion VRMS. Cependant, il continuera à répliquer des machines virtuelles.

    Solution : redémarrez le serveur vSphere Replication.

  • L'exécution d'une récupération de test rapidement après un nettoyage provoque une erreur.

    Si vous exécutez une récupération de test trop rapidement après un nettoyage à la suite d'un test de récupération, la récupération peut échouer avec l'erreur Le fichier existe déjà. Cela se produit généralement si vous exécutez la récupération de test à partir d'un code d'automatisation, plutôt qu'à partir de l'interface SRM.

    Solution : attendez quelques minutes et recommencez l'opération.

  • L'exécution de plusieurs instances vCenter Server en mode lié provoque la duplication des rôles SRM.

    Si vous configurez les instances vCenter Server sur les sites protégé et de récupération pour qu'elles soient exécutées en mode lié, une copie des rôles SRM apparaît dans la fenêtre Assigner les autorisations.

    Solution : modifiez les rôles SRM dans chaque instance vCenter Server pour leur donner des noms uniques.

  • La récupération d'un groupe de protection vSphere Replication échoue avec l'erreur La clé, le nom ou l'identificateur défini existe déjà.

    Si vous choisissez la même banque de données lorsque vous configurez l'espace réservé pour une machine virtuelle et que vous configurez vSphere Replication sur cette machine virtuelle, l'espace réservé et les fichiers récupérés des machines virtuelles peuvent se trouver sur le même chemin. Cela peut provoquer des erreurs lors de la récupération.

    Solution : choisissez différentes banques de données pour les machines virtuelles à espace réservé et vSphere Replication.

  • Le nettoyage d'une récupération de test échoue une fois que les hôtes ESXi sont mis en mode de maintenance et hors de mode de maintenance.

    Si vous exécutez une récupération de test alors que les hôtes ESXi du site de récupération sont en mode de maintenance, la récupération de test échoue comme prévu. Si vous retirez les hôtes ESXi du mode de maintenance et que vous effectuez un nettoyage, celui-ci échoue avec des erreurs qui indiquent que les hôtes sont toujours en mode de maintenance.

    Solution : après avoir retiré les hôtes du mode de maintenance, attendez environ 10 minutes avant le nettoyage. Sinon, redémarrez le serveur SRM après avoir retiré les hôtes du mode de maintenance et avant le nettoyage.

  • L'invocation du basculement à partir de l'API SRM entraîne l'exécution de la récupération d'urgence.

    Dans SRM 5.0.x et 5.1.x, si vous invoquiez un basculement à l'aide de l'API SRM, SRM effectuait la migration planifiée. Cela était incohérent avec la documentation de l'API. Dans SRM 5.5, SRM assure la cohérence entre la documentation et la mise en œuvre de l'API en effectuant une récupération d'urgence. Il s'agit du comportement correct.

  • Impossible d'installer vSphere Client sur ​​un contrôleur de domaine.

    Dans les versions précédentes, il était possible d'installer vSphere Client sur ​​une machine hôte servant de contrôleur de domaine Active Directory. Dans vSphere 5.5, si le programme d'installation de vSphere détecte les services Active Directory, il ne vous permet pas d'installer vSphere Client.

    Solution : installez vSphere Client avant d'installer le rôle des services Active Directory ou de promouvoir le serveur pour qu'il devienne un contrôleur de domaine Active Directory.

  • Sur le site protégé, le serveur SRM s'arrête de manière inattendue au cours des opérations de reprotection.

    Si vous effectuez une récupération sur une machine virtuelle qui inclut un disque vide alloué dynamiquement et si vous avez configuré SRM pour qu'il n'attende pas VMware Tools ou ne mette pas sous tension cette machine virtuelle, l'exécution d'une reprotection quelques secondes après la récupération provoque l'arrêt inattendu du serveur SRM sur le site protégé. Lorsque vous redémarrez le serveur SRM, le message d'erreur suivant s'affiche dans les journaux :

    Erreur - Échec d'inversion de la réplication des périphériques ayant été basculés. Échec de la commande SRA 'prepareReverseReplication'. L'adresse de la baie de stockage n'est pas accessible. Il se peut que la baie de stockage soit indisponible ou que l'adresse IP saisie soit incorrecte. Assurez-vous que la baie de stockage est active et en cours d'exécution, et que l'adresse IP de la baie de stockage est accessible via l'interface de ligne de commande.

    Le nettoyage provoque la même erreur. Cette erreur ne se produit pas pour les machines virtuelles disposant de disques non vides et sur lesquelles est installé un système d'exploitation. Ce problème ne se produit généralement que si vous commencez la reprotection à l'aide de l'API SRM. Si vous commencez la reprotection à partir de l'interface SRM, le temps écoulé entre la fin de la récupération et le début la reprotection est suffisamment long pour que ce problème ne se produise pas.

    Solution : attendez quelques secondes après l'exécution de la récupération avant d'effectuer la reprotection.

  • 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 de 10 à 20 minutes, étant donné que vSphere Replication met à jour le registre d'empreinte SSL de chaque hôte.

    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. Voir aussi L'enregistrement du serveur vSphere Replication prend plusieurs minutes.

  • L'annulation de la configuration des réplications ou l'exécution de la reprotection échoue après la mise à niveau de SRM et vSphere Replication.

    Si vous avez exécuté une récupération de test sans nettoyage, puis la mise à niveau de vSphere Replication vers la version 5.5, l'annulation de la configuration d'une réplication ou l'exécution de la reprotection échoue avec l'erreur Erreur générique du serveur VRM... 'Error while committing the transaction'. Cette erreur se produit car vSphere Replication ne parvient pas à nettoyer les données de l'image de test dans la base de données de vSphere Replication lors de la mise à niveau, ce qui évite d'autres suppressions de la réplication.

    Solution : exécutez un nettoyage de test avant la mise à niveau de SRM et vSphere Replication vers la version 5.5. Si vous avez déjà mis à niveau SRM et vSphere Replication vers la version 5.5, vous devez supprimer manuellement les données de test de la base de données de vSphere Replication sur le site de récupération.

    Base de données externe SQL Server ou Oracle Server :

    1. Connectez-vous à la machine hôte de la base de données de vSphere Replication sur le site de récupération.
    2. Exécutez les instructions SQL suivantes dans la base de données de vSphere Replication :

      delete from DiskImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from ConfigFileImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);
      delete from GroupImageEntity where dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);

    Base de données intégrée de PostgreSQL vSphere Replication :

    1. Connectez-vous au dispositif vSphere Replication sur le site de récupération.
    2. Tapez la commande suivante :

      /opt/vmware/vpostgresql/1.0/bin/psql -U vrmsdb

    3. Exécutez les instructions SQL suivantes :

      delete from DiskImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from ConfigFileImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);
      delete from GroupImageEntity where dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);

    4. Tapez \q ou appuyez sur CTRL+D pour quitter.
    1. Lorsque vous utilisez ESXi Server 5.0, l'exécution de la reprotection sur des machines virtuelles récupérées avec des snapshots échoue avec une erreur de banque de données verrouillée.

      Si vous restaurez une machine virtuelle protégée avec vSphere Replication, et si cette machine virtuelle a des snapshots, l'exécution de la reprotection après la récupération provoque une erreur de banque de données verrouillée. Cette erreur se produit uniquement si vous exécutez ESXi Server 5.0 et si vous n'avez pas sélectionné le paramètre avancé pour conserver des snapshots à plusieurs moments spécifiques (MPIT) lors de la récupération.

      Solution : supprimez la réplication à partir de la machine virtuelle récupérée, puis reconfigurez vSphere Replication. Vous pouvez ensuite effectuer une reprotection.

    Problèmes connus lors de l'utilisation de SRM 5.5 dans une configuration de site de récupération partagé

    Si vous utilisez SRM 5.5 avec une configuration de site de récupération partagé, également connue sous le nom de configuration N:1, les limitations suivantes s'appliquent :

    • La récupération de vSphere Replication échoue avec l'erreur Abandon de la surveillance de synchronisation.

      Lors de l'exécution d'une récupération de vSphere Replication dans une configuration de site de récupération partagé, la récupération peut échouer avec l'erreur Erreur - Échec de synchronisation VR pour le groupe VRM replication_group. Abandon de la surveillance de synchronisation. Vérifiez la connectivité du trafic de réplication entre l'hôte source et le serveur VR cible. La synchronisation reprendra automatiquement une fois les problèmes de connectivité résolus. Ce problème peut survenir si le site de récupération est chargé comme suit :

      • Il contient des machines virtuelles avec des disques de plus de 2 To.
      • Il contient beaucoup de machines virtuelles à récupérer

      Solution :

      1. Connectez-vous au dispositif vSphere Replication en tant que racine.
      2. Ouvrez le fichier /opt/vmware/hms/conf/hms-configuration.xml.
      3. Modifiez la valeur de la balise <hms-sync-secondary-passive-state-toleration-period> sur 900 000 millisecondes.
      4. Enregistrez les modifications et redémarrez le service vSphere Replication :

        service hms restart

    • 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 signale des erreurs de délai d'attente lors de la mise sous tension des machines virtuelles sur le site de récupération partagé.

      Dans une configuration SRM de grande taille, si un seul vCenter Server gère un grand nombre de machines virtuelles sur le site de récupération partagé, par exemple 1 000 ou plus, SRM peut signaler des erreurs de délai d'attente lors de la mise sous tension des machines virtuelles sur le site de récupération partagé. Le message d'erreur suivant s'affiche : Erreur : opération expirée : 900 secondes.

      Solution :

      1. Allez à C:\Program Files\VMware\VMware vCenter Site Recovery Manager\config sur la machine hôte du serveur SRM sur le site de récupération.
      2. Ouvrez le fichier vmware-dr.xml dans un éditeur de texte.
      3. Remplacez la valeur du délai d'attente RemoteManager par défaut de 900 par un nombre plus élevé, par exemple 1 200.
        <RemoteManager>
            <DefaultTimeout>900</DefaultTimeout>
         </RemoteManager>
                          
      4. Redémarrez le service du serveur SRM.

    • La configuration de la protection échoue avec une erreur de création d'un espace réservé

      La configuration de la protection simultanée sur un grand nombre de machines virtuelles échoue avec une erreur de délai d'attente de création d'un espace réservé ou une erreur de dénomination de création d'un espace réservé :

      • Erreur de création de la VM à espace réservé : Opération expirée : 300 secondes
      • Erreur de création de la VM à espace réservé : le nom 'placeholder_name' existe déjà.

      Solution : Reportez-vous à la section La configuration de la protection échoue avec une erreur de création d'un espace réservé dans Administration de SRM 5.5.

    • Dans une configuration de site de récupération partagé, les opérations échouent avec l'erreur La connexion au serveur distant est interrompue.

      Les opérations de tests de récupération, de récupération et de reprotection peuvent échouer dans une configuration de site de récupération partagé si le serveur vSphere Replication doit traiter une charge importante.

      Solution : N'effectuez pas d'opérations simultanées sur plus de 200 machines virtuelles, avec un nombre maximal de 20 machines virtuelles par site protégé.