Prenez le contrôle de votre environnement multicloud

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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 le serveur SRM. Pour résoudre ce problème, installez le certificat pour l'autorité de certification signant le certificat SRM en utilisant la console de gestion Microsoft. Après avoir installé le certificat, effectuez une opération Modifier de l'installation de SRM de façon à fournir de nouveau le certificat généré par l'utilisateur.

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.

Durant la configuration de vSphere Replication, lorsqu'une banque de données est sélectionnée sur une version prise en charge d'ESX, le message Le server VR Server Name n'a aucun hôte permettant d'accéder à la banque de données de destination...s'affiche. Cela se produit lors de l'ajout d'un nouvel hôte à vCenter Server ou durant l'enregistrement du serveur vSphere Replication, s'il y a une interruption temporaire de la communication entre le dispositif vSphere Replication et le serveur vSphere Replication. Les problèmes de communication surviennent généralement en raison d'une perte temporaire de la connectivité ou de l'arrêt des services du serveur.

Pour résoudre ce problème, redémarrez le service du serveur de gestion vSphere Replication.

1. Connectez-vous à l'interface VAMI (Virtual Appliance Management Interface) du dispositif vSphere Replication à l'adresse https://vr_applliance_address:5480.
2. Cliquez sur Configuration > Redémarrer sous État du service.

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

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.

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.

Consultez l'article KB 1009801 .

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 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 en vous aidant de l'article 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.

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 pas communiquer avec vCenter Server.

Solution :

1. Installez le correctif logiciel Microsoft depuis l'article 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.

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

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

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.

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.

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

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

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 de délai d'expiration par défaut est 2 heures.

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

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

Solution : Aucune.

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.

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.

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.

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.

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.

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

Solution :

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

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.

Si vous avez installé SRM au moyen de l'option CUSTOM_SETUP, par exemple pour créer une configuration de site de récupération partagé, toute tentative d'exécution du programme d'installation de SRM en mode modification à partir de la ligne de commande avec l'option CUSTOM_SETUP produit l'erreur CUSTOM_SETUP command line not supported when standard installation already exists.

Solution : utilisez le Panneau de configuration de Windows pour lancer le programme d'installation de SRM en mode modification.

Si ESXi Server est déconnecté de vCenter Server sur le site protégé ou s'il perd la connexion avec vCenter Server en raison d'un problème, SRM s'arrête de façon inattendue si vous tentez d'effectuer une migration planifiée. La migration planifiée échoue avec une erreur.

Solution : reconnectez le serveur ESX Server.