Notes de version de PlateSpin Migrate 11.0

7 mars 2014

La version 11.0 de PlateSpin Migrate propose plusieurs nouvelles fonctionnalités, améliorations et corrections de bogues.

Pour consulter la documentation qui accompagnait les versions 9.x et antérieures, visitez le site Web de documentation de PlateSpin Migrate 11.

1.0 Nouveautés

  • Parité des fonctions avec PlateSpin Migrate 9.2 : en raison du passage à un nouvel environnement de pré-lancement basé sur un disque virtuel Linux, certaines fonctionnalités avaient été temporairement bloquées dans la version précédente (9.3). Les fonctionnalités suivantes sont à présent restaurées dans la version 11 du produit :

    • Prise en charge de la création d'image : I2I et I2X

    • Conversions de fichiers Windows

  • Nouvelles fonctionnalités prises en charge : cette version introduit la prise de charge de workloads pour les plates-formes ci-après.

    • Microsoft Windows Server 2012 R2

    • Windows 8.1

    • SUSE Linux Enterprise Server (SLES) 11 SP1, SP2 et SP3

    • Novell Open Enterprise Server (OES) 11 SP1

    • Red Hat Enterprise Linux (RHEL)/Oracle Enterprise Linux (OEL) 5.9, 5.10, 6.4, 6.5

    Les éléments suivants sont désormais également pris en charge :

    • Les conteneurs de workload vSphere 5.0 Update 2, 5.1 Update 1 et vSphere 5.5

    • La conversion semi-automatique vers Windows 2012 R2 Hyper-V Generation 1

    • Les workloads Windows avec UEFI/GPT

  • Divers : cette version introduit également les fonctionnalités ci-après.

    • Un disque virtuel Linux SLES 11 SP3 entièrement testé (l'environnement de pré-exécution temporaire pour la migration de tous les types de workload) avec de nouveaux outils.

    • Une capacité de mise à niveau à partir de PlateSpin Migrate 9.2 et 9.3

    • Ce produit a été localisé pour pouvoir être installé et utilisé sur des machines configurées dans les langues suivantes : allemand, français et japonais.

Éléments non pris en charge dans cette version

  • L'installation du serveur PlateSpin Migrate 11.0 sur un hôte Microsoft Windows 2008 64 bits n'est pas prise en charge pour le moment.

  • PlateSpin Migrate 11.0 ne prend pas en charge la migration hors ligne des workloads Windows.

2.0 Corrections de bogues

Vous trouverez, ci-dessous, la liste des bogues corrigés dans cette version :

  • 699774 : le paquetage de pilote Linux BBT n'est pas sélectionné par le serveur. Le programme d'installation de Migrate utilise à présent un installateur de paquetage pour déployer les paquetages de pilote BBT. Le serveur Migrate sélectionne désormais 2.package.

  • 790944 : à la suite d'une modification de numéro de série, la réinitialisation des périphériques de volume ne monte aucun volume et le partitionnement échoue. Ce problème est résolu si les volumes sont montés avec le nouveau disque virtuel Linux PlateSpin.

  • 834553 : la migration (V2P) d'un workload Windows 2008 R2 vers Dell R720 entraîne le dysfonctionnement de certaines cartes réseau. Le problème est résolu grâce à des modifications du code.

  • 835805 : la machine virtuelle cible conserve les entrées de registre de la carte réseau source. Le problème est résolu grâce à des modifications du code.

  • 843800 : la migration échoue, car l'inventaire des disques classe les disques par ordre de découverte plutôt que par type de disque. Ce problème entraînait l'échec de la migration lorsque l'inventaire découvrait les disques HP Smart Array avec un pilote CCISS avant les disques SCSI. Le problème est résolu grâce à des modifications du code.

  • 844431 : la migration échoue si une machine physique dotée d'un microprogramme UEFI est convertie en machine virtuelle. Le problème est résolu grâce à des modifications du code.

  • 844486 : le service de réplication ne trouve pas le fichier boot.ini sur la source. Le problème est résolu grâce à une modification du code qui permet de renvoyer le nom de fichier boot.ini avant la réplication.

  • 856929 : la migration P2V échoue avec l'erreur L'argument ne peut pas être nul. Nom du paramètre : path1. Le problème est résolu grâce à des modifications du code.

  • 861474 : la migration P2P échoue avec l'erreur Le nom de l'unité n'existe pas. Nom du paramètre : driveName. Le problème est résolu grâce à des modifications du code.

  • 864484 : l'assistant de la tâche ne démarre pas. Erreur : Le système n'a pas référencé l'exception, la référence d'objet n'est pas définie sur une instance d'objet. Le problème est résolu grâce à des modifications du code.

  • 865272 : la création d'une machine virtuelle échoue sur un serveur vCenter doté d'un paramètre distribué. Le problème est résolu grâce à des modifications du code.

3.0 Problèmes connus

  • Non-prise en charge du RAID logiciel pour les workloads Linux : PlateSpin Migrate ne prend pas en charge les workloads Linux dont des volumes sont sur le RAID logiciel.

  • Conditions pour la prise en charge des grappes DRS VMware : 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.

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

  • Prise en charge de la norme GPT (GUID Partition Table) : PlateSpin Migrate prend en charge la migration de workloads utilisant la norme de disposition de partition de disque GPT. Cependant, les cibles sont toujours configurées pour démarrer à partir du BIOS à l'aide d'un secteur d'amorçage principal (MBR). Les conséquences de cette limitation sont les suivantes :

    • Taille maximale de 2 To par volume : la taille maximale des volumes d'une source de migration était limitée à 2,19 To pour un workload, soit le maximum autorisé pour une partition par zone amorce.

    • Les cibles X2P doivent démarrer à partir du BIOS : la plupart des fabricants de matériel assurent la prise en charge des deux normes de partitionnement de disque ; pour savoir comment configurer une cible X2P pour qu'elle démarre à partir du BIOS ou reconfigurer le matériel GPT pour qu'il fonctionne en "mode hérité" (avec prise en charge du BIOS), consultez la documentation du fabricant.

      Reportez-vous également à l'article de la base de connaissances n° 7005452.

  • 493589 (Sources Windows) Les paramètres VSS par volume autres que par défaut ne sont pas conservés après la migration : ce problème est à l'étude en vue d'un prochain correctif.

  • 505426 (ESX 4) Pas d'avertissement ni de message d'erreur en cas de sélection d'UC virtuelles incorrecte : si le nombre d'UC virtuelles demandées dépasse celui des UC physiques sur l'hôte ESX 4, le nombre demandé est ignoré et la VM cible est créée avec une seule UC sans avertissement. ce problème est à l'étude en vue d'un prochain correctif.

  • 506154 La présence de caractères spéciaux dans le nom d'une banque de données entraîne des problèmes de migration : 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.

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

  • 595490 La conservation de la partition de démarrage entraîne des problèmes de migration : 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é. Ce problème est actuellement à l'étude.

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

  • 604320 (Linux vers ESX 4) Problème d'exécution de la migration si les fonctions de connexion automatique ou de montage CD automatique sont activées pour le système d'exploitation source : la migration est également perturbée si vous vous connectez à la cible durant l'étape de configuration de la tâche.

    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.

  • 619942 Échec de l'exécution d'un script post-migration comportant des caractères Unicode dans le nom de fichier : si vous utilisez des caractères Unicode dans le nom de fichier de votre script post-migration, l'exécution de celui-ci échoue.

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

  • 655828 Échec du montage des volumes NSS : à la fin d'une migration, les volumes NSS comportant des instantanés activés ne sont pas montés automatiquement comme prévu.

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

  • 660790 : l'utilisateur ne peut pas ignorer la désinstallation des outils VMware durant la migration. Si l'utilisateur définit l'option Installer les outils VMware pour ESX sur Oui avant d'exécuter une tâche de migration, les outils ne sont pas désinstallés puis réinstallés.

  • 680259 (VMware 4.1) Performances réseau médiocres des machines virtuelles assurant le transfert du trafic : dans certains scénarios, la réplique d'un workload qui transfère le trafic réseau (par exemple, si l'objectif du workload est de faire office de pont réseau pour NAT, VPN ou un pare-feu) peut voir ses performances réseau se dégrader sensiblement. Cela est dû à un problème lié aux adaptateurs VMXNET 2 et VMXNET 3 pour lesquels la fonction LRO (Large Receive Offload, déchargement de réception volumineux) est activée.

    Solution : désactivez la fonction LRO sur l'adaptateur réseau virtuel. Pour plus d'informations, reportez-vous au document VMware vSphere 4.1 Release Notes (Notes de version de VMware vSphere 4.1) et faites-le défiler jusqu'à l'élément de liste à puces Poor TCP performance... (Performances TCP médiocres...).

  • 685509 : échec avec erreur Accès refusé lors d'une réplication sur une image stockée sur un partage réseau : le service de contrôleur qui s'exécute sur les serveurs d'images qui utilisent des partages réseau à des fins de stockage ne conserve pas ses références Ouvrir une session en tant que après une mise à niveau. Par conséquent, les opérations d'image échouent avec un message Accès refusé tant que le service du contrôleur n'est pas mis à jour avec les références Ouvrir une session en tant que adéquates.

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

  • 692680 Instantanés VSS non conservés : 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.

  • 702152 Lenteur de la migration via le réseau WAN si l'hôte de VM cible compte un nombre élevé de banques de données : dans certaines circonstances, lorsque votre serveur de migration est connecté à l'hôte de VM via le réseau WAN et si votre hôte deVM 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 prendre plus longtemps que prévu. Ce problème est actuellement à l'étude.

  • 779194 : le répertoire /home non assigné est désactivé et n'est pas monté après une synchronisation unique des serveurs. Si vous effectuez une synchronisation des serveurs avant de définir la partition /home sur aucun, ce répertoire est désactivé et n'est pas monté sur le serveur cible alors qu'il devrait y être activé et monté.

    Résolution du problème : après la synchronisation des serveurs, annulez le commentaire de la ligne adéquate dans le fichier /etc/fstab du serveur cible.

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

  • 810460 : les outils VMware ne sont pas installés durant la conversion d'un noyau de serveur Windows 2012 : Les outils VMware ne sont pas installés durant la conversion d'un noyau de serveur Windows 2012.

    Résolution du problème : installez manuellement les outils VMware après la conversion.

  • 822601 : la carte réseau n'est pas initialisée sur la machine virtuelle cible SLES 11 hébergée sur un hôte Windows 2008 Hyper-V. 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 2008 Hyper-V, le processus se bloque durant l'étape de configuration du système d'exploitation.

    Résolution du problème : pour plus d'informations sur la résolution de ce problème, reportez-vous à l'article de la base de connaissances n° 7012911.

  • 824724 : 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. Lorsqu'une machine virtuelle est convertie de VMware ESX vers Citrix Xen et que ses fichiers de démarrage sont alloués au deuxième disque, la machine virtuelle ne démarre pas et une intervention manuelle est requise. Ceci 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.

    Résolution du problème : 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 également à l'article de la base de connaissances n° 7012906.

  • 825016 : les outils XenServer ne sont pas supprimés après la conversion. 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.

    Résolution du problème : l'utilisateur doit désinstaller manuellement les outils XenServer après la conversion.

  • 825434 : après la migration, la partition primaire (C:\) est convertie en partition logique sur la cible. 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.

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

    Exemple : l'erreur suivante se produit lorsqu'une machine Windows 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.
    

    Résolution du problème : pour plus d'informations sur la résolution de ce problème, reportez-vous à l'article de la base de connaissances n° 7012913.

  • 826545 : lorsque Migrate annule la découverte d'une machine, le noeud de cette machine reste affiché sur l'hôte ESX comme étant découvert. 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.

    Résolution du problème : annulez la découverte du workload sur l'hôte ESX, puis rafraîchissez l'hôte ESX.

  • 839329 : échec de la tentative de récupération de données à partir du serveur VMware vCenter avec l'exception Cette opération n'est pas autorisée. Vous pouvez corriger ce problème en suivant les procédures pour définir les rôles VMware en utilisant les outils comme indiqué dans la section Utilisation d'outils pour définir des rôles VMware du Guide de l'utilisateur de PlateSpin Migrate 11.0.

  • 843431 : erreur de chargement du système d'exploitation lors d'une tentative de démarrage à partir du disque dur (C:). MBR est corrompu. Vous pouvez résoudre ce problème en exécutant la commande /BcdEditor /fixboot dans le LRD.

    Reportez-vous également à l'article de la base de connaissances n° 7014709.

  • 859440 : la conversion V2P est suspendue durant l'étape de configuration du système d'exploitation. 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.

    Résolution du problème : 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 de la base de connaissances n° 7014623.

  • 864325 : les workloads Windows 8.1 convertissant UEFI en BIOS ne peuvent pas procéder à la conversion durant l'étape « Envoi des fichiers ». 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'une copie shadow du volume (VSS) pour la partition.

    Résolution du problème : supprimez ou développez la partition de récupération. Pour plus d'informations, consultez l'article de la base de connaissances n° 7014696.

  • 864326 : échec de la conversion durant la mise à niveau vers une version antérieure d'UEFI vers le microprogramme BIOS. La conversion d'un workload UEFI (Windows 6.2 et versions de kernel supérieures) vers une machine BIOS échoue durant 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.

    Résolution du problème : 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 de la base de connaissances n° 7014637.

  • 865570 : le transfert de fichiers est interrompu pour le workload Windows 2012 R2 UEFI. Le transfert de fichiers X2P de Windows 6.2 (et versions de kernel supérieures) échoue durant l'étape d'envoi et de réception des fichiers.

    Résolution du problème : pour forcer le transfert de fichiers dans ce scénario X2P, vous devez désactiver les indicateurs d'UC avancés dans le microprogramme, à savoir VT-d, VT-s et Execute Disable Bit. Pour plus d'informations, consultez l'article de la base de connaissances n° 7014698.

  • 866467 : échec de la capture d'image d'un système d'exploitation Windows 32 bits. 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 2008/Vista. Donc, lorsque Migrate exporte les informations BCD vers le dossier, l'opération échoue avec l'erreur :

    Error message: Failed: C:\Windows\Boot\EFI
    

    Résolution du problème : pour résoudre ce problème, vous devez créer le dossier C:\Windows\Boot\EFI, puis créer un répertoire de jonction sous C:\Windows pour C:\Windows\System32. Pour plus d'informations, consultez l'article de la base de connaissances n° 7014710.