1. Accueil
  2. Support
  3. Ressources de support
  4. Documentation VMware
  5. VMware vCenter Site Recovery Manager
  6. VMware vCenter Site Recovery Manager 5.0.1
+33 (0)1 71 23 08 74

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

VMware vCenter Site Recovery Manager 5.0.1 | 15 mars 2012 | Build 633117

Dernière mise à jour : 21 octobre 2013

Recherchez les ajouts et les mises à jour de ces notes.

Contenu des notes de mise à jour

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés

VMware vCenter Site Recovery Manager 5.0.1 présente les améliorations suivantes :

  • Le basculement forcé, qui vous permet de récupérer les machines virtuelles dans les cas où les baies de stockage échouent au niveau du site protégé et où, en conséquence, les machines virtuelles protégées ne peuvent pas être gérées, arrêtées, mises hors tension ou désenregistrées.
  • Correctifs de bogues décrits dans la section Problèmes résolus.

Localisation

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

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

Compatibilité

Matrice de compatibilité SRM

Pour obtenir les informations les plus récentes sur l'interopérabilité et la compatibilité des produits, reportez-vous au document Matrices de compatibilité pour VMware vCenter Site Recovery Manager.

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

Pour obtenir la liste la plus récente des baies de stockage et SRA compatibles, reportez-vous au document Matrice de compatibilité des partenaires de stockage de Site Recovery Manager.

Prise en charge de VMware VSA

Les machines virtuelles qui résident sur vSphere Storage Appliance (VSA) peuvent être protégées par SRM 5.0.1 en utilisant VR (vSphere Replication). VSA ne nécessite pas d'adaptateur de réplication de stockage (SRA) pour fonctionner avec SRM 5.0.1.

Installation et mise à niveau

SRM 5.0.1 peut être exécuté avec ESXi Server 4.0 et 4.1 et avec Virtual Infrastructure 3.5 uniquement si vous utilisez la réplication basée sur la baie. Si vous utilisez vSphere Replication, seul ou avec la réplication basée sur la baie, vous devez mettre à niveau les hôtes ESXi Server vers la version 5.0 ou ESXi Server 5.0 update 1 dans le cadre du processus de mise à niveau.

Pour installer SRM 5.0.1 sans effectuer la mise à niveau à partir d'une version précédente, reportez-vous à la section Installation et mise à jour de Site Recovery Manager du Guide d'administration de Site Recovery Manager .

Mise à niveau de SRM 5.0 vers SRM 5.0.1

Vous pouvez effectuer une mise à niveau sur place de SRM 5.0 vers SRM 5.0.1. VMware recommande les mises à niveau sur place plutôt que les installations complètes, car tous les rapports d'historique, plans de récupération, groupes de protection et personnalisations des plans de récupération sont ainsi conservés. Vous devez effectuer la procédure de mise à niveau sur le site protégé et sur le site de récupération.

  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 VMware-srm-5.0.1- buildnumber.exe.
  4. Cliquez sur Oui lorsque vous êtes invité à confirmer que vous souhaitez mettre à niveau SRM.
  5. Cliquez sur Suivant pour installer SRM 5.0.1 en utilisant les paramètres de l'installation SRM précédente.
  6. Cliquez sur Oui pour confirmer que vous avez sauvegardé la base de données SRM.
  7. Cliquez sur Terminer une fois l'installation effectuée.
  8. Répétez le processus de mise à niveau sur le site de récupération.

Après avoir mis à niveau SRM Server, vous devez réinstaller le plug-in du client SRM.

  1. Désinstallez le plug-in du client SRM 5.0.
  2. Connectez-vous à une instance de vSphere Client et connectez-vous au vCenter Server auquel le serveur SRM Server est connecté.
  3. Sélectionnez Plug-ins > Gérer les plug-ins.
  4. Cliquez sur Télécharger et installer pour installer le plug-in du client SRM 5.0.1.
  5. 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.
  6. 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 1.0 vers vSphere Replication 1.0.1

SRM 5.0 incluait vSphere Replication 1.0. SRM 5.0.1 inclut vSphere Replication 1.0.1. La mise à niveau de SRM 5.0 vers SRM 5.0.1 ne met pas automatiquement à niveau vSphere Replication 1.0 vers vSphere Replication 1.0.1. Sur le plan fonctionnel, vSphere Replication 1.0.1 est identique à vSphere Replication 1.0, avec l'ajout des correctifs de bogues.

Vous pouvez exécuter SRM 5.0.1 avec vSphere Replication 1.0, ou vous pouvez mettre à niveau vSphere Replication vers la version 1.0.1 pour bénéficier des correctifs de bogues dans la version 1.0.1. Vous mettez à niveau vSphere Replication Management Server (VRM Server) et les serveurs vSphere Replication (VR) Server séparément.

IMPORTANT : dans l'interface VAMI, ne sélectionnez pas l'option Mise à jour > Paramètres pour mettre à jour automatiquement vSphere Replication. Si vous sélectionnez les mises à jour automatiques, l'interface VAMI met à jour vSphere Replication vers la version 5.x la plus récente qui est incompatible avec SRM et vCenter Server 5.0.x. Laissez le paramètre de mise à jour défini sur Aucune mise à jour automatique.

Mettez à niveau le VRM Server :

  1. Mettez à niveau le serveur SRM Server et le client vers SRM 5.0.1.
  2. Accédez à l'interface de configuration du serveur VRM à l'adresse : https:// VRMS_IP_address:8080.
  3. Connectez-vous à l'interface de configuration VRM Server comme utilisateur racine.
  4. Sélectionnez l'onglet Mise à jour.
  5. Cliquez sur Vérifier les mises à jour. L'outil de recherche de mise à jour indique que la version 1.0.1 est disponible.
  6. Cliquez sur Installer des mises à jour.
  7. Sélectionnez l'onglet VRM > Configuration, puis cliquez sur le bouton Redémarrer sous État du serveur VRM pour redémarrer le serveur VRM.
  8. Répétez la procédure pour VRM Server sur le site de récupération.

Mettez à niveau les serveurs VR Server :

  1. Mettez à niveau le serveur VRM Server.
  2. Accédez à l'interface de configuration de VR Server à l'adresse : https:// VR_IP_address:5480.
  3. Connectez-vous à l'interface de configuration de VR Server en tant qu'utilisateur racine.
  4. Sélectionnez l'onglet Mise à jour.
  5. Cliquez sur Vérifier les mises à jour. L'outil de recherche de mise à jour indique que la version 1.0.1 est disponible.
  6. Cliquez sur Installer des mises à jour.
  7. Sélectionnez l'onglet Système > Informations et cliquez sur le bouton Redémarrer pour redémarrer le serveur VR Server.
  8. Répétez la procédure pour les serveurs VR Server sur le site de récupération.

Mise à niveau de SRM 4.1.2 vers SRM 5.0.1

Vous pouvez effectuer une mise à niveau sur place de SRM 4.1.2 vers SRM 5.0.1. VMware recommande les mises à niveau sur place plutôt que les installations complètes, car tous les rapports d'historique, plans de récupération, groupes de protection et personnalisations des plans de récupération sont ainsi conservés. Pour mettre à niveau le client SRM vers 5.0.1, vous devez préalablement désinstaller le client SRM 4.1.2.

REMARQUE : la mise à niveau de SRM 4.1 ou SRM 4.1.1 vers SRM 5.0.1 n'est pas prise en charge.

Pour mettre à niveau SRM 4.1.2 vers SRM 5.0.1, suivez la procédure de mise à niveau de SRM 4.1 ou 4.1.1 vers SRM 5.0 dans la section Mise à niveau de SRM du Guide d'administration de Site Recovery Manager . Consultez également le blog concernant le processus de mise à niveau de SRM 5 Upgrade Process .

Composants Open Source

Les déclarations de copyright et les licences applicables aux composants logiciels Open Source distribués dans vCenter Site Recovery Manager 5.0.1 sont disponibles sur le site de téléchargements de SRM. Vous pouvez également télécharger les fichiers sources de toutes les licences GPL, LGPL ou autres licences similaires qui nécessitent la mise à disposition du code source ou des modifications du code source pour la version la plus récente de vCenter Site Recovery Manager officiellement disponible.

Mises en garde et limites

  • Interopérabilité avec Storage vMotion et Storage DRS
    En raison de certains cas spécifiques et limités pour lesquels les performances de récupération peuvent être compromises durant le mouvement de stockage, l'utilisation de Site Recovery Manager 5.0.1 n'est prise en charge ni avec Storage vMotion (SVmotion), ni avec SDRS (Storage Distributed Resource Scheduler), ni avec les clusters de banque de données. Si vous utilisez SVMotion pour transférer une machine virtuelle protégée d'une banque de données située dans un groupe de protection vers une banque de données non protégée, vous devez reconfigurer manuellement la protection de la machine virtuelle.

  • La conversion NAT (Network Address Translation) n'est pas prise en charge avec SRM
    Lorsque vous configurez vSphere Replication, vous devez configurer le serveur vSphere Replication (serveur VR) avec une adresse IP visible du serveur protégé vSphere Replication Management (serveur VRM) et du serveur VRM de récupération.

  • Interopérabilité avec vCloud Director
    Site Recovery Manager 5.0.1 offre une prise en charge limitée des environnements vCloud Director. Il n'est pas possible d'utiliser SRM pour protéger des machines virtuelles situées dans des pools de ressources vCloud (machines virtuelles déployées dans une organisation). En revanche, 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 de vCD Server et de vCenter Server, ainsi que les bases de données qui fournissent l'infrastructure de gestion de vCloud Director, reportez-vous à Étude de cas de résilience de l'infrastructure VMware vCloud Director.

  • Reprotection et retour arrière automatisé non pris en charge avec vSphere Replication
    La reprotection et le retour arrière automatisé ne sont pris en charge qu'avec des machines virtuelles répliquées sur des baies. Les machines virtuelles configurées avec vSphere Replication ne peuvent pas faire l'objet d'un retour arrière automatique vers le site d'origine en utilisant des plans de reprise d'activité existants.

  • Certaines fonctions vSphere et RDM ne sont pas prises en charge avec vSphere Replication
    Vous ne pouvez pas utiliser vSphere Replication avec vSphere Fault Tolerance, les modèles de machines virtuelles, les clones liés et le mappage de disque brut physique (RDM).

  • Protection et récupération des machines virtuelles avec des snapshots d'état de mémoire
    Lorsque vous protégez des machines virtuelles avec des snapshots d'état de mémoire, les hôtes ESX des sites de protection et de récupération doivent disposer de CPU compatibles, comme indiqué dans les articles de la base de connaissances VMware Conditions de compatibilité de CPU VMotion pour les processeurs Intel et Conditions de compatibilité de CPU VMotion pour les processeurs AMD. Les hôtes doivent également avoir les mêmes fonctions BIOS activées. Si les configurations BIOS des serveurs ne correspondent pas, elles affichent un message d'erreur de compatibilité, même si elles sont par ailleurs identiques. Les deux fonctions les plus courantes à contrôler sont : la protection mémoire des microprocesseurs (NX/XD) et la technologie de virtualisation (VT/AMD-V). Pour connaître les autres limites de la protection et de la récupération des machines virtuelles avec des snapshots, reportez-vous à la section Limitations de la protection et de la récupération des machines virtuelles du Guide d'administration de Site Recovery Manager .

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

  • Nombre maximal de plans de récupération par instance de SRM Server
    Vous pouvez créer le nombre maximal suivant de plans de récupération par instance de SRM Server :

    • Réplication basée sur la baie : 150
    • vSphere Replication : 250

    Pour connaître le nombre de plans de récupération que vous pouvez exécuter simultanément et les autres limites opérationnelles de SRM, reportez-vous au Guide d'administration de Site Recovery Manager .

Problèmes résolus

  • La migration planifiée peut entraîner un ralentissement des hôtes ESX

    Durant la migration planifiée, SRM donne d'abord l'instruction aux hôtes ESX de démonter les banques de données répliquées et de détacher les LUN assurant la sauvegarde de ces banques de données. SRM donne ensuite l'instruction au logiciel de baie de stockage de faire passer les LUN détachés en lecture seule. Ce processus permet de s'assurer que les périphériques sur les hôtes ESX ne rencontrent pas une condition APD (Tous chemins hors service) pour les banques de données et les LUN qui font l'objet d'une migration. La migration d'une machine virtuelle avec des RDM peut amener les LUN RDM à passer dans une condition ADP. Après que les RDM passent dans une condition ADP, les hôtes ESX continuent de réessayer d'établir la connectivité avec les LUN RDM perdus. Au fur et à mesure que le nombre de RDM indisponibles s'élève, le nombre de tentatives de l'hôte ESX pour se reconnecter aux RDM perdues augmente en conséquence. Alors que cela continue, l'hôte ESX peut être lent à répondre et vCenter Server peut finalement trouver que les hôtes répondent mal. Ce problème est plus susceptible de se produire avec certaines baies de stockage. Par exemple, le risque est plus important lorsqu'un SRA prend en charge une cible iSCSI par LUN. Ce problème est maintenant corrigé.

  • Les tâches SRM nettoyées trop rapidement génèrent une exception ManagedObjectNotFound

    Les tâches SRM sont supprimées du service vmware-dr une minute après la fin des tâches. Si SRM fait référence à un objet de tâche qui a été supprimé, il renvoie l'exception ManagedObjectNotFound et affiche le message d'erreur L'objet a déjà été supprimé ou n'a pas été créé complètement. Le délai de nettoyage des tâches par défaut est de une minute. Dans ce cas, vous pouvez configurer l'heure de nettoyage en définissant le paramètre Topology.drTaskCleanupTime dans le fichier config.xml.

    <topology>
    <drTaskCleanupTime>300</drTaskCleanupTime>
    </topology>

  • 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. Ils peuvent continuer à travailler avec SRM 5.0.1 en utilisant ces licences par CPU. Dans SRM 5.0, la formule de comptage du nombre de licences CPU utilisées est trop tolérante. Dans ce scénario, il est possible que la conversion accorde à tort trop de licences par CPU pour SRM 5.0. Ce problème a été résolu dans SRM 5.0.1 et des avertissements plus stricts ont été mis en place lorsque les licences sont insuffisantes.

  • La protection d'une machine virtuelle dans une banque de données répliquée répartie sur deux partitions de disque provoque l'arrêt intempestif de SRM et il ne démarre pas.

    Si vous protégez une machine virtuelle contenue dans une banque de données répliquée répartie sur deux partitions de disque d'un même périphérique, SRM s'arrête de manière intempestive lors du recalcul du groupe de banques de données. Les journaux SRM affichent l'erreur Panic: Assert Failed: "ok" @ d:\build\ob\bora-474459\srm\public\persistence/saveLoadUtils.h:329. Dans ce cas, SRM Server ne redémarre pas. Ce problème a été résolu.

  • De brèves interruptions de communication peuvent amener SRM Server à attendre indéfiniment.

    Si la communication réseau entre les sites protégés et de récupération est interrompue pendant moins de cinq minutes, SRM Server peut ne pas répondre. Ce problème est dû à l'absence des résultats de la mise à jour dans SRM Server et au délai d'expiration côté serveur des appels waitforupdate provenant du site distant pendant l'interruption du réseau. Ce problème a été résolu par l'introduction de délais d'expiration côté client sur​l'appel waitforupdate. Le délai d'attente par défaut côté client est de 5 minutes.

  • Analyses d'hôtes répétitives réactivées pendant le test et la récupération

    SRM 4.1 fournissait une option configurable, storageProvider.hostRescanCnt, pour vous permettre d'analyser à maintes reprises plusieurs hôtes pendant les tests et la récupération. Cette option n'existait pas dans SRM 5.0, mais elle a été restaurée dans le menu Paramètres avancés de SRM 5.0.1. Cliquez avec le bouton droit sur un site dans la vue Sites, sélectionnez Paramètres avancés, puis storageProvider. Voir l'article KB 1008283 .

  • La spécification de la personnalisation ne configure pas la passerelle pour Red Hat Enterprise Linux 5.x

    La personnalisation d'image des machines virtuelles Red Hat Enterprise Linux 5.x ne configure pas correctement la passerelle. Par conséquent, si vous attribuez une nouvelle passerelle à la machine virtuelle de récupération RHEL 5.x lors de la personnalisation, la nouvelle entrée de la passerelle est ajoutée au fichier /etc/sysconfig/network-scripts/route-ethX. Le service réseau RHEL sélectionne la première entrée dans le fichier, à savoir l'ancienne passerelle sur le site de protection, au lieu de la nouvelle passerelle définie par l'utilisateur lors de la personnalisation. Ce problème a été résolu.

  • Le serveur SRM Server de récupération s'arrête de manière intempestive après une suspension en générant une erreur indiquant que le plan de récupération ne se trouve pas dans le contexte approprié.

    Après une suspension du site protégé et du site de récupération, le serveur SRM Server de récupération s'arrête de manière inattendue lorsque vous le redémarrez, avec l'erreur CreateRemoteSuspendVmListViewAndCallback on plan Recovery Plan on wrong context. Ce problème a été résolu.s

  • La configuration de vSphere Replication génère une erreur d'environnement régional non valide lorsque vous utilisez SRM dans l'environnement régional en chinois simplifié sur vCenter Server Appliance

    Si vous utilisez SRM dans un environnement régional en chinois simplifié sur vCenter Server Appliance et que vous tentez de configurer une réplication vSphere sur une machine virtuelle, l'opération échoue avec une erreur d'environnement régional non valide. Ce problème a été résolu.

  • SRM s'arrête de manière intempestive au cours du démarrage après vérification de l'utilisation de la licence CPU.

    Dans certains cas, SRM s'arrête de manière inattendue en cours de démarrage lors de la vérification de l'utilisation de la licence CPU, en générant l'erreur Unexpected Object in results: vim.VirtualMachine. Ce problème a été résolu.

  • L'exécution du programme d'installation SRM en mode de réparation supprime le fichier exportConfig.xml.

    Lors d'une mise à niveau sur place de SRM 4.1.x vers la version 5.0.x, SRM crée un fichier, exportConfig.xml, qui contient les détails des mappages d'inventaire, des mappages de banque de données, des machines virtuelles et des groupes protégés, des plans de récupération, et ainsi de suite. Vous pouvez utiliser ce fichier pour migrer les données vers la base de données après la mise à niveau. Toutefois, si vous exécutez le programme d'installation de SRM en mode de réparation avant de migrer les données vers la base de données, le programme d'installation supprime le fichier exportConfig.xml. Ce problème a été résolu et l'exécution du programme d'installation en mode de réparation ne supprime pas le fichier exportConfig.xml.

  • La personnalisation IP des machines virtuelles échoue avec le code d'erreur 14010

    La personnalisation IP des machines virtuelles échoue avec l'erreur There was an error in communication' Error Code: '14010' lorsqu'elle tente de configurer des adaptateurs qui ne sont pas spécifiques à VMware. Ce problème a été résolu et la personnalisation IP ignore désormais les adaptateurs réseau qui ne sont pas des adaptateurs réseau par défaut et elle configure uniquement l'adaptateur physique.

  • La récupération de test échoue si SRA obtient des ID de snapshot dupliqués de plusieurs périphériques de stockage.

    L'exécution d'un test de récupération peut échouer avec l'erreur Panic: Assert Failed: "runtimeInfo._résultat != 0 (Missing results in plan: recovery-plan-10257)" @ d:/build/ob/bora-474459/srm/src/recovery/engine/manager.cpp:1300^M. Ce problème ses produit, car les adaptateurs de réplication de stockage (SRA) permettent d'utiliser des ID de snapshot identiques sur des périphériques de stockage différents, alors que SRM nécessite que les ID de snapshot soient uniques. Ce problème affecte les récupérations de test, mais pas les récupérations réelles. Le problème a été résolu et SRM accepte désormais les ID de snapshot dupliqués.

  • Impossible de faire défiler la liste des réseaux des plans de récupération lorsque plusieurs options de réseau sont disponibles.

    Si plus de 30 réseaux sont disponibles dans l'environnement SRM, la liste complète des réseaux disponibles que vous pouvez sélectionner lorsque vous créez un plan de récupération n'est pas visible. Ce problème a été résolu et vous pouvez désormais faire défiler la liste complète.

Problèmes connus

Les problèmes connus suivants ont été détectés lors de tests rigoureux. Nous espérons qu'ils vous aideront à comprendre un certain nombre de comportements système que vous pourrez rencontrer dans cette version.

  • Les disques volumineux effectuent inutilement une synchronisation complète

    Lorsqu'un disque d'un volume supérieur à 256 Go est protégé à l'aide de vSphere Replication (VR), toutes les opérations qui provoquent un redémarrage interne du disque virtuel amènent le disque à effectuer une synchronisation complète. Un redémarrage interne se produit à chacune des opérations suivantes :

    • Redémarrage d'une machine virtuelle
    • Migration à l'aide de vMotion d'une machine virtuelle
    • Reconfiguration d'une machine virtuelle
    • Prise d'un snaphot d'une machine virtuelle
    • Interruption, puis reprise de la réplication

    La synchronisation complète est lancée par ESX, et toute résolution de ce problème nécessiterait une mise à jour d'ESX. Ces synchronisations nécessitent une E/S supplémentaire pour les disques du site protégé et du site de reprise, ce qui demande souvent plus de temps que l'objectif de point de récupération (RPO), ce qui entraîne une cible manquée de RPO. Ce problème existe dans ESXi Server 5.0, mais a été corrigé dans ESXi Server 5.0 update 1.

    Solution : mettez à niveau ESXi Server vers la version 5.0 Update 1.

  • La définition de LVM.enableResignature sur la valeur 1 persiste après un test de basculement.

    SRM ne prend pas en charge les environnements ESX dans lesquels l'indicateur LVM.enableResignature est défini sur 0. Au cours d'un test de basculement ou d'un basculement réel, SRM définit automatiquement LVM.enableResignature sur 1 si cet indicateur n'est pas déjà défini. SRM définit l'indicateur pour resigner les volumes de snapshot et il les monte sur les hôtes ESX pour la récupération. Une fois l'opération terminée, l'indicateur reste défini sur la valeur 1. Pour plus d'informations, reportez-vous à l'article KB 2010051.

  • Impossible de reconfigurer vSphere Replication sur une machine virtuelle après la réception du message Erreur lors de la validation de la transaction au cours de la configuration

    Si vous recevez le message Erreur lors de la validation de la transaction au cours de la configuration de la réplication d'une machine virtuelle et que vous tentez de reconfigurer la réplication sur la machine virtuelle, l'opération échoue. Ce problème survient, car vSphere Replication ne nettoie pas correctement les données de configuration après la tentative de configuration. Par conséquent, la réplication de la machine virtuelle semble être configurée pour vSphere Replication alors qu'elle ne l'est pas.

    Solution : Pour nettoyer correctement les données de configuration, désactivez la réplication de la machine virtuelle depuis la ligne de commande.

    1. Connectez-vous à la console ESXi.
    2. Exécutez une commande permettant de rechercher l'ID de la machine virtuelle dans l'hôte ESXi. 
      # vim-cmd vmsvc/getallvms | grep 
nom_machine_virtuelle
      L'ID de la machine virtuelle est le nombre figurant dans la première colonne.
    3. Exécutez une commande permettant de désactiver la réplication de la machine virtuelle avec l'ID trouvé dans l'étape précédente. 
      # vim-cmd hbrsvc/vmreplica.disable 
ID_machine_virtuelle
  • La case à cocher Basculement forcé reste activée après le retour à une migration planifiée

    Si vous exécutez un plan de récupération en sélectionnant l'option de basculement forcé et que vous revenez à la migration planifiée en sélectionnant Migration planifiée, la case Basculement forcé reste cochée et affichée en grisé dans l'assistant d'exécution du plan de récupération. Ce problème affecte uniquement l'interface utilisateur et SRM fonctionne correctement.

    Solution : Fermez, puis rouvrez l'assistant d'exécution du plan de récupération après avoir désactivé l'option de basculement forcé.

  • Les opérations de récupération et de migration peuvent échouer si les banques de données à espace réservé ne sont pas visibles par tous les hôtes d'un cluster protégé

    Au cours d'une récupération et d'une migration, les machines virtuelles à espace réservé sont remplacées par des machines virtuelles récupérées. Si vous disposez d'un cluster comportant plusieurs hôtes sur le site de récupération, toutes les banques de données à espace réservé doivent être disponibles pour tous les hôtes du cluster, car dans le cas contraire, la permutation des machines virtuelles peut échouer. SRM ne vous empêche pas de sélectionner des banques de données à espace réservé qui ne sont pas disponibles pour tous les hôtes du cluster. Si les banques de données à espace réservé ne sont pas visibles par tous les hôtes, le plan de récupération échoue avec le message d'erreur Erreur - Impossible d'accéder au fichier [datastore]" Impossible d'annuler l'enregistrement des VM protégées. Les hôtes doivent avoir accès aux banques de données qui contiennent à la fois les machines virtuelles à espace réservé et les machines virtuelles récupérées.

    Solution : Vérifiez manuellement que les banques de données des machines virtuelles à espace réservé et des machines virtuelles récupérées sont visibles par tous les hôtes du cluster protégé.

  • Les versions VRM Server et VR Server ne sont pas mises à jour dans le récapitulatif des machines virtuelles après une mise à niveau.

    Si vous mettez à niveau une installation existante du dispositif VRMS (vSphere Replication Manager Server) de la version 1.0 vers la version 1.0.1, les numéros de version de VRM Server et de VR Server ne sont pas mis à jour dans l'onglet du récapitulatif des machines virtuelles. Lorsque vous sélectionnez le serveur VRM Server ou un serveur VR Server dans l'inventaire vCenter Server, l'onglet du récapitulatif affiche toujours la version 1.0.0.0, même si le serveur VRM Server a été mis à jour vers la version 1.0.1. Si vous effectuez une nouvelle installation de VRM Server version 1.0.1, l'onglet du récapitulatif affiche le numéro de version correct.

    Solution : Vérifiez le numéro de version dans l'interface de gestion du dispositif virtuel VRMS :

    1. Connectez-vous à https:// adresse_IP_VRMS:8080.
    2. Sélectionnez l'onglet Mise à jour.
    3. Cliquez sur État. Le numéro de version est 1.0.1.0.

    Vous pouvez également afficher le numéro de version correct dans la console du serveur VRM Server ou VR Server dans vSphere Client.

  • Vous pouvez utiliser des bases de données non prises en charge avec vSphere Replication Management Server.

    Vous pouvez configurer VRMS (vSphere Replication Management Server) pour utiliser des bases de données non prises en charge ; la configuration VRMS aboutit sans avertissements sur le support des bases de données. Toutefois, l'utilisation d'une base de données non prise en charge peut générer un comportement imprévisible. Les bases de données suivantes ont été testées complètement et sont prises en charge totalement avec VRMS :

    • SQL Server 2005 SP4 64 bits
    • SQL Server 2008 R2 SP1 64 bits
    • SQL Server 2008 R2 64 bits

  • Certains SRA gèrent des fuseaux horaires de façon incorrecte lors d'un basculement

    Les tests de basculement et les basculements réels peuvent s'arrêter avec l'erreur Impossible de créer des snapshots des périphériques de réplication pour le groupe 'protection-group-999' à l'aide de la paire de baies 'array-pair-999': Vmacore::SystemException "Le paramètre est incorrect. " (87). Cette erreur est due à une gestion incorrecte du fuseau horaire que la baie de stockage retourne au SRA. Ce problème est commun à tous les horodatages antérieurs au 1er janvier 1970. Pour obtenir des informations détaillées et une solution, reportez-vous à l'article KB 2018597.

  • Lors de la mise à niveau de SRM 4.1.2 vers SRM 5.0.1, la commande srm-migration importConfig échoue en raison de la modification des ID des objets de banque de données.

    Le processus de mise à niveau SRM 5.0.1 se termine sans erreur, vCenter Server redémarre, et les hôtes, les invités et le stockage se mettent tous en ligne, dans le même état que lorsque le service vCenter Server a été arrêté. Toutefois, lors de la migration de SRM, l'importation du groupe de protection échoue avec l'erreur suivante :

    Protection des VM ignorée pour toutes les VM du groupe ( groupe) en raison d'une erreur : une ou plusieurs banques de données sont déjà protégées dans un autre groupe ou ne sont pas répliquées actuellement.

    Les ID d'objets de banque de données répertoriés dans le fichier SRM exportConfig.xml sont différents des mêmes ID d'objets de banque de données affichés dans le navigateur MOB. Ce problème est lié à celui décrit dans l'article KB 2007404.

    Solution : Modifiez le fichier exportConfig.xml afin d'utiliser les ID d'objets de banque de données du navigateur MOB, puis réexécutez la commande srm-migration importConfig.

  • Événements non affichés correctement pour les systèmes d'exploitation coréens

    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 coréen, le client demande des messages du dossier kodans l'installation de vCenter Server, car vCenter Server et vSphere Client sont localisés en coréen. Or, si vCenter Server et vSphere Client sont localisés en coréen, SRM ne l'est pas. De ce fait, des messages XXXs'affichent à la place des messages de SRM Server. Pour résoudre ce problème, créez une copie du dossier enqui se trouve dans C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\. Renommez le dossier de enen koet redémarrez vCenter Server et les services SRM.

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

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

    Solution : Réexécutez le plan de récupération. Si l'erreur persiste, configurez le DRS du cluster du site de récupération sur le mode manuel et relancez le plan de récupération.

  • La récupération échoue avec l'erreur suivante : Error creating test bubble image for group... L'exception détaillée est la suivante : Error while getting host mounts for datastore: managed-object-id...ou The object has already been deleted or has not been completely created.

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

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

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

    Solution : Si le site principal n'est plus disponible, contactez le support VMware pour obtenir des instructions sur la mise à jour manuelle de la base de données VRMS avec le nouvel ID d'objet géré par la banque de données. Si le site principal est encore disponible :

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