目次

はじめに
1. 概要
- 1-1. 前提
2. OVA ファイル用の File Storage の準備
3. OVA ファイルの作成
- 3-1. 【方法1】tarball で固めて OVA を作成
- 3-2. 【方法2】ovftool で OVA に変換
4. OVA ファイルの配置
5. OVA Provider の作成
6. OVA Provider による Cold plan の作成と実行
- 6-1. Plan の作成
- 6-2. Plan の実行
7. 終わりに

はじめに

#1 の § 2. MTV のインストールでは、OpenShift Virtualization on IBM ROKS に MTV Operator をインストールしました。#2 では MTV の VMware Provider を使い、vSphere から OpenShift Virtualization on IBM ROKS へ Cold/Warm の移行を実行しました。一方、同じ Cold 移行でも「VMware Provider で vCenter/ESXi に直接つなぐ」のではなく、OVF/OVA をいったんファイルとして受け取り、OVA を取り込む OVA Provider という選択肢があります。

OVA Provider は、移行元インベントリへの接続や VDDK/CBT を前提にしないため、ネットワーク制約や権限制約がある環境でも採りやすい一方、代わりに「OVA をどこに置き、どう運ぶか」が重要です。

なお本記事では Warm 移行 (CBT/VDDK) には触れません。OVA Provider は基本的に Cold 移行の選択肢として整理します。移行のための準備から実行までを一気通貫かつ再現可能な形でまとめます。

1. 概要

本記事では、MTV の OVA Provider を用いて vSphere のVMを OVA/OVF として取り出し、OpenShift Virtualization on IBM ROKS に Cold 移行する一連の手順を、再現可能な形で整理します。特に「OVA/OVF を置く場所 (File Storage)」の準備と、失敗時の切り分けポイントに重点を置きます。

1-1. 前提

2. OVA ファイル用の File Storage の準備

OVA Provider は、移行元の vCenter に接続してディスクを読み出すのではなく、OVA/OVF を「クラスタから参照できる共有ストレージ上」に置き、そのファイルを取り込む方式です。そのため、まずは OVA/OVF を配置するための RWX のファイル共有（NFS）を用意します。

2-1. セキュリティグループの同期

ROKS 4.11 以降ではセキュリティグループのルールが変わっており、File Storage for VPC を使う前にセキュリティグループ (SG) を同期 (sync) する必要がある場合があります。

[参考] IBM Cloud Docs > Adding File Storage for VPC to apps

クラスター ID を取得
```
ibmcloud oc cluster ls
```
kube-<clusterID> セキュリティグループの ID を取得
```
ibmcloud is sg kube-<cluster-id> | grep ID
```

取得した ID を使ってセキュリティグループを同期

ibmcloud ks security-group sync -c <cluster ID> --security-group <ID>

これで、File Storage for VPC が kube-<clusterID> セキュリティグループを使ってノード・ゾーンをまたいでアクセスできる状態になります。

2-2. StorageClass の確認

ストレージクラス一覧から File Storage for VPC 用のものを確認します。

$ oc get sc | { read -r header; echo "$header"; grep vpc-file; }

# 出力例
NAME                                          PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ibmc-vpc-file-1000-iops                       vpc.file.csi.ibm.io                     Delete          Immediate              true                   64d
ibmc-vpc-file-3000-iops                       vpc.file.csi.ibm.io                     Delete          Immediate              true                   64d
ibmc-vpc-file-500-iops                        vpc.file.csi.ibm.io                     Delete          Immediate              true                   64d
ibmc-vpc-file-eit                             vpc.file.csi.ibm.io                     Delete          Immediate              true                   64d
ibmc-vpc-file-metro-1000-iops                 vpc.file.csi.ibm.io                     Delete          WaitForFirstConsumer   true                   64d
ibmc-vpc-file-metro-3000-iops                 vpc.file.csi.ibm.io                     Delete          WaitForFirstConsumer   true                   64d
ibmc-vpc-file-metro-500-iops                  vpc.file.csi.ibm.io                     Delete          WaitForFirstConsumer   true                   64d
ibmc-vpc-file-metro-retain-1000-iops          vpc.file.csi.ibm.io                     Retain          WaitForFirstConsumer   true                   64d
ibmc-vpc-file-metro-retain-3000-iops          vpc.file.csi.ibm.io                     Retain          WaitForFirstConsumer   true                   64d
ibmc-vpc-file-metro-retain-500-iops           vpc.file.csi.ibm.io                     Retain          WaitForFirstConsumer   true                   64d
ibmc-vpc-file-min-iops                        vpc.file.csi.ibm.io                     Delete          Immediate              true                   64d
ibmc-vpc-file-regional                        vpc.file.csi.ibm.io                     Delete          Immediate              true                   64d
ibmc-vpc-file-regional-max-bandwidth          vpc.file.csi.ibm.io                     Delete          Immediate              true                   64d
ibmc-vpc-file-regional-max-bandwidth-sds      vpc.file.csi.ibm.io                     Delete          WaitForFirstConsumer   true                   64d
ibmc-vpc-file-retain-1000-iops                vpc.file.csi.ibm.io                     Retain          Immediate              true                   64d
ibmc-vpc-file-retain-3000-iops                vpc.file.csi.ibm.io                     Retain          Immediate              true                   64d
ibmc-vpc-file-retain-500-iops                 vpc.file.csi.ibm.io                     Retain          Immediate              true                   64d

2-3. File Storage for VPC の動的プロビジョニング

PVC を作成するプロジェクト (名前空間) に切り替えます。ここでは ocpv-lab という名前の名前空間を利用しました。
```
$ oc project ocpv-lab
Now using project "ocpv-lab" on server "https://■■■■■■.us-south.containers.cloud.ibm.com:31060".
```

例として、ibmc-vpc-file-retain-500-iops StorageClass を利用し、256Gi の RWX ボリュームを作ります。PVC 用の YAML ファイルを作成します。ここでは、hm-pvc-test.yamlという名前の YAML を用意し、作業 PC (macOS) の ~/Downloads/ ディレクトリに置きました。

hm-pvc-test.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: hm-pvc-test  # PVC 名は任意
spec:
  accessModes:
    - ReadWriteMany  # 複数ノード・複数Podからマウント可能
  resources:
    requests:
      storage: 256Gi  # 容量（Gi）
  storageClassName: ibmc-vpc-file-retain-500-iops  # 利用したい StorageClass 名

用意した YAML ファイルから PVC を作成します。

# hiroaki.mishima @ HiroakinoMacBook-Pro in ~/Downloads [16:20:00]
$ oc apply -f hm-pvc-test.yaml
persistentvolumeclaim/hm-pvc-test created

PVC が PV にバインドされたことを確認します。

$ oc describe pvc hm-pvc-test

# 出力例 (作成直後)
Name:          hm-pvc-test
Namespace:     ocpv-lab
StorageClass:  ibmc-vpc-file-retain-500-iops
Status:        Pending
Volume:
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-provisioner: vpc.file.csi.ibm.io
               volume.kubernetes.io/storage-provisioner: vpc.file.csi.ibm.io
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Used By:       <none>
Events:
  Type    Reason                 Age               From                                                                                                   Message
  ----    ------                 ----              ----                                                                                                   -------
  Normal  Provisioning           41s               vpc.file.csi.ibm.io_ibm-vpc-file-csi-controller-57b446f89c-tzcs5_c97fab19-9b15-4322-9842-810525be6e40  External provisioner is provisioning volume for claim "ocpv-lab/hm-pvc-test"
  Normal  ExternalProvisioning   9s (x5 over 41s)  persistentvolume-controller                                                                            Waiting for a volume to be created either by the external provisioner 'vpc.file.csi.ibm.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
  Normal  ProvisioningSucceeded  0s                vpc.file.csi.ibm.io_ibm-vpc-file-csi-controller-57b446f89c-tzcs5_c97fab19-9b15-4322-9842-810525be6e40  Successfully provisioned volume pvc-672a2b75-ef2e-4880-a8ca-3d9db2dcf6ae

# 出力例 (作成完了)
Name:          hm-pvc-test
Namespace:     ocpv-lab
StorageClass:  ibmc-vpc-file-retain-500-iops
Status:        Bound
Volume:        pvc-672a2b75-ef2e-4880-a8ca-3d9db2dcf6ae
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: vpc.file.csi.ibm.io
               volume.kubernetes.io/storage-provisioner: vpc.file.csi.ibm.io
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      256Gi
Access Modes:  RWX
VolumeMode:    Filesystem
Used By:       <none>
Events:        <none>

Status: Bound になっており、Volume: pvc-xxxx のように PV が割り当てられていれば成功です。
Events 欄の Reason 列に ProvisioningSucceeded と出ていれば、File Storage for VPC のボリューム注文も完了しています。

IBM Cloud Web UI からも作成済みの PVC の PV (Persistent Volume) を確認できます。

oc コマンドでも PV を確認できます。

$ NS=ocpv-lab
PVC=hm-pvc-test
PV=$(oc get pvc -n "$NS" "$PVC" -o jsonpath='{.spec.volumeName}{"\n"}')
echo "PV=$PV"

# 出力例
PV=pvc-672a2b75-ef2e-4880-a8ca-3d9db2dcf6ae

作成に失敗した場合は下記のコマンドで PVC の作成処理をキャンセルします。
```
$ oc delete -f hm-pvc-test.yaml
persistentvolumeclaim "hm-pvc-test" deleted
```

作成された File Storage Shares (PVC) を確認します。

$ NS=ocpv-lab
oc get pvc -n "$NS" hm-pvc-test -o wide
NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                    VOLUMEATTRIBUTESCLASS   AGE     VOLUMEMODE
hm-pvc-test   Bound    pvc-672a2b75-ef2e-4880-a8ca-3d9db2dcf6ae   256Gi      RWX            ibmc-vpc-file-retain-500-iops   <unset>                 3d23h   Filesystem

IBM Cloud Web コンソール > Infrastructure > Storage > File storage shares から、先程作成された PV (例 pvc-...) をクリックして、この PV の [Overview] ページを表示します。その後、自動作成されている Mount target を選択します。
Mount target をクリックして Mount path (例：<host>:/<mount_target_path>) を確認します。
筆者の環境では File Storage Share (PVC) の Security Group に Inbound/Outbound rules を追加する必要がありました。

3. OVA ファイルの作成

vSphereからエクスポートした OVF ファイル群から MTV 用の OVA ファイルを生成します。

vSphere 6.5 以降では、OVA テンプレートを直接エクスポートできません、OVF テンプレートが唯一のオプションです。

[参考] Broadcom > OVF および OVA テンプレートのデプロイとエクスポート

vSphere Client にログインし、移行対象の仮想マシンを選択して、OVF テンプレートをエクスポートします。このとき、仮想マシンは停止している必要があります。
下記の画面が表示されるので、そのまま [OK] ボタンをクリックします。
OVF ファイル群が Web ブラウザ経由でローカルにダウンロードされます。ファイルサイズが大きいので、数分待ちます。
下記のようなファイルがダウンロードされたことを確認します。
- <VM名>.ovf (VMの定義)
- <VM名>.mf (チェックサム情報)
- <VM名>-1.vmdk (ディスク)
- <VM名>-3.nvram (BIOS/UEFI 設定)
- <VM名>-2.iso (CD/DVDの中身)
すべての OVF ファイル一式を同じディレクトリに置きます。
cd コマンドで、そのディレクトリに移動しておきます。

OVF一式（.ovf + .vmdk + .mf + .nvram + .iso）を単一のOVA ファイルに“再パッケージング”します。下記の2つの方法 (tarball, OVF Tool) を紹介します。筆者の環境ではどちらの方法でも出来上がった OVA ファイルに差異は確認できませんでした。

3-1. 【方法1】tarball で固めて OVA を作成

ファイルを tarball でまとめて、拡張子 .ova を付けます。
```
tar cvf <VM名>.ova \
  <VM名>.ovf \
  <VM名>.mf  \
  <VM名>-1.vmdk \
  <VM名>-2.iso \
  <VM名>-3.nvram
```
- tar cvf <出力ファイル名>.ova <ファイル列> のように実行します。
- ファイルの順番は基本的に「.ovf → .mf → .vmdk → その他」にしておくと無難です。

3-2. 【方法2】`ovftool` で OVA に変換

ovftool CLI ツールを使う公式な方法です。VMware (Broadcom) 純正の ovftool がある場合はこちらも使えます。インストールから ovftool の実行までを解説します。

まずはインストール手順です。

Broadcom の Developer Portal から作業環境にあった Open Virtualization Format (OVF) Tool のソースをダウンロードしておきます。筆者の検証時点では 5.0.0 が最新バージョンでした。
- [参考] Broadcom > Developer Portal > Open Virtualization Format (OVF) Tool

Windows 版は MSI インストーラとして提供されており、指示通りにインストールできますので手順は省略します。macOS 版 OVF Tool のインストール手順を説明します。macOS 版は DMG 形式ではなく ZIP ファイルであるため、手動でセットアップする必要があります。インストーラが無い代わりに、フォルダ一式をどこかに置いて、OVF Tool の実行ファイルへの PATH を通すか、シンボリックリンクを張るだけで使えます。

ダウンロードした OVF Tool の ZIP ファイルを適当なディレクトリ (例: ~/Download/) 内で解凍します。解凍後のファイル群は VMware OVF Tool ディレクトリに展開されています。
解凍後の OVF Tool のファイル群を /Applications ディレクトリに移動します。
ovftool に実行権限が付いているか確認します。
```
ls -l "/Applications/VMware OVF Tool/ovftool"
```
- パーミッションの先頭が -rwxr-xr-x のように x を含んでいれば実行可能です。もし -rw-r--r-- のように x が無ければ、下記のコマンドで設定します：
```
sudo chmod +x "/Applications/VMware OVF Tool/ovftool"
```
シンボリックリンクを張って PATH に乗せます。/usr/local/bin はすでに PATH に入っていることが多いので、そこに ovftool へのリンクを 1 本張る方法が簡単です。
```
sudo ln -s "/Applications/VMware OVF Tool/ovftool" /usr/local/bin/ovftool
```
- これで /usr/local/bin/ovftool → /Applications/VMware OVF Tool/ovftool というリンクができました。
正常にインストールされているか確認します。

ovftool --version

# 出力例
VMware ovftool 5.0.0 (build-24781994)

macOS のターミナルから OVF Tool のバージョン確認を実施した際に「”***” は開いていません」という警告が出て、コマンドを実行できない場合があります。これは macOS の Gatekeeper にブロックされている状態です。

下記の手順で回避できます。

いまのダイアログはいったん「完了」で閉じます。
メニュー → 「システム設定…」を開きます。
左側で「プライバシーとセキュリティ」を選択します。
画面を下の方へスクロールすると、「セキュリティ」セクションに *** は使用がブロックされました または "***" was blocked from use…のようなメッセージと「このまま許可」／「許可」ボタンが表示されます。
その「許可」ボタンをクリックします。

筆者の環境では、ovftool だけでなく、/VMware OVF Tool/lib 配下のライブラリ群 (12項目) に対しても同様に実行を許可する必要がありました。

ovftool がインストールされたので、ovftool を使って OVFファイル一式を OVA ファイルに変換します。

ovftool で変換します。

ovftool <VM名>.ovf <VM名>.ova

# 実行例
#hiroaki.mishima @ HiroakinoMacBook-Pro in ~/Downloads/win2019-acs-ovf [15:50:49]
$ ovftool win2019-acs.ovf win2019-acs.ova
Opening OVF source: win2019-acs.ovf
The manifest validates
Opening OVA target: win2019-acs.ova
Writing OVA package: win2019-acs.ova
Transfer Completed
Warning:
  - Wrong file size specified in OVF descriptor for 'win2019-acs-1.vmdk' (specified: -1, actual 5914354688).
Completed successfully

ovftool <入力OVF> <出力OVA> という形式です。
カレントディレクトリに <VM名>.ovf と関連ファイルがあることが前提です。
Warning は、OVF (.ovf) 内の VMDK の “サイズ情報” が -1 (不明/未設定) になっているのに、実体の win2019-acs-1.vmdk は 5,914,354,688 bytes ある、というメタ情報の不一致を ovftool が指摘しているだけですので、問題ありません。

4. OVA ファイルの配置

下記のフローで PV (NFS 共有) に OVA ファイルをアップロードします。
macOS (Client PC) → 踏み台 VSI (bastion-ova-uploader) → File Storage share (PVC)

4-1. OVA アップロード用の踏み台サーバーの用意

OVA アップロード用の踏み台サーバーとして、ここでは「bastion-ova-uploader」という名前の IBM Cloud Virtual Server Instance (VSI) を作成しました。

踏み台サーバーの作成過程で SSH key (例: hmishima-ssh-key) を作成しました。作成された SSH key の秘密鍵は自動的にローカルにダウンロードされます。
- ローカルの SSH key は安全な場所 (例: ~/.ssh) で保管しておくことが推奨される。実施例は下記の通り：
```
mkdir -p ~/.ssh
mv ~/Downloads/hmishima-ssh-key_rsa.prv ~/.ssh/
```
- 権限を厳しくします。筆者の環境では、これをしないと SSH 接続が拒否されました。
```
chmod 0600 ~/.ssh/hmishima-ssh-key_rsa.prv
```

この秘密鍵を利用して踏み台サーバー (例: IP=10.239.64.16) に root でログインできることを確認します。

# hiroaki.mishima @ HiroakinoMacBook-Pro in ~ [12:05:24]
$ ssh root@10.239.64.16 -i /path/to/hmishima-ssh-key_rsa.prv
[root@bastion-ova-uploader ~]#

Optional) 下記のように ~/.ssh/config ファイルを作成することで、ログイン情報の入力を省略できます。

config

Host bastion-ova-uploader
  HostName 10.239.64.16
  User root
  IdentityFile ~/.ssh/hmishima-ssh-key_rsa.prv
  IdentitiesOnly yes

ホスト名の指定だけで踏み台サーバーにログインできるようになります。

# hiroaki.mishima @ HiroakinoMacBook-Pro in ~ [13:36:40]
$ ssh bastion-ova-uploader
Last login: Thu Dec 25 04:28:30 2025 from 10.244.65.4
[root@bastion-ova-uploader ~]#

4-2. PV を踏み台サーバーにマウント

SSH で踏み台サーバー (例: bastion-ova-uploader) へログインします。
PVC に紐づいた Security groups から、踏み台サーバー (VSI) → PVC のアクセスを許可する Inbound/Outbound rules を追加します。
- ROKS から PVC を作成しているため、ROKS → PVC のアクセスはデフォルトで許可されていますが、VSI → PVC のアクセスはデフォルトで許可されていません。

OS 毎に少し手順が異なるため、場合分けします。

4-2-1. Red Hat Enterprise Linux / CentOS の場合

NFS クライアントを導入します。
```
dnf install nfs-utils
```
マウント先（ディレクトリ）を作成します。
```
mkdir -p /mnt/nfs
```
- -p は “parents” の意味です。-p フラグを指定しない場合、新しく作成されるディレクトリのそれぞれの親ディレクトリーは既に存在していなければなりません。冪等（何回実行しても同じ結果）にしたい手順書では、-p フラグの使用が安全です。
Mount target（NFS サーバー）をマウントします。
```
mount -t nfs4 -o <options> <host:/mount_target_path> /mnt/nfs
# 例: mount -t nfs4 -o sec=sys 10.239.128.5:/4e137021_f151_40a4_9455_31d229975e13 /mnt/nfs
```
- IBM Cloud File Storage for VPC は NFS v4.1 以上が前提のため、-t nfs4 に加えて vers=4.1 を明示しても良いです。
- <mount-target-ip> は File Storage share の Mount target の IP、<export-path> は share に紐づく Mount path (export path) です。
- うまくいかない場合は、まず疎通と名前解決を疑います (例: ping は通っても NFS のポートが閉じているとマウントできません)。

注記:
Red Hat Enterprise Linux に対して IBM Power Virtual Server インスタンスからファイル共有をマウントしたい場合は、ロードバランサーを介したネットワークパスを使用する必要があります。詳細は次のチュートリアルを参照： IBM Power Virtual Server インスタンスから File Storage for VPC 共有にアクセスする。

4-2-2. Ubuntu の場合

NFS クライアントを導入します。
```
sudo apt install nfs-common
```
マウント先（ディレクトリ）を作成します。
```
mkdir -p /mnt/nfs
```
インスタンス再起動 (reboot)
Mount target（NFS サーバー）をマウントします。
```
mount -t nfs4 -o <options> <host:/mount_target> /mnt/nfs
```
- ファイルが作成でき、一覧に表示されれば Read/Write は概ね OK です。

4-2-3. OS 共通

ここからは OS 共有の確認手順です。

マウントできたか確認します。
```
mount | grep /mnt/nfs
df -h /mnt/nfs
```
テスト用のファイル作成し、Read/Write できるか確認します。
```
touch <mountpoint>/test.txt
ls -al <mountpoint>
```

4-3. NFS 共有に OVA ファイルをアップロード

踏み台サーバーにマウントされた File storage share のボリューム (PV) に OVA ファイルをアップロードします。3つの方法 (scp, rsync, Cyberduck) を紹介します。

4-3-1. 【方法1】`scp` (再開不可・シンプル)

scp (Secure Copy) は SSH を使ってファイルをコピーするコマンドです。ローカルPC ↔ リモートサーバー間で、ファイル/ディレクトリを “そのまま” 転送できます。

scp は途中で切れると基本的に再開できません。大容量ファイルを不安定な回線で転送する場合は、まず SSH セッションが切れにくいように設定しておきます。macOS の場合、~/.ssh/config に以下を追記します。
```
Host bastion-ova-uploader
...
  ServerAliveInterval 30
  ServerAliveCountMax 6
```
ローカルの OVA ファイルを、SSH 接続先の踏み台サーバー bastion-ova-uploader の /mnt/nfs/ (NFSマウント済みの共有ディレクトリ) へ scp で転送します。
```
scp "/path/to/file.ova" bastion-ova-uploader:/mnt/nfs/
```

4-3-2. 【方法2】`rsync` による SSH 転送 (再開可・安定)

rsync は差分同期 (incremental transfer) に強いファイル転送ツールです。ローカル ↔ リモート間でファイルをコピーする際に、途中で切れても再開しやすく、2回目以降は変更分だけ送れ (高速)、権限/タイムスタンプなどの属性も揃えられるという点が scp との大きな違いです。

[参考] FreeBSD Manual Pages > rsync

ローカルの OVA ファイルを、SSH 接続先の踏み台サーバー bastion-ova-uploader の /mnt/nfs/ (NFSマウント済みの共有ディレクトリ) へ rsync で転送します。
```
rsync -avP --append-verify -e "ssh -i ~/.ssh/hmishima-ssh-key_rsa.prv" \
"/path/to/file.ova" bastion-ova-uploader:"/mnt/nfs/"
```
- -a (--archive) で、ディレクトリ構成、パーミッション、グループなどを保持した状態で転送します。基本的には付与しておくことをお勧めします。
- -v (--verbose) で、バックアップしたファイルの一覧や転送情報のサマリ (送信データ量、転送速度) を表示します。
- -P は --partial + --progress を含みます。転送が途中で切れても、宛先に“途中までのファイル”を残します。
- --append-verify は、宛先に “途中まで残っているファイル” がある場合に、続きから安全に再開するためのオプションです (--append より安全)。
  - --inplace も “途中ファイルを残して再開しやすくする” 目的で使われますが、通常は --append-verify か --inplace のどちらか一方で十分です。本記事では --append-verify を採用しています。
- -e (--rsh=COMMAND) は rsync がリモート接続に使う Remote Shell を指定するためのオプションです。典型例は ssh です。
- rsync が差分計算して続きを送るには、少なくとも次の条件を満たす必要があります。
  - 宛先の途中ファイルが残っていること
  - 同じファイル名に対して、同じコマンドを再実行すること
  - 宛先ファイルが他のプロセスで書き換えられていないこと

4-3-3. 【方法3】Cyberduck による SFTP 転送（再開可・要インストール）

Cyberduckは、macOS / Windows で使える GUI のファイル転送クライアントです。ターミナルで scp や rsync を打たなくても、Finder 同様の操作でサーバーに接続してファイルをアップロード／ダウンロードできます。

接続情報を設定し、SFTP で踏み台サーバー bastion-ova-uploader にアクセスします。
SFTP で踏み台サーバーにログインし、/mnt ディレクトリが存在することを確認します。
/mnt ディレクトリ配下に /nfs ディレクトリを作成し、ドラッグ＆ドロップなどで OVA ファイルをアップロードします。

4-3-4. 転送後の確認

OVA ファイルが正しく転送できているか確認します。ここでは win2019-acs.ovftool.ova という名前の OVA ファイルを検証しています。

転送前後の OVA ファイルのサイズが一致していることを確認します。

# ローカル(手元)の OVA ファイルのサイズ確認例
ls -l "/path/to/win2019-acs.ovftool.ova"
-rw-r--r--. 1 nobody nobody 11753842688 Dec 24 15:56 /path/to/win2019-acs.ovftool.ova

# 転送先の OVA ファイルのサイズ確認例
ssh bastion-ova-uploader ls -l /mnt/nfs/win2019-acs.ovftool.ova
-rw-r--r--. 1 nobody nobody 11753842688 Dec 26 03:03 /mnt/nfs/win2019-acs.ovftool.ova

転送先の OVA ファイルの中身を確認します。

ssh bastion-ova-uploader 'tar -tf /mnt/nfs/win2019-acs.ovftool.ova | head'

# 出力例
win2019-acs.ovf
win2019-acs.mf
win2019-acs-disk1.vmdk
win2019-acs-file1.iso
win2019-acs-file2.nvram

5. OVA Provider の作成

OpenShift Virtualization に MTV がインストール済みであることを前提とします。

OpenShift web console > Migration for Virtualization > Providers ページを開き、[Create provider] ボタンをクリックします。
[Create provider] ページに遷移します。Provider を作成するプロジェクト (名前空間) と Provider の種類を選択します。
- Project："openshift-mtv" を選択しました。
- Provider type："Open Virtual Appliance" (OVA) を選択します。
OVA provider の名前と OVA ファイルが保存されている NFS 共有ディレクトリの URL を指定し、[Create provider] ボタンをクリックして Provider を作成します。
- Provider の名前に使用できる文字は、小文字の英数字とハイフン (-) のみで、先頭・末尾は小文字の英数字にしてください。また、このクラスタ内でユニークな名前である必要があります。
- OVA ファイルが保存されている NFS 共有ディレクトリとして、すでに作成した File storage share の Mount path (例: 10.239.128.5:/4e137021_f151_40a4_9455_31d229975e13) を指定します。
作成された OVA Provider の状態が "Ready" になったことを確認します。

6. OVA Provider による Cold plan の作成と実行

6-1. Plan の作成

OpenShift web console > Migration for Virtualization > Migration plans ページを開き、[Create plan] ボタンをクリックします。
Basic setup > General で基本設定を入力します。
- Plan name：移行プランに任意の名前を付けます。
- Plan project：この移行プランを作成する名前空間を指定します。
- Source provider：先ほど作成した OVA Provider を指定します。
- Target provider：OpenShift Virtualization を意味する host cluster (Provider) を指定します。
- Target project：vSphere から移行してきた仮想マシンを OpenShift Virtualization のどの名前空間に配置するかを指定します。ここでは手動で作成した "ocpv-lab" 名前空間を指定しています。
Basic setup > Virtual machines から移行対象の仮想マシンを選択します。
- ここに表示される仮想マシンの一覧は、前述で作成した File storage share (PVC/NFS) の Mount path 配下に配置した OVA ファイルを、OVA Provider がインベントリとして読み取った結果です。実際に PVC (NFS 共有) に OVA が置けているかは、マウント元の踏み台サーバーから次のように確認できます。
```
ssh bastion-ova-uploader ls -l /mnt/nfs/

# 出力例
total 59153448
-rw-r--r--. 1 nobody nobody 16875234816 Mar  4 09:05 rhel9-acs4.ovftool.ova
-rw-r--r--. 1 nobody nobody  9187016192 Mar  4 06:59 ubuntu2510-acs.ovftool.ova
-rw-r--r--. 1 nobody nobody 11753842688 Dec 26 03:03 win2019-acs.ovftool.ova
-rw-r--r--. 1 nobody nobody 11753855488 Dec 26 06:35 win2019-acs.tar.ova
-rw-r--r--. 1 nobody nobody 10765590016 Dec 26 08:45 win2022-acs.ovftool.ova
```
  - 例として仮想マシン win2019-acs の OVA ファイルは、win2019-acs.ovftool.ova と win2019-acs.tar.ova の2つが存在します。これは OVF → OVA の作り方 (OVF Tool / tarball) の違いによるもので、いずれも同じ仮想マシンを表す OVA です。なお、OVA Provider がどの単位で “同一VM” とみなすかは、ファイル名だけでなく OVF 記述子 (.ovf) などのメタデータにも依存します。意図せず重複や誤認識を避けるため、基本的には移行対象ごとに OVA ファイルは1つに絞って配置した方が良いでしょう。不要な方は別ディレクトリに退避、またはリネームしておくと安全です。
Basic setup > Network map の [Use new network map] から Network mapping を作成します。
- Source network：vSphere 上の仮想マシンに紐づいている Network アダプターを指定します。
- Target network：Default network を指定します。
- Network map name：任意の名前を付けます。使用できる文字は、小文字の英数字とハイフン (-) のみで、先頭・末尾は小文字の英数字にしてください。

Migration Plan 作成時の Network mapping で選ぶ “Default network” は、基本的に移行先 (OpenShift Virtualization 側) の既定ネットワーク (primary network) です。“Default network” は、基本的に Pod network (CNI/クラスタ既定ネットワーク) を指します。

OpenShift Virtualization では、「仮想マシンは既定で単一の内部 Pod network に接続される」と Red Hat のドキュメントにも明記されています。

[参考] 10.1.2. Using the default pod network

Basic setup > Storage map から Storage mapping を作成します。
- Source storage：それぞれの仮想マシンの OVA ファイルに含まれるディスクファイル (*.vmdk) を選択します。
- Target storage class：移行してきた仮想マシンのディスクを置く StorageClass として ocs-storagecluster-ceph-rbd-virtualization 選択を選択します。
- Storage map name：任意の名前を付けます。使用できる文字は、小文字の英数字とハイフン (-) のみで、先頭・末尾は小文字の英数字にしてください。
Additional setup > Other settings > VM target power state から、移行後にこの Plan に含まれるすべての仮想マシンをどの電源状態にするかを選択します。
- この設定は、Plan 作成後でも、移行を開始する前であれば、Plan ページの "Virtual Machines" タブから特定の仮想マシン毎に変更することができます。
Hooks は作成しませんでした。
移行プランの設定内容を確認して、[Create plan] ボタンをクリックします。
移行プランが作成され、ステータスが "Ready for migration" になったことを確認します。

以上で、OVA Provider を利用した Migration plan の作成は完了です。

6-2. Plan の実行

先ほど作成した Cold Plan の画面から [Start] ボタンをクリックします。
OVA Provider を利用した Migration が開始されます。このとき、Plan のステータスは "Migration running" になります。
移行が成功し、Plan のステータスが "Complete" になっていることを確認します。
筆者の環境では３台同時に移行する Plan を作成しています。それぞれの仮想マシンの移行処理のステップと所要時間の一例を示します。
OpenShift Virtualization 側で移行された仮想マシンを確認します。今回の OVA Provider による Cold plan で移行した仮想マシンの３台すべて ocpv-lab 名前空間に作成されていました。試しに、その内の1つの仮想マシン win2022-acs を起動してみます。
- 仮想マシンの起動からログインまで正常に実行できました。

以上で、OVA Provider を利用した Migration は完了です。

7. 終わりに

本記事では、MTV の OVA Provider を使って、vSphere 上の VM を OVF テンプレート (ファイル群) としてエクスポート → OVF から OVA を作成 → 共有ストレージ (NFS) に配置 → Cold 移行する一連の流れを整理しました。

VMware Provider の Cold/Warm 移行と比べると、OVA Provider は vCenter/ESXi への直接接続や VDDK/CBT を前提にしないため、ネットワーク・権限の制約がある環境でも取り回しやすいのが利点です。すなわち、移行元インベントリではなく、共有ストレージ上の OVA ファイルをインベントリとして読みます。その代わり、移行の成否は「OVA/OVF を置く場所（File storage share）」と「そこへ確実に運ぶ手段（踏み台 + 転送）」に強く依存します。また、大きなサイズとなる OVA を扱う場合、rsync --append-verify や Cyberduck のように再開可能な転送手段を選ぶだけで、作業のストレスとやり直しコストを大きく下げられます。

本記事が、OVA Provider を使った Cold 移行の再現や、機能の理解に繋がれば幸いです。