2026/06/26 追記
IBM Cloud VCFaaSからの移行を検証しました。
2026/06/26 追記
「IBM Cloud: VSI for VPCのboot volumeが32TBまで拡張されたので試してみた」の変更により、新たにデフォルトなったsdp profileでは、Windowsからの変換オプションに変更が必要です。
詳しくは、下記の追記を確認してください。
2026/05/20 追記
VSI for VPCのboot volumeが32TBに対応しました。これで、250GB以上のboot volumeを持つVMも、この方法で移行可能です。
詳細は、@shiyasu (Shinobu Yasuda)さんのこちらでご確認ください。
2026/06/10 追記
VSI for VPCでストックイメージからデプロイする時の最低ボリュームサイズが、Linuxではストックイメージの更新時にみなおされているようです。
Centosは10GB、RHELは「01/29/26 19:17:59」更新の「ibm-redhat-9-4-minimal-amd64-13」を除き、20GBになっていました。
ただし、Standard EditionのWindowsは100GBのままでした。
- 試行錯誤により記事が読みづらくなったので記事全体の整理を行いました
- RHEL8でのOVFからの移行検証を追記しました
- 100GBより小さなVSI for VPCへの移行とWindows/RHLEをBYOLで移行する方法は、この投稿にまとめました
- 複数Diskを持ったWindowsのOVFでの移行の検証結果を、この投稿にまとめました
-
cloud-init/cloudbase-initの導入やVMの停止が必要ですので、事前テスト用にVMのクローンを作成して、それで検証を進めることをお勧めします - 本番環境を移行する前に、ストレージ構成、OSタイプやBYOLなどのパターンを洗い出して、それ毎に事前テストを行い、手順/パラメータ/処理時間/利用すべきプロファイルを確認した方がいいと思います
- 本番移行時に複数の移行を同時並行で行うと、環境によってはボトルネックが発生するかもしれません(今回はVMのエクスポートでした)。移行時間にゆとりを持たせる/移行並行数を増やしすぎないことも考えるといいかももしれません
はじめに
ハイパーバイザーの移行については、
- Diskフォーマットを変換する
- ハイパーバイザーに合わせたドライバーの導入/切り替えをする
が必要です。
今回は、VMwareからIBM Cloud VSI for VPCで利用しているKVMへの移行がそれにあたります。
そのために、今回はvirt-v2vを使っています。
また、移行先でデプロイできるような方法も必要です。移行先がIBM Cloud VSI for VPCを想定しているため
-
cloud-init/cloudbase-initを利用する - qcow2への変換でなく、Boot DisKに変換結果を直接書き込んで、そこから新しいIBM Cloud VSI for VPCをオーダーする
- 必要があればIBM Cloud VSI for VPCに合わせて調整する
というのが、今回の特徴です。
「IBM Cloud : virt-v2v+VDDKを使ったVMware環境からVSI for VPCへのサーバー移行手順」という@shiyasu(Shinobu Yasuda)さんの記事が公開されています。以降、これを「記事」と記します。
「記事」では、VMware Virtual Disk Development Kit (VDDK)を使って変換作業用のVSIからvCenterに直接接続してVMware環境上のVMを読み込み、IBM CloudのVSI for VPC環境に移行しています。
今回は「記事」を後追いして、vCenterに直接接続するのではなくOVAファイルを利用してIBM Cloud VSI for VPCへのサーバーへ移行してみます。
OVAを使った移行について
OVAを使った移行について、「記事」では下記のようにコメントされています。
今回の移行方法では、コマンド一発で移行できるように vCenter に直接接続する方式を採用しています。しかし、IBM Cloud の VCF as a Service のように、エンドユーザーが vCenter や ESXi に直接接続できない環境では、一度 VM 関連ファイルを Converter VSI にエクスポートし、その後 virt‑v2v を実行してローカルファイルから変換するといった方法も可能です。ただし、その手順はvirt-v2vのオプションを変更するだけであり、その手順は今回のやり方を理解していればほぼ自明だと思われるため、本記事ではその手順の詳細説明は割愛しています。
実際に試みると自分のスキル不足・理解不足のため試行錯誤が必要でした。とりあえず、OVAを使った移行が出来たようなので、手順をまとめておきます。
こんな環境の場合には参考になると思います。
- そもそもvCenterにアクセスできない環境
- IBM Cloud の VCF as a Service(VCFaaS)環境
- vCenterが無いESXi環境(今回試したのはこちらです)
- Transit GatewayでのvCenterへの直接接続が困難な環境
- 移行元VMware環境がIBM Cloud上ではない
- 何らかの理由でvCenterと変換用のVSIが十分なネットワーク速度で接続できない
「記事」では下記の 記載もあります。
移行元がIBM CloudのVCF環境であっても、構成が適切でなければ、必ずしもVDDKを使った移行が安定してできるわけではないようです。
なお、virt-v2vの実行をする上で、ネットワーク速度はとても重要です。このConversion VSIからvCenterやESXへのlatencyが2msec程度以内でないのであれば、適切なTransit Gatewayを利用されておらず、例えばGlobal Transit Gatewayが使われていて別のリージョンを経由しているとか、適切なリージョンにConversion VSIが構築されていない可能性があります。これらの問題は必ず事前に是正しておくことを推奨します。
基本手順
基本的な手順は「記事」と同じです。ただし、vCenterへ接続しないので、VMをOVA形式でエクスポートして変換作業用のVSI(Converter VSI)のローカルファイルに保存しておく ステップが追加されています。
- 変換作業用のVSI(Converter VSI)をVPC上に用意
使い回せます。並行移行をしなければ、ひとつだけ用意すれば大丈夫です。並行移行するのであれば、その数だけ用意します。 - VMをOVA形式でエクスポート
Converter VSIへOVAを直接エクスポートしない場合は、追加でConverter VSIにOVAファイルを転送します。 - 移行先になるVM用のBoot Diskを用意
移行先のVSI for VPCの実態のDiskになります。 - Boot DiskをConverter VSIに接続
- virt-v2vを使ってOVAファイルの内容をBoot Diskに変換・書き込み
- Boot DiskをConverter VSIから切断
- Boot Diskを使って新しいVSI for VPCをオーダー
なお、今回はWindows11のVMware Workstation Pro上に導入したVMware vSphere Hypervisor(無償版ESXi)環境のVMを移行元に利用しています。
今回、構築した環境はこちらです。
2027/04/23 追記
変換作業用のVSI(Converter VSI)や、Boot Disk作成用のVSI、実際の移行先となるVSIと複数のVSIが必要になります。特に後者二つは、移行対象のVMの数だけ必要になります。
VSIのオーダー時にIPアドレス指定したい場合は、下記の記事が参考になると思います。
Converter VSIをVPC上に用意
変換作業用のVSI(Converter VSI)をVPC上にオーダー
変換作業用のConverter VSIをVPC上にオーダーします。Converter VSIは使い回せるため、並行して変換するのでなければ、1台用意すれば十分です。並行して変換する場合は並行する数だけ用意してください。
「記事」では、vCener接続のためにのVDDKとWindows変換のためのvirt-v2vのblock-driverオプションが必要であり、その共存のためにFedora CoreOSの利用が取り上げられていました。
「記事」からもリンクされている「IBM Cloud: 各OSに含まれているvirt-v2vとnbdkit VDDK pluginの状況について」で、各OSのVDDKとvirt-v2vのblock-driverオプションが確認できます。
ubuntu 24 標準のvirt-v2vには--runオプションが存在しない
今回はVDDKが不要なことと、「記事」でも使っていたFedora CoreOSではvirt-v2vを単純に導入しようとしたところエラーが出たので、慣れているUbuntu 24を利用しようとしました。しかし、標準で用意されているvirt-v2vが古く、利用しようと考えていた--runオプションが存在しませんでした。
カスタムスクリプトの利用を計画している場合は、ご注意ください。
root@onoda-converter-ubuntu24:~# virt-v2v --version
virt-v2v 2.4.0
root@onoda-converter-ubuntu24:~# virt-v2v --help | grep -e '--run'
root@onoda-converter-ubuntu24:~#
結局、「記事」に従ってFedora CoreOSで検証しています。
Fedora CoreOSを選択してVSI for VPCをオーダーします。
イメージは2026-02-25に更新されたようです。このためか、単純に「記事」の通りの実行では、後述のようにエラーが発生しました。
今回、ストレージはデフォルトのブートボリューム100GBだけ構成していますが、OVAファイルを保持できる十分なサイズを用意してください。
なお、OVAファイルは圧縮イメージのため対象VMの論理的なストレージサイズそのままを用意する必要はありません。
もちろん、サイズ変更やデータ・ボリュームを追加しても構いません。
Converter VSIのセットアップ
近頃、新規にデプロイしたIBM CloudのVSI for VPCのLinuxでは、セキュリティ強化のためrootでのログインが出来なくなっています。
代わりに「https://cloud.ibm.com/docs/vpc?topic=vpc-vsi_is_connecting_linux#determining-default-user-account」に記載があるとおりディストリビューション毎に設定されているデフォルトユーザーで接続します。
Fedora CoreOSの場合は「core」が設定されています。
ssh core@[ipアドレス]
C:\Users\onoda>ssh core@10.244.129.6
The authenticity of host '10.244.129.6 (10.244.129.6)' can't be established.
ED25519 key fingerprint is SHA256:4D6JlLf+GXa9V2pIzcMfQNy7AzFKohh14l1SwJpF0J4.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.244.129.6' (ED25519) to the list of known hosts.
Fedora CoreOS 43.20260202.3.1
Tracker: https://github.com/coreos/fedora-coreos-tracker
Discuss: https://discussion.fedoraproject.org/tag/coreos
root になっておきます。
sudo su -
core@onoda-converter-fedora:~$ sudo su -
root@onoda-converter-fedora:~#
「IBM Cloud: 各OSに含まれているvirt-v2vとnbdkit VDDK pluginの状況について-Fedora CoreOS 43」を参考に、パッケージを導入します。
「記事」にはlibvirtの導入については触れられていませんでしたが、今回の 手順では必要でした。OVAからの変換のための前提のようです。
systemctl stop zincati.service
rpm-ostree upgrade
rpm-ostree install virt-v2v libvirt libguestfs-tools
実行結果は、こちらです。
root@onoda-converter-fedora:~# systemctl stop zincati.service
root@onoda-converter-fedora:~# rpm-ostree upgrade
Pulling manifest: ostree-image-signed:docker://quay.io/fedora/fedora-coreos:stable
Importing: ostree-image-signed:docker://quay.io/fedora/fedora-coreos:stable (digest: sha256:ddba48fcf975b316c2a526648172fa7687a3ec3feb955c18d6494e8644e6ed11)
ostree chunk layers already present: 15
ostree chunk layers needed: 50 (771.2 MB)
custom layers needed: 1 (179 bytes)
[0/51] Fetching ostree chunk 334dd0ee32bb6c6ca97 (42.2 MB)... done
[1/51] Fetching ostree chunk 2774297c200f261ee0a (34.3 MB)... done
[2/51] Fetching ostree chunk cc215bcf01bac12ec22 (103.6 MB)... done
:
(中略)
:
[49/51] Fetching ostree chunk 745d5c03d97bb65f87f (1.6 MB)... done
[50/51] Fetching layer 24a85a4740abc8ccbea (179 bytes)... done
Staging deployment... done
Pruned images: 0 (layers: 39)
Freed: 575.3 MB (pkgcache branches: 0)
Upgraded:
afterburn 5.10.0-1.fc43 -> 5.10.0-3.fc43
afterburn-dracut 5.10.0-1.fc43 -> 5.10.0-3.fc43
:
(中略)
:
zincati 0.0.30-4.fc43 -> 0.0.32-1.fc43
zlib-ng-compat 2.3.2-2.fc43 -> 2.3.3-1.fc43
Run "systemctl reboot" to start a reboot
root@onoda-converter-fedora:~# rpm-ostree install virt-v2v libvirt libguestfs-tools
Checking out tree 9c75fe3... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'updates'... done
:
(中略)
:
rpm-md repo 'updates-archive'; generated: 2026-04-04T02:00:30Z solvables: 43347
Resolving dependencies... done
Will download: 201 packages (106.4 MB)
Downloading from 'fedora'... done
Downloading from 'updates-archive'... done
Downloading from 'updates'... done
Importing packages... done
Checking out packages... done
error: Checkout nfs-utils-1:2.8.7-1.fc43.x86_64: Hardlinking 4b/a781a32bc42d7b140bd2fdc0e3515572fe68b127481e28e4802e6ac53b3938.file to mount.nfs: File exists
root@onoda-converter-fedora:~#
「error: Checkout nfs-utils-1:2.8.7-1.fc43.x86_64: Hardlinking 4b/a781a32bc42d7b140bd2fdc0e3515572fe68b127481e28e4802e6ac53b3938.file to mount.nfs: File exists」とエラーになりました。
「IBM Cloud: 各OSに含まれているvirt-v2vとnbdkit VDDK pluginの状況について」の時から、Fedora Coreのイメージが更新されているので、その時にパッケージの依存関係に問題が発生したようです。
nfs-utilsで問題が発生しているようなので、いったん除去します。CoreOSなので除去もrpm-ostreeを使います。
rpm-ostree override remove nfs-utils-coreos
root@onoda-converter-fedora:~# rpm-ostree override remove nfs-utils-coreos
Checking out tree 9c75fe3... done
Resolving dependencies... done
Applying 1 override
Processing packages... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Freed: 445.2 MB (pkgcache branches: 201)
Upgraded:
afterburn 5.10.0-1.fc43 -> 5.10.0-3.fc43
afterburn-dracut 5.10.0-1.fc43 -> 5.10.0-3.fc43
:
(中略)
:
zincati 0.0.30-4.fc43 -> 0.0.32-1.fc43
zlib-ng-compat 2.3.2-2.fc43 -> 2.3.3-1.fc43
Removed:
nfs-utils-coreos-1:2.8.4-0.fc43.x86_64
Use "rpm-ostree override reset" to undo overrides
Run "systemctl reboot" to start a reboot
再度、導入します。
rpm-ostree install virt-v2v libvirt libguestfs-tools
root@onoda-converter-fedora:~# rpm-ostree install virt-v2v libguestfs-tools
Checking out tree 9c75fe3... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2025-03-05T10:45:56Z solvables: 6
:
(中略)
:
zerofree-1.1.1-16.fc43.x86_64
zlib-ng-2.3.3-2.fc43.x86_64
Changes queued for next boot. Run "systemctl reboot" to start a reboot
root@onoda-converter-fedora:~#
今後は導入できました。
再起動します。
systemctl reboot
root@onoda-converter-fedora:~# systemctl reboot
Broadcast message from root@onoda-converter-fedora on pts/1 (Tue 2026-04-14 04:38:50 UTC):
The system will reboot now!
root@onoda-converter-fedora:~# client_loop: send disconnect: Connection reset
sshで再接続します。virt-v2vが導入され、Ubuntu 24の時とは違い--runオプションがあることが確認できます。
core@onoda-converter-fedora:~$ virt-v2v --version
virt-v2v 2.10.0fedora=43,release=1.fc43
core@onoda-converter-fedora:~$ virt-v2v --help | grep -e '--run'
--run <SCRIPT> Run script in disk image
--run-command <'CMD+ARGS'> Run command in disk image
「sudo su -」でrootになっておきます。
core@onoda-converter-fedora:~$ sudo su -
root@onoda-converter-fedora:~#
libvirtdを有効にします。
sudo systemctl enable --now libvirtd
root@onoda-converter-fedora:~# sudo systemctl enable --now libvirtd
Created symlink '/etc/systemd/system/multi-user.target.wants/libvirtd.service' → '/usr/lib/systemd/system/libvirtd.service'.
Created symlink '/etc/systemd/system/sockets.target.wants/virtlockd.socket' → '/usr/lib/systemd/system/virtlockd.socket'.
Created symlink '/etc/systemd/system/sockets.target.wants/virtlogd.socket' → '/usr/lib/systemd/system/virtlogd.socket'.
Created symlink '/etc/systemd/system/sockets.target.wants/libvirtd.socket' → '/usr/lib/systemd/system/libvirtd.socket'.
Created symlink '/etc/systemd/system/sockets.target.wants/libvirtd-ro.socket' → '/usr/lib/systemd/system/libvirtd-ro.socket'.
Created symlink '/etc/systemd/system/sockets.target.wants/libvirtd-admin.socket' → '/usr/lib/systemd/system/libvirtd-admin.socket'.
Created symlink '/etc/systemd/system/sockets.target.wants/virtlockd-admin.socket' → '/usr/lib/systemd/system/virtlockd-admin.socket'.
Created symlink '/etc/systemd/system/sockets.target.wants/virtlogd-admin.socket' → '/usr/lib/systemd/system/virtlogd-admin.socket'.
Linux移行用の追加準備
「記事」から、カスタムスクリプト 「nwscript-update.sh」をコピーします。
これは、RHELに対して、VSI for VPCの標準イメージと同等の構成に調整するカスタムスクリプトだそうです。
このスクリプトはRHELでしか検証していませんし、Ubuntuや他のOSではそのままでは動かないと思いますが、容易に拡張できると思います。
今回の検証でもRHELを利用しているので、そのまま利用させていただきます。
今回はnanoで貼り付けました。
root@onoda-converter-fedora:~# nano nwscript-update.sh
root@onoda-converter-fedora:~# ls -l nwscript-update.sh
-rw-r--r--. 1 root root 2100 Apr 14 04:45 nwscript-update.sh
2026/04/20 追記/2026/04/23 変更 - デフォルトユーザーがcloud-userになる
当初、デフォルトユーザーが「cloud-user」になり、それに気が付かず、ログインできずに悩みました。
@shiyasu(Shinobu Yasuda)さんに別途、相談した追記です。cloud-initのデフォルトで導入される構成ファイルを、IBM Cloud VPCで通常オーダーした構成ファイル/etc/cloud/cloud.cfgに差し替えてしまえばいいのでは」コメントをいただきました。ありがとうございます。
RHEL8の場合、cloud-initのデプロイの設定は/etc/cloud/cloud.cfgに記述されています。いったんIBM Cloud標準のRHEL8をオーダーして、そこから/etc/cloud/cloud.cfgをダウンロードして置き、virt-v2vで対象にアップロードしてはとアドバイスいただきました。
その方がIBM Cloudの標準デプロイに準拠するのでいろいろ悩まなくて良いかもしれません。
なお、後から下記を確認すると「cloud-user」で作成されることは、正常であることの記述が見つかりました。
RHEL ベースのカスタムイメージのデフォルトユーザーは cloud-user です。 cloud-initの有効化の詳細については、 cloud-initの設定をを参照してください。
Windows移行用の追加準備
Windowsを移行するためにはvirtioドライバーのためのisoファイルが必要です。
「記事」に従って、RHEL9から入手し、Converter VSIにコピーしました。
root@onoda-converter-fedora:~# ls *.iso
virtio-win-1.9.53.iso
2026/04/20 追記/2026/04/24 更新 - Windows環境用のIBM Cloud用構成ファイルについて
これも@shiyasu(Shinobu Yasuda)さんに別途、相談した追記です。Windowsのcloudbase-initの構成ファイルは、c:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confです。
cloudbase-initのパッケージ標準では「Admin」というユーザーが作成される設定になっています。
いったんIBM Cloud標準のWindowsをオーダーして、そこからc:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confをダウンロードして置き、virt-v2vで対象にアップロードした場合、「Admin」ユーザーは作成されなくなりました。
移行元VMへのcloud-init/cloudbase-initの導入
今回はVMとしてRHEL8(開発者サブスクリプション)とWindows2025(日本語評価版)を用意しました。
デプロイには、cloud-init/cloudbase-initが使われますので、導入されていなければ VMにcloud-init/cloudbase-initを導入します。
RHEL8の場合は、cloud-initをパッケージとして導入します。
dnf install cloud-init
Windowsの場合は、cloudbase-initを導入します。
「https://cloudbase.it/cloudbase-init/」からインストーラをダウンロードして導入します。
ダウンロードしたインストーラを起動して導入します。
OVA形式でのエクスポートとConverter VSIへのコピー
各々の移行元環境に合わせて、OVA形式でVMをエクスポートします。
今回の検証で移行元環境として用意したのはvCenterのないESXi 8.0.3です。
現在、管理に使うブラウザー接続のESXi Host Clientでは、VMのエクスポートではOVFのみがサポートされます。
そこでクライアントであるWindowsにOpen Virtualization Format (OVF) Toolを導入して、OVAとしてエクスポートしました。
vCenterが利用できる環境やVCFaaSの場合は、ふさわしい方法を使って、OVA形式でVMをエクスポートします。
この場合、OVF Toolを使ったOVAエスクポート手順は不要です。
OVAとしてエスクポートする前にVMをシャットダウンしておきます。
OVF ToolのOVAエスクポートのパラメーターは下記になります。
ovftool.exe --noSSLVerify vi://[ESX iホストのIP]/[VM名] [ovaファイル名]
RHEL8での実行結果はこちらです。ESX iホストのIPのユーザー名/パスワードが求められ、VMがOVAとしてエスクポートされました。
C:\temp>\tools\ovftool\ovftool.exe --noSSLVerify vi://192.168.0.100/rhel8 rhel8.ova
Enter login information for source vi://192.168.0.100/
Username: root
Password: *********
Opening VI source: vi://root@192.168.0.100:443/rhel8
Opening OVA target: rhel8.ova
Writing OVA package: rhel8.ova
Transfer Completed
Completed successfully
OVAは圧縮イメージです。この例のRHEL8 VMは、もともと50GBのThick Provisioningでした。
しかし、導入直後ということもあり3.7GBのOVAになりました。
C:\temp>dir rhel8.ova
Volume in drive C is Windows
Volume Serial Number is 2044-292D
Directory of C:\temp
2026/04/14 23:40 3,711,389,696 rhel8.ova
1 File(s) 3,711,389,696 bytes
0 Dir(s) 29,094,322,176 bytes free
Converter VSI上の作業エリアも、このサイスの空きがあれば十分です。
scpでConverter VSIにコピーしました。
C:\temp>scp rhel8.ova core@10.244.129.6:.
rhel8.ova 100% 3539MB 16.0MB/s 03:41
同様に、Windows2025のVMもOVAにエクスポートして、Converter VSIにコピーします。
C:\temp>\tools\ovftool\ovftool.exe --noSSLVerify vi://192.168.0.100/Win2025 win2025.ova
Enter login information for source vi://192.168.0.100/
Username: root
Password: *********
Opening VI source: vi://root@192.168.0.100:443/Win2025
Opening OVA target: win2025.ova
Writing OVA package: win2025.ova
Transfer Completed
Completed successfully
C:\temp>scp win2025.ova core@10.244.129.6:.
win2025.ova 100% 12GB 15.7MB/s 13:25
2026/04/24 追記
OVFとしてエクスポートする場合はディレクトリ名を指定して変換
Open Virtualization Format (OVF) Toolが使えない場合はOVFとしてのエクスポートして変換します。
その際は、.ovfファイルの他、関連ファイルをひとつのディレクトリにまとめてください。
root@onoda-converter-fedora:~# ls -l /var/home/core/rhel8-ovf
total 3183452
-rw-r--r--. 1 core core 3259832832 Apr 24 00:11 rhel8-0.vmdk
-rw-r--r--. 1 core core 61 Apr 24 00:11 rhel8.mf
-rw-r--r--. 1 core core 15207 Apr 24 00:11 rhel8.ovf
その時、virt-v2vの入力オプションは「-i ova [ovaファイル名]」の代わりにovfのディレクトリ名を指定します。
-i ova [ovfディレクトリ名] \ # ovf形式で入力. ディレクトリ名を指定
上記の例の場合、こうなります。
-i ova /home/core/rhel8-ovf
RHLE8で検証済みです。
また、WindowsでのOVFからの移行は「IBM Cloud : virt-v2vを使ったVMwareからVSI for VPCへ移行手順の補足-複数Diskの環境」ここでも確認しました。
変換の実施
上の方でも述べましたが、実際の変換手順はこのようになります。
- 移行先になるVM用のBoot Diskを用意
移行先のVSI for VPCの実態のDiskになります。 - Boot DiskをConverter VSIに接続
- virt-v2vを使ってOVAファイルの内容をBoot Diskに変換・書き込み
- Boot DiskをConverter VSIから切断
- Boot Diskを使って新しいVSIをオーダー
移行先VSI for VPCの器となるBoot Diskの用意
今回は、OVA形式のVMwareのVMイメージを virt-v2vでKVM用に変換します。結果はqcow2ファイルにするのではなく、直接ストレージに書き込みます。
VSI for VPCでは、OSが起動可能なBoot Diskと、追加ボリュームになりOSの起動には利用できないData Diskが存在します。Boot Diskは現在最大250GBまでという制限があります。
とちらになるかは、作成時(VSIデプロイの時に新規作成されたか、COSからカスタム・イメージとしてインポートされた時)に決まります。
VSIデプロイの時にIBM Cloud標準のイメージから新規作成する場合は、デフォルトのサイズは100GBでそれ以上小さくできません。
また、Boot DiskにはOSタイプやライセンス属性(IBM Cloud提供のライセンスかBYOLか)が付属します。
そのため下記の場合は、カスタム・イメージとしてインポートして作成する必要があります。
- 100GBより小さなVSIとしてデプロイしたい
- 現在のVMware環境で利用しているRHELやWindowsのライセンスをBYOLとして継続利用するので、IBM Cloud提供の有料ライセンスは不要
この方法については「IBM Cloud : virt-v2vを使ったVMwareからVSI for VPCへ移行手順の補足-100GBより小さいVMとBYOL」 を別に投稿しました。
今回は、全体の手順を確認するために一時的なVSI for VPCをオーダーして、そこで作成されるBoot Diskを利用したいと思います。
一時的なVSI for VPCをオーダーし、移行先用のBoot Diskを作成
「記事」では、Boot disk作成に利用する一時的なVSIを「暫定的な VSI(ephemeral VSI)」と呼んでいます。
ここで作成したBoot diskに、OVA形式になったVMのイメージを virt-v2vを使ったKVM形式に変換して書き込みます。
ephemeral VSIのオーダーは、構成されるBoot Diskを作成させるためだけに行います。
ephemeral VSIをオーダーするポイントは、下記の2点です。
- 移行するVMのOSタイプに合わせること
- インスタンスを削除する時にBoot Diskの自動削除を行わないように設定すること
また、下記を行ってもいいかもしれません。
- 最終的に移行先となるVSIの名前と合わせること
Boot Diskには、どのOS用のものかの属性が付くようです。デプロイの自動化やBYOLでない場合のライセンスの設定にも影響を与えるので、矛盾のないできるだけ類似のものを選択します。
今回はRHEL 8とWindows Server 2025で移行をテストするので、RHEL 8をrhel8-ephemeral、Windows Server 2025をwin2025-ephemeralという名前でデプロイします。
作成されるBoot Diskの名前はオーダーしたVSIの名前から決まります。移行後のVMとの関連が分かりやすい名前にしておけば、後のDiskの管理が楽になります。
また、このステップはBoot Diskが欲しいためだけのオーダーです。ephemeral VSはBoot Diskの作成後にキャンセルします。その時にBoot Diskが自動削除されないように設定しておく必要があります。
鉛筆マークで編集します。
名前を必要に応じて付け直し、自動削除が行われない設定にします。
デフォルトではサイズが100GBになっています。
ここで設定できるのは、100GBから250GBです。
先に述べたように、100GBより小さいVSI for VPCを作成したい場合は、別の方法でBoot diskを作成します。
また、250GBより大きなBoot Diskは、ここでは設定できませんし、別の方法で作成しても起動できません。
今回はフォルトの100GBで進めます。
一時的なVSI for VPCを削除
インスタンスのデプロイに伴い、移行先用のBoot Diskが作成されます。
その時点で一時的なVSIを削除します。
Boot Diskが手に入りました。
オーダーした一時的なVSIに伴うOSタイプが属性についています。
RHELの変換
RHELを変換してみます。
Boot DiskをConverter VSIに接続
Boot Diskを接続する前のストレージの状況をlsblkで確認しておきます。
root@onoda-converter-fedora:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 253:0 0 100G 0 disk
├─vda1 253:1 0 1M 0 part
├─vda2 253:2 0 127M 0 part
├─vda3 253:3 0 384M 0 part /boot
└─vda4 253:4 0 99.5G 0 part /var
/sysroot/ostree/deploy/fedora-coreos/var
/sysroot
/etc
vdb 253:16 0 366K 0 disk
vdc 253:32 0 44K 0 disk
接続します。
いくつか方法はありますが、今回はConverter VSIインスタンスのストレージ・タブから接続します。
接続する Boot Diskを 選択します。
「データ・ボリューム」として接続されました。
もう一度lsblkで確認すると「vdd」として接続されたのが分かります。
root@onoda-converter-fedora:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 253:0 0 100G 0 disk
├─vda1 253:1 0 1M 0 part
├─vda2 253:2 0 127M 0 part
├─vda3 253:3 0 384M 0 part /boot
└─vda4 253:4 0 99.5G 0 part /var
/sysroot/ostree/deploy/fedora-coreos/var
/sysroot
/etc
vdb 253:16 0 366K 0 disk
vdc 253:32 0 44K 0 disk
vdd 253:48 0 100G 0 disk
├─vdd1 253:49 0 1M 0 part
├─vdd2 253:50 0 100M 0 part
└─vdd3 253:51 0 99.9G 0 part
書き出し先用のリンクの作成
注意が必要なのは、書き出し先です。
「記事」にも下記の記述があります。
Scottさんの記事や「virt-v2vのガイダンス」にあるように、
virt-v2vは出力ディレクトリを指定することはできますが、ファイル名を指定することはできません。そのため、例えば以下のようなスクリプトを実行して、/tmpディレクトリへの出力が、自動的に追加したDoot Disk(今回のケースでは/dev/vdd）に書き込まれるように構成しておきます。
つまりvirt-v2vの出力先は変換元の名前から決定されます。
「記事」では、下記のことをやっていました。
- vCenter上「syasuda-win2022-1」という名前のVMを
- 「/tmp」ディレクトリへ出力するように指定している
- その結果は「/tmp/${VM_NAME}-sda」に書き込まれる
- 「/tmp/${VM_NAME}-sda」を「/dev/vdd」にリンクしておくことで、接続したBoot Diskに書き込みが行われる
今回はOVAからの変換でvCenterは利用しません。しかし、移行先として使われるVMの名前はOVAに含まれるESXi上のVM名が使われます。
実は、ここでもはまりました。OVAのファイル名とESXi上のVM名は、合わせておくことをお勧めします。
今回のRHEL用は、VM名もファイル名も「rhel8」という名前になっています。
root@onoda-converter-fedora:~# ls -l /home/core/rhel8.ova
-rw-r--r--. 1 core core 3711389696 Apr 14 14:45 /home/core/rhel8.ova
そのため今回は 「/tmp/rhel8-sda」を「/dev/vdd」にリンクします。
ln -fs /dev/vdd /tmp/rhel8-sda
実行結果はこちらです。
root@onoda-converter-fedora:~# ln -fs /dev/vdd /tmp/rhel8-sda
root@onoda-converter-fedora:~# ls -l /tmp/rhel8-sda
lrwxrwxrwx. 1 root root 8 Apr 14 05:32 /tmp/rhel8-sda -> /dev/vdd
virt-v2vを使ってOVAファイルの内容をBoot Diskに変換・書き込み
いよいよ変換しましょう。
vCenter関連のパラメーターがないので、「記事」よりずいぶんシンプルです。
export LIBGUESTFS_BACKEND=direct # backend daemonとの接続方法の指定
virt-v2v \
-i ova [ovaファイル名] \ # ova形式で入力. ファイル名を指定
-o disk -os /tmp \ # diskイメージで出力. 出力先は 「/tmp」を指定
--run nwscript-update.sh # カスタムスクリプト「nwscript-update.sh」を実行
2026/04/17追記 2026/04/20更新 RHELのユーザー名について
作成されるデフォルトユーザーは、/etc/cloud/cloud.cfgで決定されます。
cloud-initのパッケージのデフォルトでは左のように「cloud-user」になっていました。一方、IBM Cloud VPCの標準イメージでオーダーしたRHEL8は右のように「vpcuser」になっていました。
IBM Cloud VPC標準に合わせたい場合は/etc/cloud/cloud.cfgを変更するか、いったんIBM Cloud VPCの標準のVSIをオーダーして、その/etc/cloud/cloud.cfgを、Converter VSIにコピーしてvirt-v2vの 実行時に、下記のオプションを追加して変換時に置き換えるのが楽だと思います。
--upload cloud.cfg:'/etc/cloud/cloud.cfg'
今回の環境では、このようになります。
virt-v2v \
-i ova /home/core/rhel8.ova \
-o disk -os /tmp \
--run nwscript-update.sh
変換されました。
root@onoda-converter-fedora:~# virt-v2v \
-i ova /home/core/rhel8.ova \
-o disk -os /tmp \
--run nwscript-update.sh
[ 0.0] Setting up the source: -i ova /home/core/rhel8.ova
[ 11.1] Opening the source
[ 19.2] Checking filesystem integrity before conversion
[ 22.5] Detecting if this guest uses BIOS or UEFI to boot
[ 23.1] Inspecting the source
[ 26.8] Detecting the boot device
[ 26.9] Checking for sufficient free disk space in the guest
[ 26.9] Converting Red Hat Enterprise Linux 8.10 (Ootpa) (rhel8.10) to run on KVM
virt-v2v: The QEMU Guest Agent will be installed for this guest at first
boot.
virt-v2v: This guest has virtio drivers installed.
[ 71.5] Setting a random seed
[ 71.5] Running: nwscript-update.sh
[ 73.8] SELinux relabelling
[ 77.1] Mapping filesystem data to avoid copying unused and blank areas
[ 78.0] Checking filesystem integrity after conversion
[ 80.2] Closing the overlay
[ 80.3] Assigning disks to buses
[ 80.3] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 80.3] Setting up the destination: -o disk -os /tmp
[ 81.3] Copying disk 1/1
█ 100% [****************************************]
[1173.2] Creating output metadata
[1173.2] Finishing off
virt-v2vの実行で下記のエラーが出る場合、libvirtdが有効になっていません。
root@onoda-converter-fedora:~# virt-v2v -i ova /home/core/rhel.ova -o disk -os /tmp --run nwscript-update.sh
virt-v2v: error: exception: libvirt: VIR_ERR_OPERATION_UNSUPPORTED:
VIR_FROM_REMOTE: Operation not supported: No URI is provided and cannot
identify any listening daemon socket path to attempt to connect to. Please
ensure the expected daemon sockets are active and/or provide an explicit
URI. For more information see
https://libvirt.org/kbase/failed_connection_after_install.html
If reporting bugs, run virt-v2v with debugging enabled and include the
complete output:
virt-v2v -v -x [...]
下記のようにlibvirtdを有効にしてから変換を実行してください。
sudo systemctl enable --now libvirtd
lsblkで確認すると、vddが変換元に従ったパーティション構造になっているのが確認できます。
もともと50GBのRHELだったので、50GB分が使われています。
root@onoda-converter-fedora:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 253:0 0 100G 0 disk
├─vda1 253:1 0 1M 0 part
├─vda2 253:2 0 127M 0 part
├─vda3 253:3 0 384M 0 part /boot
└─vda4 253:4 0 99.5G 0 part /var
/sysroot/ostree/deploy/fedora-coreos/var
/sysroot
/etc
vdb 253:16 0 366K 0 disk
vdc 253:32 0 44K 0 disk
vdd 253:48 0 100G 0 disk
├─vdd1 253:49 0 600M 0 part
├─vdd2 253:50 0 1G 0 part
└─vdd3 253:51 0 48.4G 0 part
変換先のDiskを切り離します。
Boot Diskを使って新しいVSIをオーダー
新しいVSIをオーダーします。
既存のボリュームから、先ほど変換したものを選択します。
オーダー後、起動が確認できました。
移行先VSIへアクセスして確認
cloud-initを導入しなかった場合
cloud-initを導入しないでも、ここまでの手順でデプロイしても起動してきました。
その場合cloud-initが実行されないので下記の状況になりました。
- ユーザー・クレデンシャルは、オリジナルVMイメージのまま
- 例えばオリジナルVMがパスワード認証のrootを許していた場合、そのままアクセス可能
- IBM Cloud提供ライセンスのRHELとしてオーダーすると、サブスクリプション登録がされないため、ポータル上の状況が最終的に「Failed」となる
- Rockyなどの無料ライセンスやRHELでもBYOLとして デプロイした場合は「Failed」にならずポータル上の状況は「Running」になり、一見正常に見える
- 「Failed」になった状態でも
cloud-initを導入して再起動すれば「Running」になる
「cloud-user」で接続します。
ホスト名が、ポータルで指定したものになっています。
C:\Users\onoda>ssh cloud-user@10.244.129.4
The authenticity of host '10.244.129.4 (10.244.129.4)' can't be established.
ED25519 key fingerprint is SHA256:ZmngsulorAt36Do6RPNi0z9GzdewxOaBVaEctEgBhUQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.244.129.4' (ED25519) to the list of known hosts.
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Wed Apr 15 02:53:06 2026 from 10.10.129.130
[cloud-user@onoda-rhel8 ~]$
systemd-detect-virtでハイパーバイザーがkvmになっています。
NIC名がスクリプトにより「eth0」になっていること、サブスクリプション登録が正常にされていること、オリジナルVMで作成しておいたファイルが存在していることが確認できました。
[cloud-user@onoda-rhel8 ~]$ sudo su -
[root@onoda-rhel8 ~]# systemd-detect-virt
kvm
[root@onoda-rhel8 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 02:00:01:89:98:ce brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname ens3
inet 10.244.129.4/24 brd 10.244.129.255 scope global dynamic noprefixroute eth0
valid_lft 290sec preferred_lft 290sec
[root@onoda-rhel8 ~]# subscription-manager identity
システム ID: 811018a2-a875-49c2-8711-463ca387ff59
名前: ng-02g7-23aab0f8-4cc0-40db-8c67-5351b0770755
組織名: customer
組織 ID: customer
環境名: Library
[root@onoda-rhel8 ~]# ls -l test.txt
-rw-r--r--. 1 root root 5 3月 23 22:04 test.txt
なお、ESXi上のオリジナルのVMでの実行結果はこちらです。
rootのパスワード認証でログインでき、NIC名が「ens34」であるなど、手が加えられている一方、移行先で確認したファイルが、もともとあったものであることが分かります。
当然systemd-detect-virtの結果はvmwareです。
C:\Users\onoda>ssh root@192.168.0.24
root@192.168.0.24's password:
Activate the web console with: systemctl enable --now cockpit.socket
Last failed login: Wed Apr 15 04:34:15 EDT 2026 from 192.168.0.9 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Wed Apr 15 04:22:35 2026
[root@rhel8 ~]# systemd-detect-virt
vmware
[root@rhel8 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:4c:93:7d brd ff:ff:ff:ff:ff:ff
altname enp2s2
inet 192.168.0.24/24 brd 192.168.0.255 scope global dynamic noprefixroute ens34
valid_lft 82539sec preferred_lft 82539sec
inet6 240f:112:8c7b:1:20c:29ff:fe4c:937d/64 scope global dynamic noprefixroute
valid_lft 272sec preferred_lft 272sec
inet6 fe80::20c:29ff:fe4c:937d/64 scope link noprefixroute
valid_lft forever preferred_lft forever
[root@rhel8 ~]# subscription-manager identity
システム ID: db7e06ab-b084-4fc6-a32d-55f1b51487c8
名前: rhel8.test.private
組織名: 12550137
組織 ID: 12550137
[root@rhel8 ~]# ls -l test.txt
-rw-r--r--. 1 root root 5 3月 23 22:04 test.txt
Windows Serverの変換
Windows Serverも変換を変換してみましょう。
Boot DiskをConverter VSIに接続
Windows用のBoot DiskをConverter VSIに接続します。
lsblkで確認するとやはり「vdd」として接続されました。
root@onoda-converter-fedora:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 253:0 0 100G 0 disk
├─vda1 253:1 0 1M 0 part
├─vda2 253:2 0 127M 0 part
├─vda3 253:3 0 384M 0 part /boot
└─vda4 253:4 0 99.5G 0 part /var
/sysroot/ostree/deploy/fedora-coreos/var
/sysroot
/etc
vdb 253:16 0 366K 0 disk
vdc 253:32 0 44K 0 disk
vdd 253:48 0 100G 0 disk
├─vdd1 253:49 0 100M 0 part
├─vdd2 253:50 0 98.8G 0 part
├─vdd3 253:51 0 200M 0 part
└─vdd4 253:52 0 887M 0 part
もともとがWindows用なので、RHELの時とパーティション構造が違いますね。
書き出し先用のリンクの作成
今回はOVAからの変換でvCenterは利用しません。しかしOVA内にVM名を持っています。書き出し先の決定には、その名前が利用されます。
今回のOVAは「 win2025.ova」という名前でしたが、ESXi上は「Win2025」という名前を付けていました。
root@onoda-converter-fedora:~# ls -l /home/core/win2025.ova
-rw-r--r--. 1 core core 13270890496 Apr 14 22:10 /home/core/win2025.ova
そのため今回は 「/tmp/Win2025-sda」を「/dev/vdd」にリンクします。
ln -fs /dev/vdd /tmp/Win2025-sda
実行結果はこちらです。
root@onoda-converter-fedora:~# ln -fs /dev/vdd /tmp/Win2025-sda
root@onoda-converter-fedora:~# ls -l /tmp/Win2025-sda
lrwxrwxrwx. 1 root root 8 Apr 16 02:46 /tmp/Win2025-sda -> /dev/vdd
virt-v2vを使ってOVAファイルの内容をBoot Diskに変換・書き込み
2026/04/20更新/2026/04/25更新 Windowsで「Admin」ユーザーが追加作成される
Windowsを移行すると「Admin」ユーザーが追加作成されていました。これは、cloudbase-initを標準で導入した場合のC:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confによるものでした(厳密には、インストーラのウィザードのデフォルトで指定されていた)。
左が、cloudbase-initを標準で導入した`cloudbase-init.conf'、右がIBM Cloudの標準イメージからWindowsを導入した時のものです。
IBM Cloud VPC標準に合わせたい場合は、いったんIBM Cloud VPCの標準のVSIをオーダーして、そのC:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.confを、Converter VSIにコピーしてvirt-v2vの 実行時に、下記のオプションを追加して変換時に置き換えるのが楽だと思います。
--upload cloudbase-init.conf:'/Program Files/Cloudbase Solutions/Cloudbase-Init/conf/cloudbase-init.conf'
Windowsをvirt-v2vで変換する場合、virtioドライバーのためのisoファイルが必要です。
「記事」では、環境変数VIRTIO_WINに設定しています。
root@syasuda-converter-fedora:~# export VIRTIO_WIN=/root/virtio-win-1.9.50.iso
この設定は「man virt-v2v」でも確認できます
Windows Drivers are installed from the ISO or directory pointed
to by the "VIRTIO_WIN" environment variable if present.
If the "VIRTIO_WIN" environment variable is absent
(which is the recommended setting), then libosinfo is
consulted first, for driver files that are locally
available on the conversion host.
「記事」を同じ手順で入手したつもりですが、isoが更新されているようで、ファイル名が 変わっていました。
root@onoda-converter-fedora:~# ls -l /root/*.iso
-rw-r--r--. 1 core core 637956096 Apr 14 05:15 /root/virtio-win-1.9.53.iso
vCenter接続のパラメーターが無いので、このように実行します。
export LIBGUESTFS_BACKEND=direct # backend daemonとの接続方法の指定
export VIRTIO_WIN=/root/virtio-win-1.9.53.iso # virtioドライバーのためのisoファイルの指定
virt-v2v \
-i ova [ovaファイル名] \ # ova形式で入力. ファイル名を指定
-o disk -os /tmp \ # diskイメージで出力. 出力先は 「/tmp」を指定
--block-driver virtio-scsi # block-driverを指定
今回の環境では、このよう実行しました。
virt-v2v \
-i ova /home/core/win2025.ova \
-o disk -os /tmp \
--block-driver virtio-scsi
実行結果がこちらです。
root@onoda-converter-fedora:~# virt-v2v \
-i ova /home/core/win2025.ova \
-o disk -os /tmp \
--block-driver virtio-scsi
[ 0.0] Setting up the source: -i ova /home/core/win2025.ova
[ 270.5] Opening the source
[ 281.3] Checking filesystem integrity before conversion
[ 282.2] Detecting if this guest uses BIOS or UEFI to boot
[ 283.2] Inspecting the source
[ 288.0] Detecting the boot device
[ 288.0] Checking for sufficient free disk space in the guest
[ 288.0] Converting Windows Server 2025 Standard Evaluation (win2k25) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 303.9] Setting a random seed
virt-v2v: warning: random seed could not be set for this type of guest
[ 304.0] SELinux relabelling
[ 304.5] Fixing NTFS permissions
[ 304.5] Mapping filesystem data to avoid copying unused and blank areas
[ 307.5] Checking filesystem integrity after conversion
[ 308.4] Closing the overlay
[ 308.5] Assigning disks to buses
virt-v2v: warning: removable CD-ROM device in slot 0 clashes with another
disk, so it has been moved to a higher numbered slot on the same bus. This
may mean that this removable device has a different name inside the guest
(for example a CD-ROM originally called /dev/hdc might move to /dev/hdd, or
from D: to E: on a Windows guest).
[ 308.5] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 308.5] Setting up the destination: -o disk -os /tmp
[ 309.5] Copying disk 1/1
█ 100% [****************************************]
[1401.4] Creating output metadata
[1401.4] Finishing off
変換されました。
変換先のDiskを切り離します。
2026/04/21 追記 Windowsが正常に起動しない場合、変換時に下記のメッセージが出ていませんでしたか?
virt-v2v: warning: QEMU Guest Agent MSI not found on tools ISO/directory.
You may want to install the guest agent manually after conversion.
virt-v2v: warning: Balloon Server (blnsvr.exe) not found on tools
ISO/directory. You may want to install this component manually after
conversion.
virt-v2v: warning: there are no virtio drivers available for this version
of Windows (10.0 x86_64 Server win2k25). virt-v2v looks for drivers in
/usr/share/virtio-win
The guest will be configured to use slower emulated devices.
virt-v2v: This guest does not have virtio drivers installed.
VIRTIO_WINでドライバーのisoの指定を忘れているか、間違っているとこうなります。
export VIRTIO_WIN=/root/virtio-win-1.9.50.iso
正しく指定していしていれば、「does not have」の代わりに下記が表示されるはずです。
virt-v2v: This guest has virtio drivers installed.
Boot Diskを使って新しいVSIをオーダー
新しいVSIをオーダーします。
既存のボリュームから、先ほど変換したものを選択します。
オーダー後、起動が確認できました。
移行先VSIへ「Administrator」でアクセスして確認
VPCのWindowsにRDPでアクセスする情報はこちらにあります。
VPC環境にRDP用ポート3389での接続を許可します。
IBMの標準イメージから通常通りWindows Serverをオー出した場合、VPC環境のAdministratorのパスワードは、Classic環境とは違い、ポータルでそのまま確認することはできません。
ランダムに生成された後、オーダー時に指定したsshキーで暗号化されたものがポータルには表示されます。
対応するsshの秘密キーで複合化する記述になっています。
ibmcloud is instance-initialization-values INSTANCE [--private-key (KEY | @KEY_FILE)]
余談ですが「（小ネタ）IBM Cloud: IBM Cloud CLIを使わずにVSI for VPC(Windows)のための暗号化パスワードを復号する方法」のように、IBM Cloud CLIを使わなくてもopensslでデコードする方法もあるようです。
しかし、今回の手順ではAdministratorのパスワードは、オリジナルのVMのままでした。
hostnameは、オーダーした時のものに変更されていましたので、デプロイのプロセスは実行されたようです。
ただ、もともとが評価ライセンスのため、移行先でも評価ライセンスのままでした。
通常は必要ないと思いますが、今回は、その変更が必要でした。
VPC環境のKMSは「kms.adn.networklayer.com:1688」のようです。
こちらを登録します。
slmgr /skms kms.adn.networklayer.com:1688
slmgr /ato
評価ライセンスから正式ライセンスに切り替えるため、こちらを参考にして追加のステップを実行しました。
切り替え用のキーは、こちらで確認しました。
C:\Users\Administrator>Dism /Online /Get-TargetEditions
展開イメージのサービスと管理ツール
バージョン: 10.0.26100.5074
イメージのバージョン: 10.0.26100.32522
アップグレード可能なエディション:
ターゲット エディション : ServerTurbine
ターゲット エディション : ServerStandard
ターゲット エディション : ServerDatacenter
操作は正常に完了しました。
C:\Users\Administrator> Dism /Online /Set-Edition:ServerStandard /ProductKey:TVRH6-WHNXV-R9WG3-9XRFY-MY832 /AcceptEula
展開イメージのサービスと管理ツール
バージョン: 10.0.26100.5074
イメージのバージョン: 10.0.26100.32522
コンポーネントの更新を開始しています...
プロダクト キーのインストールを開始しています...
プロダクト キーのインストールが完了しました。
パッケージ Microsoft-Windows-ServerStandardEdition~31bf3856ad364e35~amd64~~10.0.26100.1742 を追加しています
[==========================100.0%==========================]
コンポーネントの更新が完了しました。
エディション固有の設定の適用を開始しています...
エディション固有の設定の適用が完了しました。
操作は正常に完了しました。
Windows を再起動してこの操作を完了してください。
今すぐコンピューターを再起動しますか? (Y/N)
再起動後、評価ライセンスの表示は消えライセンス認証が確認できました。
