マルチディスクの VMware 仮想マシンを、ダイレクトボリュームコピー機能を使用して IBM Cloud へ移行する

qemu-imgによるダイレクトボリュームコピー、またはディスクレベルでの完全な制御が可能な virt-v2v を使用して、マルチディスク構成の VMware 仮想マシン（VM）を IBM Cloud VPC 仮想サーバーに移行します。

アーキテクチャー・コンポーネント

次の表に、ダイレクト・ボリューム・コピー移行のアーキテクチャ・コンポーネントを示します。

ダイレクト・ボリューム・コピー移行方式のアーキテクチャ・コンポーネント
アーキテクチャー・コンポーネント 説明
ワーカー仮想サーバーインスタンス

移行ワークスペースとなる一時的な仮想サーバーインスタンス。 この仮想サーバーインスタンスには、以下の前提条件が必要です。

  • 変換ツールを実行するための十分な中央処理装置（CPU）およびメモリ

  • エクスポートされた仮想マシンディスク（VMDK）ファイル（または大容量の一時ディスク）を格納するための十分なワークスペースストレージ

  • VMware 環境へのネットワーク接続 （ライブ転送を使用する場合）

  • 変換ツール「 qemu-img 」および、必要に応じて変換用の「 libguestfs 」（ virt-v2v ）
エフェメラル仮想サーバーインスタンス ブートボリュームとデータボリュームを生成するためにのみ作成される、短期間の仮想サーバーインスタンス。 この仮想サーバーインスタンスはすぐに削除しますが、ボリュームは保持します。
ターゲット・ボリューム 移行された VM のディスクとなる実際のボリューム。

コピーダイレクトボリューム移行プロセスの概要

以下のステップでは、ダイレクト・ボリューム・コピーを使用して移行する手順を示します。

  1. プロビジョニング作業用仮想サーバーインスタンス

    1. Ubuntu または適切なワークスペースを持つRHELインスタンス
    2. VMDK用にワークスペースが必要な場合は、大きなセカンダリボリュームをアタッチする
    3. 必要なツールをインストールする
      • qemu-img
      • libguestfs-tools ( virt-v2v )

  2. 一時的な仮想サーバーインスタンスを作成する

    1. ターゲット VM （OS、ブートディスクサイズ、セカンダリディスク数/サイズ）に合わせて設定する
    2. クリティカル ：すべてのボリュームで自動削除を無効にする
    3. クリティカル ：ブート・ボリュームに general-purpose ストレージ・プロファイルを使用する
    4. ネットワーク構成は捨てられる
    5. ボリュームの大きさと順序に注意

  3. エフェメラル仮想サーバーインスタンスの削除、ボリュームの保持

    1. UI または CLI を使用した仮想サーバーインスタンスの削除
    2. ボリュームがまだ存在し、添付可能であることを確認する

  4. ワーカー仮想サーバーインスタンスにボリュームをアタッチする

    1. 作成された順番に添付する
    2. デバイス名に注意（例えば、 /dev/vdb, /dev/vdc,、など）
    3. サイズを確認する： blockdev --getsize64 /dev/vdb

  5. VM ディスクの転送と変換

    1. エクスポートした場合VMDKをワーカー仮想サーバーインスタンスにコピー
    2. 変換と書き込みをワンステップで：
    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. オプションで、Windowsドライバーインジェクションに virt-v2v

  6. 確認と洗浄

    1. パーティションテーブルをスポットチェックする： fdisk -l /dev/vdb
    2. バッファをフラッシュする： blockdev --flushbufs /dev/vdb

  7. ワーカーからボリュームを切り離す

    1. すべてのターゲットボリュームを切り離す
    2. これで、最終的な仮想サーバーインスタンスにアタッチする準備が整った

  8. 既存のブートボリュームから最終仮想サーバーインスタンスを作成する

    1. イメージを選択する代わりに、"既存のブートボリューム "を選択する
    2. 投入したブートボリュームを選択する
    3. ネットワーク、セキュリティグループ、SSHキーの設定（既存の VM の場合は使用されませんが必須です。）
    4. セカンダリボリュームの場合：CLI/APIを使用するか、作成後にアタッチして再起動します

  9. 移行後の設定

    1. 仮想サーバーインスタンスを起動し、ネットワーク設定の調整が必要な場合はVNCコンソールからアクセスする
    2. すべてのディスクが存在し、マウントされていることを確認する
    3. ブートボリューム・パーティションを上方にリサイズした場合、それを拡張する

ダイレクト・ボリューム・コピー・デザインの利点

次の表は、ダイレクト・ボリューム・コピー移行の設計上の利点を示しています。

ダイレクト・ボリューム・コピー移行方式の設計上の利点
デザインの優位性 説明
マルチディスク対応 マルチディスクのサポートは、VPCの12ディスク制限まで、任意のディスク数の仮想マシンを処理します。
画像の無秩序な拡散がない 仮想マシンごとにカスタムイメージを作成するわけではありません。 カスタム画像リストはきれいなままです。
柔軟な変形 ドライバーインジェクションやOSの調整など、 virt-v2v と簡単に統合できる。
ストレージ効率化オプション ベーステンプレートをカスタムイメージとしてインポートし、エフェメラル仮想サーバーインスタンスのブートボリュームソースとして使用する場合（手順2）、最終的なブートボリュームはリンククローンスペースの効率を継承します。

ダイレクト・ボリューム・コピー設計の制約と限界

次の表は、ダイレクトボリュームコピー移行の制約と制限の一覧です。

ダイレクト・ボリューム・コピー移行方法の制限と制約
制限または制約 説明
オーケストレーションの複雑さ より多くのステップと可動部分がある。 しっかりとしたランブックと、できれば自動化（Terraform、 Ansible、スクリプト）が必要だ。
ボリュームの接続に関する制限

IBM Cloud のユーザーインターフェース（UI）では、仮想サーバーインスタンスの作成中にセカンダリボリュームをアタッチすることはサポートされていません。 以下のいずれかの方法を実行する必要があります：

  • コマンドラインインターフェース（CLI）を使用する： ibmcloud is instance-create ... --volume-attach ...

  • API/Terraform を使用して完全自動化を行う：

  • 仮想サーバーインスタンスを作成し、停止してからボリュームをアタッチし、その後起動する
輸出諸経費 VMware からVMDKをエクスポートする場合、（OVAエクスポートよりも少ないとはいえ）オーバーヘッドは発生する。

ネットワーク転送を使用してエクスポートをスキップ

方法2をネットワーク転送技術（方法3で詳述）と組み合わせることで、VMDKのエクスポートを完全に回避することができます。 ソース VM を ISO からブートし、ワーカー仮想サーバーインスタンスへのネットワーク接続を確立し、ディスクコンテンツを直接ストリーミングします：

  1. ワーカー仮想サーバーインスタンス（デスティネーション）で、以下のコマンドを実行します：

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

  2. ソース仮想マシン（ISOからブート）で、以下のコマンドを実行する：

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

このプロセスにより、輸出時間と輸出保管の必要性がなくなる。

このプロセスは、マルチディスクのVMや、正確な制御を必要とするシナリオ、あるいはカスタム・イメージの拡散を避けることが重要な場合に使用します。 ネットワーク転送でも効率を上げることができる。