Migration de machines virtuelles VMware s à disques multiples vers IBM Cloud à l'aide de la copie directe de volumes

Migrer des machines virtuelles (VM) multi-disques d’ VMware vers des serveurs virtuels d’ IBM Cloud VPC à l’aide de la copie directe de volume avec qemu-img ou virt-v2v pour un contrôle total au niveau du disque.

Composants de l'architecture

Le tableau suivant répertorie les composants de l'architecture d'une migration par copie directe de volume.

Composants de l'architecture de la méthode de migration par copie directe de volume
Composants de l'architecture Description
Instance de serveur virtuel de travailleur

Une instance de serveur virtuel temporaire qui sert d'espace de travail pour la migration. Cette instance de serveur virtuel nécessite les prérequis suivants :

  • Une unité centrale (CPU) et une mémoire suffisantes pour exécuter les outils de conversion

  • Un espace de stockage suffisant pour accueillir les fichiers de disque de machine virtuelle (VMDK) exportés (ou un disque éphémère de grande taille)

  • Une connectivité réseau vers votre environnement VMware (si vous utilisez le transfert en direct)

  • L’outil qemu-img et, en option, libguestfs ( virt-v2v ) pour les transformations
Instance de serveur virtuel éphémère Instance de serveur virtuel de courte durée créée uniquement pour générer des volumes de démarrage et de données avec la bonne configuration. Vous supprimez immédiatement cette instance de serveur virtuel, mais vous conservez ses volumes.
Volumes cibles Les volumes réels qui deviennent les disques de votre site VM migré.

Vue d'ensemble du processus de copie directe de la migration des volumes

Les étapes suivantes décrivent le processus de migration à l'aide de la copie directe de volume.

  1. Mise en place d'une instance de serveur virtuel pour les travailleurs temporaires

    1. Ubuntu ou une instance RHEL avec un espace de travail adéquat
    2. Attachez un volume secondaire de grande taille si vous avez besoin d'un espace de travail pour les VMDK
    3. Installer les outils nécessaires
      • qemu-img
      • libguestfs-tools (pour virt-v2v )

  2. Créer une instance de serveur virtuel éphémère

    1. Configurez-le pour qu'il corresponde à votre cible VM (système d'exploitation, taille du disque de démarrage, nombre et taille des disques secondaires)
    2. Critique: Désactiver la suppression automatique sur tous les volumes
    3. Critique: Utiliser le profil de stockage general-purpose pour le volume de démarrage
    4. La configuration du réseau peut être jetable
    5. Notez les tailles de volume et l'ordre

  3. Supprimer une instance de serveur virtuel éphémère, conserver les volumes

    1. Supprimer l'instance de serveur virtuel via l'interface utilisateur ou le CLI
    2. Confirmer que les volumes existent toujours et qu'ils sont disponibles pour être joints

  4. Attacher des volumes à une instance de serveur virtuel de travailleur

    1. Attachez-les dans l'ordre dans lequel elles ont été créées
    2. Notez les noms des appareils (par exemple, /dev/vdb, /dev/vdc,, etc.)
    3. Vérifier les tailles : blockdev --getsize64 /dev/vdb

  5. Transfert et conversion des disques VM

    1. Si exporté : Copier le VMDK dans l'instance de serveur virtuel du travailleur
    2. Convertir et écrire en une seule étape :
    qemu-img convert -f vmdk -O raw source-vm-boot.vmdk /dev/vdb
qemu-img convert -f vmdk -O raw source-vm-data.vmdk /dev/vdc
    1. Utiliser éventuellement virt-v2v pour l'injection de pilotes Windows (voir la section Windows suivante)

  6. Vérifier et rincer

    1. Vérifier ponctuellement les tables de partition : fdisk -l /dev/vdb
    2. Vider les tampons : blockdev --flushbufs /dev/vdb

  7. Détacher les volumes du travailleur

    1. Détachement de tous les volumes cibles
    2. Ils sont maintenant prêts à être attachés à l'instance finale du serveur virtuel

  8. Créer une instance de serveur virtuel final à partir d'un volume d'amorçage existant

    1. Au lieu de sélectionner une image, sélectionnez "volume de démarrage existant"
    2. Choisissez le volume de démarrage que vous avez peuplé
    3. Configuration du réseau, des groupes de sécurité, de la clé SSH (obligatoire même si elle n'est pas utilisée s'il s'agit d'un site existant VM )
    4. Pour les volumes secondaires : Utiliser la CLI/API ou attacher après la création et le redémarrage

  9. Configuration post-migration

    1. Démarrage de l'instance du serveur virtuel, accès par la console VNC si la configuration du réseau a besoin d'être ajustée
    2. Vérifier que tous les disques sont présents et montés
    3. Étendre la partition du volume de démarrage si vous l'avez redimensionnée vers le haut

Avantages de la conception de la copie en volume direct

Le tableau suivant énumère les avantages de la migration par copie directe de volume.

Avantages de la conception de la méthode de migration par copie directe de volume
Avantage de la conception Description
Prise en charge de plusieurs disques La prise en charge multi-disques permet de gérer les machines virtuelles avec n'importe quel nombre de disques, jusqu'à la limite de 12 disques de VPC.
Pas de prolifération d'images Vous ne créez pas une image personnalisée pour chaque machine virtuelle. Votre liste d'images personnalisées reste propre.
Transformation flexible Permet une intégration facile avec virt-v2v pour l'injection de pilotes, les modifications du système d'exploitation, etc.
Option d'optimisation du stockage Si vous importez un modèle de base en tant qu'image personnalisée et que vous l'utilisez comme source de volume de démarrage pour votre instance de serveur virtuel éphémère (étape 2), le volume de démarrage final hérite de l'efficacité de l'espace de clone lié.

Contraintes et limites de la conception de la copie directe en volume

Le tableau suivant énumère les contraintes et les limites d'une migration par copie directe de volume.

Limites et contraintes de la méthode de migration par copie directe de volume
Limitation ou contrainte Description
Complexité de l'orchestration Il y a plus d'étapes et de pièces mobiles. Vous avez besoin de runbooks solides et de préférence d'automatisation (Terraform, Ansible, scripts).
Limites relatives aux pièces jointes volumineuses

L'interface utilisateur (UI) d' IBM Cloud ne prend pas en charge l'ajout de volumes secondaires lors de la création d'une instance de serveur virtuel. Vous devez effectuer l'une des opérations suivantes :

  • Utiliser l'interface de ligne de commande (CLI): ibmcloud is instance-create ... --volume-attach ...

  • Utiliser l'API ou Terraform pour une automatisation complète :

  • Créer l'instance de serveur virtuel, l'arrêter, y associer des volumes, puis la démarrer
Frais généraux d'exportation Si vous exportez des VMDK à partir de VMware, vous subissez toujours ces frais généraux (bien qu'ils soient moindres que pour l'exportation d'OVA).

Sauter l'exportation en utilisant le transfert réseau

Vous pouvez combiner la méthode 2 avec des techniques de transfert en réseau (détaillées dans la méthode 3) pour éviter d'exporter des VMDK. Démarrez votre source VM à partir d'une ISO, établissez une connectivité réseau avec votre instance de serveur virtuel de travail et diffusez directement le contenu du disque :

  1. Sur l'instance de serveur virtuel de travail (destination), exécutez la commande suivante :

    nc -l 192.168.100.5 8080 | gunzip | dd of=/dev/vdb bs=16M status=progress

  2. Sur la machine virtuelle source (démarrée à partir de l'ISO), exécutez la commande suivante :

    dd if=/dev/sda bs=16M | gzip | nc -N -v 192.168.100.5 8080

Ce processus élimine les délais d'exportation et les exigences en matière de stockage des exportations.

Utilisez ce processus pour les machines virtuelles multidisques, pour les scénarios dans lesquels vous souhaitez un contrôle précis, ou lorsqu'il est important d'éviter la prolifération d'images personnalisées. Vous pouvez également améliorer l'efficacité grâce au transfert de réseau.