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

1. 移行の方法の選択

VMware 環境から IBM Cloud の VSI for VPC に移行する際には、さまざまな考慮点が存在します。単にサーバーを移行するだけでも、イメージ変換や virtio ドライバーのインストールなど、多くの作業が必要です。
こうした移行を開始するにあたり、Scott Moonen 氏の記事を最初にご一読ください（日本語翻訳版はこちら）。彼の記事は素晴らしくまとまっており、サーバー移行に必要なエッセンスが凝縮されています。

一般的に、移行方法としては以下の二つの方式に大別されます。

(a) VM イメージを基にまず Custom Image を作成し、その Custom Image を使用して VSI for VPC をプロビジョニングする方法

• 汎用的に繰り返しプロビジョニング可能な Custom Image を作成し、それを基に VSI for VPC を展開する方式です。IBM Cloud Docs にも記載されている一般的な方法ですが、個人的に不満に感じている点があります。それは、この方法では 1 VM の移行につき 1 つの Custom Image が必要となり、しかもその Custom Image は移行時に一度しか使用されない という点です。本来、Custom Image の存在意義は、同一構成のサーバーを繰り返しプロビジョニングするためのテンプレートとして利用することにあります。しかし移行においては、一度しかプロビジョニングしないサーバーのためだけに作成されるテンプレート となってしまっており、本来の目的から外れていると感じています。
• Custom Image を構築するには、単に qcow2 形式へ変換すればよいというわけではありません。あくまで作業の一例ですが、Linux 環境では 例えばVMware Toolsのアンインストール、virtio ドライバーのインストール、カーネルパラメーターの変更、initramfs/initrd の再生成、/etc/fstab の修正、cloud-init のインストールおよび設定、DHCP への変更などが必要になります。また、Windows 環境では、例えば virtio ドライバーのインストール、cloudbase-init のインストールおよび設定、sysprep の実行といった事前準備が必須です。繰り返しになりますが、これらはあくまで必要作業の一例であり、例えばRHEL9以降でLVMを利用している場合は、/etc/lvm/devices/system.devicesによるデバイスフィルタリングなども考慮しなければいけないでしょう。また、Linux 環境では cloud-init によって既存の SSH 設定や root パスワード設定が意図せず変更される可能性があり、Windows 環境では sysprep がシステム構成に与える影響もあるため、これらの影響を十分に理解したうえで作業を行う必要があります。
• boot disk は Custom Image に紐づくため、たとえば 100 台の VM を移行する場合、100 個の Custom Image を作成する必要があります。さらに、その Custom Image を基にプロビジョニングされた VSI が削除されない限り、元となる Custom Image も削除できないという制限もあります。
• よって、Custom Image はテンプレートとして複数サーバーを展開する際には非常に強力な仕組みですが、移行のためだけに使用するというアプローチは本来の利用目的に合っていないのではないか と考えており、個人的にはこの方式をあまり好きではありません。

(b) VM イメージの変換データを直接 Boot Disk（Block Storage）に書き込んで移行する方法

• この方法は、Custom Image を作成せず、移行対象の boot disk に変換済みイメージを直接書き込むことで移行を実現する方式です。この方法では Custom Image を作成する場合と異なり、意図せず既存サーバーの設定が書き換えられる可能性は非常に低くなります。

• すでに VMware 環境上で OS ライセンスを持ち込み利用しており、そのライセンスを IBM Cloud でも継続して利用する場合には、IBM Cloudへの登録作業が不要となるため、cloud-init/cloudbase-init のインストールさえ不要です。しかし、IBM Cloud 提供の RHEL／Windows ライセンスを利用したい場合は cloud-init/cloudbase-init の事前導入が必要になります。また、移行後にその VSI for VPC を基に Custom Image を作成したくなった場合も、やはりcloud-init/cloudbase-initのインストールが必要になります。

• この方法を実施する際にもいくつかアプローチがありますが、私は特に Scott さんの記事で紹介されている “Method 4: Direct copy to VPC volumes using VDDK” をこの記事で特に取り上げたいと考えています。その理由は、この方法であれば vCenter に接続でき、かつ移行対象の VM が安全に停止しているだけで良いので、事前に VM にログインして作業を行う必要がほぼ不要と言って良いためです。この方法では、virt-v2vというツールを利用しますが、正しく環境さえセットアップできれば、

  • VMware Toolsのアンインストール（とはいえ、virt-v2vの公式docsに記載されている通り、Windows環境においてはうまくいかないことが多いです。事前にアンインストールしておくか、サーバー移行後に手動でアンインストールする必要があるかもしれません）
  • virtioドライバのインストール
  • ブート設定(Linuxならinitramfs/initrd再生成や/etc/fstabの修正、Windowsならレジストリ変数の変更やドライバサービス登録など）
  • ネットワーク設定
  • qemu-guest-agentのインストール
  • イメージの変換

  などの一連の作業を自動化しており、ほぼ “コマンド一発” で移行に必要な作業の大部分を完了できます。特に、 Windows 環境では、virtio ドライバーは単にインストールしただけでは有効に機能しません。virtio デバイスがサーバーに割り当てられた際に、それを OS に認識させる作業が必要であり、これが手間のかかる工程になります。このような既存のデバイスとデバイスドライバーの紐付けをリセットし、新たなデバイスにデバイスドライバーを認識させる作業は一般的にはsysprepでも自動化できますが、sysprepは影響範囲が大きいコマンドです。virt-v2v は virtio ドライバーを PnP デバイスとして初回起動時に利用できるように構成してくれるため、VSI for VPC の初回起動時に virtio デバイスが自動的に認識される ところまで処理してくれます。私は a)もb)もどちらの手法も試したことがありますし、b)の手法でもsysprepもvirt-v2vを使わずに手動での移行を試したことがありますが、細かな注意点が幾つかあり、それをOSごとやバージョンごとに落とし穴に気をつけながら実施するのはそれなりに大変な作業でした。virt-v2v はそうした一連の作業を自動化してくれるため、移行手法として非常に優れた方法だと思っています。

• 今回の移行方法では、コマンド一発で移行できるように vCenter に直接接続する方式を採用しています。しかし、IBM Cloud の VCF as a Service のように、エンドユーザーが vCenter や ESXi に直接接続できない環境では、一度 VM 関連ファイルを Converter VSI にエクスポートし、その後 virt‑v2v を実行してローカルファイルから変換するといった方法も可能です。ただし、その手順はvirt-v2vのオプションを変更するだけであり、その手順は今回のやり方を理解していればほぼ自明だと思われるため、本記事ではその手順の詳細説明は割愛しています。

• IBM CloudのVCF for ClassicはGuest OSのライセンスはBYOLであることを前提としています。もしVSI for VPCに移行するタイミングでIBM Cloud提供のライセンスに切り替えたい場合は、あらかじめcloud-init/cloudbase-initをインストールしておけば、boot diskからの起動時にIBM Cloud固有の初期化が実施されます。これについてもこの記事ではその詳細まで説明していません。

2. virt-v2v + VDDKの概要を利用してVMware環境(VCF for Classic on IBM Cloud)からの移行を動作確認したOSの一覧

私はこの手法にて、以下の日本語のOS環境でVMware環境(VCF for Classic on IBM Cloud)からVSI for VPCへの移行がうまく動作することを確認しました。

• Linux
  • RHEL9
  • RHEL8
  • RHEL7
  • RHEL6-64bit
  • RHEL6-32bit
  • RHEL5.11 (64bit)
• Windows
  • Windows Server 2025
  • Windows Server 2025 (Domain Controller)
  • Windows Server 2022
  • Windows Server 2019
  • Windows Server 2016

これ以外の環境でも後述するスクリプトを改修すれば動作する可能性はありますが、テスト環境の準備が難しいのと、時間的制約のため、私自身は他のバリエーションを検証できていません。今後他のOSも検証できた際には、この記事を更新したいと思います。

3. 移行の流れの概要

以下の図を使って大まかな移行の流れを説明します。

• Step 1: 移行用の boot disk を作成するため、暫定的に VSI for VPC をプロビジョニングします。IBM Cloud には boot disk のみ を単体で注文する機能がないため、VSI for VPCをプロビジョニングするというステップを最初に踏む必要があります。この VSI for VPC は、あくまで boot disk を作成するためだけの暫定環境 であり、実際には使用しません。
• Step 2: 暫定的に作成した VSI for VPC を削除し、boot disk を獲得します。
• Step 3: boot disk を変換用 VSI（Converter VSI）にアタッチし、その後、Converter VSI 上で virt‑v2v コマンドを実行し、vCenter に接続します。内部的にはVDDK を利用することで VMware 環境の VMDK ファイルへ効率的にアクセスでき、対象 VM が配置されている ESX ホストから Converter VSI へのデータ転送が開始されます。virt-v2vは、virtio ドライバーのインストールなどの変換処理を行ったうえで、VMware 環境の VM の内容が boot disk に書き込みます。この処理は、基本的には コマンド一つで実行可能 です。
  また、この処理を実行するにあたり、VMware 側の VM が正常に停止していることが必須条件 です。なお、VPC 環境と IBM Cloud の VMware 環境の間は、Transit Gateway によって事前に接続され、疎通が確保されていること が前提となります。
• Step 4: 変換が完了した boot disk をデタッチします。
• Step 5: この boot disk を使用して VSI for VPC をプロビジョニングします。Windows 環境では、初回起動時に複数回の再起動が行われ、virtio ドライバーのセットアップなどが自動的に実施されます。

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

4. Converter VSIの準備

4-1. Fedora環境の準備

virt-v2vは、IBM Cloud VPCのWindows Server環境のために"--block-driver virtio-scsi"オプションが必要であり、尚且つnbdkitでVMware Virtual Disk Development Kit (VDDK)プラグインがサポートされている必要があります。virt-v2vのBuild imageにはRHEL系とUbuntu系があり、前者は"--block-driver virtio-scsi"が含まれておらず、後者はライセンスの問題でVDDKプラグインが含まれていなかったりと、両方の条件を揃えるのが大変です。Red Hatは意図的に"--block-driver virtio-scsi"を削除したようですが、このオプションなしでは私はWindows ServerをうまくVSI for VPC上で動かせませんでした。
https://access.redhat.com/errata/RHBA-2023:6376
https://bugzilla.redhat.com/show_bug.cgi?id=2190387

SLESはその両方をサポートしていますが、vpx driverをnativeサポートしていないため、vCenterに接続できません。これらの要件を満たすためには、virt-v2vをsourceコードからコンパイルするしかないのかもしれませんが、実際にそれを試みようとするととても大変な作業であることがわかります。

IBM Cloudの標準イメージで利用可能な様々なOSを試してみたところ、Fedoraはこの全ての要件を満たしているOSでした。しかし、IBM CloudはFedora CoreOSしか提供していません。Fedora CoreOSでも実際はこの変換処理は上手くいくことは確認していますが、/usrなど幾つかのディレクトリに書き込みができないとか、様々な制約があることに注意して利用する必要があります。私はFedora CoreOSではなく普通のFedoraを自分でKVM環境を利用してインストールしてVSI for VPCとして動かしていますが、その話は本筋からズレるので機会があれば別の記事で書きたいと思います。私自身は特に何も制約のないFedoraを構築して利用することを推奨しますが、Fedora CoreOSでも稼働するので、その構成例を以下で説明します。

なお、virt-v2vの実行をする上で、ネットワーク速度はとても重要です。このConversion VSIからvCenterやESXへのlatencyが2msec程度以内でないのであれば、適切なTransit Gatewayを利用されておらず、例えばGlobal Transit Gatewayが使われていて別のリージョンを経由しているとか、適切なリージョンにConversion VSIが構築されていない可能性があります。これらの問題は必ず事前に是正しておくことを推奨します。

4-2. モジュールのインストール

Fedora CoreOSへのSSHは、rootユーザーではなく、coreユーザーで行う必要があるので注意してください。

core@syasuda-converter-fedora:~$ sudo su -
root@syasuda-converter-fedora:~# systemctl stop zincati.service
root@syasuda-converter-fedora:~# rpm-ostree upgrade
root@syasuda-converter-fedora:~# rpm-ostree install virt-v2v

必須ではないが、別途自分が利用したいツールをインストール

root@syasuda-converter-fedora:~# rpm-ostree install screen tcpdump iftop

インストールを反映するために再起動

root@syasuda-converter-fedora:~# systemctl reboot

環境確認

root@syasuda-converter-fedora:~# cat /etc/os-release
NAME="Fedora Linux"
VERSION="43.20260105.3.0 (CoreOS)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=43
VERSION_CODENAME=""
PRETTY_NAME="Fedora CoreOS 43.20260105.3.0"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:43"
HOME_URL="https://getfedora.org/coreos/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-coreos/"
SUPPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
BUG_REPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=43
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=43
SUPPORT_END=2026-12-02
VARIANT="CoreOS"
VARIANT_ID=coreos
OSTREE_VERSION='43.20260105.3.0'
IMAGE_VERSION='43.20260105.3.0'

root@syasuda-converter-fedora:~# uname -a
Linux syasuda-converter-fedora 6.17.12-300.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Dec 13 05:06:24 UTC 2025 x86_64 GNU/Linux

virt-v2vのバージョン確認と、--block-driverオプションが存在することを確認

root@syasuda-converter-fedora:~# virt-v2v --version
virt-v2v 2.10.0fedora=43,release=1.fc43

root@syasuda-converter-fedora:~# virt-v2v --help | grep "block"
  --block-driver <driver>             Prefer 'virtio-blk' or 'virtio-scsi'

vddkプラグインがインストールされていることを確認

root@syasuda-converter-fedora:~# rpm -qa|grep vddk
nbdkit-vddk-plugin-1.46.1-1.fc43.x86_64

root@syasuda-converter-fedora:~# nbdkit vddk --dump-plugin
path=/usr/lib64/nbdkit/plugins/nbdkit-vddk-plugin.so
name=vddk
version=1.46.1
api_version=2
struct_size=384
max_thread_model=parallel
thread_model=parallel
errno_is_preserved=0
magic_config_key=file
has_longname=1
has_unload=1
has_dump_plugin=1
has_config=1
has_config_complete=1
has_config_help=1
has_get_ready=1
has_after_fork=1
has_open=1
has_close=1
has_get_size=1
has_block_size=1
has_can_flush=1
has_can_extents=1
has_can_fua=1
has_pread=1
has_pwrite=1
has_flush=1
has_extents=1
vddk_default_libdir=/usr/lib64/vmware-vix-disklib
vddk_has_nfchostport=1
vddk_has_fnm_pathname=0

4-3. VDDKのインストール

今回は移行対象のVMware環境がvSphere8だったので、VMware Virtual Disk Development Kit (VDDK) 8.0.3 for Linuxを使用しています。

• VDDK v9.0: https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/latest
• VDDK v8.0: https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/8.0
• VDDK v7.0: https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/7.0
• VDDK v6.7: https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/6.7

root@syasuda-converter-fedora:~# tar -xvzf VMware-vix-disklib-*.x86_64.tar.gz -C /opt
root@syasuda-converter-fedora:~# chown -R root:root /opt/vmware-vix-disklib-distrib/
root@syasuda-converter-fedora:~# ls -l /opt/vmware-vix-disklib-distrib/
total 16
-rw-r--r--. 1 root root 8034 May 27  2024 FILES
drwxr-xr-x. 2 root root   73 Jan 23 02:47 bin64
drwxr-xr-x. 6 root root 4096 Jan 23 02:47 doc
drwxr-xr-x. 2 root root   95 Jan 23 02:47 include
drwxr-xr-x. 2 root root    6 May 27  2024 lib32
drwxr-xr-x. 2 root root 4096 Jan 23 02:47 lib64

4-4. /etc/hostsの設定

vCenter/ESXのhostnameに対して名前解決ができる必要があります。

/etc/hosts

# Loopback entries; do not change.
# For historical reasons, localhost precedes localhost.localdomain:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
# See hosts(5) for proper format and other examples:
# 192.168.1.10 foo.example.org foo
# 192.168.1.13 bar.example.org bar


10.173.1.3  vcsosv-vc.acs.japan.local
10.173.166.232 host-km000.acs.japan.local
10.173.166.227 host-km001.acs.japan.local
10.173.166.198 host-km002.acs.japan.local

4-5. vCenterのFingerprintを確認

vCenterのFingerprintを確認

root@syasuda-converter-fedora:~# echo | openssl s_client -connect vcsosv-vc.acs.japan.local:443 2>/dev/null   | openssl x509 -noout -fingerprint -sha1
sha1 Fingerprint=D2:AE:CF:26:22:8C:89:13:A4:67:89:19:7F:64:1C:97:35:C8:11:54

4-6. vCenterのパスワードをファイルに格納

vCenterのパスワードをファイルに格納

root@syasuda-converter-fedora:~# echo <"vCenter Password"> > vcenter_passwd.txt
root@syasuda-converter-fedora:~# chmod 600 vcenter_passwd.txt

4-7. virtio-winの準備(Windows環境で必要）

Windows環境ではvirtioドライバーをインストールする必要があるため、そのためのisoファイルが必要です。fedoraのサイトから最新のvirtioドライバーをダウンロードすることはできますし、それでも動く環境があるのはわかっていますが、RHELから署名を受けたドライバーである方が確実に稼働するという情報もWebサイト上には散見されます。そのため、私はIBM Cloud上でRHEL9をプロビジョニングし、dnf install virtio-winを実行すると/usr/share/virtio-win/配下にisoイメージがダウンロードできます。これをこのVSIにコピーしてきます。

root@syasuda-converter-fedora:~# ls -l virtio-win-1.9.50.iso
-rw-r--r--. 1 root root 645939200 Jan 23 02:52 virtio-win-1.9.50.iso

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

Step 1: ephemeral VSIの注文

• 今回の移行方法では、VSI for VPC の boot disk に対して、変換後のイメージを直接書き込みます。しかし IBM Cloud では、boot 可能な disk を単体で直接作成する機能がありません。そのため、まず暫定的な VSI（以下、ephemeral VSI）を作成する際に、boot disk の Auto-delete 属性を No に設定します。その後、注文完了後すぐにこの ephemeral VSI を削除することで、boot disk のみを残します。この boot disk は後続の手順で上書きされるため、ephemeral VSI が正常に起動する必要はありません。そのため、私は通常、ephemeral VSI を注文した直後に Stop ボタンを押し、続いて Force stop を実行してサーバーを停止させたうえで VSI を削除する、という手順を踏んでいます。これにより、一連の処理を高速に進めることができます。

• boot diskはOS属性を持ち、VSIが削除された後もその情報を持ち続けます。そして、その情報を使ってVSI for VPCは内部的にlibvirt domain XMLを構成していると考えられます。例えば、Windows環境ではvirtio-scsiで起動してほしいのですが、もしboot diskの持つOS属性がLinuxの場合は、IBM Cloud内部ではvirtio-blkを利用するように内部的に指定されてしまう可能性があります。そのため、boot diskを作成する上でephemeral VSIはできれば移行したいOS環境の情報を反映したものにすることが望ましいです。CentOS9属性を持つboot diskでFedoraやRHELを動かすことに関して特に問題はありませんでしたが、そのboot diskでWindows Serverを動かすことは一般的には失敗します。実際、私は当初boot diskであれば何でも良いと思っていて、IBM Cloud提供の標準イメージを使ってcentos-stream-9-amd64のephemeral VSIを作成し、そのboot diskを使ってWindows Serverを移行しようとしたため、数々の問題にハマってしまいました。例えば、virtioドライバーが自動的に認識されなかったり、Secure BootをdisableにするとWindows Serverが起動しないのに、Secure BootをenableにするとWindows Serverが起動するという奇妙な問題に遭遇したこともありました。
  

• boot diskの属性でもう一点注意しないといけないのは、BYOLの有無です。通常、IBM Cloud上のVMware(例えばVCF for Classic)において、そのGuest OSのライセンスはBYOLです。しかし、IBM Cloud提供の標準イメージを利用すると、IBMからライセンス料金が課金されてしまいます。そのため、この環境をBYOLのまま移行するためには、このboot diskに対してもBYOL属性を持っていないと別途課金される可能性があります。Custom Imageは実際には動くものである必要はないため、以下のようにqcow2フォーマットのファイルを作成してICOSにuploadした後、このファイルを使ってCustom Imageを作ることができます。OSの種類を選択する際には、BYOLとなっているものから選択してください。

[root@fedora ~]# dd if=/dev/zero bs=1M count=1 of=zero.img
[root@fedora ~]# qemu-img convert -f raw -O qcow2 zero.img zero.qcow2

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

VSIを削除します。繰り返しですが、VSIを削除する前に、このboot diskの属性がAuto-delete=noになっていることを改めて確認してください。そうでないと、VSIを削除すると同時にこのboot diskまで削除されてしまいます。この操作により、どのVSIにも紐づいていないboot diskが用意されます。

Step 3: boot diskをConverter VSIにアタッチしてvirt-v2vを実行

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

必要に応じてサイズを増やしておいてください。上記の手順に従って作成したCustom Imageに基づいて作成した場合、boot diskは最小の10GBとして構成されているはずです。IBM Cloud提供のデフォルトのImageを利用した場合、boot diskは100GBが最小単位となっていますが、この方式だと10GBから250GBの任意のサイズに変更することができます。VMware側では今回の移行対象のVMは16GB利用しているため、その場合はboot diskを16GB以上に増やす必要があります。
ただし、2026/01/22時点では、boot diskの上限は250GBであることに注意してください。また、一度大きくしたら小さくはできないことにもご注意ください。ディスクサイズを250GBより大きくすると以下のようにboot diskとして認識しなくなります。この制限事項は近い将来解消される予定です。

• 250GBより大きくしてしまってboot diskとして利用できなくなってしまった失敗例

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

/dev/vddが割り当てられた。

root@syasuda-converter-fedora:~# lsblk -pf
NAME        FSTYPE  FSVER            LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
/dev/vda
├─/dev/vda1
├─/dev/vda2 vfat    FAT16            EFI-SYSTEM 7B77-95E7
├─/dev/vda3 ext4    1.0              boot       99d3b227-8df4-44aa-9e03-c7f3dbc6b118   44.4M    81% /boot
└─/dev/vda4 xfs                      root       d0463b38-8446-453c-83bf-8d7a8a6f8b60   91.4G     8% /var
                                                                                                    /sysroot/ostree/deploy/fedora-coreos/var
                                                                                                    /sysroot
                                                                                                    /etc
/dev/vdb    iso9660 Joliet Extension cidata     2026-01-23-02-05-26-00
/dev/vdc    swap    1                SWAP-xvdb1 7cd086aa-8f57-4ef4-a5d0-53dae14dc808
/dev/vdd

Step 3-3. リンクを作成

Scottさんの記事やvirt-v2vのガイダンスにあるように、virt-v2vは出力ディレクトリを指定することはできますが、ファイル名を指定することはできません。そのため、例えば以下のようなスクリプトを実行して、/tmpディレクトリへの出力が、自動的に追加したboot disk(今回のケースでは/dev/vdd）に書き込まれるように構成しておきます。

createlink_win2022-1.sh

VM_NAME=syasuda-win2022-1
TARGET_DEV=/dev/vdd

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

root@syasuda-converter-fedora:~# bash createlink_win2022-1.sh
lrwxrwxrwx. 1 root root 8 Jan 23 03:41 /tmp/syasuda-win2022-1-sda -> /dev/vdd

Step 3-4. VMware環境上のVMの正常停止

VMが正常にshutdownしていることを確認してください。
変換中にWindows Updateが走ったり、ドライバーの更新が行われるようなことがないことを確認してください。私は、Windows Updateの自動更新を止めるタイミングが悪かったのか、ダウンロードとインストールを試行する途中だったため、再起動の際に毎回Windows Updateを試みようとし、それが原因でVSI for VPCに変換後に再起動がループしてしまう経験をしました。

Step 3-5. 変換の実行(RHEL)

• 実行時にはVMが存在するESXのホスト名が指定されている必要があります。
• nwscript-update.shというカスタムスクリプトを実行しています。
  • RHEL では、VSI for VPC の標準イメージの構成に合わせて、predictable interface（例：enp0s1, ens192, etc...）ではなく、traditional interface（例：eth0, eth1, etc..）を利用する構成としています。あわせて、推奨パラメーターの設定やネットワーク構成のリセットを行うため、virt-v2v の実行時に以下のスクリプトを指定しています。
  • このスクリプトの実行は必ずしも必須ではありませんが、こうしたスクリプトを実行しない場合、後から VNC Console でログインし、手動でネットワーク構成を行う必要が生じる可能性があります。私は、プロビジョニング直後から追加設定を行うことなく移行先の VSI に接続したいため、このようなスクリプトを実行するように設定しています。
  • このスクリプトはRHELでしか検証していませんし、Ubuntuや他のOSではそのままでは動かないと思いますが、容易に拡張できると思います。

RHELでの実行例

root@syasuda-converter-fedora:~# export LIBGUESTFS_BACKEND=direct
root@syasuda-converter-fedora:~# virt-v2v -ic 'vpx://[e-mail]/IBMCloud/vcs-osv-cluster/host-km000.acs.japan.local?no_verify=1' -it vddk -io vddk-libdir=/opt/vmware-vix-disklib-distrib/ -io vddk-thumbprint=D2:AE:CF:26:22:8C:89:13:A4:67:89:19:7F:64:1C:97:35:C8:11:54  "syasuda-rhel9-2" -ip vcenter_passwd.txt -o disk -os /tmp --run nwscript-update.sh
[   0.0] Setting up the source: -i libvirt -ic vpx://[e-mail]/IBMCloud/vcs-osv-cluster/host-km000.acs.japan.local?no_verify=1 -it vddk syasuda-rhel9-2
[   1.6] Opening the source
[  10.3] Checking filesystem integrity before conversion
[  31.5] Detecting if this guest uses BIOS or UEFI to boot
[  31.8] Inspecting the source
[  35.0] Detecting the boot device
[  35.1] Checking for sufficient free disk space in the guest
[  35.1] Converting Red Hat Enterprise Linux 9.7 (Plow) (rhel9.7) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  85.9] Setting a random seed
[  86.0] Running: nwscript-update.sh
[  89.8] SELinux relabelling
[  96.6] Mapping filesystem data to avoid copying unused and blank areas
[  97.4] Checking filesystem integrity after conversion
[  99.6] Closing the overlay
[  99.6] Assigning disks to buses
[  99.6] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  99.6] Setting up the destination: -o disk -os /tmp
[ 101.1] Copying disk 1/1
█ 100% [****************************************]
[ 450.4] Creating output metadata
virt-v2v: warning: get_osinfo_id: unknown guest operating system: rhel9.7
[ 450.4] Finishing off

nwscript-update.sh

#!/bin/bash
set -e

############################################
# CentOS/RHEL 7+ (update kernel parameter)
############################################
if grep -qE "release (7|8|9|10)" /etc/redhat-release; then
  GRUB_CFG="/etc/default/grub"
  CMDLINE=$(grep '^GRUB_CMDLINE_LINUX=' "$GRUB_CFG" | cut -d'"' -f2)
  CMDLINE_DEFAULT=$(grep '^GRUB_CMDLINE_LINUX_DEFAULT=' "$GRUB_CFG" | cut -d'"' -f2)
  [[ "$CMDLINE_DEFAULT" != *net.ifnames=0* && "$CMDLINE" != *net.ifnames=0* ]] && CMDLINE="$CMDLINE net.ifnames=0"
  [[ "$CMDLINE_DEFAULT" != *biosdevname=0* && "$CMDLINE" != *biosdevname=0* ]] && CMDLINE="$CMDLINE biosdevname=0"
  [[ "$CMDLINE_DEFAULT" != *vga=normal* && "$CMDLINE" != *vga=normal* ]] && CMDLINE="$CMDLINE vga=normal"
  [[ "$CMDLINE_DEFAULT" != *console=tty1* && "$CMDLINE" != *console=tty1* ]] && CMDLINE="$CMDLINE console=tty1"
  [[ "$CMDLINE_DEFAULT" != *console=ttyS0* && "$CMDLINE" != *console=ttyS0* ]] && CMDLINE="$CMDLINE console=ttyS0"
  sed -i "s|^GRUB_CMDLINE_LINUX=.*|GRUB_CMDLINE_LINUX=\"$CMDLINE\"|" "$GRUB_CFG"
  # For RHEL7
  grub2-mkconfig -o /boot/grub2/grub.cfg 2>/dev/null || true
  # For RHEL8+
  grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline 2>/dev/null || true
fi


############################################
# Network Settings
############################################
rm -f /etc/NetworkManager/system-connections/* || true
rm -f /etc/sysconfig/network-scripts/ifcfg-* || true
rm -f /etc/sysconfig/network-scripts/route-* || true
rm -f /etc/udev/rules.d/70-persistent-net.rules || true


#keyfile for Network Manager
if grep -qE "release (7|8|9|10)" /etc/redhat-release; then
  cat <<EOF >/etc/NetworkManager/system-connections/dhcp-any.nmconnection
[connection]
id=dhcp-any
type=ethernet
autoconnect=true

[ipv4]
method=auto

[ipv6]
method=disabled
EOF

  chmod 600 /etc/NetworkManager/system-connections/dhcp-any.nmconnection
fi

#ifcfg for Network Manager or Legacy RHEL/CentOS
IFCFG_FILE="/etc/sysconfig/network-scripts/ifcfg-eth0"
cat > "$IFCFG_FILE" <<EOF
BOOTPROTO=dhcp
DEVICE=eth0
ONBOOT=yes
TYPE=Ethernet
EOF
chmod 600 "$IFCFG_FILE"

Step 3-5. 変換の実行(Windows)

• 実行時にはVMが存在するESXのホスト名が指定されている必要があります。
• VIRTIO_WIN環境変数を設定して、virtioドライバーの場所を明示的に指定しています。
• --block-driver virtio-scsiオプションの指定が必要です。

Windowsでの実行例

root@syasuda-converter-fedora:~# export LIBGUESTFS_BACKEND=direct
root@syasuda-converter-fedora:~# export VIRTIO_WIN=/root/virtio-win-1.9.50.iso
root@syasuda-converter-fedora:~# virt-v2v -ic 'vpx://[e-mail]/IBMCloud/vcs-osv-cluster/host-km001.acs.japan.local?no_verify=1' -it vddk -io vddk-libdir=/opt/vmware-vix-disklib-distrib/ -io vddk-thumbprint=D2:AE:CF:26:22:8C:89:13:A4:67:89:19:7F:64:1C:97:35:C8:11:54  "syasuda-win2022-1" -ip vcenter_passwd.txt --block-driver virtio-scsi -o disk -os /tmp
[   0.0] Setting up the source: -i libvirt -ic vpx://[e-mail]/IBMCloud/vcs-osv-cluster/host-km001.acs.japan.local?no_verify=1 -it vddk syasuda-win2022-1
[   1.6] Opening the source
[  11.1] Checking filesystem integrity before conversion
[  11.7] Detecting if this guest uses BIOS or UEFI to boot
[  12.2] Inspecting the source
[  15.6] Detecting the boot device
[  15.6] Checking for sufficient free disk space in the guest
[  15.6] Converting Windows Server 2022 Standard Evaluation (win2k22) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  30.8] Setting a random seed
virt-v2v: warning: random seed could not be set for this type of guest
[  30.8] SELinux relabelling
[  31.0] Fixing NTFS permissions
[  31.0] Mapping filesystem data to avoid copying unused and blank areas
[  31.8] Checking filesystem integrity after conversion
[  32.3] Closing the overlay
[  32.4] Assigning disks to buses
[  32.4] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  32.4] Setting up the destination: -o disk -os /tmp
[  34.0] Copying disk 1/1
█ 100% [****************************************]
[ 383.6] Creating output metadata
[ 383.6] Finishing off

Step 4: boot diskをデタッチ

変換イメージを書き込んだboot diskをdetachします。

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

このboot diskを使ってVSIをプロビジョニングします。
この初回プロビジョニングのタイミングでは、Secure Bootは有効にしないでください。

また、移行先サーバーのプロファイルに注意してください。

• bx2プロファイル(Cascade Lake)は、BIOSモードでのみ起動します。UEFIモードでは起動できません。そのため、移行元環境がUEFIを前提としている場合、このプロファイルではブートできません。
• bx3プロファイル(Sapphire Rapids)やbxf(Flex Profile)は、OS構成を自動的に検知し、BIOSモードまたはUEFIモードのいずれかで起動します。

結果は以下の通りです。

• RHEL: すでに構成済みの状況で起動してきます。

• Window: 初回セットアップに伴う再起動が何回か行われます。その動作を止めないようにしてください。