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

Nous contacter

VMware vCenter Site Recovery Manager 5.0.3.3a | 7 avril 2016

VMware vCenter Site Recovery Manager 5.0.3.3 | 29 octobre 2015 | Build 3022051

VMware vCenter Site Recovery Manager 5.0.3.2 | 22 juillet 2014 | Build 1964819

VMware vCenter Site Recovery Manager 5.0.3.1 | 29 mai 2014 | Build 1848414

VMware vCenter Site Recovery Manager 5.0.3 | 17 octobre 2013 | Build 1344912

Dernière mise à jour : 7 avril 2016

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

Pour obtenir des informations sur les versions des correctifs Site Recovery Manager 5.0.3.x, notamment des détails sur n'importe quel correctif vSphere Replication requis, consultez les articles correspondants de la base de connaissances.

Contenu des notes de mise à jour

Ces mises à jour contiennent les rubriques suivantes :

Nouveautés

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

Localisation

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

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

Compatibilité

Matrice de compatibilité SRM

Pour les informations actuelles sur l'interopérabilité et la compatibilité des produits, consultez Matrices de compatibilité pour VMware vCenter Site Recovery Manager 5.0.

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

Pour connaître la liste actuelle des baies de stockage et SRA compatibles, veuillez consulter le Guide de compatibilité de VMware.

Support de VSA de VMware

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

Installation et mise à niveau

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

Pour installer SRM 5.0.3 sans effectuer de mise à niveau, reportez-vous à la section Installation et mise à jour de Site Recovery Manager dans le Guide d'administration de Site Recovery Manager .

Mise à niveau de SRM 5.0.x vers SRM 5.0.3

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

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

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

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

REMARQUE : Microsoft a publié une mise à niveau de sécurité provoquant le refus des certificats avec des clés RSA de moins de 1 024 bits de la part de Windows. Voir http://support.microsoft.com/kb/2661254. Cette norme a été portée à 2 048 bits à la fin de l'année 2013. Par conséquent, SRM 5.0.2 et les versions ultérieures génèrent automatiquement des certificats avec des clés RSA de 2 048 bits. SRM versions 5.0 et 5.0.1 génèrent automatiquement des certificats avec des clés RSA de 512 bits. Lors de la mise à niveau de SRM 5.0 ou 5.0.1 vers 5.0.3, SRM conserve le certificat de l'installation précédente. Par conséquent, si vous installez la mise à jour de sécurité de Microsoft, vous devez mettre à niveau les certificats SRM pour utiliser des clés RSA d'au moins 1 024 bits ou de préférence de 2 048 bits.

  • Si vous avez utilisé des certificats générés automatiquement avec SRM 5.0 ou 5.0.1, après la mise à niveau vers SRM 5.0.3, vous pouvez mettre à niveau le certificat en réexécutant le programme d'installation de SRM 5.0.3 en mode Modification et en sélectionnant l'option permettant de générer un nouveau certificat de 2 048 bits.
  • Si vous avez utilisé des certificats signés par une autorité de certification dans SRM 5.0 ou 5.0.1, vous devez les mettre à niveau et les importer manuellement en vous assurant qu'ils utilisent des clés RSA d'au moins 1 024 bits ou de préférence de 2 048 bits.

Mise à niveau de vSphere Replication 1.0.x vers vSphere Replication 1.0.3

Les versions SRM 5.0 à 5.0.2 incluent vSphere Replication 1.0 à 1.0.2. La version SRM 5.0.3 inclut vSphere Replication 1.0.3. La mise à niveau de SRM 5.0, 5.0.1 ou 5.0.2 vers SRM 5.0.3 ne met pas automatiquement à niveau vSphere Replication 1.0, 1.0.1 ou 1.0.2 vers vSphere Replication 1.0.3. vSphere Replication 1.0.3 est identique du point de vue fonctionnel à vSphere Replication 1.0.2, mais comporte en plus des correctifs de bogues. Vous pouvez utiliser vSphere Update Manager pour effectuer la mise à jour du serveur VRM et des serveurs VR. Vous pouvez également utiliser l'interface de gestion du dispositif virtuel (VAMI) pour effectuer la mise à jour du serveur VRM et des serveurs VR.

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

Pour mettre à jour les serveurs VRM à l'aide de l'interface VAMI :

  1. Mettez à niveau SRM Server et le client vers SRM 5.0.3.
  2. Accédez à l'interface de configuration du serveur VRM sur le site https:// VRM_IP_address:8080.
  3. Connectez-vous à l'interface de configuration du serveur VRM en tant qu'utilisateur racine.
  4. Cliquez sur l'onglet Mettre à jour.
  5. Cliquez sur Paramètres.
  6. Sélectionnez Utiliser le référentiel spécifié et collez l'URL de la mise à jour dans la zone de texte URL du référentiel :
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/1.0.3.0
    REMARQUE : Pour obtenir l'URL de mise à niveau via l'interface VAMI pour une version de correctif vSphere Replication 1.0.3.x, consultez l'article de la base de connaissances sur la version de correctif Site Recovery Manager 5.0.3.x correspondante.
  7. Cliquez sur Statut.
  8. Cliquez sur Vérifier les mises à jour. L'outil de recherche de mise à jour indique que la version 1.0.3.0 est disponible.
  9. Cliquez sur Installer les mises à jour, puis sur OK.
  10. Lorsque la mise à jour est effectuée, sélectionnez l'onglet VRM, cliquez sur Configuration puis sur Redémarrer pour redémarrer le serveur VRM.
  11. Répétez cette procédure pour le serveur VRM sur le site de récupération.

Pour mettre à jour les serveurs VR à l'aide de l'interface VAMI :

  1. Mettez à niveau le serveur VRM.
  2. Accédez à l'interface de configuration du serveur VR sur le site https:// adresse_VR:5480.
  3. Connectez-vous à l'interface de configuration du serveur VR en tant qu'utilisateur racine.
  4. Cliquez sur l'onglet Mettre à jour.
  5. Cliquez sur Paramètres.
  6. Sélectionnez Utiliser le référentiel spécifié et collez l'URL de la mise à jour dans la zone de texte URL du référentiel :
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/9f73d994-d8b5-11df-ace9-18a9053dae02/1.0.3.4117
    REMARQUE : Pour obtenir l'URL de mise à niveau via l'interface VAMI pour une version de correctif vSphere Replication 1.0.3.x, consultez l'article de la base de connaissances sur la version de correctif Site Recovery Manager 5.0.3.x correspondante.
  7. Cliquez sur Statut.
  8. Cliquez sur Vérifier les mises à jour. L'outil de recherche de mise à jour indique que la version 1.0.3 est disponible.
  9. Cliquez sur Installer les mises à jour, puis sur OK.
  10. Lorsque la mise à jour est effectuée, sélectionnez l'onglet Système, cliquez sur Information puis sur Redémarrer pour redémarrer le serveur VR.
  11. Répétez ce processus pour tous les serveurs VR sur le site protégé et sur le site de récupération.

Mise à niveau de SRM 4.1.2 vers SRM 5.0.3

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

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

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

Composants Open Source

Les déclarations de droits d'auteur et les licences applicables aux composants logiciels Open Source distribuées dans vCenter Site Recovery Manager 5.0.3 sont disponibles sur le site de téléchargements de SRM. 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

  • ESXi Server 5.0 ne prend pas en charge la personnalisation du système d'exploitation invité de machines virtuelles qui exécutent Windows 8 ou Windows Server 2012.
    La prise en charge de la personnalisation du système d'exploitation invité de machines virtuelles Windows 8 et Windows Server 2012 est disponible avec ESXi Server 5.0 u2 et versions ultérieures. Si vous exécutez ESXi Server 5.0.x sur le site protégé et ESXi Server 5.0 sur le site de récupération, les tests de récupération et les récupérations réelles échouent, car ESXi Server 5.0 sur le site de récupération ne peut pas exécuter le processus de démarrage de Windows 8 ou Windows Server 2012. La machine virtuelle sur le site de récupération n'affiche pas l'écran de connexion de Windows. SRM affiche un message d'erreur dans les étapes de récupération qui indique que VM Tools atteint l'expiration de son délai d'attente pendant la mise sous tension, avant l'étape de personnalisation IP.

    Solution : Mettez à niveau ESXi Server sur le site de récupération vers la version 5.0 u2 ou une version ultérieure.

  • 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.3 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. Si vous utilisez SVMotion pour transférer une machine virtuelle d'une banque de données, qui se trouve dans un groupe de protection, vers une banque de données non protégée, vous devez reconfigurer manuellement la protection de la machine virtuelle.

  • La conversion NAT (Network Address Translation) n'est prise en charge ni par le serveur SRM Server ni par le serveur vSphere Replication
    Lorsque vous configurez SRM, vous devez configurer un serveur SRM Server avec une adresse IP visible par le serveur SRM Server correspondant auquel il est associé. Voir La configuration NAT n'est pas prise en charge dans SRM.

  • Interopérabilité avec vCloud Director
    Site Recovery Manager 5.0.3 fournit une prise en charge limitée des environnements vCloud Director. Il n'est pas possible d'utiliser SRM pour protéger les machines virtuelles dans les pools de ressources vCloud (machines virtuelles déployées dans une organisation). Il est possible d'utiliser SRM pour protéger la structure de gestion de vCD. Pour plus d'informations sur l'utilisation de SRM pour protéger les instances vCD Server et vCenter Server, ainsi que les bases de données qui fournissent l'infrastructure de gestion pour vCloud Director, voir Étude de cas de résilience de l'infrastructure VMware vCloud Director.

  • Reprotection et retour arrière automatisé non pris en charge avec vSphere Replication
    Dans SRM 5.0.x, la reprotection et le retour arrière automatisé sont uniquement pris en charge avec la réplication basée sur la baie. Les machines virtuelles que vous protégez à l'aide de vSphere Replication ne peuvent pas être récupérées automatiquement sur le site d'origine en utilisant des plans de récupération existants.

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

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

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

  • Nombre maximum de plans de récupération par instance SRM Server
    Vous pouvez créer la quantité suivantes de plans de récupération par instance SRM Server :

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

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

  • Utilisation de certificats MD5 avec le serveur de gestion de vSphere Replication
    SRM 5.0.3 et vSphere Replication 1.0.3 vous permettent de configurer le serveur de gestion de vSphere Replication afin d'utiliser des certificats MD5. Toutefois, en raison de la vulnérabilité aux attaques de l'algorithme de signature du certificat MD5, vous devez utiliser, si possible, au moins SHA-1 comme algorithme de signature de certificat. Vous pouvez utiliser des certificats MD5 avec SRM 5.0.3 et vSphere Replication 1.0.3, mais vous devez commencer dès que possible à préparer votre infrastructure à utiliser au moins l'algorithme de signature de certificat SHA-1.

  • L'algorithme de signature du certificat vCenter Server par défaut est SHA256RSA. Windows Server 2003 ne prend pas en charge SHA256RSA. Pour installer SRM 5.0.3 sur Windows Server 2003, vous devez effectuer l'une des actions suivantes :

    • Installer l'un des correctifs Microsoft suivants :
    • Mettre à niveau le système d'exploitation hôte pour SRM Server vers Windows Server 2008 ou version ultérieure.
    • Vous assurer d'utiliser SHA1RSA pour vos certificats vCenter Server. Si vous n'utilisez pas SHA1RSA pour les certificats vCenter Server, vous devez mettre à niveau les certificats, ou mettre à niveau vCenter Server et SRM vers la version 5.5.

Problèmes résolus

Les problèmes suivants ont été résolus dans SRM 5.0.3.

  • NEW La version de correctifs Site Recovery Manager 5.0.3.3a résout un problème de vulnérabilité dans la librairie glibc qui 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.

    Pour plus d'informations sur l'installation de la version de correctifs Site Recovery Manager 5.0.3.3a, reportez-vous à l'article http://kb.vmware.com/kb/2144832

  • La modification ou la réparation d'une installation du serveur SRM requiert l'intervention de l'utilisateur Administrateur ou la désactivation d'UAC.

    Si vous êtes membre du groupe Administrateurs, mais non administrateur, vous devez désactiver le Contrôle de compte d'utilisateur (UAC) Windows avant de tenter de modifier ou de réparer une installation de serveur SRM depuis le panneau de configuration Windows. Si vous avez installé le serveur SRM sur un hôte Windows Server 2012, désactivez l'UAC en modifiant le registre. Ce problème a été résolu.

  • L'exécution d'une migration planifiée entraîne l'arrêt inattendu du service SRM si l'hôte est déconnecté.

    Si un hôte ESXi est déconnecté de vCenter Server et que vous exécutez la migration planifiée, le service SRM peut s'arrêter de manière inattendue à l'étape Définir le volume en lecture seule du plan de récupération. Ce problème a été résolu.

  • Des délais d'expiration surviennent avec l'erreur « Cannot find replicated datastore due to timeout of HBA rescan operation ».

    Ce problème a été résolu pour améliorer la détection de l'erreur et du message d'erreur pour les délais d'expiration durant les opérations de réanalyse de l'hôte.

  • Des volumes dupliqués apparaissent dans l'onglet Périphériques de la vue Gestionnaires de baies de l'interface utilisateur SRM.

    Ce problème se produit lorsque le numéro cible d'un LUN est le même que le numéro source d'un autre LUN. Ce problème d'interface utilisateur a été résolu.

  • La récupération d'une machine virtuelle Contrôleur de domaine (DC) Windows Server 2012 met fin au mécanisme de sauvegarde du DC.

    La récupération d'une machine virtuelle DC Windows Server 2012 est possible en utilisant une réplication basée sur la baie ou vSphere Replication. Cependant, l'exécution d'une opération de récupération sur ce type de machine virtuelle peut compromettre le mécanisme Windows Server 2012 DC SafeGuard. Ce problème a été résolu.

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

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

    • Sur certaines machines virtuelles Windows utilisant des chemins modifiés pour les dossiers temporaires, la personnalisation IP recherche au mauvais endroit les journaux de résultats. Pour plus de détails, reportez-vous à l'article KB 2021083. Ce problème a été résolu.
    • Si un journal de résultats intermédiaire était inaccessible lors de l'exécution de la personnalisation IP sur des machines virtuelles Windows, la personnalisation aboutit mais signale l'erreur Erreur - Impossible de terminer la personnalisation, probablement du fait d’une erreur d’exécution de script ou de paramètres de script non valides (Code d'erreur : -1). Les paramètres IP ont pu être appliqués en partie. Ce problème a été résolu. La personnalisation IP indique maintenant correctement l'aboutissement de l'opération.
  • Sur le site de récupération, les réanalyses des banques de données échouent en raison de périphériques de stockage non prêts.

    Les SRA peuvent envoyer des réponses à SRM avant qu'un périphérique de stockage promu sur le site de récupération ne soit disponible pour les hôtes ESXi. Lorsque SRM reçoit une réponse d'un SRA, il effectue une réanalyse des périphériques de stockage. Si les périphériques de stockage ne sont pas encore totalement disponibles, ESXi Server ne les détecte pas et SRM ne trouve pas les périphériques dupliqués lorsqu'il effectue des réanalyses. Les banques de données ne sont pas créées et les machines virtuelles récupérées sont introuvables.

    Solution : si vous rencontrez des problèmes liés à des banques de données indisponibles, SRM 5.0.3 propose un nouveau paramètre vous permettant de retarder le début des réanalyses après la promotion d'un périphérique de stockage par un SRA.

    1. Cliquez avec le bouton droit sur un site SRM et sélectionnez Paramètres avancés.
    2. Cliquez sur storageProvider.
    3. Définissez le paramètre storageProvider.hostRescanDelaySec pour retarder le début des réanalyses du stockage d'un certain nombre de secondes. Une valeur comprise entre 20 et 180 est raisonnable.
    4. Redémarrez le service SRM.

    REMARQUE : dans les versions précédentes, vous avez peut-être utilisé le paramètre storageProvider.hostRescanRepeatCnt pour introduire un délai dans les récupérations. Utilisez plutôt le nouveau paramètre storageProvider.hostRescanDelaySec.

  • La procédure de récupération personnalisée n'empêche pas la mise sous tension des machines virtuelles avant la personnalisation IP.

    Si vous insérez une étape de récupération personnalisée après l'étape « Créer un snapshot de stockage inscriptible » dans une récupération de test ou après l'étape « Modifier le stockage du site de récupération en inscriptible » dans une récupération réelle et si vous avez configuré la machine virtuelle pour la personnalisation IP, le plan de récupération n'attend pas la fin de l'étape de récupération personnalisée pour mettre sous tension la machine virtuelle. Ce problème a été résolu.

  • SRM ne parvient pas à monter des volumes VMFS et l'erreur Déjà monté s'affiche.

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

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

    Si un plan de récupération ne progresse pas, les utilisateurs peuvent choisir de réexécuter le plan de récupération. Dans de rares cas, la réexécution du plan de récupération provoque l'arrêt inattendu du serveur SRM. Après le redémarrage de SRM Server, le plan de récupération continue d'arrêter le serveur de manière inattendue. Les journaux indiquent qu'une machine virtuelle a été modifiée juste avant que le serveur SRM s'arrête, avec l'entrée de journal IP customization succeeded for VM VM Name. Ce problème a été résolu.

  • Le service SRM s'arrête après vérification du gestionnaire de licences pendant la protection d'une machine virtuelle.

    Lorsque vous configurez la protection sur une machine virtuelle, SRM Server s'arrête de façon inattendue. Les journaux contiennent l'erreur Panic : Assert Failed "found == _reservations.get<by::vm>().end() (There is already a Reservation for VM [vim.VirtualMachine: virtual_machine])". Ce problème a été résolu.

  • Le couplage des serveurs SRM échoue lorsque des certificats personnalisés sont utilisés avec VCVA.

    Le couplage des serveurs SRM lorsque des certificats personnalisés pour le serveur SRM et le dispositif virtuel vCenter Server sont utilisés échoue avec l'erreur suivante : Permission to perform this operation was denied. Ce problème a été résolu.

  • Impossible d'installer SRM 5.0.2 sur Windows Server 2012.

    Il n'était pas possible d'installer SRM Server 5.0.2 sur Windows Server 2012. Ce problème a été résolu et SRM 5.0.3 prend désormais en charge Windows Server 2012 comme système d'exploitation pour SRM Server.

  • SRM ne peut pas protéger les machines virtuelles qui disposent d'un ou plusieurs disques RDM si les machines virtuelles font partie d'un vApp.

    Si une machine virtuelle fait partie d'un vApp et si elle utilise des disques RDM, la configuration de la protection provoque l'erreur Périphérique introuvable : disque X dans l'état de protection. Dans cette erreur, disque X correspond au disque RDM connecté à la machine virtuelle. Ce problème a été résolu.

  • SRM Server s'arrête de manière inattendue pendant un nettoyage test.

    Dans de rares circonstances, SRM Server s'arrête de manière inattendue pendant le nettoyage test avec l'erreur Panic: Assert Failed .../srm/src/replication/providers/storageProvider/data/groupPostFailoverInfoData.cpp:108. Ce problème a été résolu.

  • SRM s'arrête de façon imprévue lorsqu'un système d'exploitation invité Windows envoie un message à SRM Server.

    Ce problème se produit lorsque SRM Server s'exécute sur un système d'exploitation Windows utilisant les paramètres régionaux JP, KO ou CN, et lorsque vCenter Server s'exécute avec les paramètres régionaux EN. Par exemple, lorsqu'un script lancé après la mise sous tension exécute une commande qui renvoie une erreur en caractères japonais, vCenter Server ne traduit pas ce message dans le codage approprié. SRM reçoit une exception non valide et s'arrête de façon inattendue. Ce problème a été résolu.

  • L'outil DR IP Customizer s'arrête de façon inattendue dans les systèmes d'exploitation invités Windows 2003, sans envoyer de notification.

    L'outil DR IP Customizer s'arrête de façon inattendue sur les systèmes d'exploitation invités Windows 2003. Aucune notification n'est envoyée, mais les journaux SRM indiquent l'erreur C:\WINDOWS\TEMP\vmware-SYSTEM\netshIPv6.vbs(279, 4) Microsoft VBScript runtime error: Object doesn't support this property or method: 'GUID'. Ce problème est causé par une erreur non gérée lors d'une tentative d'accès à une propriété GUID inexistante. Ce problème a été résolu.

  • L'option de mise au repos du système d'exploitation invité n'est pas disponible pour les machines virtuelles exécutant Windows Server 2012.

    Lors de la configuration de vSphere Replication sur une machine virtuelle disposant du système d'exploitation invité Windows Server 2012, l'option permettant d'activer la mise au repos du système d'exploitation invité n'est pas disponible. Ce problème a été résolu.

  • vSphere Replication supprime des fichiers de disque pour des machines virtuelles non répliquées du site cible si un fichier a le même nom que le fichier de disque répliqué.

    Si, immédiatement avant de cliquer sur le bouton Terminer dans l'assistant de configuration de la réplication, un disque avec le même nom qu'un disque répliqué apparaît dans l'emplacement de la banque de données cible, la tâche de configuration de réplication échoue, car vSphere Replication ne s'attend pas à trouver le disque là et supprime par erreur le disque qui n'a pas été créé pour cette tâche. Ce problème a été résolu.

  • Le test de basculement, la migration planifiée ou la récupération d'urgence échouent avec l'erreur Error creating ... image ... NullPointerException".

    VRMS peut ne pas recevoir de réponse de la part du serveur VR à une certaine étape du workflow de récupération d'urgence. L'opération de récupération d'urgence échoue. La tentative d'exécuter de nouveau l'opération continue d'échouer en générant l'erreur Error creating ... image ... NullPointerException". Ce problème a été résolu et les réexécutions réussissent.

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

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

  • Avec vSphere Replication, les machines virtuelles test sont supprimées si RevertSwap échoue pendant le nettoyage test.

    Si RevertSwap échoue pendant le nettoyage test, les machines virtuelles test que vSphere Replication crée sur le site secondaire sont supprimées. Les disques parents sont également supprimés. Il est alors nécessaire d'effectuer une synchronisation complète avant d'effectuer la récupération réelle. Ce problème a été résolu. Désormais, vSphere Replication désenregistre la machine virtuelle test au lieu de la supprimer, ce qui permet de ne pas supprimer les disques.

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.

  • 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 existe avec ESXi Server 5.0, mais il a été résolu dans la version 5.0 Update 1 d'ESXi Server.

    Solution : Mettez à niveau ESXi Server vers la version 5.0 mise à jour 1 ou ultérieure.

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

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

  • Impossible de reconfigurer vSphere Replication sur une machine virtuelle après la réception du message Error committing the transaction au cours de la configuration

    Si vous recevez le message Error committing the transaction au cours de la configuration de la réplication d'une machine virtuelle et que vous tentez de reconfigurer la réplication sur la machine virtuelle, l'opération échoue. Ce problème se produit car vSphere Replication ne nettoie pas correctement les données de configuration après la tentative de configuration. Par conséquent, la réplication de la machine virtuelle apparaît configurée pour vSphere Replication alors qu'elle ne l'est pas.

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

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

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

    Solution : fermez et rouvrez l'assistant d'exécution d'un plan d'un récupération après avoir désélectionné l'option de basculement forcé.

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

    Au cours d'une récupération et d'une migration, les machines virtuelles réservées sont remplacées par des machines virtuelles récupérées. Si vous disposez d'un cluster avec plusieurs hôtes sur le site de récupération, toutes les banques de données réservées doivent être disponibles pour tous les hôtes du cluster, car dans le cas contraire, la permutation des machines virtuelles échoue. SRM ne vous empêche pas de sélectionner des banques de données réservées qui ne sont pas disponibles pour tous les hôtes du cluster. Si les banques de données réservées ne sont pas visibles de tous les hôtes, le plan de récupération échoue avec l'erreur Error - Unable to access file [datastore]" Unable to access file [datastore] Failed to unregister protected VMs. Les hôtes doivent avoir accès aux banques de données qui contiennent à la fois les machines virtuelles réservées et les machines virtuelles récupérées.

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

  • Les versions du serveur VRM et du serveur VR ne sont pas mises à jour dans la synthèse des machines virtuelles après une mise à niveau

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

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

    1. Connectez-vous au site https:// Adresse_IP_serveur_VRM:8080.
    2. Sélectionnez l'onglet Mettre à jour.
    3. Cliquez sur Statut. Le numéro de version est 1.0.1.0.

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

  • Il est possible d'utiliser des bases de données non prises en charge avec le serveur de gestion vSphere Replication

    Vous pouvez configurer le serveur de gestion vSphere Replication (serveur VRM) pour utiliser des bases de données non prises en charge ; la configuration du serveur VRM s'effectue sans avertissement quant à la prise en charge des bases de données. Toutefois, l'utilisation d'une base de données non prise en charge peut générer un comportement imprévisible. Les bases de données suivantes ont été intégralement testées et sont prises en charge par le serveur VRM :

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

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

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

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

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

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

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

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

  • Les événements ne s'affichent pas correctement avec 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. De ce fait, des messages XXXs'affichent au lieu des messages de SRM Server. Pour résoudre ce problème, créez une copie du dossier enqui se trouve dans C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\. Renommez le dossier de envers koet redémarrez vCenter Server et les services SRM.

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

  • La reprotection échoue après la suppression de l'hôte déconnecté sur le site protégé.

    Si vous supprimez un hôte déconnecté du site protégé après une opération de récupération, puis que vous exécutez la reprotection, cette opération peut échouer en générant l'erreur Internal error: std::exception 'class Vmacore::Exception".

    Solution : réexécutez la reprotection en sélectionnant l'option Forcer le nettoyage.

  • SRM panique au démarrage et à d'autres moments aléatoires.

    Suite à un problème dans vCenter Server, SRM Server peut s'arrêter de manière inattendue en générant l'erreur panic 'Default' opID=7b0e972e] Duplicate key 'key-vim.host.ScsiDisk-020002000050002ac0000f0c70565620202020' in linkable vim.host.ScsiDisk referenced by field scsiLun (wsdl name scsiLun). Ce problème provient de l'erreur vCenter Server décrite dans l'article http://kb.vmware.com/kb/2033163.

    Solution : Supprimez les hôtes de l'inventaire vCenter Server, puis ajoutez-les de nouveau.

  • La première tentative de connexion à l'interface SRM échoue après installation sur Windows Server 2012.

    Si vous installez SRM Server sur Windows Server 2012, la première tentative de connexion à l'interface SRM échoue en générant des messages d'erreur, indiquant que le serveur distant prend trop de temps pour répondre. Ce problème survient uniquement lors de la première tentative de connexion à SRM après son installation sur Windows Server 2012.

    Solution : Fermez, puis ouvrez de nouveau vSphere Client. Reconnectez-vous ensuite à SRM.