VMware vCenter Site Recovery Manager 5.1.0.1 | 20 décembre 2012 | Build 941848
VMware vCenter Site Recovery Manager 5.1 (ISO seulement) | 10 septembre 2012 | Build 820150

Dernière mise à jour : 9 jan 2013

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

Contenu des notes de mise à jour

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés dans SRM 5.1.0.1

SRM 5.1.0.1 apporte les améliorations suivantes :

  • Il résout les problèmes critiques de SRM 5.1. Si vous avez installé SRM 5.1 (build 820150), vous devez effectuer une mise à niveau de votre installation vers SRM 5.1.0.1 (build 941848).
  • Il inclut vSphere Replication 5.1.0.1. Si vous avez installé vSphere Replication 5.1 après la mise à niveau de SRM vers 5.1.0.1, vous devez également effectuer une mise à niveau de vSphere Replication vers vSphere Replication 5.1.0.1.

Consultez les instructions de mise à niveau dans les Notes d'installation et de mise à niveau.

Problèmes résolus dans SRM 5.1.0.1

  • L'installation de SRM 5.1 ou la mise à niveau vers SRM 5.1 avec un certificat importé échoue
    Si vous tentez d'installer SRM 5.1 ou d'effectuer une mise à niveau vers SRM 5.1 avec un certificat PKCS12 importé au lieu d'utiliser un certificat généré automatiquement, le programme d'installation s'exécute jusqu'à la fin, mais échoue avec l'erreur Échec de l'installation du certificat. Voir KB 2036909. Ce problème a été résolu dans SRM 5.1.0.1.
  • SRM Server sur le site de récupération échoue lors du nettoyage des plans de récupération
    SRM Server sur le site de récupération échoue en boucle lors du nettoyage s'il n'y a rien à nettoyer, par exemple en l'absence de LUN à détacher ou de banques de données à démonter. Ce problème se produit lorsque la commande de démarrage de la récupération de test depuis SRM Server vers le SRA signale avoir réussi avec au moins un LUN, mais ne trouve aucun LUN lorsque les hôtes ESXi sur le site de récupération exécutent une réanalyse. Ce problème a été résolu dans SRM 5.1.0.1.

Nouveautés dans SRM 5.1

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

  • SRM 5.1 prend en charge l'option de reprotection et le retour arrière avec vSphere Replication. Auparavant, ces fonctions de reprotection et de retour arrière étaient uniquement exécutables avec des groupes de protection basés sur la baie. Avec SRM 5.1, vous pouvez procéder à la reprotection et au retour arrière sur des groupes de protection de vSphere Replication.
  • Le serveur SRM de SRM 5.1 est à présent une application 64 bits à part entière.
  • Gestion améliorée des banques de données dans l'état APD (Tous chemins hors service). Si le SRM détecte que la banque de données d'un site protégé est en état APD (Tous chemins hors service) et que, par conséquent, elle empêche une machine virtuelle de s'éteindre, le SRM attend pendant une certaine période avant d'essayer à nouveau d'arrêter la machine virtuelle en question. L'état APD est généralement transitoire. Ainsi, en attendant qu'une banque de données à l'état APD revienne en ligne, le SRM peut arrêter normalement les machines virtuelles protégées de cette banque de données.
  • Resignature améliorée des disques VFMS.

Localisation

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

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

Compatibilité

Matrice de compatibilité SRM

Pour accéder à la matrice actuelle d'interopérabilité et de compatibilité des produits, référez-vous à la section Matrices de compatibilité de VMware vCenter Site Recovery Manager 5.1.

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

Pour afficher la liste actuelle des baies de stockage et SRA compatibles pris en charge, référez-vous à la section Guide de compatibilité des partenaires de stockage de Site Recovery Manager.

Support de VSA de VMware

SRM 5.1 est capable de protéger des machines virtuelles résidant dans vSphere Storage Appliance (VSA) en utilisant vSphere Replication. VSA ne nécessite pas d'adaptateur de réplication de stockage (SRA) pour fonctionner avec SRM 5.1.

Notes d'installation et de mise à niveau

Pour obtenir un guide d'évaluation vous proposant une présentation technique des fonctions et capacités majeures de Site Recovery Manager 5.1, consultez la section Ressources VMware vCenter Site Recovery Manager relatives à la continuité d'activité.

Installer SRM 5.1.0.1

Pour créer une nouvelle installation de SRM 5.1.0.1, téléchargez et exécutez le programme d'installation VMware-srm-5.1.0-941848.exe. Voir la section Installation de SRM dans Installation et configuration de Site Recovery Manager.

Mettre à niveau une installation existante de SRM 5.0.x vers SRM 5.1.0.1

Pour mettre à niveau une installation existante de SRM 5.0.x vers SRM 5.1.0.1, téléchargez et exécutez le programme d'installation VMware-srm-5.1.0-941848.exe. Voir la section Mise à niveau de SRM dans Installation et configuration de Site Recovery Manager.

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

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

  1. Connectez-vous à la machine sur laquelle vous exécutez SRM Server sur le site protégé.
  2. Sauvegardez la base de données SRM en utilisant les outils fournis par votre logiciel de base de données.
  3. Téléchargez et exécutez le programme d'installation VMware-srm-5.1.0-941848.exe.
  4. Cliquez sur Oui lorsque vous êtes invité à confirmer que vous souhaitez mettre à niveau SRM.
  5. Cliquez sur Oui pour confirmer que vous avez sauvegardé la base de données SRM.
  6. Cliquez sur Terminer une fois l'installation effectuée.
  7. Répétez le processus de mise à niveau sur le site de récupération.

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

  1. Connectez-vous à une machine sur laquelle vous exécutez une instance de vSphere Client que vous utilisez pour vous connecter à SRM.
  2. Désinstallez le plug-in du client SRM 5,1.
  3. Connectez-vous à une instance de vSphere Client et au vCenter Server auquel SRM Server est connecté.
  4. Sélectionnez Plug-ins > Gérer les plug-ins.
  5. Cliquez sur Télécharger et installer pour installer le plug-in du client SRM 5.1.0.
  6. Lorsque l'installation du plug-in a été effectuée, connectez-vous à SRM et vérifiez que la configuration de la version précédente a été conservée.
  7. Répétez le processus pour toutes les instances de vSphere Client que vous utilisez pour vous connecter à SRM Server.

Si vous avez installé vSphere Replication 5.1, vous devez également effectuer une mise à niveau de vSphere Replication vers vSphere Replication 5.1.0.1. Voir la section Mise à niveau de vSphere Replication dans Installation et configuration de Site Recovery Manager.

Restrictions de fonctionnement pour SRM et vSphere Replication

Pour connaître les restrictions de fonctionnement de SRM 5.1 et de vSphere Replication 5.1, voir http://kb.vmware.com/kb/2034768.

SRM SDK

Pour consulter un guide d'utilisation de l'API basée sur SRM SOAP, consultez la section API de VMware vCenter Site Recovery Manager.

Composants Open Source

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

Mises en garde et limites

  • L'installation ou la mise à niveau vers SRM 5.1 à l'aide d'un certificat importé échoue
    Si vous tentez d'installer SRM 5.1 ou de passer à SRM 5.1 à l'aide d'un certificat PKCS12 importé au lieu d'utiliser un certificat généré automatiquement, le programme d'installation s'exécute jusqu'à la fin, mais échoue avec l'erreur Échec de l'installation du certificat. Voir KB 2036909. Ce problème a été résolu dans la version SRM 5.1.0.1. Pour utiliser un certificat PKCS12 importé, effectuez une mise à niveau vers SRM 5.1.0.1.

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

  • Interopérabilité avec vCloud Director
    Site Recovery Manager 5.1 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.

  • Le nombre de conversions SRM depuis la licence par CPU vers la licence par machine virtuelle est incorrect
    Certains clients ayant 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.1 par machine virtuelle, 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 machine virtuelle pour SRM 5.1. 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é.

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

  • SRM 5.1 prend en charge 2 nœuds Microsoft Cluster Server (MSCS)
    vSphere 5.1 prend en charge jusqu'à 5 nœuds MSCS. SRM 5.1 prend en charge 2 nœuds MSCS.

Problèmes résolus dans SRM 5.1

Les problèmes suivants, typiques de la version 5.0 de SRM, ont été résolus dans cette version.

  • Le couplage ou le découplage des dispositifs vSphere Replication échoue avec LockingFailedException

    Dans de rares cas, lors du couplage ou du découplage entre les serveurs du dispositif vSphere Replication, 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

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

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

    Le couplage des dispositifs vSphere Replication é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 du dispositif vSphere Replication.
      Les valeurs de nom d'hôte pourraient inclure le nom du sujet ou d'autres noms de sujet. L'adresse du dispositif vSphere Replication est spécifiée dans l'interface VAMI (Virtual Appliance Management Infrastructure) durant la configuration de l'application.
    • Le serveur du dispositif vSphere Replication 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 du dispositif vSphere Replication homologue, ce qui établit ainsi la confiance.

     

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

     

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

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

    Lorsque les utilisateurs exécutent une opération de reprotection, il se pourrait que les tâches excédant ce que les privilèges accordés devraient leur permettre 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 pourrait 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. Ce problème a été résolu.

  • 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 pourraient dérouter les utilisateurs. Ce problème a été résolu.

  • Il se pourrait 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 pourrait que les historiques des récupérations soient perdus. Ce problème a été résolu.

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

  • 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 pourraient se produire. Étant donné que le nom de la machine est utilisé pour construire des URL, il se pourrait que ces URL qui contiennent des caractères non-ASCII ne soient pas valides. Ce problème a été résolu.

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

  • 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 de ce type à un plan et que vous effectuez ensuite un test ou une récupération, SRM Server 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é. Ce problème a été résolu.

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

  • L'état de la machine virtuelle ne se met pas à jour après la déconnexion des dispositifs vSphere Replication

    Les dispositifs vSphere Replication échangent des informations entre les sites sur la réplication de la machine virtuelle. En cas d'interruption de la connexion des dispositifs vSphere Replication par l'option Interrompre la connexion des dispositifs vSphere Replication, l'échange des informations sur les machines virtuelles répliquées n'est pas rétabli automatiquement lorsque vous reconfigurez la connexion des dispositifs vSphere Replication. Il pourrait en résulter des informations incomplètes sur la réplication des machines virtuelles, y compris les machines virtuelles disponibles pour ajouter des groupes de protection. Ce problème a été résolu.

  • Il se pourrait 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 récupération, il se pourrait 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. Ce problème a été résolu.

  • 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 de la chaîne de l'hôte n'est pas compris dans les limites de la validité temporelle.Ce problème a été résolu.

  • Il se pourrait 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 Server et avec SRM Server 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 récupération, des problèmes risqueraient de se produire. Les opérations pourraient expirer ou échouer avec diverses explications. Ce problème a été résolu.

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

    Les groupes de protection pourraient être basés sur SAN ou sur VR (vSphere Replication), et les plans de récupération pourraient ê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. Ce problème a été résolu.

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

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

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

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

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

    Durant une récupération, les messages d'erreur suivants pourraient 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.

     

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

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

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

    Si le dispositif vSphere Replication 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.

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

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

  • La migration planifiée pourrait 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 pourrait 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 pourrait être lent à répondre et vCenter Server pourrait 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. Ce problème a été résolu.

Problèmes connus dans SRM 5.1

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.

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

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

  • Une perte temporaire des connexions de vCenter Server pourrait être à l'origine de problèmes de récupération pour les machines virtuelles avec des mappages de disques bruts

    En cas de perte de la connexion de vCenter Server pendant une récupération, une des situations suivantes pourrait se produire :

    • vCenter Server demeure indisponible et la récupération échoue. Pour résoudre ce problème, rétablissez la connexion avec vCenter Server et réexécutez la récupération.
    • En de rares cas, vCenter Server est à nouveau disponible et la machine virtuelle est récupérée. Dans une telle situation, si la machine virtuelle a des mappages de disques bruts (RDM), ceux-ci risqueraient de ne pas être correctement mappés. Suite au mauvais mappage des RDM, il se pourrait qu'il soit impossible d'allumer la machine virtuelle, ou des erreurs liées au système d'exploitation client ou aux applications exécutées sur le système d'exploitation client pourraient survenir.
      • S'il s'agit d'une récupération test, procédez à une opération de nettoyage et relancez le test.
      • S'il s'agit d'une récupération réelle, vous devez manuellement joindre le bon RDM à la machine virtuelle récupérée.

    Consultez la rubrique relative à la modification des paramètres de la machine virtuelle dans la documentation de vSphere pour en savoir plus sur l'ajout de mappages de disques bruts.

  • Annulation du plan de récupération inachevée

    Lors de l'exécution d'un plan de récupération, une tentative de synchronisation des machines virtuelles est effectuée. Il est possible d'annuler le plan de récupération, mais les tentatives d'annulation de l'exécution du plan de récupération n'aboutissent pas tant que la synchronisation n'est pas terminée ou expirée. Par défaut, le délai d'expiration est de 60 minutes. Vous pouvez utiliser les options suivantes pour effectuer une annulation du plan de récupération :

    • Mettez vSphere Replication en pause pour déclencher l'échec de la synchronisation. Lorsque la récupération entre dans un état d'erreur, utilisez vSphere Client pour redémarrer vSphere Replication sous l'onglet vSphere Replication. Après le redémarrage de la réplication, vous pouvez, le cas échéant, réexécuter le plan de récupération.
    • Attendez que la synchronisation soit terminée ou expirée. L'opération pourrait éventuellement durer assez longtemps, mais finira par se terminer. Au terme ou à l'expiration de la synchronisation, l'annulation du plan de reprise d'activité continue.

     

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

    Lors du téléchargement et de l'installation de certificats sur le dispositif vSphere Replication, l'erreur suivante se produit :

    Le certificat est installé avec des avertissements. Il se pourrait 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 mots de passe composés par des caractères autres que ASCII ne sont pas acceptés pour la connexion à l'interface VAMI (Virtual Appliance Management Infrastructure)

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

  • É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 la réplication de la machine virtuelle vSphere 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'arrêt de la réplication de la banque de données pour les machines virtuelles protégées génère des messages d'erreur incorrects.

    Il est possible de protéger une machine virtuelle qui comporte des disques sur de nombreuses banques de données puis de désactiver ultérieurement la réplication pour une des banques de données. Dans un tel cas, l'état de la machine virtuelle dans le groupe de protection devient Invalide : La machine virtuelle 'VM' n'est plus protégée. Erreur interne : Impossible de créer un localisateur pour disk'2001'...Ces informations sont incorrectes. L'état doit passer à La banque de données '[ datastore name]' n'est plus répliquée.

  • La récupération d'une machine virtuelle échoue en raison d'une erreur de configuration sur le disque

    Il est possible de placer différents disques et fichiers de configuration pour une seule machine virtuelle protégée sur de nombreuses banques de données. Durant la récupération, le serveur SRM doit avoir accès au mappage du disque de données brutes et aux fichiers du disque parent. Sans cet accès, le serveur SRM ne peut pas déterminer les types de disque durant une récupération. Dans un tel cas, le serveur SRM pourrait supposer qu'un disque RDM (mappage du disque de données brutes) n'est pas un disque RDM, ce qui entraînerait l'échec de la reconfiguration. Pour éviter ce problème, vérifiez si tous les hôtes pouvant accéder aux fichiers de configuration de la machine virtuelle récupérée peuvent également accéder aux fichiers de mappage RDM et aux disques parents éventuels.

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

    Lors du couplage des sites SRM, l'erreur Les serveurs locaux et distants utilisent différentes méthodes de confiance du certificatapparaît. Ce problème se produit lorsque le certificat racine pour l'autorité de certification (CA) qui signe le certificat manque sur SRM Server. 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 SRM de façon à fournir de nouveau le certificat généré par l'utilisateur.

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

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

  • Le dispositif vSphere Replication ne parvient pas à prendre en charge les hôtes ESX valides

    Durant la configuration de vSphere Replication, lorsqu'une banque de données est sélectionnée sur une version prise en charge d'ESX, le message Le server VR Server Name n'a aucun hôte permettant d'accéder à la banque de données de destination...s'affiche. Cela se produit en raison d'un hôte valide marqué comme NON SUPPORTÉ, même si l'hôte est une sélection valide. Pendant l'enregistrement du serveur vSphere Replication, 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 dispositifs vSphere Replication et les serveurs vSphere Replication durant l'enregistrement des serveurs vSphere Replication ou lors de la connexion d'un nouvel hôte à un inventaire 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 vSphere Replication, vous devez exécuter les étapes suivantes :

    1. Parcourez la base de données des dispositifs vSphere Replication sur le site de récupération.
    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 Server 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 des dispositifs vSphere Replication est le suivant :

    1. Interroger
      • Pour interroger tous les hôtes marqués NON PRIS EN CHARGE, qui ne sont pas associés à un serveur vSphere Replication :
        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 PRIS EN CHARGE, qui sont associés à un serveur vSphere Replication : 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 PRIS EN CHARGE pour les hôtes qui ne sont pas associés à un serveur vSphere Replication :
        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 PRIS EN CHARGE, qui sont associés à un serveur vSphere Replication :
        mettre à jour HostEntity définir state=1 où state=4 et existe (sélectionnez * depuis HbrHostEntity où vcMoId=HbrHostEntity.vcHost_vcMoId).

     

  • Le démontage des banques de données ne réussit pas lorsque ces dernières se trouvent sur des clusters DPM (Distributed Power Management)

    Les migrations planifiées et les récupérations d'urgence ne permettent pas de démonter les banques de données depuis les hôtes qui sont attachés à un cluster DPM si l'hôte passe en mode de veille. L'erreur Erreur : Impossible de démonter la banque de données datastorename depuis l'hôte hostname. Impossible de communiquer avec l'hôte distant, puisqu'il est déconnectépourrait apparaître. Pour résoudre ce problème, désactivez DPM au site protégé avant d'exécuter les migrations planifiées ou les récupérations d'urgence. Vous pouvez choisir de réactiver DPM au terme des tâches de récupération.

  • Les serveurs vSphere Replication déployés avec une configuration réseau non spécifiée ne fonctionnent pas correctement

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

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

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

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

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

  • L'aide contextuelle n'est pas disponible sous Internet Explorer 7.

    Voir KB 1009801 .

  • SRM ne peut récupérer les machines virtuelles après des pannes RDM.

    Les LUN Raw Disk Mapping (RDM) peuvent échouer tandis que les LUN en charge de la sauvegarde des banques de données restent intacts. En pareille circonstance, SRM ne peut récupérer les machines virtuelles dotées de RDM.

    Solution : Procédez à la récupération manuelle des machines virtuelles affectées. Effectuez le basculement du LUN RDM et joignez-le à nouveau en tant que disk RDM de la machine virtuelle récupérée.

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

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

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

  • L'exécution de la récupération prend beaucoup de temps. La reprotection échoue et le message d'erreur suivant s'affiche : Impossible de vérifier les informations d'identification de connexion Échec de l'infrastructure des services d'authentification.

    Cette erreur se produit à cause de l'épuisement des ports éphémères de vCenter Server fonctionnant sous Windows 2003 server. Le serveur SRM ne peut communiquer avec vCenter Server.

    Solution :

    1. Installez le correctif logiciel Microsoft à partir de KB 979230 pour résoudre ce problème du pilote tcpip.sys.
    2. Paramétrez les valeurs regedit suivantes, en effectuant des modifications manuelles ou en important le fichier .reg suivant : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "MaxUserPort"=dword:00002710 "TcpTimedWaitDelay"=dword:0000001E
    3. Si les valeurs de registre n'existent pas, créez-les.
    4. Après avoir effectué ces modifications, redémarrez la machine Windows 2003 Server.

     

  • Erreur dans le plan de récupération lors de l'arrêt des machines virtuelles protégées : Erreur - Opération expirée : 900 secondes pendant l'étape Arrêt des machines virtuelles sur le site protégé.

    Si vous utilisez SRM pour protéger les banques de données sur des baies qui prennent en charge un échange dynamique, par exemple Clariion, l'exécution d'une récupération d'urgence lorsque le site protégé est partiellement arrêté ou l'exécution d'une récupération forcée peut conduire à des erreurs lors de la nouvelle exécution du plan de récupération pour terminer les opérations du site protégé. Une telle erreur se produit lorsque le site protégé revient en ligne, mais que SRM ne parvient pas à arrêter les machines virtuelles protégées. Cette erreur survient généralement lorsque certaines baies rendent les LUN protégés uniquement accessibles en lecture seule, ce qui empêche ESXi de terminer l'E/S pour les machines virtuelles protégées sous tension.

    Solution : Redémarrez les hôtes ESXi sur le site protégé qui sont affectés par les LUN en lecture seule.

  • La génération de bundles de support dans un environnement très chargé peut interrompre les opérations vSphere Replication en cours.

    La génération de bundles de support dans des environnements très chargés peut causer des problèmes de connexion de vSphere Replication pendant la récupération. Ces cas surviennent en particulier lorsque le stockage de la machine virtuelle de vSphere Replication est surchargé.

    Solution : Si une opération ne peut démarrer lorsque le serveur de vSphere Replication est bloqué par la génération du bundle de support, essayez d'exécuter à nouveau cette opération. Réévaluez les exigences projetées de bande passante de stockage du cluster, ainsi que la bande passante du réseau si le stockage est NAS.

  • La réexécution de la reprotection échoue avec l'erreur : Le groupe de protection '{protectionGroupName}' dispose de VM protégées avec des paramètres fictifs nécessitant une réparation.

    Si une opération ReloadFromPath échoue au cours de la première reprotection, les machines virtuelles protégées correspondantes entrent dans un état repairNeeded. Lorsque SRM exécute une reprotection sur un groupe de protection, SRM ne peut ni réparer les machines virtuelles protégées, ni restaurer les machines virtuelles à espace réservé. L'erreur survient lorsque la première opération de reprotection échoue pour une machine virtuelle du fait que l'opération ReloadFromPath correspondante a échoué.

    Solution : Exécutez à nouveau la reprotection avec l'option Forcer le nettoyage activée. Cette option termine l'opération de reprotection et active l'option Recréer l'espace réservé. Cliquez sur Recréer l'espace réservé pour réparer les machines virtuelles protégées et pour restaurer les machines virtuelles à espace réservé.

  • La tâche Protéger les machines virtuelles semble rester à 100 %.

    Le panneau Tâches récentes de VI Client indique une machine virtuelle plafonnant à 100 % au cours de la tâche Protéger une VM. SRM marque la machine virtuelle comme étant Configurée, indiquant qu'elle était protégée. Aucune action n'est nécessaire car SRM protégeait parfaitement la machine virtuelle.

  • Le nettoyage échoue s'il a lieu dans les 10 minutes suivant le redémarrage des hôtes ESXi du site de récupération à partir du mode maintenance.

    L'opération de nettoyage tente d'échanger les espaces réservés et repose sur le cache de tolérance des hôtes qui a une période d'actualisation de 10 minutes. Si vous tentez une opération d'échange sur des hôtes ESXi ayant été redémarrés dans l'intervalle de 10 minutes, SRM ne met pas à jour les informations dans le cache de tolérance des hôtes SRM et l'opération d'échange échoue. L'opération de nettoyage échoue également.

    Solution : Patientez 10 minutes et tentez un nouveau nettoyage.

  • SRM s'arrête au cours d'une tentative de protection d'une machine virtuelle basée sur la baie déjà reprotégée à l'aide de vSphere Replication.

    Si vous exécutez une récupération, et que vous essayez ensuite d'utiliser vSphere Replication pour protéger une machine virtuelle déjà protégée par un groupe de protection basé sur la baie, SRM Server réagit.

    Solution : Redémarrez le serveur SRM et ôtez tout d'abord la protection de la machine virtuelle protégée basée sur la baie avant de protéger avec vSphere Replication. Vous pouvez également poursuivre avec une protection basée sur la baie et ne pas protéger avec vSphere Replication. SRM ne prend pas en charge la protection avec les deux fournisseurs.

  • La reprotection échoue avec l'erreur : Opération expirée : Échec de la synchronisation VR 3 600 secondes pour le groupe VRM <Unavailable>. Opération expirée : 3 600 secondes.

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

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

  • Impossible de configurer une machine virtuelle à l'aide d'un disque RDM à mode physique, même si le disque est exclu de la réplication.

    Si vous configurez la réplication d'une machine virtuelle en mode physique, l'un des messages d'erreurs suivants risque d'apparaître :

    Erreur générique du serveur VRM. Consultez la documentation pour toutes les informations de dépannage. L'exception détaillée est la suivante : HMS ne peut pas définir UUID disque pour les disques de VM : MoRef: type = VirtualMachine, value = , serverGuid = null'.

    Solution : Aucune.

  • La migration planifiée échoue avec Erreur : Impossible de copier le fichier de configuration...

    Si dans un cluster contenant deux hôtes ESXi, un des hôtes perd sa connectivité au stockage, l'autre hôte peut généralement récupérer les machines virtuelles répliquées. Dans certains cas, l'autre hôte peut ne pas récupérer les machines virtuelles et la récupération échoue avec l'erreur suivante : Erreur : Impossible de copier le fichier de configuration...

    Solution : Exécutez une nouvelle récupération.

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

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

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

  • vSphere Replication ne peut accéder aux banques de données par le biais des hôtes avec NIC virtuelles de gestion multiple et publie DatastoreInaccessibleEvent dans vCenter Server : vSphere Replication ne peut pas accéder à la banque de données.

    Si un hôte est configuré avec plusieurs NIC virtuelles et que vous sélectionnez plus d'une NIC pour la gestion du trafic, vSphere Replication enregistre seulement la première NIC et l'utilise pour accéder aux banques de données cibles. Si l'adresse du serveur vSphere Replication ne se trouve pas sur le premier réseau de gestion de l'hôte, vSphere Replication ne pourra pas communiquer avec l'hôte.

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

  • Une machine virtuelle ne peut pas être mise hors tension en raison d'une erreur de question en attente.

    Si vous créez une situation de perte permanente de périphérique (PDL), accidentellement ou délibérément, en abandonnant un initiateur du SAN sur l'hôte où est enregistrée la machine virtuelle, l'erreur suivante peut se produire :

    Erreur : Impossible d'effectuer cette opération actuellement car il y a une question en attente sur la machine virtuelle...

    Cette erreur se produit en cas de panne matérielle sur le site de récupération pendant une PDL lors de l'exécution d'un nettoyage après avoir exécuté un plan de récupération en mode de récupération test.

    Solution : Répondez à la question dans l'onglet Résumé de la machine virtuelle. Puis, exécutez à nouveau un nettoyage en mode de nettoyage forcé. Une fois l'opération de nettoyage terminée, il est possible que la machine virtuelle soit encore présente sur le site de récupération. Si c'est le cas, supprimez-la manuellement.

  • SRM version 5.0 peut communiquer avec le serveur SRM version 5.1 pendant l'exécution de la récupération.

    Si vous effectuez une mise à niveau de la version 5.0 vers la version 5.1 du site de récupération et que vous tentez une récupération d'urgence sur le site mis à niveau, les serveurs SRM version 5.0 sur le site protégé et le serveur SRM version 5.1 sur le site de récupération peuvent communiquer entre eux et effectuer des opérations sur le site protégé. Si vous exécutez une opération de reprotection avant de mettre à niveau le site protégé, l'opération s'exécute pendant une durée anormalement longue sans progresser.

    Avant d'exécuter une récupération sur un site mis à niveau, arrêtez tous les services SRM 5.0 en cours d'exécution sur le site distant. Si vous ne le faites pas, les serveurs SRM ayant des versions incompatibles pourront continuer de communiquer entre eux.

  • Une erreur interne se produit au cours de la récupération.

    SRM récupère diverses informations à partir de vCenter au cours du processus de récupération. S'il ne reçoit pas les informations cruciales requises pour poursuivre, une erreur interne CannotFetchVcObjectPropertypeut se produire. Cette erreur peut survenir lorsque vCenter est soumis à de fortes contraintes ou qu'un hôte ESXi devient indisponible en raison de fortes contraintes. Cette erreur peut également survenir lorsque SRM tente de rechercher les informations d'un hôte ESXi qui est déconnecté ou a été supprimé de l'inventaire vCenter.

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

  • L'adresse MAC de la carte réseau virtuelle d'une machine virtuelle est généralement préservée pendant la récupération.

    Dans de très rares circonstances, le test ou la récupération peut échouer dans la récupération d'une machine virtuelle spécifique, du fait que vCenter affecte de manière inattendue une nouvelle adresse MAC à la VNIC de la machine virtuelle sur le site de récupération. Le message d'erreur qui s'affiche dans la colonne de résultat dans les étapes de récupération est le suivant : Erreur - Impossible de terminer la personnalisation, probablement du fait d’une erreur d’exécution de script ou de paramètres de script non valides (Code d'erreur : 255). Les paramètres IP ont pu être appliqués en partie. Les journaux SRM contiennent un message : Erreur lors de la recherche de la NIC spécifiée pour l'adresse MAC = xx::xx:xx:xx:xx où xx::xx:xx:xx:xx correspond à l'adresse MAC attendue.

    Solution : Modifiez manuellement l'adresse MAC de la machine virtuelle affectée dans les propriétés de la machine virtuelle vSphere Client sur « xx::xx:xx:xx:xx » et redémarrez le plan de récupération.

  • vSphere Replication signale que « la banque de données est inaccessible » pour les banques de données sur un hôte ajouté à l'inventaire vCenter Server lors de l'enregistrement d'un serveur vSphere Replication.

    vSphere Replication sélectionne l'ensemble des hôtes pris en charge dans l'inventaire vCenter et les active dans le cadre de l'enregistrement de vSphere Replication. Si vous ajoutez un hôte à vCenter alors que vSphere Replication est en cours d'enregistrement, vSphere Replication ne sélectionne pas cet hôte et il ne peut pas accéder aux banques de données sur le site de récupération.

    Solution : Déconnectez et reconnectez l'hôte dans l'inventaire vCenter pour que vSphere Replication puisse l'activer.

  • Les opérations de synchronisation de la machine virtuelle, de récupération ou de reprotection échouent avec l'erreur générique de vSphere Replication : L'instance demandée avec l'Id=<...> est introuvable sur le site distant.

    Même si l'opération signale un échec, vSphere Replication réussit à synchroniser l'état de la machine virtuelle sur le site distant. Cette erreur peut se produire lorsque vous demandez une opération de synchronisation ou lorsque vous exécutez des opérations principales telles que la récupération ou la reprotection qui utilisent cette opération.

    Solution : Exécutez à nouveau l'opération échouée.

  • Le montage du volume VMFS récupéré échoue avec l'erreur : Échec de récupération de la banque de données.

    Cette erreur peut se produire en raison d'une latence entre vCenter, ESXi et le serveur SRM.

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

  • L'enregistrement du serveur vSphere Replication peut prendre un certain temps selon le nombre d'hôtes présents dans l'inventaire vCenter Server.

    Si l'inventaire vCenter Server contient une centaine d'hôtes, ou plus, la tâche Enregistrer le serveur VR prendra une heure ou plus, étant donné que vSphere Replication met à jour le registre d'empreinte SSL de chaque hôte. Le panneau Événements de vCenter Server affiche L'hôte est configuré pour vSphere Replication pour chaque hôte au fur et à mesure que la tâche d'enregistrement du serveur vSphere Replication progresse.

    Solution : Attendez que la tâche d'enregistrement soit terminée. Une fois terminée, vous pouvez utiliser vSphere Replication pour le trafic de réplication entrant.

  • L'enregistrement de vSphere Replication peut échouer avec l'erreur : Erreur générique du serveur VRM... La rangée a été mise à jour ou supprimée par une autre transaction ... HostEntity #<host-managed-object-id>.

    L'opération Enregistrer le serveur VR peut échouer avec cette erreur si vCenter Server compte un grand nombre d'hôtes dans son inventaire et si vous effectuez les actions suivantes alors que l'enregistrement est en cours :

    • Supprimer un hôte de l'inventaire vCenter Server.
    • Supprimer et reconnecter un hôte de l'inventaire.
    • Modifier l'empreinte SSL de l'hôte.

    Solution : Relancez l'opération Enregistrer le serveur VR.

  • Les opérations de récupération test, de migration planifiée ou de reprotection peuvent échouer avec l'erreur : Opération expirée.

    Cette erreur peut survenir lors de l'exécution de plusieurs opérations avec plusieurs sites principaux.

    Solution : Exécutez à nouveau l'opération échouée.

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

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

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

  • Certaines tâches initiées par SRM qui échouent avec une erreur NoPermission et affichent Erreur interne : vim.fault.NoPermissionau lieu de L'autorisation d'effectuer cette opération a été refusée.

    Le vSphere Client réagit si une tâche en miroir contient une MoRef à un objet autre qu'un objet vCenter Server ou SRM.

    Solution : Si la tâche SRM échouée est une tâche de récupération, consultez le panneau de la tâche de récupération pour une erreur plus spécifique. Pour une défaillance de la tâche vCenter Server, consultez les sous-tâches qui contiennent plus d'informations.

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

    vSphere Replication cesse de répondre aux requêtes SRM lors de la reprotection de plusieurs machines virtuelles pour plusieurs sites distants.

    Solution : Modifiez plusieurs paramètres vSphere Replication :

    1. Arrêtez le serveur de gestion vSphere Replication : /etc/init.d/hms stop
    2. Modifiez /opt/vmware/hms/conf/hms-configuration.xml et passez la valeur de hms-db-max-connections de 99 à 500.
    3. Modifiez /var/lib/vrmsdb/postgresql.conf et passez la valeur de max_connections de 100 à 501.
    4. Redémarrez la base de données vPostgres intégrée : /etc/init.d/hms-vpostgres stop /etc/init.d/hms-vpostgres start
    5. Modifiez la taille du pool de threads hms-vlsi-server : /opt/vmware/vpostgres/1.0/bin/psql -U vrmsdb vrmsdb update ConfigEntryEntity set configValue='250' where configKey = 'hms-vlsi-server-threadpool-size'
    6. Augmentez la taille du segment de mémoire pour le processus du serveur de gestion vSphere Replication : modifiez /etc/init.d/hms et ajoutez -Xmx1536M dans JAVA_TOOL_OPTIONS.
    7. Lancez le serveur de gestion vSphere Replication : /etc/init.d/hms start
    8. Exécutez à nouveau l'opération échouée.

     

  • La valeur Taille de la dernière synchronisation pour une machine virtuelle protégée par vSphere Replication correspond à la quantité de données modifiées depuis la dernière synchronisation.

    Même si vous effectuez une synchronisation complète sur une machine virtuelle protégée par vSphere Replication, la valeur Taille de la dernière synchronisation indique la quantité des données qui ont été modifiées depuis la dernière synchronisation, et non la taille de la machine virtuelle complète. Ceci peut être mal interprété dans le sens où la synchronisation n'était pas complète. Après la synchronisation initiale, lors d'une synchronisation complète d'une machine virtuelle, vSphere Replication compare tous les disques, mais ne transfère que les données ayant été modifiées, pas l'ensemble du disque.

    Pour afficher la taille et la durée de la synchronisation initiale, vous pouvez vérifier les événements que vSphere Replication poste sur vCenter Server. Le problème survient uniquement sur les hôtes ESXi 5.0.x. Ce comportement a été résolu sur les hôtes ESXi 5.1.

  • La récupération ou la récupération test peut échouer avec l'erreur « Aucun hôte avec la version matérielle '7' et banque de données 'ds_id' sous tension et hors mode de maintenance n'est disponible... » dans les cas où des modifications très récentes ont lieu dans l'inventaire de l'hôte.

    Le serveur SRM conserve un cache de l'état de l'inventaire de l'hôte. Parfois, lorsque de récentes modifications ont été apportées à l'inventaire, par exemple si un hôte devient inaccessible, est déconnecté ou perd sa connexion avec certaines banques de données, la mise à jour du cache du serveur SRM peut nécessiter jusqu'à 15 minutes. Si le serveur SRM a dans son cache le mauvais état d'inventaire de l'hôte, une récupération ou une récupération test peut échouer.

    Solution : Patientez 15 minutes avant d'exécuter une récupération si vous avez apporté des modifications à l'inventaire de l'hôte. Si vous observez l'erreur ci-dessus, patientez 15 minutes, puis relancez la récupération.

  • La reprotection échoue avec un message d'erreur qui contient Impossible de communiquer avec l'hôte distant, puisqu'il est déconnecté.

    Cette erreur est probablement due au fait que le cluster latéral protégé a été configuré pour utiliser DPM (Distributed Power Management), et que l'un des hôtes ESX requis pour l'opération était en mode veille. Cela peut se produire si DPM a détecté que l'hôte était inactif et l'a placé en mode veille. SRM devait communiquer avec l'hôte afin d'accéder à la banque de données répliquée gérée par cet hôte. SRM ne gère pas l'état DPM sur le site protégé mais gère, cependant l'état DPM pendant la récupération, le test et le nettoyage sur le site de récupération.

    Solution : Si l'erreur persiste, désactivez temporairement DPM et vérifiez que les hôtes ESX gérant les banques de données répliquées du côté protégé sont activés avant de relancer une nouvelle reprotection.

  • Le nettoyage de la récupération test peut échouer si l'un des hôtes perd la connexion avec une banque de données à espace réservé.

    Si vous avez exécuté une récupération test sur un cluster avec deux hôtes sur un site de récupération et si un des hôtes du cluster perd la connexion avec une banque de données à espace réservé, le nettoyage de la récupération test peut échouer.

    Solution : Exécutez le nettoyage en mode forcé. Sur le site de récupération, supprimez manuellement les machines virtuelles à espace réservé créées sur l'hôte ayant perdu la connexion avec la banque de données à espace réservé. Supprimez la configuration de la réplication des machines virtuelles et reconfigurez la réplication. Reconfigurez la protection des machines virtuelles dans les propriétés du groupe de protection.

  • La reprotection échoue avec une erreur lors de l'exécution simultanée de plusieurs plans de récupération.

    Lors de l'exécution simultanée de plusieurs plans de récupération, la reprotection peut échouer avec l'erreur Erreur - L'opération n'a été terminée que de manière partielle pour le groupe de protection 'protection_group', une machine virtuelle protégée lui étant attachée n'ayant en effet pas réussi à achever l'opération.

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

  • Une fois vCenter Server redémarré, lors de l'utilisation de vSphere Replication, les opérations de reprotection échouent avec Erreur - Impossible d'inverser la réplication pour la machine virtuelle ' virtual_machine'. La session n'est pas authentifiée.

    Après le redémarrage de vCenter Server, celui-ci ne parvient pas à actualiser certaines sessions utilisées par SRM pour communiquer avec vSphere Replication et provoque l'échec de la reprotection.

    Solution : Redémarrez les services SRM sur les deux sites.

  • Lorsque les LUN du site de protection rencontrent une condition APD (Tous chemins hors service) ou PDL (perte permanente de périphérique), dans certains cas, il est possible que SRM ne récupère pas les LUN de mappage de disque brut (RDM).

    Lors de la première tentative de migration planifiée, le message d'erreur suivant peut s'afficher lorsque SRM tente d'arrêter la machine virtuelle protégée :

    Erreur - Impossible d'effectuer cette opération actuellement car il y a une question en attente sur la machine virtuelle : 'msg.hbacommon.askonpermanentdeviceloss:Le disque virtuel de sauvegarde de stockage VM1-1.vmdk présente une perte permanente de périphérique. Il se peut que vous puissiez retirer à chaud ce périphérique virtuel de la machine virtuelle et continuer après avoir cliqué sur Réessayer. Cliquez sur Annuler pour mettre fin à cette session.

    Si les machines virtuelles protégées ont des périphériques RDM, dans certains cas, SRM ne récupère pas le LUN RDM.

    Solution :

    1. Lorsque des LUN accèdent à APD/PDL, le serveur ESXi marque toutes les machines virtuelles correspondantes avec une question qui bloque les opérations des machines virtuelles.
      1. Dans le cas de PDL, cliquez sur Annuler pour désactiver la machine virtuelle.
      2. Dans le cas d'APD, cliquez sur Réessayer.

      Si vous exécutez une migration planifiée, SRM ne parvient pas à désactiver les machines virtuelles de production.
    2. Si les machines virtuelles ont des périphériques RDM, SRM pourrait perdre la trace du périphérique RDM et pourrait ne pas le récupérer. Réanalysez tous les HBA et vérifiez que l'état, pour l'ensemble des LUN affectés a récupéré de l'état APD/PDL.
    3. Vérifiez l'inventaire vCenter Server et répondez à la question PDL qui bloque la machine virtuelle.
    4. Si vous répondez à la question PDL avant que les LUN reviennent en ligne, le serveur SRM sur le site protégé détecte de manière incorrecte que le périphérique RDM n'est plus attaché à cette machine virtuelle et supprime le périphérique RDM. Lors de la prochaine récupération, SRM ne récupérera pas ce LUN.
    5. Réanalysez tous les HBA pour vérifier que tous les LUN sont en ligne dans l'inventaire vCenter Server et mettez sous tension toutes les machines virtuelles affectées. vCenter Server associe les RDM perdus aux machines virtuelles protégées.
    6. Vérifiez l'onglet Gestionnaires de baies dans l'interface SRM. Si l'ensemble des banques de données et des périphériques RDM protégés ne s'affichent pas, cliquez sur Actualiser pour découvrir les périphériques et recalculer les groupes de banques de données.
    7. Vérifiez que Modifier les paramètres de groupe affiche l'ensemble des banques de données et des périphériques RDM protégés et que l'état de protection des machines virtuelles n'indique aucune erreur.
    8. Lancez une migration planifiée pour récupérer tous les LUN protégés, y compris les périphériques RDM.
  •  

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

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

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

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

    Solution : Si le site principal n'est plus disponible, contactez l'assistance VMware pour obtenir des instructions sur l'ajout d'une entrée de configuration spéciale dans la base de données des dispositifs vSphere Replication qui déclenche une correction automatique de l'ID de la banque de données interne modifié afin de permettre la récupération. Si le site principal est encore disponible :

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