VMware vCenter Site Recovery Manager 5.5.1 | 11 mars 2014 | Build 1647061

Dernière mise à jour : 11 mars 2014

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

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

Localisation

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

Prise en charge de VMware Virtual SAN

SRM 5.5.1 peut protéger des machines virtuelles résidant sur VMware Virtual SAN à l'aide de vSphere Replication. Virtual SAN n'a pas besoin d'un adaptateur de réplication de stockage (SRA) pour fonctionner avec SRM 5.5.1.

Support de VSA de VMware

SRM 5.5.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.5.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.5.1, consultez la section Ressources VMware vCenter Site Recovery Manager.

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

Installer SRM 5.5.1

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

Voir la section Installation de SRM dans Installation et configuration de Site Recovery Manager 5.5.

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

Effectuez une mise à niveau de SRM 4.1.2 vers SRM 5.0.x avant d'installer SRM 5.5.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.5.1 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.5.1 n'est pas un chemin de mise à niveau pris en charge, et vous devez procéder à une mise à niveau vers SRM 5.0.x avant d'effectuer la mise à niveau vers 5.5.1. Lors de la mise à niveau d'une instance de vCenter Server 4.1.2 qui inclut une installation de SRM 4.1.2, vous devez également mettre à niveau vCenter Server vers la version 5.0.x avant de procéder à la mise à niveau de SRM vers la version 5.0.x. Si vous effectuez une mise à niveau de vCenter Server version 4.1.2 directement vers la version 5.5.1, lorsque vous tentez d'effectuer la mise à niveau de SRM version 4.1.2 vers la version 5.0.x, la mise à niveau de SRM échoue. SRM 5.0.x ne peut pas se connecter à une instance vCenter Server 5.5.

Mise à niveau d'une installation existante de SRM 5.0.x ou 5.1.x vers SRM 5.5.1

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

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

Mise à niveau d'une installation existante de SRM 5.5 vers SRM 5.5.1

Afin de mettre à niveau une installation existante de SRM 5.5 vers SRM 5.5.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.5.1-1647061.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 à jour de SRM Server, 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.5.
  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.5.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.

Mise à niveau de vSphere Replication vers vSphere Replication 5.5.1

Si vous avez installé vSphere Replication avec une version précédente de SRM et que vous effectuez une mise à niveau vers SRM 5.5.1, vous devez mettre à niveau vers la version 5.5.1 non seulement vSphere Replication, mais également les serveurs vSphere Replication. Avant de procéder à la mise à niveau de vSphere Replication vers la version 5.5.1, vous devez vérifier que vous avez mis à niveau SRM vers la version 5.5.1 et vCenter Server vers la version 5.5 au minimum.

  • Pour mettre à niveau vSphere Replication de la version 1.0.x ou 5.1.x vers la version 5.5.1, utilisez le fichier ISO téléchargeable correspondant à vSphere Replication 5.5.1.
  • Pour mettre à jour vSphere Replication de la version 5.5 vers la version 5.5.1, utilisez le fichier ISO téléchargeable correspondant à vSphere Replication 5.5.1, vSphere Update Manager ou l'interface de gestion de dispositif virtuel (VAMI) du dispositif vSphere Replication.
  • Pour mettre à jour vSphere Replication de la version 5.5 vers la version 5.5.1 dès qu'une nouvelle version de mise à jour est disponible, utilisez le fichier ISO téléchargeable correspondant à vSphere Replication 5.5.1 ou définissez l'option Utiliser le référentiel spécifié de VAMI sur https://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/5.5.1.0.

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

IMPORTANT : Ne sélectionnez pas l'option dans Mise à jour > Paramètres dans l'interface VAMI pour mettre à jour automatiquement vSphere Replication. Si vous optez pour les mises à jour automatiques, l'interface VAMI met à jour vSphere Replication vers la version 5.x la plus récente, qui peut être incompatible avec SRM et vCenter Server 5.5.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.5.x et de vSphere Replication 5.5.x, voir http://kb.vmware.com/kb/2034768.

Pour connaître les limitations de protection et de récupération lorsque vous utilisez SRM 5.5.x et vSphere Replication 5.5.x dans une configuration de site de récupération partagé, reportez-vous à http://kb.vmware.com/kb/2008061.

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 open source distribués dans Site Recovery Manager 5.5.1 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

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

Problèmes résolus

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

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

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

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

  • 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. Ce problème a été résolu.

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

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

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

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

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

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

  • Le serveur de gestion vSphere Replication ne répond plus en raison d'une fuite de mémoire potentielle lorsque vous tentez, à plusieurs reprises, de vous connecter à vCenter Server ou au serveur vSphere Replication.

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

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

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

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

  • La migration planifiée échoue pendant l'arrêt de certaines machines virtuelles, car leur état n'est pas valide.

    La migration planifiée échoue pour certaines machines virtuelles avec l'erreur Erreur : erreur de réception de la réponse SOAP de [ machine virtuelle] : shutdownGuest L'opération que vous tentez d'effectuer ne peut pas s'exécuter dans l'état actuel (Mise sous tension). Cette erreur se produit, car SRM tente d'arrêter une machine virtuelle alors qu'elle est toujours en cours de changement d'état. SRM tente désormais d'arrêter une machine virtuelle à trois reprises avant d'envoyer l'erreur. Si vous continuez à voir cette erreur, exécutez à nouveau la récupération.

  • SRM Server s'arrête de manière inattendue au cours de la récupération forcée de la reprotection.

    Lorsque vous utilisez vSphere Replication et que vous exécutez la reprotection après avoir exécuté une récupération avec l'option de récupération forcée sélectionnée, SRM Server s'arrête de manière inattendue avec l'erreur Panique : Assert Failed "!peerHmsServerRef.IsNull()". SRM Server n'a pas trouvé le serveur de gestion à distance de vSphere Replication. 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.

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

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

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

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

  • 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, 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é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 SRM Server.

    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, 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.
  • 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 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 SRM Server après avoir retiré les hôtes du mode de maintenance et avant le nettoyage.

  • 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é, SRM Server s'arrête de manière inattendue au cours des opérations de reprotection.

    SRM Server sur le site protégé peut s'arrêter de manière inattendue si vous démarrez une opération de reprotection immédiatement après une migration planifiée réussie. Ce problème est dû à un retard de détection de la liste des périphériques répliqués sur la baie de stockage après une migration planifiée. Si vous rencontrez ce problème, l'erreur suivante 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.

    Solution : Attendez environ 10 minutes après avoir effectué 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.

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

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

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

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

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

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

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

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

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

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

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

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

  • 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. Ce problème a été résolu.

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

  • Les événements ne s'affichent pas correctement dans les systèmes d'exploitation en chinois traditionnel

    Lorsque vSphere Client démarre, il détermine le paramètre régional sur lequel il fonctionne, puis choisit l'ensemble des messages à afficher sur la base du paramètre régional. Lorsque vSphere Client est installé sur un système d'exploitation en chinois traditionnel, le client demande des messages du dossier zh_TWà partir de l'installation de vCenter Server, car vCenter Server et vSphere Client sont localisés en chinois traditionnel. Bien que vCenter Server et vSphere Client soient localisés en chinois traditionnel, SRM ne l'est pas. De ce fait, des messages XXXs'affichent au lieu des messages de SRM Server.

    Solution :

    1. Créez une copie du dossier ensitué dans C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\.
    2. Renommez le dossier de enen zh_TW.
    3. Redémarrez vCenter Server et les services SRM.
  • La personnalisation IP échoue en raison de l'expiration d'un délai d'attente lors du chargement de scripts de personnalisation sur des machines virtuelles via l'API VIX.

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

    Solution : Aucune.

  • SRM Server s'arrête de manière inattendue si vous exécutez un nettoyage de test après avoir effectué une mise à niveau vers SRM 5.5.1 sans avoir mis à niveau les SRA.

    Si vous utilisez une réplication basée sur la baie et que vous avez mis à niveau SRM vers la version 5.5.1 sans avoir mis à niveau les SRA, SRM Server s'arrête de manière inattendue lorsque vous exécutez un nettoyage de test.

    Solution : Mettez à niveau les SRA vers leur version appropriée pour la version 5.5.1.

  • Le nombre de licences par CPU est incorrect

    Certains clients ayant acheté SRM 1.x et SRM 4.0 peuvent encore utiliser des licences allouées par CPU, plutôt que par machine virtuelle. Il est possible qu'un nombre inférieur de licences par CPU à celui requis par SRM 5.5 soit accordé.

    Solution : Aucune.

  • La reprotection échoue après la reconfiguration de la réplication d'une machine virtuelle dans le dossier à espace réservé d'origine de la machine virtuelle.

    Si vous supprimez vSphere Replication d'une machine virtuelle que vous avez ajoutée à un groupe de protection et à un plan de récupération, puis reconfigurez la réplication sur la machine virtuelle et utilisez Spécifier le dossier cible pour sélectionner le dossier de banque de données à espace réservé d'origine de la machine virtuelle d'origine, la récupération réussit, mais la reprotection échoue avec l'erreur Erreur : Impossible d'inverser la réplication pour la machine virtuelle ' machine_virtuelle', Aucun disque n'a été trouvé pour le disque répliqué portant l'UUID.

    Solution : Si vous reconfigurez vSphere Replication sur des machines virtuelles qui sont déjà ajoutées à un groupe de protection SRM, recréez le groupe de protection. N'utilisez pas Spécifier le dossier cible lors de la configuration de la réplication.

  • L'opération X-vMotion d'une machine virtuelle Virtual SAN à partir d'un cluster HA (High Availability) peut entraîner une alarme.

    Lorsque vous effectuez une opération X-vMotion d'une machine virtuelle Virtual SAN à partir d'un cluster HA vers un autre cluster et un autre stockage, la machine virtuelle signale une alarme similaire à Le basculement de la machine virtuelle vSphere HA a échoué.

    Solution : Aucune.