Migrazione di macchine virtuali multi-disco di VMware verso IBM Cloud con copia diretta dei volumi

Eseguire la migrazione delle macchine virtuali (VM) multi-disco di VMware verso i server virtuali di IBM Cloud VPC utilizzando la copia diretta dei volumi con qemu-img o virt-v2v per un controllo completo a livello di disco.

Componenti dell'architettura

La tabella seguente elenca i componenti dell'architettura di una migrazione diretta di un volume.

Componenti dell'architettura per il metodo di migrazione diretta dei volumi
Componenti dell'architettura Descrizione
Istanza del server virtuale del lavoratore

Un'istanza di server virtuale temporanea che funge da spazio di lavoro per la migrazione. Questa istanza di server virtuale richiede i seguenti prerequisiti:

  • Unità di elaborazione centrale (CPU) e memoria adeguate per l'esecuzione degli strumenti di conversione

  • Spazio di archiviazione sufficiente per contenere i file del disco della macchina virtuale (VMDK) esportati (o un disco effimero di grandi dimensioni)

  • Connettività di rete all'ambiente VMware (se si utilizza il trasferimento in tempo reale)

  • Lo strumento qemu-img e, facoltativamente, libguestfs ( virt-v2v ) per le trasformazioni
Istanza di server virtuale effimera Un'istanza di server virtuale di breve durata creata solo per generare volumi di avvio e di dati con la configurazione corretta. L'istanza del server virtuale viene eliminata immediatamente, ma i volumi vengono mantenuti.
Volumi di destinazione I volumi effettivi che diventano i dischi migrati di VM.

Panoramica del processo di copia della migrazione diretta del volume

I passaggi seguenti illustrano il processo di migrazione mediante copia diretta del volume.

  1. Provisionare l'istanza del server virtuale del lavoratore

    1. Ubuntu o istanza RHEL con uno spazio di lavoro adeguato
    2. Collegare un volume secondario di grandi dimensioni se è necessario uno spazio di lavoro per i VMDK
    3. Installare gli strumenti necessari
      • qemu-img
      • libguestfs-tools (per virt-v2v )

  2. Crea un'istanza di server virtuale effimera

    1. Configuratelo in modo che corrisponda al vostro VM (sistema operativo, dimensioni del disco di avvio, numero/dimensioni dei dischi secondari)
    2. Critico: Disattivare la cancellazione automatica su tutti i volumi
    3. Critico: utilizzare il profilo di archiviazione general-purpose per il volume di avvio
    4. La configurazione di rete può essere usa e getta
    5. Si noti la dimensione dei volumi e l'ordine

  3. Eliminare l'istanza di server virtuale effimera, conservare i volumi

    1. Eliminare l'istanza del server virtuale tramite l'interfaccia utente o l'interfaccia utente (CLI)
    2. Confermare che i volumi esistono ancora e sono disponibili per l'allegato

  4. Collegare i volumi all'istanza del server virtuale del lavoratore

    1. Allegarli nello stesso ordine in cui sono stati creati
    2. Annotare i nomi dei dispositivi (ad esempio, /dev/vdb, /dev/vdc, e così via)
    3. Verificare le dimensioni: blockdev --getsize64 /dev/vdb

  5. Trasferimento e conversione dei dischi VM

    1. Se esportato: Copiare il VMDK nell'istanza del server virtuale worker
    2. Convertire e scrivere in un solo passaggio:
    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. Utilizzare facoltativamente virt-v2v per l'iniezione dei driver di Windows (vedere la seguente sezione Windows)

  6. Verifica e risciacquo

    1. Controllare le tabelle di partizione: fdisk -l /dev/vdb
    2. Risciacquare i buffer: blockdev --flushbufs /dev/vdb

  7. Staccare i volumi dal lavoratore

    1. Staccare tutti i volumi di destinazione
    2. Ora sono pronti per essere collegati all'istanza finale del server virtuale

  8. Creare l'istanza del server virtuale finale dal volume di avvio esistente

    1. Invece di selezionare un'immagine, selezionare "volume di avvio esistente"
    2. Scegliere il volume di avvio popolato
    3. Configurare la rete, i gruppi di sicurezza, la chiave SSH (necessaria anche se non viene utilizzata se si tratta di un sito esistente VM )
    4. Per i volumi secondari: Utilizzare CLI/API o allegare dopo la creazione e il riavvio

  9. Configurazione post-migrazione

    1. Avviare l'istanza del server virtuale, accedere attraverso la console VNC se la configurazione di rete necessita di modifiche
    2. Verificate che tutti i dischi siano presenti e montati
    3. Espandere la partizione del volume di avvio se è stata ridimensionata verso l'alto

Vantaggi del design della copia diretta in volume

La tabella seguente elenca i vantaggi progettuali della migrazione diretta della copia di volume.

Vantaggi di progettazione per il metodo di migrazione diretta della copia di volume
Vantaggio del design Descrizione
Supporto multi-disco Il supporto multidisco gestisce macchine virtuali con qualsiasi numero di dischi, fino al limite di 12 dischi di VPC.
Nessuna proliferazione di immagini Non si crea un'immagine personalizzata per ogni macchina virtuale. L'elenco delle immagini personalizzate rimane pulito.
Trasformazione flessibile Consente una facile integrazione con virt-v2v per l'iniezione di driver, modifiche al sistema operativo e così via.
Opzione di efficienza di archiviazione Se si importa un modello di base come immagine personalizzata e lo si usa come origine del volume di avvio per l'istanza di server virtuale effimero (passaggio 2), il volume di avvio finale eredita l'efficienza dello spazio clone collegato.

Vincoli e limiti della progettazione della copia diretta di volume

La tabella seguente elenca i vincoli e le limitazioni di una migrazione di copia diretta del volume.

Limitazioni e vincoli per il metodo di migrazione diretta della copia di volume
Limitazione o vincolo Descrizione
Complessità dell'orchestrazione Ci sono più passaggi e parti mobili. È necessario disporre di runbook solidi e preferibilmente di automazione (Terraform, Ansible, script).
Limiti relativi agli allegati di volume

L'interfaccia utente (UI) di IBM Cloud non supporta l'aggiunta di volumi secondari durante la creazione di un'istanza di server virtuale. È necessario eseguire una delle seguenti operazioni:

  • Utilizzare l'interfaccia a riga di comando (CLI): ibmcloud is instance-create ... --volume-attach ...

  • Utilizzare l'API/Terraform per l'automazione completa

  • Creare l'istanza del server virtuale, arrestarla, collegare i volumi, quindi avviarla
Spese generali di esportazione Se si esportano VMDK da VMware, si incorre comunque in questo overhead (anche se minore rispetto all'esportazione di OVA).

Saltare l'esportazione utilizzando il trasferimento di rete

È possibile combinare il metodo 2 con le tecniche di trasferimento in rete (descritte nel metodo 3) per evitare completamente l'esportazione dei VMDK. Avviate il vostro VM di origine da una ISO, stabilite la connettività di rete alla vostra istanza di server virtuale worker e fate lo streaming diretto del contenuto del disco:

  1. Sull'istanza del server virtuale worker (destinazione), eseguire il seguente comando:

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

  2. Sulla macchina virtuale di origine (avviata da ISO), eseguire il seguente comando:

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

Questo processo elimina i tempi di esportazione e i requisiti di stoccaggio delle esportazioni.

Utilizzate questo processo per le macchine virtuali su più dischi, per gli scenari in cui desiderate un controllo preciso o in cui è importante evitare la proliferazione di immagini personalizzate. È possibile migliorare l'efficienza anche con il trasferimento in rete.