「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で行う事です。

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

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

IBM Cloud VPCで行う事

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

変換サーバーの用意
変換サーバーにOVAをインポート
OVAからvmdkの取り出し
移行先VSI用のboot storageの準備
変換サーバーに移行先VSI用のboot storageを接続
変換サーバーでvmdkからVMイメージを移行先VSI用boot storageに変換・書き込み
変換された、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」に所属しています。

この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」という名前にしました。

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

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

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

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

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

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

コピーした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をパワーオフします。

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

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

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

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

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

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

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

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

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

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も前回と同様に下記から入手できます。

https://developer.broadcom.com/tools/open-virtualization-format-ovf-tool/latest

今回は、いったんローカルにダウンロードして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名」は③の部分です。

「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をオーダーします。
手順はこちらになります。

移行先VSI用のboot storageの準備
変換サーバーに移行先VSI用のboot storageを接続
変換サーバーでvmdkからVMイメージを移行先VSI用boot storageに変換・書き込み
変換された、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)なのかに注意してください。
それによって、オプションが違います。

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

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

--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で作成したファイルも確認できました。