Notes de version de PlateSpin Migrate 12.1

Option pour définir le type de génération de machine virtuelle cible Hyper-V

PlateSpin Migrate 12.1 introduit une option de configuration Type de génération de la machine virtuelle pour les machines virtuelles situées sur des hôtes Hyper-V. Cette option vous permet de sélectionner un des types de génération suivants pour la nouvelle machine virtuelle :

Reportez-vous à la section Configuration de machine virtuelle : Microsoft Hyper-V du Guide de l'utilisateur de PlateSpin Migrate 12.1.

Option de définition de l'ID de réseau virtuel pour une machine virtuelle cible sur un hôte Hyper-V

PlateSpin Migrate 12.1 introduit une nouvelle option ID du VLAN qui permet de spécifier l'ID de réseau virtuel à utiliser sur la machine virtuelle cible située sur un hôte Hyper-V. Si vous ne spécifiez pas cet ID, l'ID de réseau virtuel de la machine source est utilisé par défaut.

Pour plus d'informations, reportez-vous à la section Réseau de post-migration pour les interfaces réseau virtuelles (Windows et Linux) du Guide de l'utilisateur de PlateSpin Migrate 12.1.

Option de modification du type d'adaptateur utilisé lors du processus de prise de contrôle cible d'une migration de workloads vers une machine virtuelle cible sur un hôte Hyper-V

PlateSpin Migrate 12.1 permet de modifier le type d'adaptateur utilisé lors du processus de prise de contrôle cible d'une migration de workloads vers une machine virtuelle cible sur un hôte Hyper-V.

Pour plus d'informations, reportez-vous à la section Modification du type d'adaptateur utilisé lors du processus de prise de contrôle cible dans le cadre de la migration de workloads vers une machine virtuelle cible située sur un hôte Hyper-V du Guide de l'utilisateur de PlateSpin Migrate 12.1.

La suppression d'une cible ne déclenche pas l'affichage d'une boîte de dialogue de confirmation dans un navigateur en allemand

Problème : si l'option de langue de votre navigateur Web est définie sur l'allemand, l'interface Web n'affiche pas de boîte de dialogue de confirmation lorsque vous cliquez sur Supprimer en regard d'une cible dans la liste Cibles. Ce problème concerne à la fois les cibles VMware et les cibles Azure. L'interface Web affiche la boîte de dialogue de confirmation de suppression de la cible pour les navigateurs Web dont la langue est définie sur l'anglais ou sur une autre langue nationale prise en charge (français, japonais, chinois simplifié et chinois traditionnel). (Bogue 978490)

Solution : si vous utilisez un navigateur en allemand, soyez prudent lorsque vous choisissez de supprimer des cibles. Vous pouvez également modifier le paramètre de la langue du navigateur Web de manière à utiliser une autre langue prise en charge.

L'aide sur les paramètres régionaux chinois s'affiche en anglais

Dans les paramètres régionaux chinois, l'aide s'affiche en anglais.

Le test de transition échoue lorsque le paramètre de nom d'hôte sur la page de configuration d'un workload Linux cible contient un caractère de soulignement

Problème : pour les workloads Linux cibles, si le nom d'hôte spécifié sur la page de configuration contient un caractère de soulignement, le test de transition échoue avec le message suivant :

Échec de la configuration de la machine virtuelle

(Bogue 975854)

Solution : l'utilisation d'un trait de soulignement dans le nom d'hôte n'est généralement pas prise en charge par les plates-formes Linux. Modifiez le nom d'hôte de manière à utiliser uniquement des caractères pris en charge : les lettres de a à z, les chiffres de 0 à 9 et le trait d'union (-). Ensuite, réessayez.

La réplication incrémentielle basée sur des fichiers ne se termine pas lorsque le codage est activé

Problème : une fois le codage activé pour un workload Windows configuré pour le transfert de données basé sur les fichiers, le récepteur Windows peut se bloquer à la fin du transfert pour les réplications incrémentielles. La suspension se produit si le dernier octet du transfert est mal défini par le processus de codage sur une valeur autre que zéro, ce qui indique que d'autres fichiers sont en cours de transfert et qu'il faut poursuivre la lecture à partir du flux. (Bogue 944559)

Solution : vous pouvez utiliser le transfert de données par bloc pour les workloads Windows si vous souhaitez activer le codage pour les transferts de données de réplication.

Le message de validation dans l'interface Web ne s'affiche pas après l'exécution de la suppression d'un workload avec l'option Conserver la source

Problème : après avoir supprimé un workload avec les options Supprimer le workload et Conserver la source, le workload découvert se trouve dans un état Non configuré et l'emplacement cible est nettoyé. L'historique de validation se rapporte uniquement à l'opération la plus récente, à savoir Supprimer le workload. L'historique de validation pour la précédente découverte de workload n'est plus disponible. (Bogue 971118)

Solution : avant de supprimer le workload, notez les informations de la validation de la découverte en réalisant une capture d'écran ou en copiant le message à un autre emplacement.

L'installation échoue lorsque la langue et les paramètres régionaux du système d'exploitation ne correspondent pas sur l'ordinateur

Problème : si vous choisissez d'installer PlateSpin Migrate sur un ordinateur sur lequel le paramètre de langue du système d'exploitation ne correspond pas aux paramètres régionaux de ce dernier, l'installation échoue. (Bogue 939805)

Solution : pour installer correctement PlateSpin Migrate, assurez-vous que le paramètre de langue du système d'exploitation correspond aux paramètres régionaux de ce dernier sur l'ordinateur. Une fois l'installation terminée, vous pouvez modifier les paramètres régionaux de l'ordinateur conformément à vos besoins.

Par exemple, si le paramètre de langue du système d'exploitation est l'anglais, vous devez vous assurer que les paramètres régionaux du système d'exploitation sont également définis sur l'anglais lorsque vous installez la version anglaise ou une version localisée de PlateSpin Migrate. Une fois l'installation terminée, vous pouvez modifier les paramètres régionaux conformément à vos besoins.

L'option d'installation des pilotes par bloc au cours de la préparation de la réplication est activée lors de la configuration de la migration de workload même si les pilotes par bloc sont déjà installés

Problème : lorsque vous configurez la migration pour un workload sur lequel des pilotes par bloc sont déjà installés, l'option Installer pendant la préparation de la réplication du paramètre Méthode de transfert est activée et sélectionnée par défaut. Cette option doit être désactivée, car les pilotes par bloc sont déjà installés. Cela ne nuit toutefois pas à la fonctionnalité. (Bogue 967018)

Solution : ignorez l'option.

Comportement incohérent entre les cibles Azure et VMware en cas de désélection du groupe de volumes LVM mais pas du volume logique correspondant

Problème : pour un workload Linux avec LVM, si vous désélectionnez le groupe de volumes, mais pas le volume logique correspondant, le comportement est incohérent pour les cibles suivantes :

(Bogue 973926)

Solution : si vous désélectionnez un groupe de volumes, vous devez également désélectionner son volume logique correspondant.

L'assignation de volumes n'est pas prise en charge lors de la migration de workloads Linux

Problème : lorsque vous utilisez le client PlateSpin Migrate pour migrer des workloads Linux, les opérations suivantes ne sont pas prises en charge : (Bogue 930355)

Impossible de faire migrer des workloads Linux comportant des volumes créés sur des disques bruts (RAW) sans partitions

Problème : PlateSpin Migrate ne prend pas en charge la migration de workloads Linux comportant des volumes créés sur des disques bruts (RAW) sans partitions. (Bogue 937071)

Impossible de migrer un workload vers une partition LPAR Hitachi

Problème : lorsque vous migrez un workload vers une partition LPAR Hitachi sur laquelle un système d'exploitation est en cours d'exécution, il se peut que la migration échoue. Cela est dû au fait que la tâche de migration attend une intervention de l'utilisateur au cours de l'étape Configuration de la machine cible de la procédure de migration. (Bogue 902489)

Solution : modifiez l'ordre de démarrage UEFI du LPAR Hitachi pour qu'il puisse se lancer à partir du disque dur plutôt que de l'image ISO.

Affichage d'un message d'avertissement lors de la migration d'un workload vers une partition LPAR Hitachi

Problème : lorsque vous migrez un workload vers une partition LPAR Hitachi, il se peut qu'un message d'avertissement semblable à celui-ci s'affiche : (Bogue 917209)

Le périphérique 'Périphérique FC partagé Hitachi non assigné 3017' n'est pas pris en charge par .......

Solution : ignorez le message.

Impossible d'installer PlateSpin Migrate sur un ordinateur Windows Server 2012 ou Windows Server 2012 R2

Problème : sur un ordinateur Windows Server 2012 ou Windows Server 2012 R2, si vous désactivez le contrôle de compte d'utilisateur (UAC) par le biais du Panneau de configuration et installez ensuite PlateSpin Migrate, l'utilitaire de vérification de la configuration requise affiche un message d'erreur indiquant que ce contrôle est toujours activé. Cela est dû au fait que lorsque vous désactivez le contrôle de compte d'utilisateur (UAC) par le biais du Panneau de configuration, la modification n'est pas répercutée dans la clé de Registre correspondante. (Bogue 929511) 

Solution : pour désactiver le contrôle de compte d'utilisateur sur un ordinateur Windows Server 2012 ou Windows Server 2012 R2, reportez-vous à l'article « Windows Server 2012: Deactivating UAC » (Windows Server 2012 : désactivation du contrôle de compte d'utilisateur) du wiki de Microsoft TechNet.

Le conteneur Hyper-V découvert s'affiche en tant que workload dans l'interface Web de PlateSpin Migrate

Problème : si vous utilisez l'interface Web de PlateSpin Migrate pour découvrir un conteneur Hyper-V, ce dernier est répertorié en tant que workload dans l'interface. Vous ne devez pas faire migrer ce conteneur Hyper-V. (Bogue 929978) 

Solution : vous ne devez pas migrer ce conteneur Hyper-V.

Impossible de migrer un workload Linux vers un conteneur qui ne prend pas en charge le microprogramme de workload source

Problème : la migration d'un workload Linux échoue dans les cas suivants, car la conversion UEFI vers BIOS, et inversement, n'est pas prise en charge :(Bogue 937070)

(Sources Windows) Les paramètres VSS par volume autres que par défaut ne sont pas conservés après la migration

Problème : les paramètres VSS par volume autres que par défaut ne sont pas conservés après la migration d'un workload Windows. (Bogue 493589)

Solution : après la migration, vous devez reconfigurer vos paramètres VSS personnalisés.

(ESX 4.1) Pas d'avertissement ni de message d'erreur en cas de sélection incorrecte des UC virtuelles

Problème : si le nombre d'UC virtuelles (vCPU) demandées dépasse celui des UC physiques sur l'hôte ESX 4.1, le nombre demandé est ignoré et la machine virtuelle cible est créée avec une seule vCPU sans avertissement. (Bogue 505426) 

Solution : assurez-vous que votre sélection de vCPU ne dépasse pas le nombre d'UC physiques sur le serveur hôte ESX 4.1.

La présence de caractères spéciaux dans le nom d'une banque de données entraîne des problèmes de migration

Problème : les opérations de migration risquent d'échouer lors de tentatives sur des banques de données ESX dont le nom contient le caractère « + » ou d'autres caractères spéciaux. (Bogue 506154) 

Reportez-vous à l'article de la base de connaissances n° 7009373.

La conservation de la partition de démarrage entraîne des problèmes de migration

Problème : dans certains scénarios de migration, le système vous permet à tort de conserver votre partition de démarrage sur la cible, empêchant alors le démarrage du workload approprié. (Bogue 595490) 

Solution : choisissez de ne pas conserver votre partition de démarrage sur la cible.

(Linux vers ESX 4) Problème d'exécution de la migration si les fonctions de connexion ou de montage CD automatique sont activées pour le système d'exploitation source

Problème : lorsque les fonctions de connexion ou de montage CD automatique sont activées sur le système d'exploitation source, la migration est affectée. la migration est également perturbée si vous vous connectez à la cible durant l'étape de configuration de la tâche. (Bogue 604320) 

Solution : désactivez les fonctions de connexion et de montage CD automatiques sur la source ; évitez de vous connecter au workload cible tant que la migration n'est pas terminée.

Échec de l'exécution d'un script post-migration comportant des caractères Unicode dans le nom de fichier

Problème : si vous utilisez des caractères Unicode dans le nom de fichier de votre script post-migration, l'exécution de celui-ci échoue. (Bogue 619942) 

Solution : utilisez uniquement des caractères ASCII dans les noms d'opérations post-migration.

Instantanés VSS non conservés

Problème : les instantanés VSS pris par des applications tierces sur le workload source ne sont pas répliqués sur la cible lors de la migration. (Bogue 692680) 

Lenteur de la migration via le réseau WAN si l'hôte de machine virtuelle cible compte un nombre élevé de banques de données

Problème : dans certaines circonstances, lorsque votre serveur Migrate est connecté à l'hôte de machine virtuelle via un réseau WAN et si l'hôte en question compte un nombre important de banques de données, le processus de localisation de l'image ISO appropriée requise pour le démarrage de la cible risque de durer plus longtemps que prévu. (Bogue 702152) 

Solution : pour optimiser la bande passante disponible, planifiez la migration pour qu'elle ait lieu en dehors des heures de trafic intense.

Le répertoire privé non assigné est désactivé et n'est pas monté après une synchronisation unique des serveurs

Problème : si vous effectuez une synchronisation des serveurs avant d'annuler l'assignation de la partition /home vers none, le répertoire /home est désactivé et n'est pas monté sur le serveur cible alors qu'il devrait y être activé et monté. (Bogue 779194) 

Solution : après la synchronisation des serveurs, annulez les marques de commentaire de la ligne appropriée dans le fichier /etc/fstab du serveur cible. Reportez-vous à l'article de la base de connaissances n° 7014638.

Les outils VMware ne sont pas installés au cours de la conversion d'un noyau Windows Server 2012

Problème : les outils VMware ne sont pas installés au cours de la conversion d'un noyau Windows Server 2012 (Bogue 810460)

Solution : installez les outils VMware manuellement après la conversion.

La carte réseau n'est pas initialisée sur la machine virtuelle cible SLES 11 hébergée sur un hôte Windows Server 2008 Hyper-V

Problème : si vous effectuez une migration de workload SLES 11 (machine virtuelle clonée) à l'aide d'une méthode semi-automatique vers une machine virtuelle cible (non physique) sur un hôte Windows Server 2008 Hyper-V, le processus se bloque durant l'étape de configuration du système d'exploitation. (Bogue 822601) 

Solution : reportez-vous à l'article n° 7012911 de la base de connaissances.

La machine virtuelle cible ne démarre pas après une migration de VMware ESX vers Citrix Xen si les fichiers de démarrage sont situés sur un disque secondaire

Problème : lorsqu'une machine virtuelle est convertie de VMware ESX vers Citrix Xen et que ses fichiers de démarrage sont alloués à un disque secondaire, la machine virtuelle ne démarre pas et une intervention manuelle est requise. Cela est dû au fait que la machine virtuelle Citrix XEN tente de démarrer avec le disque 0 plutôt qu'avec les fichiers de démarrage alloués au disque 2. (Bogue 824724) 

Solution : pour résoudre ce problème, réorganisez l'emplacement du disque virtuel dans XenCenter pour que la machine virtuelle démarre à partir du disque virtuel contenant le système d'exploitation. L'article de la base de connaissances du site Web de Citrix contient des informations sur la modification de l'emplacement du disque virtuel contenant le système d'exploitation. Reportez-vous à l'article n° 7012906 de la base de connaissances.

Les outils XenServer ne sont pas supprimés après la conversion

Problème : les outils XenServer d'une machine virtuelle Windows dans un environnement d'hyperviseur Citrix XenServer ne sont pas supprimés lorsque la machine virtuelle est convertie en conteneur VMware ou en conteneur physique. (Bogue 825016) 

Solution : désinstallez manuellement les outils XenServer après la conversion.

La partition primaire est convertie en partition logique sur la cible après la migration

Problème : prenons le scénario suivant :

Scénario : déplacement ou copie d'une machine Windows avec plus de trois partitions primaires vers une machine physique Windows dotée d'au moins trois partitions primaires. Au moins une partition primaire est préservée sur la machine cible. (Bogue 825434)

Effet : après la migration, la machine Windows ne peut plus démarrer.

Exemple : l'erreur suivante se produit lorsqu'une machine Windows Server 2003 est convertie en machine physique.

Windows could not start because the following file is missing or corrupt:
<Windows root>\system32\ntoskrnl.exe.Please re-install a copy of the above file.

Solution : reportez-vous à l'article n° 7012913 de la base de connaissances.

La découverte d'un noeud de machine sur un hôte ESX n'est pas annulée lorsque Migrate annule la découverte d'une machine

Problème : lorsque vous annulez la découverte d'un workload, son affichage est rafraîchi dans le client Migrate, mais pas sur l'hôte ESX (Bogue 826545)

Solution : annulez la découverte du workload sur l'hôte ESX, puis rafraîchissez l'hôte ESX.

Échec de la tentative de récupération de données à partir du serveur VMware vCenter

Problème : une tentative de récupération de données à partir du serveur VMware vCenter échoue avec une exception indiquant que l'opération n'est pas autorisée. (Bogue 839329)

Solution : vous pouvez corriger ce problème en suivant les procédures de définition des rôles VMware à l'aide d'outils comme indiqué dans la section Utilisation d'outils pour définir des rôles VMware du Guide de l'utilisateur de PlateSpin Migrate 12.1. 

La conversion V2P est suspendue au niveau de l'étape de configuration du système d'exploitation

Problème : lorsqu'il existe plusieurs options de démarrage dans le microprogramme et que le disque dur n'est pas le premier périphérique de démarrage dans la liste d'options de démarrage, la machine cible ne démarre pas à partir du disque dur et la conversion est suspendue. (Bogue 859440)

Solution : dans les options de démarrage de la machine physique, modifiez l'ordre de démarrage pour que le Disque dur soit la première option, puis redémarrez la machine. Reportez-vous également à l'article n° 7014623 de la base de connaissances.

Échec de la conversion UEFI vers BIOS pour un workload Windows 8.1 au niveau de l'étape d'envoi de fichiers

Problème : l'installation OEM par défaut de Windows 8.1 (UEFI) crée une partition de récupération dotée d'un espace disponible insuffisant, ce qui rend impossible la création d'un cliché instantané de volume (VSS) pour la partition. (Bogue 864325)

Solution : supprimez ou développez la partition de récupération. Reportez-vous à l'article n° 7014696 de la base de connaissances.

Échec de la conversion durant la mise à niveau du microprogramme UEFI vers le microprogramme BIOS

Problème : la conversion d'un workload UEFI (Windows 6.2 et versions de kernel supérieures) vers une machine BIOS échoue au niveau de l'étape de préparation du système d'exploitation, car la partition active est introuvable pour la mise à jour des paramètres de démarrage. (Bogue 864326)

Solution : mettez à jour le type de partition de disque comme MBR où le volume système est présent dans le workload source ou dans l'image. Utilisez les options d'interface utilisateur Exporter et Importer ou un navigateur OFX pour modifier le fichier XML. Pour obtenir une liste de toutes les étapes, reportez-vous à l'article n° 7014637 de la base de connaissances.

Le transfert de fichiers est interrompu pour le workload UEFI Windows Server 2012 R2

Problème : le transfert de fichiers X2P de Windows 6.2 (et versions de kernel supérieures) échoue au niveau de l'étape d'envoi et de réception des fichiers. (Bogue 865570)

Solution : pour forcer le transfert de fichiers dans ce scénario X2P, désactivez les indicateurs d'UC avancés dans le microprogramme, à savoir VT-d, VT-s et Execute Disable Bit. Reportez-vous à l'article de la base de connaissances n° 7014698.

Échec de la capture d'image d'un système d'exploitation Windows 32 bits

Problème : Migrate prévoit la présence d'un dossier nommé C:\Windows\Boot\EFI sur le serveur source, pour exporter les contenus en vue de leur utilisation future. Ce dossier n'est pas inclus dans les systèmes d'exploitation Windows 32 bits antérieurs à Windows Server 2008 ou Windows Vista. Donc, lorsque Migrate exporte les informations BCD vers le dossier, l'opération échoue avec l'erreur :

Message d'erreur : Échec : C:\Windows\Boot\EFI

(Bogue 866467)

Solution : créez le dossier C:\Windows\Boot\EFI, puis créez un répertoire de jonction sous C:\Windows pour C:\Windows\System32. Reportez-vous à l'article n° 7014710 de la base de connaissances.

La machine source reste à l'état « Sous contrôle » après la conversion hors ligne

Problème : si vous configurez le paramètre End State d'une tâche de conversion hors ligne sur Restart, la machine source reste à l'état under control une fois la tâche terminée. (Bogue 875562)

Solution : redémarrez la source manuellement à la fin de la conversion.

La configuration du démarrage de la machine source n'est pas restaurée après la conversion hors ligne

Problème : le menu de démarrage de la machine source Windows n'est pas restauré après une conversion hors ligne. (Bogue 878043)

Solution : après la conversion, le menu de démarrage de la source affiche deux options : le disque virtuel Linux (LRD) et le système d'exploitation (OS). Lors du premier démarrage après la conversion, sélectionnez manuellement l'option OS. Cela permet de purger le menu de démarrage de l'option de démarrage LRD pour les futures opérations de démarrage.

La création et le déplacement d'une machine virtuelle sous une réserve de ressources en tant que paramètre ne sont pas pris en charge dans l'outil CLI

Problème : actuellement, l'outil d'interface de ligne de commande (CLI) ne prend pas en charge le déplacement ou la création d'une machine virtuelle sous une réserve de ressources en tant que paramètre dans le fichier conversion.ini. (Bogue 891690)

Solution : après la conversion, déplacez manuellement la nouvelle machine vers la réserve de ressources souhaitée.

Les partitions ne sont pas montées sur des lettres d'unité après la conversion

Problème : après une conversion vers Windows Server 2012 R2 Hyper-V, seule l'unité « C » est visible. Les autres partitions ne sont pas montées sur des lettres d'unité.(Bogue 894623)

Solution : après la conversion, accédez à la gestion des disques et assignez manuellement les lettres d'unité aux partitions.

L'ajout d'une assignation de disques et de volumes ne fonctionne pas correctement pour la conversion d'un workload vers Windows Server 2012 R2 Hyper-V

Problème : le démarrage de la machine virtuelle Windows Server 2012 R2 Hyper-V avec LRD renvoie des périphériques répertoriés de manière aléatoire dans la liste des périphériques du disque dur, qu'il s'agisse d'IDE, de SCSI ou d'une combinaison des deux. (Bogue 896584)

Solution : la liste doit contenir d'abord les disques IDE, puis les disques SCSI. Utilisez le client Migrate pour personnaliser la liste.

Les scénarios suivants illustrent le comportement de la liste. Hypothèses dans ces scénarios : il s'agit d'une machine virtuelle de génération 1. Vous devez créer trois lecteurs de disque virtuel ou plus.

Scénario 1-- Comportement d'IDE à SCSI

Paramètre initial donné :

• Disque 2 : IDE
• Disque 3 : IDE

Scénario 2-- Comportement de SCSI à IDE

Paramètre initial donné :

• Disque 2 : SCSI
• Disque 3 : SCSI

Présence de disques redondants après une migration par bloc de RHEL 6.2 x64 vers Windows Server 2012 R2 Hyper-V

Problème : après une migration par bloc réussie de RHEL 6.2 x64 avec l'option Installer les services d'intégration sélectionnée, l'exécution de la commande fdisk -l montre des disques redondants. Autrement dit, un disque unique s'affiche deux fois, en tant que sda et sdb. (Bogue 896598)

Solution : il s'agit d'un problème Microsoft connu, en cours de résolution.

Conditions pour la prise en charge des grappes DRS VMware

Problème : PlateSpin Migrate prend en charge les grappes VMware, indépendamment de l'activation ou non de DRS et quel que soit le niveau d'automatisation de ce dernier (Manuel, Partiellement automatisé ou Entièrement automatisé). Toutefois, pour être une cible de migration valide, votre grappe VMware doit être découverte via vCenter ; elle ne peut pas être découverte en réalisant directement un inventaire des différents serveurs ESX. (Bogue 896598)

Reportez-vous à la section Instructions de découverte des types de machine et des références du Guide de l'utilisateur.

Échec de l'installation du serveur d'images PlateSpin lorsque le chemin complet du fichier image comporte plus de 248 caractères

Problème : si vous choisissez de désigner une machine comme serveur d'images PlateSpin et spécifiez le chemin complet d'un fichier image qui comporte plus de 248 caractères, l'installation du serveur d'images échoue. (Bogue 967414)

Solution : assurez-vous que le chemin complet du fichier image spécifié ne contient pas plus de 248 caractères.

La tâche de conversion ne parvient pas à configurer les cartes d'interface réseau sur une machine cible Windows 2000 Server

Problème : si vous décidez de migrer une source Windows 2000 Server qui a une ou plusieurs cartes d'interface réseau, la tâche de conversion ne parvient pas à configurer ces dernières sur la machine cible. (Bogue 971414)

Solution : configurez manuellement les cartes d'interface réseau une fois la tâche de conversion terminée.

La redécouverte du serveur ESX dans le client Migrate affiche une entrée de serveur en double avec un message d'erreur « L'ajout a échoué » dans l'interface Web

Problème : lorsque vous utilisez le client Migrate pour découvrir un serveur ESX directement ou via le serveur vCenter, le serveur découvert est répertorié dans l'interface Web. Si vous redécouvrez le même serveur ESX via le client Migrate, une entrée en double du serveur s'affiche dans l'interface Web avec une erreur L'ajout a échoué. (Bogue 975870)

Solution : supprimez l'entrée de serveur en double dans l'interface Web.

Une réplication complète planifiée ne démarre pas à l'heure prévue

Problème : dans PlateSpin Migrate 12.0, il peut arriver dans certaines circonstances qu'une planification définie pour une réplication complète ne soit pas respectée. (Bogue 971849)

Solution : après avoir effectué la mise à niveau de la version 12.0 Hotfix 1 vers la version 12.1, certaines planifications existantes peuvent être dans un état endommagé. Si le champ Prochaine réplication indique une planification vide, vous devez reconfigurer la planification pour ce workload. Les planifications définies dans PlateSpin 12.1 seront respectées.

Échec de la transition pendant les opérations de partitionnement

Problème : une condition de concurrence peut se produire au cours du partitionnement de disque lorsque PlateSpin Migrate tente de lire la table de partition avant que l'utilitaire npart ait renvoyé toutes les informations de partition. Cette condition entraîne l'échec de la transition avec le message suivant :

Unable to find a device to map the Windows volume (Impossible de trouver un périphérique pour assigner le volume Windows)

(Bogue 959079)

Solution : exécutez à nouveau la transition.

Les connexions réseau sur la machine virtuelle cible risquent de ne pas être assignées au bon réseau ou sous-réseau virtuel Azure

Problème : si vous migrez un workload Windows qui possède plusieurs cartes d'interface réseau avec DHCP vers Azure, la connexion réseau sur la machine virtuelle cible risque de ne pas être assignée au bon réseau ou sous-réseau Azure.

Par exemple : imaginez que le workload source comporte trois cartes d'interface réseau avec DHCP et que les connexions réseau sont assignées comme suit :

Après la migration, les connexions réseau sur la machine virtuelle cible risquent d'être assignées comme suit :

(Bogue 967316)

Solution : vous ne pouvez pas utiliser le workload cible dans cet état. Vous devez supprimer le workload cible défectueux, puis répéter la configuration de la migration et la transition. Une deuxième tentative réussit généralement à assigner correctement les cartes réseau DHCP à leur bon réseau ou sous-réseau virtuel Azure.

Après une transition réussie, l'interface utilisateur Web du portail Azure doit afficher le nom de l'ordinateur et le nom DNS de la machine virtuelle cible

Problème : dans le portail Microsoft Azure, les champs DNS name (Nom DNS) et Properties (Propriétés) > COMPUTER NAME (NOM DE L'ORDINATEUR) du workload sont vides. (Bogue 969489)

Solution : utilisez l'option Bureau à distance pour vous connecter à l'ordinateur, puis ouvrez le Panneau de configuration à la page Système pour afficher le nom de l'ordinateur et le nom DNS du workload.

Les machines virtuelles cibles Azure sont créées avec un disque dur supplémentaire

Problème : Azure ajoute automatiquement un disque à la machine virtuelle qui n'est pas montée avec la lettre d'unité. La taille de ce disque varie en fonction de l'instance Cloud que vous choisissez pour le déploiement. (Bogue 967314)

Solution : vous pouvez supprimer le disque Azure supplémentaire de la configuration de la machine virtuelle.

Pour la taille maximale de l'instance Azure, une vérification de l'interface utilisateur est requise afin de limiter les disques de données pour la réplication à 63

Problème : PlateSpin Migrate prend en charge des tailles de machine virtuelle Azure comportant jusqu'à 64 disques de données. Pour la taille maximale d'instance, Migrate utilise un seul disque de données pour la réplication de disque de système d'exploitation dans l'environnement de réplication PlateSpin. Après la migration, ce disque devient le disque de système d'exploitation et vous pouvez lui ajouter un disque de données. Si vous soumettez un workload source pour réplication avec 64 disques de données, l'interface utilisateur n'affiche aucun avertissement et la réplication échoue. (Bogue 972053)

Solution : pour la taille maximale d'instance Azure, assurez-vous que votre workload source ne comporte pas plus de 63 disques de données lorsque vous soumettez le workload pour la réplication.

Une migration Azure vers Azure peut supprimer le workload source si vous sélectionnez les mêmes cible et banque de données

Problème : si vous essayez par erreur de migrer un workload source Azure vers la même cible et le même emplacement de banque de données dans Azure, la configuration de la migration échoue comme prévu avec l'erreur BlobAlreadyExists. Le nettoyage après échec du workload cible supprime le workload source, car ils sont au même emplacement. (Bogue 971998)

Solution : ne migrez pas un workload source Azure vers la même cible et le même emplacement de banque de données dans Azure.

Les numéros de disque et d'index de disque ne sont pas séquentiels pour les workloads de disques dynamiques découverts

Problème : pour les workloads sources Windows avec les types de disques dynamiques simples, fractionnés, agrégés par bandes, en miroir et RAID-5, la configuration du workload cible assigne des numéros non séquentiels dans les noms et les index de disque. La numérotation non séquentielle est un artefact des types de disques dynamiques sur le workload source. Tous les disques nécessaires sont présents pour le workload cible. Ce problème concerne les workloads cibles Azure et VMware. (Bogue 973266)

Solution : il n'existe aucune solution pour contourner ce problème.

La taille d'instance Cloud par défaut pour les workloads de disques dynamiques est trop importante

Problème : pour les workloads sources Windows avec les types de disques dynamiques simples, fractionnés, agrégés par bandes, en miroir et RAID-5, la taille par défaut de l'instance Cloud pour le workload cible peut être supérieure à ce qui est nécessaire. Le paramètre par défaut pour le composant de disques de données est basé sur le nombre de disques total sur le workload source, plutôt que sur le nombre de disques à créer sur le workload cible. (Bogue 973265)

Solution : vous devez modifier manuellement la taille de l'instance Cloud de manière à définir le paramètre approprié. Il se peut qu'une taille avec moins de disques de données réponde à vos besoins.

L'ordre des disques virtuels change de manière incorrecte lorsqu'un disque est exclu de la migration sur la page de configuration

Problème : un workload découvert répertorie tous les disques découverts sur la page de configuration. Si vous excluez un disque de la migration et enregistrez le changement, la liste vdisk avec le chemin de disque correspondant est réorganisée et le disque attendu risque de ne pas être celui exclu. Ce problème est observé pour les machines virtuelles cibles VMware et Azure. (Bogue 969639)

Solution : il s'agit d'une modification superficielle de la configuration dans l'interface utilisateur. La configuration sous-jacente est enregistrée correctement et il est inutile de modifier les chemins ou l'ordre des disques.

Échec de la migration vers Azure pour SLES 11 SP4 avec 3 disques et sans LVM

Problème : la migration vers Azure échoue pour un workload SUSE Linux Enterprise Server (SLES) 11 SP4 qui comporte uniquement des disques non-LVM. Différentes tentatives renvoient des erreurs distinctes :

La commande a échoué. Consultez ses détails. Le service de configuration de la machine cible ne semble pas avoir démarré.

Les migrations vers Azure réussissent pour les workloads exécutant d'autres versions de SLES et d'autres systèmes d'exploitation Linux dont la configuration comporte uniquement des disques non-LVM. (Bogue 972062)

Solution : il n'existe aucune solution pour les workloads SLES 11 SP4 utilisant des disques non-LVM.

Les disques ou partitions Linux sont migrées vers la cible dans un ordre différent de celui de la source Linux

Problème : les disques Linux sont créés sur le workload cible dans un ordre différent de celui sur le workload source. L'ensemble des disques et partitions sont présents ; seul l'ordre des disques change. (Bogue 974156)

Solution : il n'existe aucune solution. La machine virtuelle cible est totalement fonctionnelle.

Les groupes de volumes LVM sont créés sur des partitions opposées sur le même disque de la machine virtuelle cible Linux

Problème : en cas de workload Linux comportant plusieurs groupes de volumes LVM sur le même disque, ces derniers sont créés dans l'ordre inverse sur le workload cible. Par exemple, si l'ordre des groupes de volumes sources est AB, l'ordre des groupes de volumes cibles est BA. Ce problème concerne les workloads cibles sous Azure et VMware. (Bogue 973227)

Solution : l'ordre des groupes de volumes LVM sur le disque n'affecte pas la fonctionnalité. La machine cible fonctionne comme prévu.

Les partitions Linux sont créées sur des partitions opposées sur le même disque de la machine virtuelle cible Linux

Problème : en cas de workload Linux comportant plusieurs partitions Linux sur le même disque, ces dernières sont créées dans l'ordre inverse sur le workload cible. Par exemple, si l'ordre des partitions sources est AB, l'ordre des partitions cibles est BA. Ce problème concerne les workloads cibles sous Azure et VMware. (Bogue 970822)

Solution : l'ordre des partitions Linux sur le disque n'affecte pas la fonctionnalité. La machine cible fonctionne comme prévu.

La machine virtuelle cible Azure est lancée en mode sans échec après la transition d'un workload

Problème : si vous décidez de migrer un workload Windows Small Business Server 2011 vers Azure, la transition s'effectue, mais la machine virtuelle cible dans Azure est lancée en mode sans échec.(Bogue 978131)

Solution : pour démarrer la machine virtuelle cible en mode normal :

La page des paramètres de la machine virtuelle cible dans le portail Azure n'affiche pas la taille de cette dernière

Problème : après la transition d'un workload vers Azure, la page des paramètres de la machine virtuelle du portail Azure n'affiche pas la taille de la machine virtuelle Azure si celle-ci appartient à la série DSX_v2. Bien que la taille de la machine virtuelle ne soit pas affichée sur la page des paramètres, elle est définie dans la configuration de machine virtuelle sous-jacente. (Bogue 977497)

Solution : vous pouvez consulter la taille de la machine virtuelle dans l'interface CLI Azure pour les machines virtuelles de la série DSX_v2.

Les seuils blob de l'environnement de réplication ne sont pas nettoyés automatiquement après une opération de transition, de suppression de workload ou d'abandon

Problème : pour les migrations vers Microsoft Azure, le service Azure Blob crée des artefacts de stockage (un seuil blob de page et un seuil blob de bloc) dans la banque de données assignée pour l'environnement de réplication du workload. Bien que PlateSpin Migrate n'ait plus besoin de ces artefacts après la transition, l'abandon ou la suppression du workload, il ne les supprime pas automatiquement. Or, vous devez payer Microsoft Azure pour stocker ces fichiers de données inutiles. (Bogue 977308)

Solution : après avoir effectué, abandonné ou supprimé une migration de workload, vous devez supprimer manuellement les artefacts de stockage connexes dans le conteneur de stockage vhds de la banque de données assignée à la migration. Ne supprimez aucun fichier de seuil blob dont la migration associée est en cours.

Deux disques partagent le même chemin de disque sur la page de configuration pour des workloads avec des disques dynamiques

Problème : pour les workloads sources Windows avec les types de disques dynamiques simples, fractionnés, agrégés par bandes, en miroir et RAID-5, la configuration du workload cible peut utiliser le même paramètre Chemin du disque pour deux disques. La migration ignore le paramètre en double et configure des chemins uniques pour les deux disques sur le workload cible. La migration s'effectue correctement. (Bogue 973271)

Solution : aucune opération n'est requise pour la configuration.

Les numéros de disque et d'index de disque ne sont pas séquentiels pour les workloads de disques dynamiques découverts

Problème : pour les workloads sources Windows avec les types de disques dynamiques simples, fractionnés, agrégés par bandes, en miroir et RAID-5, la configuration du workload cible assigne des numéros non séquentiels dans les noms et les index de disque. La numérotation non séquentielle est un artefact des types de disques dynamiques sur le workload source. Tous les disques nécessaires sont présents pour le workload cible. Ce problème concerne les workloads cibles Azure et VMware. (Bogue 973266)

Solution : il n'existe aucune solution pour contourner ce problème.

L'ordre des disques virtuels change de manière incorrecte lorsqu'un disque est exclu de la migration sur la page de configuration

Problème : un workload découvert répertorie tous les disques découverts sur la page de configuration. Si vous excluez un disque de la migration et enregistrez le changement, la liste vdisk avec le chemin de disque correspondant est réorganisée et le disque attendu risque de ne pas être celui exclu. Ce problème est observé pour les machines virtuelles cibles VMware et Azure. (Bogue 969639)

Solution : il s'agit d'une modification superficielle de la configuration dans l'interface utilisateur. La configuration sous-jacente est enregistrée correctement et il est inutile de modifier les chemins ou l'ordre des disques.

Les groupes de volumes LVM sont créés sur des partitions opposées sur le même disque de la machine virtuelle cible Linux

Problème : en cas de workload Linux comportant plusieurs groupes de volumes LVM sur le même disque, ces derniers sont créés dans l'ordre inverse sur le workload cible. Par exemple, si l'ordre des groupes de volumes sources est AB, l'ordre des groupes de volumes cibles est BA. Ce problème concerne les workloads cibles sous Azure et VMware. (Bogue 973227)

Solution : l'ordre des groupes de volumes LVM sur le disque n'affecte pas la fonctionnalité. La machine cible fonctionne comme prévu.

Les partitions Linux sont créées sur des partitions opposées sur le même disque de la machine virtuelle cible Linux

Problème : en cas de workload Linux comportant plusieurs partitions Linux sur le même disque, ces dernières sont créées dans l'ordre inverse sur le workload cible. Par exemple, si l'ordre des partitions sources est AB, l'ordre des partitions cibles est BA. Ce problème concerne les workloads cibles sous Azure et VMware. (Bogue 970822)

Solution : l'ordre des partitions Linux sur le disque n'affecte pas la fonctionnalité. La machine cible fonctionne comme prévu.

Dans le client vSphere, la transition se bloque avec un message indiquant un verrouillage de vCDROM VMware et nécessite une intervention de l'utilisateur

Problème : pour les workloads cibles Linux sur des conteneurs VMware, une fois les données copiées et le service de configuration lancé, la transition se bloque avec le message suivant dans l'interface Web :

La tâche ReconfigVM_Task soumise au serveur VMware vCenter a échoué : Échec de l'opération de contrôle de connexion pour le disque ide0:0

Dans le client vSphere de l'environnement cible, les boîtes de dialogue Virtual Machine Message (Message de machine virtuelle) et Virtual Machine Question (Question de machine virtuelle) vous invitent à ignorer le verrouillage de CD-ROM. Dans l'interface Web, la transition reste suspendue jusqu'à ce que vous ignoriez manuellement le verrouillage de vCDROM dans le client vSphere de l'environnement cible.

Ce problème ne concerne pas tous les workloads cibles Linux ni toutes les versions de conteneur VMware. (Bogue 975853)

Solution : connectez-vous au client vSphere de l'environnement cible. Lorsque vous êtes invité à ignorer le verrouillage de CD-ROM, sélectionnez Yes (Oui), puis cliquez sur OK.

L'intervention de l'utilisateur peut être nécessaire lors de l'utilisation du client Migrate pour configurer le système d'exploitation des workloads cibles Linux

Problème : si vous utilisez le client Migrate pour configurer le système d'exploitation des workloads cibles Linux sur les conteneurs VMware, il peut ne pas réagir.

Dans le client vSphere de l'environnement cible, les boîtes de dialogue Virtual Machine Message (Message de machine virtuelle) et Virtual Machine Question (Question de machine virtuelle) vous invitent à ignorer le verrouillage de CD-ROM. Il se peut que tant que vous n'ignorez pas manuellement le verrouillage vCDROM dans le client vSphere de l'environnement cible, le client Migrate ne réagisse pas.

Ce problème ne concerne pas tous les workloads cibles Linux ni toutes les versions de conteneur VMware. (Bogue 975853)

Solution : connectez-vous au client vSphere de l'environnement cible. Lorsque vous êtes invité à ignorer le verrouillage de CD-ROM, sélectionnez Yes (Oui), puis cliquez sur OK.