Notes de mise à jour de VMware Site Recovery Manager5.0

Nous contacter

VMware vCenter Site Recovery Manager 5.0 | 14 sept 2011 | Version 474459

Dernière mise à jour : 9 mars 2016

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

Contenu des notes de mise à jour

Ces mises à jour contiennent les rubriques suivantes :

Nouveautés

VMware vCenter Site Recovery Manager 5.0 améliore votre capacité à construire, à gérer et à exécuter des plans fiables de récupération d'urgence pour votre environnement virtuel. VMware accompagne la sortie de la version 5.0 du développement des capacités du Gestionnaire de récupération du site de façon à fournir des niveaux de protection sans précédent. L'ajout des capacités suivantes a rendu de nouveaux cas d'utilisation possibles :

  • vSphere Replication. Utilisé conjointement à VMware vSphere 5.0, Site Recovery Manager 5.0 introduit une nouvelle capacité d'utilisation de l'hôte vSphere 5.0 pour effectuer la réplication des machines virtuelles mises sous tension sur le réseau vers un autre hôte vSphere 5.0, sans l'exigence de la réplication basée sur la baie de stockage. Étant donné que les machines virtuelles changent avec l'utilisation, les blocs modifiés sont répliqués vers un cliché instantané de la machine virtuelle résidente sur le site de récupération, conformément à l'objectif de point de récupération défini comme étant une propriété de la machine virtuelle elle-même.

  • Migration planifiée. Nouveau workflow conçu pour assurer la migration tout en minimisant le risque de perte de données. La migration planifiée empêchera le workflow de continuer si une erreur est rencontrée, offrant ainsi la possibilité de rectifier le problème, en s'assurant que les systèmes sont correctement mis à l'état de repos et que toutes les modifications des données ont été entièrement répliquées.

  • Reprotection automatisée. La reprotection est une nouvelle extension des plans de reprise d'activité à utiliser uniquement avec la réplication basée sur la baie. La reprotection automatisée met en œuvre l'environnement sur le site de récupération de façon à rétablir la réplication et la protection de l'environnement sur le site protégé d'origine par un seul clic.

  • Retour arrière automatisé. Le retour arrière automatisé permet de renvoyer l'ensemble de l'environnement vers le principal site protégé à l'origine. Cela peut se produire uniquement après que la reprotection a assuré que la réplication et la synchronisation des données ont été effectuées sur le site d'origine principal. Le retour arrière exécutera le même workflow qui a été utilisé pour migrer l'environnement vers le site protégé, en veillant à ce que les systèmes critiques encapsulés par le plan de reprise d'activité soient renvoyés vers l'environnement d'origine. Le retour arrière automatisé, comme la reprotection, ne peut être utilisé qu'avec les machines virtuelles protégées de réplication basée sur la baie.

  • Définition de la dépendance améliorée. Cela inclut l'ajout d'autres groupes de priorité (5), et la possibilité de définir les dépendances des machines virtuelles dans un groupe de priorité. Les dépendances des machines virtuelles peuvent être définies afin que les systèmes requis soient disponibles avant la mise sous tension des machines virtuelles dépendantes. Cela permet le contrôle très structuré du workflow, assurant que les services requis sont disponibles avant la mise sous tension des machines virtuelles dépendantes.

Localisation

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

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

Compatibilité

Matrice de compatibilité SRM

Pour connaître la matrice actuelle d'interopérabilité et de compatibilité des produits, consultez les Matrices de compatibilité pour VMware vCenter Site Recovery Manager.

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

Pour la liste actuelle des baies de stockage et adaptateurs de réplication de stockage compatibles pris en charge, consultez la Matrice de compatibilité des partenaires de stockage de Site Recovery Manager.

Support de VSA de VMware

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

Notes d'installation et de mise à niveau

Pour la documentation d'administration, d'installation, et de mise à niveau, consultez le Guide d'administration du Site Recovery Manager.

Pour obtenir un guide d'évaluation facilitant la revue technique des principales fonctionnalités et possibilités de Site Recovery Manager 5.0, consultez les Ressources pour la continuité d'activité VMware vCenter Site Recovery Manager.

Mise à niveau depuis une version précédente :

SRM 5.0 peut être mis à niveau en place depuis SRM 4.1 et 4.1.1 uniquement. Pour les chemins de mise à niveau pris en charge des versions de mise à jour SRM 5.0, consultez les notes de mise à jour de ces versions de mise à jour. Les mises à niveau en place sont conseillées au lieu d'une installation complète car cela permettra de conserver tous les rapports d'historique, les plans de reprise d'activité, les groupes de protection et les personnalisations des plans de reprise d'activité.

SRM 5.0 peut s'exécuter avec les versions précédentes de vSphere (4.0, 4.1) et Virtual Infrastructure (3.5) uniquement si la réplication basée sur la baie est utilisée. Si vSphere Replication doit être utilisé (soit tout seul, soit conjointement à la réplication basée sur la baie), alors les hôtes vSphere doivent être mis à niveau vers la version 5.0 dans le cadre du processus de mise à niveau.

Les étapes de mise à niveau à haut niveau pour SRM 5.0 consistent à :

  1. Désinstaller le plug-in SRM depuis vSphere Client.
  2. Interrompre, et mettre à niveau le service vCenter Server du site protégé vers la version 5.0.
  3. Si l'intention est d'utiliser vSphere Replication, vous devez mettre à niveau les hôtes vSphere vers ESXi 5.0 à ce stade.
  4. Interrompre, et mettre à niveau le service SRM du site protégé vers la version 5.0.
  5. Mettre à niveau ou installer l'adaptateur de réplication de stockage compatible avec SRM 5.0. Cet adaptateur de réplication de stockage doit être certifié pour être utilisé avec SRM 5.0 par VMware.
  6. Reprenez ce processus pour le site de récupération après avoir vérifié si la fonctionnalité de base de vSphere et vCenter Server fonctionne correctement. SRM ne fonctionnera pas jusqu'à ce que les deux sites aient été mis à niveau complètement.
  7. Téléchargez le plug-in SRM et installez-le sur vSphere Client.
  8. Lancez le SRM et vérifiez si le SRA est actualisé correctement.
  9. Couplez les sites, les gestionnaires de baies et les périphériques. Activez les paires de baie.
  10. Exécutez l'utilitaire de la ligne de commande srm-migration pour importer les précédents plans de reprise d'activité, les groupes de protection, les rapports d'historique, les scripts, et la personnalisation IP.

Pour la documentation complète sur le processus de mise à niveau, consultez les pp. 33-37 du Guide d'administration du Site Recovery Manager.

SRM SDK

SRM 5.0 inclut 33 nouvelles opérations API, dont de nombreuses sont propres au site et permettent l'automatisation des processus propres à chaque site. Les nouvelles opérations API dans SRM 5.0 incluent :

  • ListProtectionGroups
  • ListInventoryMappings
  • GetInfo
  • GetPeer
  • ListProtectedVms
  • ListProtectedDatastores
  • ListAssociatedVms
  • GetProtectionState
  • ProtectionGroupListRecoveryPlans
  • ProtectionGroupQueryVmProtection
  • ProtectVms
  • UnprotectVms
  • AssociateVms
  • UnassociateVms
  • GetTasks
  • IsComplete
  • GetProtectionStatus
  • ListPlans
  • GetHistory
  • RecoveryPlanGetInfo
  • RecoveryPlanGetPeer
  • Démarrer
  • Annuler
  • ListPrompts
  • AnswerPrompt
  • GetResultCount
  • GetRecoveryResult
  • GetResultLength
  • RetrieveStatus
  • RetrieveContent
  • SrmLoginLocale
  • SrmLoginSites
  • SrmLogoutLocale

Notez que VMware publiera un guide complet mis à jour d'utilisation de l'API SOAP SRM qui se trouve sur API de VMware vCenter Site Recovery Manager.

Composants Open Source

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

Mises en garde et limites

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

  • Interopérabilité avec vCloud Director
    Site Recovery Manager 5.0 fournit un support limité pour les 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.

  • Reprotection et retour arrière automatisé non pris en charge avec vSphere Replication
    La reprotection et le retour arrière automatisé sont pris en charge uniquement avec les machines virtuelles répliquées basées sur la baie. 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.

  • Le nombre de conversions SRM depuis la licence par CPU vers la licence par VM est incorrect
    Certains clients qui ont acheté SRM 1.x et SRM 4.0 peuvent toujours utiliser des licences allouées par CPU. Il existe un problème connu dans le processus de conversion depuis ces plus anciennes licences par CPU vers les licences SRM 5.0 par VM, en ce sens que 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 incorrectement un trop grand nombre de licences par VM pour SRM 5.0. C'est un comportement incorrect qui sera réparé avec un patch pour SRM. Veuillez noter soigneusement le nombre de conversions de licence pour vous assurer de la conformité aux termes et aux conditions du contrat de licence et vérifier que le nombre de VM protégées qui ont fait l'objet d'une licence n'est pas dépassé.

  • Limites d'évolutivité de la réplication basée sur la baie et de vSphere Replication (VR)

    Les limites d'évolutivité indiquées dans le Guide de l'Administrateur du Site Recovery Manager sont incorrectes, mais seront bientôt mises à jour. Les limites d'évolutivité correctes sont les suivantes :

    Limites d'évolutivité de la réplication basée sur la baie (ABR)

    VM protégées par groupe de protection 500
    VM protégées 1 000
    Groupes de protection par plan de reprise d'activité 150
    Groupes de banques de données 150
    Récupérations simultanées 10

    Limites d'évolutivité de vSphere Replication (VR)

    VM protégées par groupe de protection unique 500
    VM protégées 500
    Groupes de protection par plan de reprise d'activité unique 250
    Groupes de banques de données 250
    Récupérations simultanées 10

Problèmes connus

Les problèmes connus suivants ont été rencontrés lors de tests rigoureux. Nous espérons qu'ils vous aideront à comprendre certains désagréments que vous pourriez rencontrer dans cette version.

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

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

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

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

    Lors d'un basculement 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'un basculement réel, ce dernier aboutit mais avec une erreur. Pour résoudre ce problème, réessayez le basculement.

  • Création inattendue de dossiers suite à la réplication de machines virtuelles dans des sous-dossiers

    Lors de la configuration de vSphere Replication (VR) pour une machine virtuelle, il est possible de configurer la machine virtuelle de sorte qu'elle soit répliquée dans un quelconque répertoire d'une banque de données sur le site de récupération. Si le répertoire sélectionné se trouve dans le répertoire racine, la réplication s'exécute comme prévu. Si le répertoire sélectionné se trouve sous le niveau racine, la machine virtuelle n'est pas répliquée dans le répertoire spécifié. À la place, un nouveau répertoire est créé avec un nom composé des différents noms de dossiers et sous-dossiers. Par exemple, /path1/path2/path3devient /path1path2path3. La machine virtuelle est répliquée, mais pas à l'emplacement prévu. Pour éviter ce problème, répliquez les machines virtuelles dans des dossiers au niveau racine.

  • L'interruption du service SRM pendant le mappage des ressources entraîne l'échec de vSphere Client

    Si le service SRM est interrompu lorsqu'un utilisateur configure des mappages de ressources à l'aide de vSphere Client, le client doit afficher un message d'erreur de connexion. Au lieu de cela, le client cesse de répondre. Pour résoudre ce problème, interrompez le processus vSphere Client à l'aide du Gestionnaire des tâches de Windows. Pour éviter ce problème, assurez-vous que le service SRM est en cours d'exécution lors de la configuration des mappages de ressources.

  • Les utilisateurs ayant des privilèges suffisants peuvent être à l'origine d'une réplication de conditions trompeuses

    Vous pouvez configurer la réplication de machines virtuelles au moyen de l'assistant vSphere Replication Wizard. L'utilisation de cet assistant est réservée aux utilisateurs disposant des autorisations appropriées. Si un utilisateur dont les autorisations sont insuffisantes tente de reconfigurer la réplication avec l'assistant vSphere Replication Wizard, une erreur s'affiche à la fin de l'assistant pour indiquer que l'opération n'est pas autorisée. L'erreur suivante s'affiche :

    Impossible de déterminer le type de contrôleur du disque 'Nom VMDK [Nom du disque].' L'autorisation d'effectuer cette opération a été refusée.

    La réplication de la machine virtuelle se poursuit comme prévu, malgré le signalement de problèmes par vSphere Client. Pour résoudre ce problème, un utilisateur disposant d'autorisations suffisantes peut réexécuter l'opération pour analyser les messages dans le client.

  • Le couplage ou le découplage des serveurs VRMS (vSphere Replication Management Servers) échoue avec LockingFailedException

    Dans de rares cas, lors du couplage ou du découplage entre les serveurs VRMS, si le service vSphere est en cours d'arrêt en même temps, l'opération échoue avec l'exception suivante :

    LockingFailedException: Échec du objet de verrouillage de l'écriture : com.vmware.hms.db.entities.HmsLocalServerEntity: VRM Server GUID

    Pour résoudre ce problème, redémarrez les serveurs VRMS.

  • Une perte temporaire des connexions de vCenter Server peut ê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 un basculement, une des situations suivantes peut se produire :

    • vCenter Server demeure indisponible et le basculement é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 risquent de ne pas être correctement mappés. Suite au mauvais mappage des RDM, il se peut 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 peuvent survenir.
      • S'il s'agit d'un basculement test, procédez à une opération de nettoyage et relancez le test.
      • S'il s'agit d'un basculement réel, vous devez manuellement joindre le bon RDM à la machine virtuelle récupérée.

    Consultez la rubrique relative à la modification des paramètres VM 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

    À 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 le basculement 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 peut éventuellement durer assez longtemps, mais finira par se terminer. Au terme ou à l'expiration de la synchronisation, l'annulation du plan de reprise d'activité continue.

  • Les certificats valides génèrent des avertissements.

    Lors du téléchargement et de l'installation de certificats sur le serveur vSphere Replication Management (VRMS), l'erreur suivante se produit :

    Le certificat est installé avec des avertissements. Il se peut que les systèmes VRM distants dont l'option 'Accepter uniquement un certificat SSL signé par une autorité de certification approuvée' est activée ne soient pas capables de se connecter à ce site pour la raison suivante : Le certificat n'a pas été délivré pour une utilisation avec le nom d'hôte auquel il est associé : Nom d'hôte VRM

    Cette erreur peut être ignorée, ou vous pouvez éviter cette erreur en utilisant un navigateur pris en charge autre que Internet Explorer.

  • Les certificats valides génèrent des avertissements.

    Le couplage des serveurs VRMS (vSphere Replication Management Servers) échoue en raison de problèmes de certificats lorsque les deux conditions suivantes sont remplies :

    • Le certificat du serveur a une valeur de nom d'hôte qui ne correspond pas à l'adresse VRMS.
      Les valeurs de nom d'hôte pourraient inclure le nom du sujet ou d'autres noms de sujet. L'adresse VRMS est spécifiée dans l'interface VAMI (Virtual Appliance Management Infrastructure) durant la configuration de l'application.
    • Le serveur VRMS homologue possède une chaîne de confiance valide auprès d'une autorité de certification (CA) pour le certificat.
      C'est le cas si le certificat a été délivré par une autorité de certification approuvée telle que Verisign ou Go Daddy ou par une autorité de certification inconnue dont le certificat a été ajouté au fichier hms-truststore.jksdu serveur VRMS homologue, ce qui établit ainsi la confiance.

    Pour résoudre ce problème, utilisez l'une des techniques suivantes :

    • Utilisez la fonctionnalité Générer et Installer de l'interface VAMI pour créer et utiliser un nouveau certificat.
    • Utilisez l'interface VAMI pour transférer un certificat ayant des valeurs du nom d'hôte correspondant à celles du serveur VRMS.
    • Supprimez le certificat de l'autorité de certification auto-signée du fichier hms-truststore.jksdu serveur VRMS homologue.

  • Option par plan pour ignorer les signaux de pulsation de VMware Tools non disponibles

    Les plans de récupération attendent généralement que les machines virtuelles émettent des signaux de pulsation VMware Tools. Dans les anciennes versions de SRM, il était possible de désactiver cette vérification par plan de récupération. L'activation ou la désactivation de cette option au niveau du plan de récupération n'est plus disponible. Il est désormais possible de désactiver l'attente des signaux de pulsation de VMware Tools pour tout le système en utilisant les paramètres avancés ou pour les machines virtuelles individuelles.

  • L'installation de plusieurs plug-ins vSphere Client SRM crée des problèmes

    Une seule version du plug-in vSphere Client SRM ne peut être installée à tout moment. Les utilisateurs peuvent installer le plug-in client version 4.0.x ou 4.1.0 sur le plug-in pour SRM 5.0. Avant d'installer de nouvelles versions du plug-in client, désinstallez les plug-ins SRM existants. Si plusieurs plug-ins vSphere Client ont été installés, désinstallez tous les plug-ins clients, téléchargez le plug-in du serveur à gérer et réinstallez-le.

  • Les groupes de protection signalent des erreurs suite à la non-synchronisation des machines virtuelles

    Quand une machine virtuelle est protégée par vSphere Replication, cette machine virtuelle est répliquée sur le site de récupération. Les opérations de réplication ont des valeurs d'expiration qui annulent les opérations qui semblent ne pas progresser. Si une machine virtuelle n'est pas répliquée, le groupe de protection auquel elle appartient entre dans un état d'erreur. Dans certains cas, la réplication des machines virtuelles ne peut se faire avant la temporisation, et ce malgré l'exécution normale du processus. Par exemple, quand vous créez une machine virtuelle volumineuse ou que vous apportez de nombreux changements à une machine virtuelle, la réplication nécessaire peut dépasser le temps disponible. Pour résoudre ce problème :

    • Augmentez l'objectif du point de récupération jusqu'au terme de la réplication.
    • Augmentez le délai de temporisation dans le fichier de configuration SRM.

    Par exemple, pour changer le délai de temporisation de la réplication à deux heures ou 7 200 secondes, modifiez le fichier de configuration comme suit :

    <config>
    ...
    <hbrProvider>
    <synchronizationTimeout>7200</synchronizationTimeout>
    </hbrProvider>
    ...
    </config>
  • Le service SRM s'arrête après avoir attendu la réponse de la base de données

    Le SRM attend les réponses aux interrogations de la base de données. Si la bande passante du réseau est insuffisante ou si la base de données est surchargée, il se peut qu'une réponse ne soit pas renvoyée avant l'expiration. Dans ces cas, une des erreurs suivantes est entrée dans le journal du SRM :

    • Panic: A expiré lors de l'attente de 'DrReplicationProviderInterface' (300 secondes)
    • Panic: A expiré lors de l'attente de 'DrReplicationRecoveryInterface' (300 secondes)
    • Panic: A expiré lors de l'attente de 'DrStorageManager' (300 secondes)

    Pour éviter ce problème, vous pouvez augmenter le temps d'attente de SRM des réponses aux interrogations. Par exemple, pour faire passer le temps d'expiration à quinze minutes ou 900 secondes, le fichier de configuration vmware-dr.xml est modifié de la façon suivante :

    <config>
    ...
    <waitForObjectTimeout>900</waitForObjectTimeout>
    ...
    </config>
  • La licence de SRM en mode d'évaluation affiche des informations erronées

    La gestion des licences peut s'effectuer en utilisant l'assistant de gestion des licences de vSphere. Quand vous utilisez cet assistant dans une installation SRM fonctionnant en mode d'évaluation, les informations concernant le nombre de licences peuvent être incorrectes. En mode d'évaluation, vSphere Client peut indiquer que le nombre de licences disponibles est illimité. vCenter Server effectue le suivi du nombre de licences disponibles et utilisées, et limite l'octroi de licences en conséquence.

  • vSphere Client affiche un état de récupération de machine virtuelle périmé

    Alors qu'un plan de reprise d'activité s'exécute, les modifications du statut de récupération de la machine virtuelle ne sont pas reflétées automatiquement dans le vSphere Client. Pour résoudre ce problème, cliquez sur Actualiser.

  • Les utilisateurs ne sont pas informés des opérations rejetées

    Si un utilisateur essaie de supprimer une machine virtuelle d'un groupe de protection, mais n'a pas suffisamment de privilèges, l'opération échoue, mais l'utilisateur n'est pas informé de cet échec. Le système fonctionne comme prévu, si ce n'est qu'en l'absence d'un message d'erreur, certains utilisateurs peuvent penser que la tâche a été accomplie.

  • La reprotection peut permettre aux utilisateurs d'accomplir des tâches non autorisées

    Lorsque les utilisateurs exécutent une opération de reprotection, il se peut que les tâches excédant ce que les privilèges accordés leur permettent de faire soient achevées. En dépit de leur manque de permissions, les utilisateurs des tâches pourraient les terminer, y compris la création de machines virtuelles sur le site de destination de la reprotection ou la protection de nouveaux périphériques sur le site de reprotection source. Cela peut se produire si une reprotection est lancée après que d'autres utilisateurs ont supprimé des machines virtuelles sur l'ancien site de production ou modifié ces machines virtuelles vers lesquelles elles étaient basculées.

  • Changement inattendu des interfaces utilisateur pendant les migrations planifiées

    Durant les migrations planifiées, les machines virtuelles sont désactivées et synchronisées avec le site de récupération. Lors de ce processus, les groupes de protection et leurs machines virtuelles affichent temporairement l'état Partiellement récupéré. Dans vSphere Client, des boutons sont activés, notamment Modifier le groupe de protection et Supprimer un groupe de protection, en fonction de ce qui convient aux états ; les opérations déclenchées par ces boutons n'aboutissent toutefois pas. Ces états changeants et la disponibilité des boutons peuvent dérouter les utilisateurs. Ces changements sont normaux et attendus durant toute migration planifiée, et ils peuvent être ignorés.

  • Il se peut que les historiques des récupérations soient perdus après une mise à niveau vers SRM 5.0.

    Durant la mise à niveau d'une migration vers un serveur, l'installateur propose le nom du site par défaut, au lieu du nom du site actuellement utilisé. Si vous ne remplacez pas le nom du site par défaut par le nom du site actuel, il se peut que les historiques des récupérations soient perdus. Pour éviter ce problème, changez le nom du site par le nom utilisé dans le déploiement. Si vous effectuez une mise à niveau par le nom du site par défaut et que l'historique des récupérations est perdu, vous pouvez restaurer la base de données 4.1 depuis la sauvegarde puis effectuer de nouveau la mise à niveau, cette fois-ci en fournissant la bonne valeur pour le nom du site.

  • Le serveur VRM ne prend pas en charge les fichiers PKCS#12 qui ne sont pas protégés par mot de passe

    Les fichiers PKCS#12 sont généralement protégés par un mot de passe. Le serveur VRM ne prend pas en charge les certificats qui ne sont pas protégés par mot de passe. Il est possible de rechercher et de sélectionner un fichier qui n'est pas protégé par mot de passe, mais les certificats ne sont pas installés. Pour éviter ce problème, utilisez des fichiers PKCS#12 protégés par mot de passe.

  • Les informations de licence ne fournissent aucun détail concernant les noms de site par défaut

    Les informations de licence SRM sont désignées dans vCenter par le nom du site SRM. Si le nom de site par défaut est utilisé et que plusieurs serveurs SRM sont enregistrés dans le même groupe vCenter, la dénomination du serveur SRM par défaut rend les informations de licence impossibles à distinguer. Pour éviter ce problème, précisez des noms de site uniques lors de l'installation.

  • Pages de mise en route impossibles à découvrir

    Les pages de mise en route comportent des liens et des informations qui vous aideront à configurer SRM et VR. Si vous avez précédemment fermé tous les onglets de mise en route, vous pourrez les restaurer en sélectionnant l'option dans la boîte de dialogue des paramètres du client, sous le menu Édition.

  • L'installation du serveur SRM sur les machines avec des caractères non-ASCII provoque des problèmes d'accès.

    Si un serveur SRM est installé sur une machine portant un nom qui inclut des caractères non-ASCII, des problèmes d'accès utilisateur peuvent se produire. Étant donné que le nom de la machine est utilisé pour construire des URL, il se peut que ces URL qui contiennent des caractères non-ASCII ne soient pas valides. Pour éviter ce problème, installez le SRM sur les machines portant des noms composés entièrement de caractères ASCII.

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

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

  • Les suffixes DNS non-ASCII ne sont pas définis correctement après la personnalisation de Windows XP et de Windows 2003

    Si vous entrez un suffixe DNS non-ASCII dans l'onglet DNS de la section Paramètres IP de la boîte de dialogue Propriétés de récupération VM pour personnaliser Windows XP ou Windows 2003, la personnalisation est signalée comme étant réussie mais le suffixe DNS non-ASCII n'est pas défini correctement. Pour éviter ce problème, définissez le suffixe DNS manuellement dans Windows XP et Windows 2003.

  • Les étapes de récupération personnalisées avec génération de caractères non-ASCII provoquent la panne des serveurs SRM

    Ne créez pas d'étapes de récupération personnalisées qui génèrent des caractères non-ASCII. Si vous ajoutez des étapes à un plan puis effectuez un test ou une récupération, le serveur SRM se bloque. Si un plan dont une étape génère des caractères non-ASCII est utilisé, le plan passe à un état où il ne peut pas être modifié ou supprimé. Créez un nouveau plan qui ne génère pas de caractères non-ASCII, utilisez ce plan de reprise d'activité pour les groupes de protection, et n'oubliez pas d'utiliser le plan non-ASCII dans les tests ou les récupérations à venir. Redémarrez les serveurs qui se sont bloqués en raison de la génération de caractères non-ASCII.

  • Échec de mise hors tension des machines virtuelles pendant le nettoyage test

    Pendant un nettoyage test, les machines virtuelles sont mises hors tension, et cette opération peut être exigeante en termes de stockage. En de rares cas, la mise hors tension peut prendre 30 minutes ou plus, dépassant les 15 minutes d'attente prévues par SRM pour la mise hors tension de ces machines virtuelles. Si le délai d'expiration de 15 minutes est dépassé, le message Erreur - Le délai de l'opération a expiré : 900 secondess'affiche. Pour résoudre ce problème, attendez que la mise hors tension soit terminée puis relancez le nettoyage. Vous pouvez également mettre hors tension manuellement les machines virtuelles test.

  • Exécution de vSphere Clients lorsqu'il est impossible de gérer les serveurs de réplication de vSphere après l'installation

    Le serveur VR (vSphere Replication) est géré en utilisant vSphere Client. vSphere Clients permet la gestion des serveurs VR pour les serveurs VR installés lorsque le plug-in SRM est activé. Lorsqu'un vSphere Client disposant du plug-in SRM démarre, il trouve tous les serveurs VR disponibles, et les présente comme des choix possibles à gérer. Si des serveurs VR sont configurés après le démarrage d'un vSphere Client, ces serveurs qui viennent d'être configurés ne sont pas automatiquement identifiés. Pour vérifier si tous les serveurs VR sont présentés comme des choix d'administration de VR, après l'installation ou la configuration d'un serveur VR :

    • Activez le plug-in SRM.
    • Redémarrez le client.

    L'un ou l'autre choix amène le client à actualiser la liste de serveurs VR disponibles.

  • L'interface de configuration du plan de reprise d'activité affiche les options de réseau invalides.

    Lors de la configuration d'un plan de reprise d'activité, les réseaux doivent être sélectionnés pour être associés aux machines virtuelles. L'interface utilisateur du plan de reprise d'activité affiche les groupes de ports de liaison montante DVS comme des sélections possibles, même si celles-ci ne sont pas des options valides. Ne sélectionnez pas les groupes de ports de liaison montante DVS.

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

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

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

  • L'état de la machine virtuelle ne se met pas à jour après la déconnexion des serveurs VRMS (vSphere Replication Management Servers)

    Les serveurs VRMS (vSphere Replication Management Servers) échangent des informations entre les sites sur la réplication de la machine virtuelle. En cas d'interruption de la connexion VRMS par l'option Interrompre la connexion VRMS, l'échange des informations sur les machines virtuelles répliquées n'est pas rétabli automatiquement lorsque vous reconfigurez la connexion VRMS. Il peut en résulter des informations incomplètes sur la réplication des machines virtuelles, y compris les machines virtuelles disponibles à ajouter des groupes de protection. Pour résoudre ce problème, redémarrez le service SRM.

  • Il se peut que les informations affichées dans vSphere Client soient périmées.

    Durant la modification des données SRM, telles que le contenu des plans de reprise d'activité, il se peut que les informations affichées ne se mettent pas à jour étant donné que les informations SRM sont modifiées. Par exemple, après avoir ajouté une machine virtuelle non-critique à interrompre pour un plan de reprise d'activité, les informations sur cette modification ne s'affichent pas automatiquement. Pour résoudre ces types de problèmes, cliquez sur Actualiser, si disponible, ou éloignez-vous de la page affichant les informations périmées puis revenez-y. Cela provoque l'actualisation du contenu de l'écran, qui fournit alors les toutes dernières informations.

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

  • Les certificats non valides sont rejetés durant l'authentification

    SRM supporte l'authentification basée sur le certificat. Si un serveur SRM possède un certificat non valide, lorsque vSphere Client utilise le plug-in SRM pour se connecter au serveur SRM, des erreurs se produisent. Des certificats non valides peuvent se produire si un certificat dans la chaîne de certificats a expiré ou n'est pas encore valide. Dans un tel cas, le message suivant apparaît : La connexion SSL à l'hôte distant s'est terminée. Le certificat de l'hôte distant rencontre les problèmes suivants : Un certificat dans la chaîne de l'hôte n'est pas valide dans le temps.Pour résoudre ce problème, installez un certificat valide sur le serveur SRM.

  • La suppression rapide et la recréation d'espaces réservés créent des problèmes

    Si vous supprimez les machines virtuelles à espace réservé d'une banque de données, démontez la banque de données, puis remontez la banque de données, il se peut que vous deviez attendre 10 minutes avant de recréer des machines virtuelles à espace réservé. La recréation des espaces réservés en l'espace de 10 minutes du démontage de la banque de données risque de provoquer l'échec de l'opération et la survenue du défaut NoCompatibleHostFound. Pour éviter ou résoudre ce problème, attendez plus de 10 minutes avant de tenter de recréer les machines virtuelles à espace réservé.

  • L'installation échoue en raison de restrictions imposées par la politique.

    Il se peut que l'installation du serveur SRM échoue avec l'erreur. L'administrateur du système a défini des politiques pour empêcher cette installation. C'est généralement le résultat de l'application de nouveaux paramètres durant la mise à niveau du système d'exploitation ou de l'application d'un patch. Solutionnez ce problème en utilisant la solution appropriée à la situation :

    • Si les mises à jour de Windows ont entraîné une hausse des restrictions qui empêchent l'installation, exécutez l'installation avec un compte ayant des permissions suffisantes. Les permissions requises peuvent être obtenues en se connectant à un compte ayant des permissions suffisantes, et en réalisant l'installation en utilisant ce compte ou en accordant des permissions à un autre compte, qui est alors utilisé pour réaliser l'installation.
    • Si des erreurs sont dues au fichier rejeté en raison de la politique de la signature numérique, installez le correctif logiciel 925336.
  • Les tentatives d'utilisation des certificats générés par l'utilisateur durant l'opération Modifier échouent

    Les tentatives d'opération Modifier d'une installation échouent lors de l'utilisation d'un certificat portant sur un SAN (subject alternative name) autre que l'adresse de la machine SRM utilisée durant l'installation initiale. L'adresse de la machine SRM utilisée dans le SAN du certificat doit correspondre à la valeur exacte entrée dans l'installation SRM. La valeur pourrait être un nom de machine, un FQDN, ou une adresse IP.

    Si ce problème se produit, générez un certificat avec un SAN qui correspond à la valeur utilisée durant l'installation initiale, puis utilisez ce certificat durant l'opération Modifier de l'installation. Si un certificat ne peut pas être généré avec une valeur correspondante, vous devez réinstaller le serveur, ce qui préserve le contenu de la base de données.

  • La récupération des machines virtuelles mises hors tension risque d'échouer

    Avant de pouvoir récupérer une machine virtuelle, le SRM doit répliquer cette machine virtuelle depuis le site protégé vers le site de reprise. Dans certains cas, les machines virtuelles protégées par vSphere Replication (VR) ne sont pas répliquées, et par conséquent, la récupération de test n'est pas possible. Ces cas sont les suivants :

    • Lorsque la réplication est d'abord effectuée, une pause a lieu avant l'achèvement de la réplication. Si un sinistre se produit avant que la machine virtuelle soit répliquée, il n'est pas possible de récupérer la machine virtuelle. Il n'existe aucun moyen d'éviter ce problème.
    • Durant une récupération de test, seules les machines virtuelles alimentées sont synchronisées lorsque l'option Répliquer les modifications récentes apportées au site de reprise est cochée. Cela signifie que les machines virtuelles qui n'ont pas été alimentées depuis que la protection VR a été établie ou celles qui n'ont pas terminé leur synchronisation initiale ne peuvent pas être récupérées au moyen d'une récupération de test. Pour éviter ce problème, vérifiez si la synchronisation initiale est terminée avant d'exécuter une récupération de test.
    • Pour une machine virtuelle hors tension qui n'a pas terminé sa synchronisation initiale, si la migration planifiée est exécutée sans que l'option Répliquer les modifications récentes apportées au site de reprise ne soit cochée, cette migration planifiée échoue parce qu'il n'existe aucune donnée de machine virtuelle sur le site de reprise. Pour éviter ce problème, activez toujours l'option Répliquer les modifications récentes apportées au site de reprise pour de telles machines virtuelles durant la migration planifiée.
  • La récupération d'une machine virtuelle échoue en raison d'une erreur de configuration sur le disque

    Il est possible de placer différents disques et fichiers de configuration pour une seule machine virtuelle protégée sur de nombreuses banques de données. Durant la récupération, SRM Server doit avoir accès au mappage du disque de données brutes et aux fichiers du disque parent. Sans cet accès, SRM Server ne peut pas déterminer les types de disque durant une récupération. Dans un tel cas, le serveur SRM peut supposer qu'un disque RDM (mappage du disque de données brutes) n'est pas un disque RDM, ce qui entraîne 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.

  • Les certificats fournis par l'utilisateur pour le serveur VRMS doivent inclure un SAN (Subject Alternative Name) qui est le FQDN du serveur VRMS.

    Lors de l'utilisation d'un certificat fourni par l'utilisateur, le SAN (Subject Alternative Name) doit être le nom de domaine complètement qualifié (FQDN) du serveur VRMS (vSphere Replication Management Server). Si une autorité de certification OpenSSL est utilisée, modifiez le fichier de configuration OpenSSL de façon à inclure ces informations. Un exemple de ces informations de configuration requises est le suivant :

    subjectAltName = DNS:VRMS.example.com

  • Le serveur SRM ne réussit pas à démarrer après la reconfiguration du réseau

    La modification du nom du serveur SRM ou de l'adresse IP n'est pas prise en charge. Le nom de la machine du serveur SRM et de l'adresse IP est enregistré durant l'installation initiale, et cette valeur ne peut pas être modifiée dans le système SRM. Pour résoudre ce problème, désinstallez le serveur SRM, en veillant à ce que le contenu de la base de données du serveur SRM soit conservé, puis réinstallez le serveur SRM en utilisant le nom et l'adresse actuels de la machine, et la base de données enregistrée.

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

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

  • Il se peut que les opérations échouent lorsque de nombreux vSphere Clients se connectent au SRM

    Le serveur SRM utilise un grand pool de connexions de taille fixe pour communiquer avec les serveurs vCenter Servers et avec le serveur SRM sur l'autre site pour réaliser des tâches. Le nombre de connexions disponibles baisse au fur et à mesure que le nombre de vSphere Clients connectés augmente. Dans de nombreux cas, cela ne nuira pas à la performance du système, mais dans le cas de nombreuses opérations simultanées, telles que la protection ou la déprotection d'un grand nombre de machines virtuelles, ou l'exécution ou l'essai d'un grand plan de reprise d'activité, des problèmes risquent de se produire. Les opérations peuvent expirer ou échouer avec diverses explications. Si ce problème se produit, il peut être résolu en fermant les connexions client extérieures avec le serveur SRM. Notez que les connexions qui sont abandonnées mais pas fermées proprement peuvent demander jusqu'à 30 minutes pour expirer. Pour terminer plus rapidement les connexions abandonnées, redémarrez le serveur SRM.

  • Une icône incorrecte peut être utilisée pour les machines virtuelles à espace réservé

    Dans certaines circonstances, vSphere Client ne réussit pas à télécharger l'icône de machine virtuelle à espace réservé. Le cas échéant, une icône de machine virtuelle de solution générique s'affiche à la place. Le redémarrage du vSphere Client peut résoudre ce problème.

  • 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 Désactiver ou durant RemoteOnlineSync ou RemotePostReprotectCleanup, les deux opérations se produisant durant la reprotection, il se peut alors que le plan de reprise d'activité 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 un basculement, il suffit d'annuler et de redémarrer le plan de reprise d'activité.

  • Les tentatives de reprotection des plans de reprise d'activité en mode mixte entraînent un état incomplet de reprotection

    Les groupes de protection peuvent être basés sur SAN ou sur VR (vSphere Replication), et les plans de reprise d'activité peuvent être composés de deux types de groupes de protection. La reprotection ne peut pas être exécutée sur un plan qui inclut un mélange de deux groupes de protection basés sur SAN et sur VR. La fonctionnalité de reprotection ne vérifie pas si les groupes de protection ne sont pas basés exclusivement sur SAN ou sur VR. S'il y a une tentative de reprotection des groupes de protection qui sont composés d'un mélange de types de groupes de protection, le processus échoue, laissant le plan de reprise d'activité dans un état incomplet de reprotection. Pour éviter ce problème, ne créez pas de plans de reprise d'activité qui mélangent les types de protection. Pour éviter ce problème, supprimez le groupe de protection basé sur VR avant d'assurer la reprotection.

  • Erreur générique du serveur VRM

    Le message d'erreur suivant peut apparaître : 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 : hostname. Cette erreur se produit lorsque le serveur VRMS (vSphere Replication Management Server) ne peut pas résoudre l'adresse IP de l'hôte indiquée dans le message d'erreur. Pour résoudre ce problème, voyez s'il existe des problèmes de configuration DNS qui peuvent être résolus. Vous pouvez également vérifier si des noms de domaine non-entièrement qualifiés (non-FQDN) sont utilisés lorsque des noms FQDN sont requis.

  • L'alarme activée par l'utilisateur ne génère aucun résultat

    Les utilisateurs peuvent activer les Paramètres de protection reconfigurés pour l'alarme VM, mais cette alarme n'est jamais déclenchée. Cela se produit parce que les utilisateurs ne peuvent pas modifier les paramètres de protection dans cette version. Pour suivre les modifications des paramètres de machine virtuelle, lancées par l'utilisateur dans le serveur SRM, les administrateurs doivent activer les Paramètres redéfinis de l'emplacement de reprise pour l'alarme VM.

  • Les tentatives de l'utilisateur pour configurer vSphere Replication échouent

    Il se peut que les utilisateurs ayant des privilèges administratifs ne puissent pas configurer vSphere Replication. Cela est souvent dû au fait que le privilège Mappeur de banque de données VRM > Affichagen'est pas accordé. Pour résoudre ce problème, accordez ce privilège aux comptes utilisateur appropriés au site protégé.

  • Le serveur VRMS (vSphere Replication Management Server) ne réussit pas supporter les hôtes ESX valides

    Durant la configuration de VR (vSphere Replication), lorsqu'une banque de données est sélectionnée sur une version prise en charge de ESX, le message Nom de serveur VR Server n'a aucun hôte permettant d'accéder à la banque de données de destination...apparaît. Cela se produit en raison d'un hôte valide marqué comme NON SUPPORTÉ, même si l'hôte est une sélection valide. Durant l'enregistrement du serveur VR, l'événement L'hôte est configuré pour vSphere Replicationn'est pas déclenché sur l'hôte. Le marquage d'hôtes comme non pris en charge se produit en raison d'une erreur dans ou une interruption de communication entre les serveurs VRM et les serveurs VR durant l'enregistrement d'un serveur VRM ou lors de la connexion d'un nouvel hôte à un inventaire de vCenter Server. Des problèmes de communication se produisent généralement en raison d'une perte de connectivité temporaire ou de l'arrêt des services du serveur.

    Pour résoudre ce problème et activer les hôtes à utiliser avec VR, vous devez exécuter les étapes suivantes :

    1. Parcourir la base de données VRM au site de reprise.
    2. Supprimez les enregistrements de la table HostEntity avec l'état 4 (NON PRIS EN CHARGE), qui ne sont pas référencés depuis la table HbrHostEntity (valeur vcMoId). S'il y a des références existantes depuis la table HbrHostEntity (la valeur vcMoId), ne supprimez pas l'enregistrement, mais mettez à jour la valeur d'état en la faisant passer de 4 à 1 (état ACTIF).
    3. Déconnectez l'hôte de l'inventaire vCenter puis reconnectez-le.
    4. Vérifiez si l'événement L'hôte est configuré pour vSphere Replicationest déclenché sur l'hôte.

    Un exemple du type de requêtes que vous pourriez utiliser pour rectifier ce problème dans la base de données du serveur VRM est le suivant :

    1. Interroger
      • Pour interroger tous les hôtes marqués NON SUPPORTÉS, qui ne sont pas associés à un serveur VR :
        sélectionnez * depuis HostEntity h où state=4 et n'existe pas (sélectionnez * depuis HbrHostEntity où h.vcMoId=HbrHostEntity.vcHost_vcMoId).
      • Pour interroger tous les hôtes marqués NON SUPPORTÉS, qui sont associés à un serveur VR : sélectionnez * depuis HostEntity h où state=4 et existe (sélectionnez * depuis HbrHostEntity où h.vcMoId=HbrHostEntity.vcHost_vcMoId).
    2. Résoudre
      • Pour nettoyer les enregistrements NON SUPPORTÉS pour les hôtes qui ne sont pas associés à un serveur VR :
        supprimez depuis HostEntity où state=4 et n'existe pas (sélectionnez * depuis HbrHostEntity où vcMoId=HbrHostEntity.vcHost_vcMoId).
      • Pour faire passer l'état à ACTIF des hôtes marqués NON SUPPORTÉS, qui sont associés à un serveur VR :
        mettre à jour HostEntity définir state=1 où state=4 et existe (sélectionnez * depuis HbrHostEntity où vcMoId=HbrHostEntity.vcHost_vcMoId).

  • L'arrêt et le redémarrage de la réplication pour les disques de machine virtuelle laissent les disques non répliqués

    Après avoir désactivé et activé rapidement la réplication pour les disques protégés par VR (vSphere Replication) sur une machine virtuelle, leur état de réplication peut être Pas Actif. Pour résoudre ce problème, déconfigurez et reconfigurez la réplication pour la machine virtuelle.

  • Perte du paramètre avancé personnalisé par l'utilisateur durant la mise à niveau

    Lors de la mise à niveau de SRM 4.1 à SRM 5.0, tous les paramètres avancés et personnalisés par l'utilisateur sont remplacés par les paramètres par défaut initiaux. Pour résoudre ce problème, appliquez de nouveau les paramètres personnalisés après la mise à niveau. Pour les mises à niveau en place, les informations de référence sur les paramètres avant la mise à niveau se trouvent dans C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\vmware-dr.xml.bak.

  • Le NFS identifié par des moyens variables n'assure pas une protection cohérente

    Les volumes NFS sont montés en tant que banque de données avec une adresse IP ou un nom d'hôte. vCenter utilise l'adresse IP ou le nom d'hôte pour suivre le mappage des montages NFS aux banques de données. Par conséquent, le même volume depuis le même hôte NFS peut être enregistré en tant que banque de données différente lorsqu'elle est montée avec une adresse IP différente ou un nom d'hôte différent.

    Les SRA (adaptateur de réplication de stockage) renvoient une liste d'adresses durant la découverte de périphériques. Le serveur SRM fait tout son possible pour faire correspondre les adresses que le SRA fournit avec les montages et les banques de données. Les SRA renvoient un groupe de paramètres au SRM. Le serveur SRM présente ces valeurs comme des éléments de la configuration de la baie, mais ne contrôle ces paramètres en aucune manière. L'adresse et le port de stockage constituent l'une de ces valeurs, et cette valeur est utilisée lors de la configuration et de la détection des points de montage. Si un SRA ne présente qu'une valeur de port de stockage, le serveur SRM utilise cette valeur de port exclusivement pour la recherche de correspondances, mais d'autres valeurs valides peuvent également exister.

    Dans un tel cas où l'identificateur utilisé par un gestionnaire de baie n'est pas le même que l'identificateur utilisé par le serveur SRM, les banques de données ne sont pas protégées comme prévu. Les machines virtuelles sur ces partages ne sont pas protégées et ne sont pas arrêtées durant le basculement.

    Pour éviter ce problème, utilisez toujours la même adresse IP ou le nom d'hôte pour le montage des banques de données NFS et pour le filtrage du port de stockage par le gestionnaire de baies.

  • Les champs d'information du réseau ne sont pas remplis avec des informations valides lorsque IPv6 est requis

    Si le serveur VRMS (vSphere Replication Management Server) est configuré pour utiliser exclusivement IPv6, les problèmes suivants se produisent :

    • Dans la page de démarrage de l'interface VAMI (Virtual Appliance Management Infrastructure), le champ d'adresse du serveur vCenter Server est pré-rempli avec une adresse littérale IPv4. Cette adresse ne peut pas être utilisée dans les périphériques utilisant uniquement IPv6. Pour résoudre ce problème, modifiez ce champ et saisissez un nom DNS valide ou une adresse littérale IPv6.
    • Le champ Nom du site ne doit pas être pré-rempli. Ce champ est généralement pré-rempli avec le nom de la machine virtuelle du périphérique dans l'inventaire du vCenter Server. Pour résoudre ce problème, entrez un nom de site valide. Un nom de site valide est différent du nom du site homologue.

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

  • Synchroniser un stockage durant une récupération génère des erreurs

    Dans de rares cas, si la synchronisation est activée, durant l'étape Synchroniser le stockage, l'erreur suivante peut se produire : Échec de synchronisation VR pour le groupe VRM groupname. 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 : 'Défaillance du verrouillage optimiste'. Il est plus probable que cela se produise lorsqu'il y a un volume important de données à transmettre durant l'exécution d'un plan de reprise d'activité, comme dans le cas d'une combinaison d'un plus grand nombre de machines virtuelles et d'un plus grand volume de données à synchroniser. En dépit de l'erreur, la synchronisation réussit. La réexécution du plan de reprise d'activité doit entraîner son achèvement sans erreurs.

  • Échec de connexion au NFC ou erreur de copie durant la récupération

    Durant une récupération, les messages d'erreur suivants peuvent apparaître :

    • Échec de connexion au service NFC à l' hôte.
    • Échec de copie du fichier filePath vers newFilePath : errorCode - errorMsg.

    Cela se produit lors de la réalisation d'un grand nombre d'opérations simultanées. Cela se produit généralement dans les conditions suivantes :

    • Lors de la récupération de 40 machines virtuelles ou plus qui sont protégées en utilisant VR (vSphere Replication).
    • Lors de la récupération de 10 banques de données ou plus sur un hôte ESX 3.5.
    • Lors de l'exécution d'un grand nombre de plans de reprise d'activité lorsque les plans de reprise d'activité affectent les machines virtuelles qui ont des disques RDM (Mappage de disque de données brutes). Cela se produit généralement lors de l'exécution de 20 plans de reprise d'activité ou plus sur de hôtes 4.x ou lors de l'exécution de 40 plans de reprise d'activité ou plus sur des hôtes 5.0.

    Pour résoudre ce problème, réexécutez les plans de reprise d'activité affectés.

  • Il se peut que le bouton Suivant sur l'Assistant Configurer la réplication ne fasse pas avancer l'Assistant

    L'Assistant Configurer la réplication contient une page intitulée serveur VR. Cette page inclut un bouton Suivant qui est toujours activé, mais il se peut qu'il ne fasse pas avancer l'Assistant vers la page suivante. Cela se produit lorsque le serveur SRM est configuré avec un seul serveur VR, et que le serveur est à l'état déconnecté. Pour résoudre ce problème, enregistrez un autre serveur VR ou faites passer l'état du serveur actuel à l'état Connecté.

  • Les serveurs VR (vSphere Replication) n'ont pas d'adresses IPv6 spécifiées

    Durant le déploiement du serveur VR (vSphere Replication) et du serveur VRM (vSphere Replication Management), les utilisateurs peuvent spécifier les adresses IPv6 à utiliser par ces serveurs. Si ces adresses sont entre parenthèses, l'adresse n'est pas appliquée correctement. Pour résoudre ce problème, indiquez l'adresse IPv6 sans parenthèses.

  • Le serveur VRM (vSphere Replication Management) ne supporte pas la réplication des modèles de machine virtuelle

    Le serveur VRM ne supporte pas la réplication des modèles de machine virtuelle. L'option de configuration de la réplication pour les modèles n'est pas disponible. Les machines virtuelles qui sont répliquées par VR mais qui sont converties ultérieurement en modèles ne sont plus répliquées. Pour éviter les problèmes constants de réplication pour les machines virtuelles converties en modèles, exécutez le processus suivant :

    1. Connectez vSphere Client au vCenter Server et cliquez sur le plug-in Site Recovery Manager.
    2. Sélectionnez vSphere Replication dans le panneau de gauche, sélectionnez le serveur VRM distant, et cliquez sur l'onglet Machines virtuelles.
    3. Sélectionnez la machine virtuelle qui a été convertie en un modèle, cliquez sur Supprimer la réplication, et confirmez ce choix.

  • Machines virtuelles pouvant être choisies après l'échec de la configuration de la réplication

    Lors de l'utilisation de l'assistant pour configurer la réplication pour de nombreuses machines virtuelles, il se peut que certaines machines virtuelles ne soient pas configurées avec succès. En dépit du fait que leur configuration a échoué, les machines virtuelles sont proposées comme choix possibles dans l'assistant Créer un groupe de protection. Cela se produit parce que l'information de l'échec de la configuration n'est pas communiquée. Pour résoudre ce problème, redémarrez le serveur SRM au site protégé.

  • Étape de récupération personnalisée avec échec de l'achèvement de la commande de démarrage

    Les étapes de récupération personnalisées peuvent exécuter des commandes. Si une étape de récupération personnalisée exécute une commande Démarrersans paramètre, la commande échoue. Par exemple, la commande c:\windows\system32\cmd.exe /C startne se termine pas. Pour résoudre ce problème, fermez manuellement la fenêtre de commande avec la commande démarrer.

  • Les serveurs VR (vSphere Replication) déployés avec un mauvais fonctionnement non spécifié de la configuration du réseau

    Les serveurs VR sont déployés depuis un fichier OVF en utilisant l'assistant Déploiement OVF. L'assistant de déploiement inclut une page permettant de spécifier la configuration du réseau du serveur VR. Si aucun paramètre réseau n'est spécifié pour la configuration du réseau, l'adressage DHCP est utilisé, mais les serveurs VR ne supportent pas l'adressage DHCP. Pour éviter ce problème, spécifiez les paramètres réseau valides pour le serveur VR durant le déploiement.

  • Les disques volumineux effectuent inutilement une synchronisation complète

    Lorsque les disques d'un volume supérieur à 256 Go sont protégés en utilisant VR (vSphere Replication), toute opération qui provoque un redémarrage interne du disque virtuel amène le disque à effectuer une synchronisation complète. Les redémarrages internes se produisent à tout moment :

    • Une machine virtuelle est redémarrée
    • Une machine virtuelle fait l'objet de vMotion
    • Une machine virtuelle est reconfigurée
    • Un instantané d'une machine virtuelle est pris
    • La réplication est interrompue momentanément et reprise

    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. Pour éviter ce problème, utilisez de plus petits disques.

    REMARQUE : Ce problème a été résolu dans ESXi Server 5.0 update 1.

  • Le plan de reprise d'activité ne se termine pas complètement après la déconnexion du stockage

    Lors des essais ou de l'exécution d'un plan de reprise d'activité, le plan de reprise d'activité peut échouer avec l'erreur Erreur lors de la création d'une image de bulle de test pour le groupe...aux étapes où les machines virtuelles sont mises sous tension. Cette erreur se produit après qu'une LUN stockant les données répliquées soit déconnectée du serveur ESX puis reconnectée. Après la reconnexion, la réplication continue comme avant, mais la LUN est affectée comme nouvel identificateur interne. Ce nouvel identificateur n'est pas associé aux machines virtuelles protégées. C'est pour cette raison que le serveur SRM ne peut ni synchroniser le stockage ni créer une image de la machine virtuelle répliquée. Par conséquent, toute l'étape de mise sous tension échoue. Pour résoudre ce problème, vous devez reconfigurer la réplication en utilisant la procédure suivante :

    1. Nettoyez le plan de reprise d'activité qui vient d'échouer.
    2. Démarrez l'assistant Reconfigurer pour le groupe de protection affecté.
    3. Changez l'emplacement des fichiers se trouvant sur la banque de données qui a été déconnectée. Sélectionnez les même banque de données et emplacements de dossier.
    4. Acceptez de réutiliser les disques existants, comme le propose l'assistant. Reconfigurez la machine virtuelle.

      5. Le groupe de protection passe à l'état de synchronisation complète, durant laquelle la cohérence des données est vérifiée. Attendez la fin du processus.

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

    Durant la migration planifiée, le serveur 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. Le SRM donne ensuite l'instruction au logiciel de baie de stockage de faire passer les LUN détachées 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 perdues. 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 lors du support d'un SRA sur la cible iSCSI par LUN. Pour résoudre ces problèmes, redémarrez l'hôte ESX.

  • L'échec de la récupération entraîne des défaillances répétées du serveur SRM

    Après l'échec de progression d'un plan de reprise d'activité, les utilisateurs peuvent choisir de réexécuter le plan de reprise d'activité. Dans de rares cas, la réexécution du plan de reprise d'activité provoque le blocage du serveur SRM. Après avoir redémarré le serveur, le plan de reprise d'activité continue à provoquer le blocage du serveur. Pour résoudre ce problème, commencez à examiner le contenu des journaux pour trouver la machine virtuelle qui était modifiée juste avant le blocage. L'entrée se présente généralement sous la forme d'une personnalisation IP réussie pour la VM Nom de la VM. Dès que vous connaissez la machine virtuelle qui a terminé la personnalisation IP juste avant le blocage, réalisez l'une des étapes suivantes :

    • Si cette défaillance s'est produite durant un test, annulez l'enregistrement de la machine virtuelle à espace réservé qui a été affectée.
    • Si cette défaillance s'est produite durant une récupération véritable, annulez l'enregistrement de la machine virtuelle récupérée, puis personnalisez manuellement les paramètres du réseau.

    Après avoir résolu le problème pour la machine virtuelle, redémarrez le serveur SRM et réexécutez le plan de reprise d'activité. Dans de rares cas, d'autres machines virtuelles peuvent être dans le même état, ce qui signifie que même après la réparation d'une seule machine virtuelle, les défaillances peuvent continuer et d'autres actions sont requises. Si les défaillances persistent, reprenez le processus d'examen des journaux, pour trouver la machine virtuelle affectée, et pour résoudre le problème. S'il existe des erreurs durant le workflow de nettoyage, sélectionnez la case à cocher Forcer le nettoyage pour remettre le système à l'état prêt.

  • É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 kodepuis l'installation vCenter Server parce que vCenter Server et vSphere Client sont localisés pour la Corée. Bien que vCenter Server et vSphere Client soient localisés pour la Corée, SRM ne l'est pas. Par conséquent, les messages XXXs'affichent, à la place des messages du serveur SRM. 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 envers koet redémarrez vCenter Server et les services SRM.

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

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

  • L'utilisation de SRM 5.0 avec les plus anciennes versions de ESX peut entraîner une perte permanente de périphériques

    Une perte permanente de périphériques (PDL) peut se produire durant les migrations planifiées et les basculements de test. Lorsque le serveur SRM protège des machines virtuelles fonctionnant sur les hôtes ESX 5.0, les nombreux cas où une perte permanente de périphériques pourrait se produire sont gérés correctement, et cette perte est évitée.

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

    Les basculements test et réels peuvent s'arrêter avec l'erreur Failed to create snapshots of replica devices for group 'protection-group-999' using array pair 'array-pair-999': Vmacore::SystemException "The parameter is 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, voir KB 2018597.

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

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

    Solution : Exécutez à nouveau le plan de récupération. Si l'erreur persiste, configurez le DRS du cluster du site de récupération en mode manuel et relancez le plan de récupération.

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

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

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

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

    Solution : si le site principal n'est plus disponible, contactez 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é de la banque de données. Si le site principal est toujours disponible :

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