IBM Cloud : virt-v2vを使ったClassic環境のVSIからVSI for VPCへのサーバー移行手順

(2026/5/15)現在記載している内容はRedhat9を前提としています。今後Windowsも検証したうえで手順を更新する予定です。

1. 背景

VMWare環境からVSI for VPCへの移行手順は以下を参照ください。
IBM Cloud : virt-v2v+VDDKを使ったVMware環境からVSI for VPCへのサーバー移行手順

仮想マシンの移行方法は以下の記事にある方法1から方法4が挙げられます。方法3を利用することでClassic環境のVSIからVSI for VPCへ移行することができるため、こちらの方法に沿った移行手順を本記事で説明します。
方法3: ISO で仮想マシンをブートして VPC ボリュームへコピーする

2. VMware環境からVSI for VPCへ移行する場合の違いについて

以下の記事ではConverter VSIがvCenterへアクセスし、移行先のboot diskへ転送と変換を行う手順が説明されています。
IBM Cloud : virt-v2v+VDDKを使ったVMware環境からVSI for VPCへのサーバー移行手順
しかし、「(b) VM イメージの変換データを直接 Boot Disk（Block Storage）に書き込んで移行する方法」に説明がありますように、Classic環境のVSIはvCenterを利用しません。

そのため、一度ディスクのデータをConverter VSIに転送し、その後Converter VSI上でvirt‑v2vコマンドを実行してデータを変換する必要があります。

virt-v2vの変換コマンドはVMWare環境からVSI for VPCへ移行する際に利用したコマンドのオプションを変更することで実施可能です。

3.移行の流れの概要

以下の「3. 移行の流れの概要」で移行元環境をClassic環境のVSIに変更した場合とほぼ同じ流れになります。
IBM Cloud : virt-v2v+VDDKを使ったVMware環境からVSI for VPCへのサーバー移行手順

Step3においてvCenterに接続すると記載がありますが、Classic環境のVSIを移行する場合はClassic環境のVSIからディスクデータをddコマンドで転送し、その後virt-v2vコマンドで変換を行います。
また、VMWare環境の場合は移行するVMを停止する必要がありますが、Classic環境のVSIを移行する場合はVSIがConverter VSIと通信を行う必要があるため、転送が完了するまでは稼働させておく必要があります。

なお、Converter VSIの作成方法に関しては上記リンクの「4. Converter VSIの準備」を参照ください。ただし、4-3.〜4-6.の手順はClassic環境のVSIを移行する場合においては必要ではありません。また、dd, gzip, Netcat(nc)コマンドを利用するため、これらのモジュールも導入が必要となります。データ転送時、ディスクに書き込みが生じると不整合が生じる可能性があります。そのため、IBM Cloud のポータル上で ISO イメージから起動させる Boot from image という方法がありますのでそちらも本記事で紹介します。

• Step 1: IBM Cloudではboot diskのみを注文する機能がないため、暫定的に VSI for VPC をプロビジョニングします
• Step 2: 暫定的に作成した VSI for VPC を削除し、boot disk を獲得します
• Step 3: boot disk を変換用 VSI（Converter VSI）にアタッチします
• Step 4: 移行対象の Classic 環境の VSI を boot from image で起動します
• Step 5: Converter VSI 上で移行元 VSI から転送されるデータを格納するファイルを作成します。Classic 環境の VSI でディスク全体を読み出して圧縮し、Converter VSI で作成したデータを格納するファイルを指定し、転送します
• Step 6: データ転送後、Converter VSI 上で送られてきたディスクを virt-v2v コマンドを利用して変換を行います
• Step 7: 変換が完了した boot disk をデタッチします
• Step 8: この boot disk を使用して VSI for VPC をプロビジョニングします

以下では、それぞれのStepごとの注意点を詳細に説明します。

4.各移行ステップの詳細

各ステップにおけるIBM Cloud関連、スクリプト、その他検証時の注意点は
IBM Cloud : virt-v2v+VDDKを使ったVMware環境からVSI for VPCへのサーバー移行手順
の「5. 各移行ステップの詳細」も併せてご確認ください。

Step 1: ephemeral VSIの注文

• IBM Cloudではboot時に使用できるdiskを単体で直接作成、発注ができないため、暫定的なVSI(ephemeral VSI)を作成します。
• RHELを移行する場合はRHEL, Windowsを移行する場合はWindowsのVSIを発注して使用します。

Step 2: VSIに紐づかないboot diskの獲得

• 発注後はVSIのboot diskメニューへ移り、Auto-deleteの設定でNoを選択します。その後VSIを削除することでboot diskが作成できます。

Step 3: boot diskをConverter VSIにアタッチ

Step 3-1. boot diskサイズの拡張（オプション）

• 移行するVMのboot sizeを確認した上でboot disk sizeを調整ください。
• 今まではboot diskの上限は250Gまででしたが、32TBまで利用可能となりました。250GBを超えたdiskの検証、注意点などについては以下もご参照ください。
  • IBM Cloud: VSI for VPCのboot volumeが32TBまで拡張されたので試してみた

Step 3-2. Converter VSIに先ほどのboot diskを割り当て

Step 4:移行対象のClassic環境のVSIをboot from imageで起動

• 私が検証を行った際は、Classic環境のVSIへデータを書き込むということはしていませんでしたため、boot from image を使用しない場合でもデータ転送途中でディスク差分が生じずに検証が成功しました。
  • (2025/5/22追記) boot from image で立ち上げた VSI で移行を実施したところ成功することを確認しました。
• ただし、VSI が業務稼働している状況で移行を行うことになるケースが大多数になると考えます。データ転送中にディスクへの書き込みが生じた場合、差分が生じてしまい、転送したデータで不整合が生じる可能性があります。
• そのため、メモリ上の情報を表示させる Boot from image を行うことで、ディスク差分の問題が解決できると考えられます。
• Boot from image はポータルのDevice一覧から移行対象のサーバーを選択し、右上のActionsで実施できます。Boot from image に関する情報は以下も併せてご参照ください。
  • IBM Cloud: VSI for Classic Infrastructureのboot from image実行時にIPアドレスや認証が正しく構成される理由
  • IBM Cloud Docs:イメージからの仮想サーバーのブート
    
• 私が検証の際に選択したイメージは rockylinux9_rescuelayer.iso を選択しました。
  
• ディスクからの通常起動に戻す場合は再度 Actions から Boot from image を選択すると、以下のような表示がされます。Continue を選択すると再起動が生じ、通常起動に戻ります。
  

Step 5: Classic VSIからConverter VSIへディスクのデータ転送

• Classic VSI から Converter VSI へディスクデータを転送する際、Converter VSI 上でデータを格納するためのファイルを初めに用意する必要があります。
  • 私が検証した際は /var/work 直下に rhel9-classic.img という空ファイルを作成しました

rhel9-classic.img

[fedora@sano-converter-fedora-custom work]$ pwd
/var/work
[fedora@sano-converter-fedora-custom work]$ sudo touch rhel9-classic.img
[fedora@sano-converter-fedora-custom work]$ ls -la 
total 0 
drwxr-xr-x. 1 root root  34 May 20 11:39 . 
drwxr-xr-x. 1 root root 184 Apr 24 09:41 .. 
-rw-r--r--. 1 root root   0 May 20 11:39 rhel9-classic.img 

• 転送時に使用したコマンドは以下となります。環境に応じて適宜変更ください。
  • Converter VSI上で実行したコマンド
    • nc -l 8080 | gunzip | dd of=/var/work/rhel9-classic.img bs=16M status=progress
      • 転送されたデータを格納するファイルを宛先にしています。(of=/var/work/rhel9-classic.img)
  • 移行対象のClassic VSIで実行したコマンド
    • dd if=/dev/xvda bs=16M status=progress | gzip -1 | nc -v 10.239.0.17 8080

Step 6: Converter VSI上で受信したデータをvirt-v2vコマンドで変換

• ディスクへの書き込みが必要なため、シンボリックリンクを作成しておく必要があります。作成スクリプトや方法については以下の「5. 各移行ステップの詳細」にある「Step 3-3. リンクを作成」を参照ください。
  • Step 3-3. シンボリックリンクを作成
• 上記URLのシンボリックリンク作成スクリプトは VM を移行する場合であり、 virt-v2v で変換時は移行元の VM hostname がファイル名として作成されるのでシンボリックリンクはそれを前提とするスクリプトとなっています。しかし、本記事で紹介している手順では、Converter VSI 上に転送したイメージファイルを変換する手順です。そのため、 VM_NAME の箇所を本記事の 「Step 5: Classic VSIからConverter VSIへディスクのデータ転送」で作成したデータ格納ファイル名を指定する必要がありました。
• また、virt-v2v で rhel9-classic.img を変換してみたところ、変換データ名は rhel9-classic.img-sda ではなく rhel9-classic-sda と .img 拡張子より前の文字列が使用されました。そのため、.img 拡張子より前の文字列のみをスクリプトの VM_NAME に指定する必要がありました。
• 私が検証時に使用したシンボリックリンク生成スクリプトは以下のようなファイルで bash コマンドを実行しました。

createlink_sano_v2v_migrate_classic.sh

VM_NAME= rhel9-classic
TARGET_DEV=/dev/vdd

SYMLINK="/tmp/${VM_NAME}-sda"
ln -fs "${TARGET_DEV}" "${SYMLINK}"
ls -l "${SYMLINK}"

• virt-v2v 変換時のコマンドは以下となります。環境に応じて適宜変更ください。
  • export LIBGUESTFS_BACKEND=direct
  • virt-v2v -i disk /var/work/rhel9-classic.img -o disk -os /tmp --run nwscript-update.sh
    • 上記コマンドの nwscript-update.sh については以下リンクの「5. 各移行ステップの詳細」にある「Step 3-5. 変換の実行(RHEL)」を参照ください。同じスクリプトで変換できました。
      • Step 3-5. 変換の実行(RHEL)

Step 7: boot diskをデタッチ

• blockdev --flushbufs を使って対象ブロックデバイスに関連するページキャッシュをフラッシュしてから、変換イメージを書き込んだboot diskをdetachします。

Step 8: boot diskを使って新規プロビジョニング

• このboot diskを使ってVSIをプロビジョニングします。Step5の注意点にありますように、Secure Bootは有効にせず起動しました。
• 上記 Step5 に説明があるプロファイルですが、私の環境では移行元がUEFIであったため、bx3プロファイルを選択しました。

Step 9: 作成した VSI へアクセス確認

• Step 8 で作成した VSI へ ssh アクセスを確認します。
• VSI for VPC で新規作成した場合、デフォルトのログインユーザー名は "vpcuser" ですが、Classic VSI から移行した場合はこちらでログインができませんでした。
  • IBM Cloud Docs:Linux インスタンスへの接続
  • 「デフォルトのユーザーアカウントを決定する」の章を参照ください
• 作成した VSI へアクセスする場合、Classic VSI 上で使用していたユーザー名を利用してアクセスする必要がありました。私の環境では検証時、rootユーザーしか存在していなかったため root でログインできました。
• Classic VSI ではパスワード認証で ssh アクセスをしていましたが、VPC for VSI ではパスワード認証ではなく、VSI 作成時に指定した証明書を用いて認証を行う必要がありました。
• これらは cloud-init の設定が関係してきますため、移行時は移行元であるClassic環境のVSI上で cloud-init の設定を確認、編集した上で移行を計画するのが良いと思われます。

Step8 で作成した VSI へ ssh アクセス

sanoyuki@sanoyukinoMacBook-Pro ssh % ssh -i sano2796626_rsa.prv root@10.239.0.15
Register this system with Red Hat Insights: rhc connect

Example:
# rhc connect --activation-key <key> --organization <org>

The rhc client and Red Hat Insights will enable analytics and additional
management capabilities on your system.
View your connected systems at https://console.redhat.com/insights

You can learn more about how to register your system
using rhc at https://red.ht/registration
Last failed login: Sun May 24 23:14:33 CDT 2026 from 10.244.65.4 on ssh:notty
There were 3 failed login attempts since the last successful login.
Last login: Sun May 24 23:11:47 2026 from 10.244.65.4
[root@sano-classic-isoboot-0522 ~]#