1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

この記事誰得？ 私しか得しないニッチな技術で記事投稿！
Qiita Tech Festa20262026年7月13日まで開催中！
@6onoda(Yasuhiro Onoda)Team CoffeeinIBM

IBM Cloud : virt-v2vを使ったVMwareからVSI for VPCへ移行手順の補足-VCFaaS環境からの移行

1
Last updated at Posted at 2026-06-26

「IBM Cloud : virt-v2vを使ったVMware OVAからVSI for VPCへのサーバー移行手順」では、vCenter環境ではない、スタンドアロンのESXi環境のVMの移行を試しました。

今回、IBM Cloud の VCF as a Service(VCFaaS)環境にアクセスできるようになりました。
そこで、VCFaaS環境からの移行を検証します。

なお、今回の記事は「IBM Cloud : virt-v2vを使ったVMware OVAからVSI for VPCへのサーバー移行手順」の情報があることを前提に、VCFaaS環境からの移行に特化した部分と最新情報の記事になってます。

基本方針

今回のポイントは、VCFaaS環境＝VMware Cloud Director(VCD)環境でのOVAのエクスポートがvApp単位という事です。
vAppでは複数のVMをまとめて管理します。つまり、単独のVMを直接OVAとしてエクスポートすることはできません。またOVAのエクスポートのためには、vAppのパワーオフ=管理下のすべてのVMのシャットダウンが必要です。
仮にvAppのパワーオフができても、すべてのVMの一括ダウンロードには時間かかかります。
さらに、移行にはcloud-init/cloudbase-initの導入が必要です。このような導入は、特に移行検証時点で既存環境の影響を心配されるかもしれせん。最終移行であってもスナップショットなど、導入前に回復できる手段が重要です。

実際、RHEL8にcloud-initを導入したところ、元々は固定IP設定だったのが、DHCP設定に書き換えられました。
その結果、今回のVCFaaS環境ではDHCPを利用可能にしていなかったので、IPアドレスが割り振られず、sshでのログインができなくなりました。

そのため、今回は下記の手順で移行を検証したいと思います。

VCFaaS/VCDで行う事

まず、移行元であるVCFaaS/VCDで行う事です。

  1. OVAエクスポート専用のvAppの作成
  2. OVAエクスポート専用のvAppにVMをコピー
  3. コピーしたVMにcloud-init/cloudbase-initを導入
  4. VMのシャットダウンとvAppのパワーオフ
  5. vAppをOVAとしてエクスポート

別のVMをOVAエクスポートしたい場合は、コピーしたVMを削除して2-5を繰り返すか、別のOVAエクスポート専用のvAppの作成して利用します。

IBM Cloud VPCで行う事

次に、移行先であるIBM Cloud VPCで行う事です。

  1. 変換サーバーの用意
  2. 変換サーバーにOVAをインポート
  3. OVAからvmdkの取り出し
  4. 移行先VSI用のboot storageの準備
  5. 変換サーバーに移行先VSI用のboot storageを接続
  6. 変換サーバーでvmdkからVMイメージを移行先VSI用boot storageに変換・書き込み
  7. 変換された、VSI用boot storageから新しいVSIをオーダー

変換サーバーの構築は「IBM Cloud : virt-v2vを使ったVMware OVAからVSI for VPCへのサーバー移行手順」を確認してください。

移行元環境

今回は「Red Hat Enterprise Linux 8 (64-bit)」と「Microsoft Windows Server 2022 (64-bit)」を標準テンプレートからデプロイしたものを、移行元とします。
このふたつのVMは現在vApp「onoda-vApp」に所属しています。

{7C37382D-E0D1-4687-9FA3-9AC01AA5570A}.png

このVMからの移行か確認できるように、各VMにファイルを作成しました。

RHEL8にenv.extを作りました。

[root@onoda-rhel8 ~]# echo FromVCFaas > env.txt
[root@onoda-rhel8 ~]# cat env.txt
FromVCFaas

Windows2022でも同様の作業をしておきます。

C:\Users\Administrator>echo FromVCFaas > env.txt

C:\Users\Administrator>type env.txt
FromVCFaas

OVAエクスポート専用のvAppの作成

OVAエクスポート専用のvAppを作成します。
今回は「onoda-vApp-export」という名前にしました。

image.png

なお、コピー後にVMに接続してcloud-init/cloudbase-initを導入するために、OVAエクスポート専用vAppにも適切なネットワーク環境が必要です。適切にvApp環境を構築してください。

OVAエクスポート専用のvAppにVMのコピー

ストレージ/静止点の整合性を求めるなら、コピーの前にVMをパワーオフする事をおすすめします。
ただし、パワーオフしなくてもコピー自体は可能です。

image.png

コピー先のvAppを指定します。

image.png

vAppが異なれば同じVM名を付けることができます。管理を容易にするため、名前を変更してもいいかもしれません。今回は変更しませんでした。
必須項目のストレージポリシーを選択し、vAppに登録済みのネットワークから接続先を選びます。
今回は、コピー元と同じネットワークに接続するので、競合しないようにMACアドレスはリセットします。

image.png

確認してコピーを開始します。

image.png

コピーしたVMにcloud-init/cloudbase-initを導入

コピー後のVMはパワーオフされているので、パワーオンして接続します。
「IBM Cloud : virt-v2vを使ったVMware OVAからVSI for VPCへのサーバー移行手順」の「移行元VMへのcloud-init/cloudbase-initの導入」の通り、cloud-init/cloudbase-initをコピーしたエクスポート用VMに導入します。

VMのシャットダウンとvAppのパワーオフ

OVAのエクスポートにはVMのシャットダウンだけではなくvAppレベルでのパワーオフが必要です。
vAppをパワーオフします。

image.png

変換サーバーにOVAをエクスポート

vAppをOVAとしてブラウザーでエクスポート

この方法のメリットは、変換用VSIにovftoolを導入することとVCD環境のローカルユーザーの作成の必要が無いことです。
ただし変換サーバーにブラウザーを導入したGUI環境がないと、OVAのエクスポートと変換サーバーへのアップロードの2度手間が発生します。

今回は、RHEL8のVMだけを持つvAppをOVAとしてエクスポートします。
今回のサイズは34GBです。

image.png

vAppをパワーオフするとダウンロードが選べるようになります。これがOVAエクスポートの指定です。

image.png

OVA形式しか選べないので、OVAとしてエクスポートします。

{13233726-3B65-4942-BA87-8961B6874320}.png

VCDのコンソールのログとしてのエクスポートが完了しても、実際のダウンロードは完了していません。

{85201FEF-0B77-45E3-86E8-9B337F097401}.png

ブラウザーではダウンロード中なのが確認できます。

{2156274E-815E-4142-BDC5-BC6248BDEEE9}.png

実際にダウンロードが完了した時間はこちらです。

PS C:\Users\6onoda\Downloads> dir *.ova


    ディレクトリ: C:\Users\6onoda\Downloads


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2026/06/08     20:10     4349647360 onoda-vApp-export.ova

後は、このOVAファイルを変換サーバーにscpなどでコピーします。

ovftoolを使って変換サーバーに直接OVAをエクスポートする場合

変換サーバーがVCFaaSと直接接続出来て、ovftoolが導入されていれば、いったんローカルにコピーして、変換サーバーに再度コピーする必要はありません。
変換を継続するなら、こちらの方法をお勧めします。

ovftoolの導入

まず、変換サーバーにovftoolをインストールします。

Lunux用のovftoolも前回と同様に下記から入手できます。

image.png

今回は、いったんローカルにダウンロードしてscpでコピーしたあとunzipし/root/ovftool/に展開しました。

root@onoda-converter-fedora:~# unzip /home/core/VMware-ovftool-5.1.0-25410048-lin.x86_64.zip
Archive:  /home/core/VMware-ovftool-5.1.0-25410048-lin.x86_64.zip
   creating: ovftool/ovftool/
  inflating: ovftool/ovftool/README.txt
   creating: ovftool/ovftool/certs/
       :
     (中略)
       :
  inflating: ovftool/schemas/vmware/ovfenv-vmware.xsd
  inflating: ovftool/vmware-eula.rtf
  inflating: ovftool/vmware.eula

./ovftool/ovftool -vで導入を確認します。

root@onoda-converter-fedora:~# ./ovftool/ovftool -v
./ovftool/ovftool: line 10: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory
./ovftool/ovftool: line 10: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory
./ovftool/ovftool.bin: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

今回の環境では警告とエラーがでるので、必要なパッケージを追加し、再起動します。

systemctl stop zincati.service
rpm-ostree upgrade
rpm-ostree install langpacks-en glibc-langpack-en libnsl
systemctl reboot

警告とエラーが消えました。

root@onoda-converter-fedora:~# ./ovftool/ovftool -v
VMware ovftool 5.1.0 (build-25410048)

VCDのローカルユーザーとパスワードの作成

通常、VMware Cloud Director(VCD)にはIBM Cloud Portalからシングルサインオンでアクセスします。
しかし、ovftoolでエクスポートする場合は、ローカルユーザーが必要です。

IBM Cloud Docsの「OVFTool を使用して VM を VCF as a Service にインポートする」は、インポート用の説明ですが、OVFTool用のユーザー名とパスワードの作り方が説明されています。

ovftoolでのOVAのエクスポート

ブラウザーからではなく、ovftoolでエクスポートする場合は、下記になります。

ovftool "vcloud://ユーザー名@VCLOUD_URL/cloud?org=組織名&vdc=VDC名&vapp=vApp名" OVAファイル名

「ユーザー名」は、先ほど作ったローカルユーザー名です。

接続先情報は、データセンターの情報として取得できます。」
「VCLOUD_URL」は①、「組織名」は②、「VDC名」は③の部分です。

image.png

「vApp名」は、エクスポート用のvAppの名前です。

今回の場合、このような指定になりました。

./ovftool/ovftool "vcloud://onoda-local@dirw002.jp-tok.vmware.cloud.ibm.com/cloud?org=b0eXXXXXXXXXX-XXXX-XXXX-XXX-XXXXXXXX88d&vdc=vdc-54-tok&vapp=onoda-vApp-export" onoda-rhel8.ova

転送結果はこちらです。ローカルユーザーのパスワードを指定したあと、処理が開始されました。
「Unsupported value」のWarningが多数表示されましたが、OVAはエクスポートされました。

root@onoda-converter-fedora:~# ./ovftool/ovftool "vcloud://onoda-local@dirw002.jp-tok.vmware.cloud.ibm.com/cloud?org=b0eXXXXXXXXXX-XXXX-XXXX-XXX-XXXXXXXX88d&vdc=vdc-54-tok&vapp=onoda-vApp-export" onoda-rhel8.ova
Enter login information for source vcloud://dirw002.jp-tok.vmware.cloud.ibm.com/b0eXXXXXXXXXX-XXXX-XXXX-XXX-XXXXXXXX88d
Username: onoda-local
Password: ****************
Opening vCloud source: vcloud://onoda-local@dirw002.jp-tok.vmware.cloud.ibm.com:443/cloud
Waiting for task on server ...........................................done
Warning:
 - Line -1: Unsupported value 'sched.cpu.latencySensitivity' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'tools.guest.desktop.autolock' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'svga.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'hpet0.present' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'numa.autosize.cookie' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'numa.autosize.vcpu.maxPerVirtualNode' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'scsi0.pciSlotNumber' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'ethernet0.pciSlotNumber' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'scsi0.sasWWID' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'vmotion.checkpointFBSize' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'vmotion.checkpointSVGAPrimarySize' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'vmotion.svga.mobMaxSize' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'vmotion.svga.graphicsMemoryKB' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'monitor.phys_bits_used' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'softPowerOff' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'svga.guestBackedPrimaryAware' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'guestInfo.detailed.data' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'tools.capability.verifiedSamlToken' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'viv.moid' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'cloud.uuid' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'vmware.tools.internalversion' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'vmware.tools.requiredversion' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'migrate.hostLog' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'vmxstats.filename' for attribute 'key' on element 'ExtraConfig'.
Opening OVA target: onoda-rhel8.ova
Writing OVA package: onoda-rhel8.ova
Transfer Completed
Completed successfully

root@onoda-converter-fedora:~# ls -l onoda-rhel8.ova
-rw-------. 1 root root 3648548864 Jun 25 09:25 onoda-rhel8.ova

OVAからtarでvmdkの取り出し

「IBM Cloud : virt-v2vを使ったVMware OVAからVSI for VPCへのサーバー移行手順」でESXi環境から単一のVMをOVA/OVFでエクスポートした時は、そのままvirt-v2vで変換できたのですが、確認した範囲では今回のOVAの変換方法が見つかりませんでした。
そこで、OVAをtarでvmdkを取り出します。
tarは単なる複数ファイルを結合するユーティリティで、zipなどと違って圧縮しているわけではありません。
vmdkを取り出しても、オリジナルストレージサイズのファイルが出来るわけではありません。
OVAを作るタイミングで、含まれるvmdkは圧縮されていて、その圧縮状態のまま取り出されます。

tar xf OVAファイル名

root@onoda-converter-fedora:~# tar xf onoda-rhel8.ova
root@onoda-converter-fedora:~# ls -l onoda-rhel8*
-rw-r--r--. 1   64   64 3855238656 Jun 25 12:37 onoda-rhel8-disk1.vmdk
-rw-r--r--. 1   64   64     270840 Jun 25 12:37 onoda-rhel8-file1.nvram
-rw-r--r--. 1   64   64        285 Jun 25 12:33 onoda-rhel8.mf
-rw-------. 1 root root 3855530496 Jun 25 12:37 onoda-rhel8.ova
-rw-r--r--. 1   64   64      17325 Jun 25 12:33 onoda-rhel8.ovf

VMの作り方によっては「vm-461b8cb9-877b-4d95-9eff-d5bd8c920289-disk-0.vmdk」のような名前になることがありました。
mvなどで分かりやすい名前に変えた方が、取り扱いやすいでしょう。

vmdkファイルが取り出されました。

VSI for VPCへの変換と移行先VSIのオーダー

ここから実際の変換し、移行先になるVSIをオーダーします。
手順はこちらになります。

  1. 移行先VSI用のboot storageの準備
  2. 変換サーバーに移行先VSI用のboot storageを接続
  3. 変換サーバーでvmdkからVMイメージを移行先VSI用boot storageに変換・書き込み
  4. 変換された、VSI用boot storageから新しいVSIをオーダー

基本的に「IBM Cloud : virt-v2vを使ったVMware OVAからVSI for VPCへのサーバー移行手順」の手順で変換します。

「変換サーバーでvmdkからVMイメージを移行先VSI用boot storageに変換・書き込み」のステップが、前回はOVA/OVFからだったものが、vmdkファイルからになる部分が前回と違います。

また、ストレージのデフォルトプロファイルが変わっているので、Windowsの場合は変換オプションに注意が必要です。

ここでは、その違いを中心に記述します。

RHEL8での検証

boot storageへのリンクの作成

前回はOVA/OVFに含まれるVM名が移行元に使われていました。
今回はvmdkファイルからの変換のためVM名の情報はありません。
そこでvmdkファイル名(拡張子無し)で書き込みディレクトリー'/tmp'にリンクを作成します。

ln -fs /dev/vdd /tmp/[vmdkファイル名(拡張子無し)]-sda

今回は、こうなります。

ln -fs /dev/vdd /tmp/onoda-rhel8-disk1-sda

root@onoda-converter-fedora:~# ln -fs /dev/vdd /tmp/onoda-rhel8-disk1-sda
root@onoda-converter-fedora:~# ls -al /tmp/o*
lrwxrwxrwx. 1 root root 8 Jun 26 03:21 /tmp/onoda-rhel8-disk1-sda -> /dev/vdd

変換

入力として「-i disk [vmdkファイル名] を指定します。

export LIBGUESTFS_BACKEND=direct

virt-v2v \
 -i disk [vmdkファイル名] \
 -o disk \
 -os /tmp \
 --run nwscript-update.sh \
 --upload cloud.cfg:'/etc/cloud/cloud.cfg'

今回はこうなります。

export LIBGUESTFS_BACKEND=direct

virt-v2v \
 -i disk onoda-rhel8-disk1.vmdk \
 -o disk \
 -os /tmp \
 --run nwscript-update.sh \
 --upload cloud.cfg:'/etc/cloud/cloud.cfg'

変換されました。

root@onoda-converter-fedora:~# export LIBGUESTFS_BACKEND=direct

root@onoda-converter-fedora:~# virt-v2v \
 -i disk onoda-rhel8-disk1.vmdk \
 -o disk \
 -os /tmp \
 --run nwscript-update.sh \
 --upload cloud.cfg:'/etc/cloud/cloud.cfg'
[   1.9] Setting up the source: -i disk onoda-rhel8-disk1.vmdk
[   3.0] Opening the source
[   8.9] Checking filesystem integrity before conversion
[  13.3] Detecting if this guest uses BIOS or UEFI to boot
[  13.8] Inspecting the source
[  21.7] Detecting the boot device
[  21.8] Checking for sufficient free disk space in the guest
[  21.8] 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.
[ 446.1] Setting a random seed
[ 446.1] Running: nwscript-update.sh
[ 448.4] Uploading: cloud.cfg to /etc/cloud/cloud.cfg
[ 448.4] SELinux relabelling
[ 451.9] Mapping filesystem data to avoid copying unused and blank areas
[ 452.7] Checking filesystem integrity after conversion
[ 455.2] Closing the overlay
[ 455.4] Assigning disks to buses
[ 455.4] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 455.4] Setting up the destination: -o disk -os /tmp
[ 456.5] Copying disk 1/1
█ 100% [****************************************]
[ 880.1] Creating output metadata
[ 880.1] Finishing off

このあと、storageを切り離し、新しいVSIをオーダーします。

接続

今回は「--upload cloud.cfg:'/etc/cloud/cloud.cfg'」を付けてIBM Cloud標準のcloud.cfgに置き換えて変換したのでvpcuserで接続します。
移行元で作成した「env.txt」が保持されているのが確認できました。

C:\Users\6onoda>ssh vpcuser@10.50.6.14
The authenticity of host '10.50.6.14 (10.50.6.14)' can't be established.
ED25519 key fingerprint is SHA256:eOV3T2VAcBcVdjYoRstLCuEe6qFkkLhSaxkN9umJ0Jo.
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.50.6.14' (ED25519) to the list of known hosts.
Activate the web console with: systemctl enable --now cockpit.socket

Register this system with Red Hat Insights: insights-client --register
Create an account or view all your systems at https://red.ht/insights-dashboard
[vpcuser@onoda-rhel8-tgt ~]$ sudo su -
[root@onoda-rhel8-tgt ~]# cat env.txt
FromVCFaas

Windows2022での検証

手順は、RHEL8の時と変わりません。

OVAを転送しtarで展開してvmdkファイルを取り出します。

root@onoda-converter-fedora:~# tar xf onoda-win22.ova
root@onoda-converter-fedora:~# ls -al onoda-win*
-rw-r--r--. 1   64   64 9830614016 Jun 26 05:01 onoda-win22-disk1.vmdk
-rw-r--r--. 1   64   64     270840 Jun 26 05:01 onoda-win22-file1.nvram
-rw-r--r--. 1   64   64        285 Jun 26 04:50 onoda-win22.mf
-rw-------. 1 root root 9830906368 Jun 26 05:01 onoda-win22.ova
-rw-r--r--. 1   64   64      17421 Jun 26 04:50 onoda-win22.ovf

変換先のboot storageを変換用VSIに接続し、vmdkファイルの名前でリンクを作成します。

root@onoda-converter-fedora:~# ln -fs /dev/vdd /tmp/onoda-win22-disk1-sda
root@onoda-converter-fedora:~# ls -l /tmp/onoda-win*
lrwxrwxrwx. 1 root root 8 Jun 26 05:57 /tmp/onoda-win22-disk1-sda -> /dev/vdd

変換します。Windows用なので先ほどと、オプションが多少違います。

用意したboot storageのタイプがgeneration 1 profileなのかsdp profile(generation 2 profile)なのかに注意してください。
それによって、オプションが違います。

こちらに解説がありますが

--block-driver を下記のよう指定してください。

storageタイプ 指定
generation 1 profile --block-driver virtio-scsi
sdp profile --block-driver virtio-blk を指定するか、指定しない

現在標準のsdp profileに対して--block-driver virtio-scsiを指定すると、移行先VSIはポータル上は実行中になりますが接続できませんでした。VNCコンソールで確認するとブートしていませんでした。

export VIRTIO_WIN=/root/virtio-win-x.x.x.iso

export LIBGUESTFS_BACKEND=direct

virt-v2v \
 -i disk [vmdkファイル名] \
 -o disk \
 -os /tmp \
[--block-driver [virtio-scsi | virtio-blk]] # 指定しないとvirtio-blkがデフォルト

今回は「sdp profile」を用意したので「--block-driver」オプションを指定しません。

実行します。

root@onoda-converter-fedora:~# VIRTIO_WIN=/root/virtio-win-1.9.53.iso
root@onoda-converter-fedora:~# export LIBGUESTFS_BACKEND=direct
root@onoda-converter-fedora:~# virt-v2v \
 -i disk onoda-win22-disk1.vmdk \
 -o disk \
 -os /tmp
[   0.0] Setting up the source: -i disk onoda-win22-disk1.vmdk
[   1.0] Opening the source
[   6.7] Checking filesystem integrity before conversion
[   7.6] Detecting if this guest uses BIOS or UEFI to boot
[   8.6] Inspecting the source
[  12.9] Detecting the boot device
[  12.9] Checking for sufficient free disk space in the guest
[  12.9] Converting Windows Server 2022 Standard (win2k22) to run on KVM
virt-v2v: warning: this guest has Anti-Virus (AV) software and a new virtio
block device driver was installed.  In some circumstances, AV may prevent
new drivers from working (resulting in a 7B boot error).  If this happens,
try disabling AV before doing the conversion.
virt-v2v: This guest has virtio drivers installed.
[  30.2] Setting a random seed
virt-v2v: warning: random seed could not be set for this type of guest
[  30.2] SELinux relabelling
[  32.8] Fixing NTFS permissions
[  32.8] Mapping filesystem data to avoid copying unused and blank areas
[  40.2] Checking filesystem integrity after conversion
[  41.1] Closing the overlay
[  41.2] Assigning disks to buses
[  41.2] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  41.2] Setting up the destination: -o disk -os /tmp
[  42.3] Copying disk 1/1
█ 100% [****************************************]
[ 607.3] Creating output metadata
[ 607.3] Finishing off

boot storageを切り離して、そこから新しいWindows2022をオーダーします。

ポータル上のVSIの状況が実行中になっても、しばらくは設定のため再起動を繰り返します。
RDPで接続できる状況になったかはVNCコンソールで確認してください。

今回の方法で移行したWindowsサーバーの場合、Administratorのパスワードは変更されていません。移行前のパスワードで接続します。

移行元のWindowsで作成したファイルも確認できました。

{A3365A9A-2CE5-4348-9A26-B69D31304255}.png

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?