目次
- はじめに
- 1. 概要
- 2. OVA ファイル用の File Storage の準備
- 3. OVA ファイルの作成
- 4. OVA ファイルの配置
- 5. OVA Provider の作成
- 6. OVA Provider による Cold 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. 前提
- MTV Operator がインストールされていること
- [参考] Qiita > MTV VMware Provider による vSphere から OpenShift Virtualization on IBM ROKS への "Cold/Warm" VM 移行 #1 − 準備編 > 2. MTV のインストール
- ROKS クラスタには File Storage for VPC アドオンがインストールされていること
- IBM Cloud コンソール > Containers > Clusters から OCPv の ROKS クラスタを選択し、 [Overview] ページの Add-ons セクションから「File Storage for VPC v2.0」を探します。[Install] ボタンをクリックするだけでインストールできます。
- OVA ファイルを配置する NFS 共有 (例：File Storage for VPC) をクラスタからマウントできること
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-iopsStorageClass を利用し、256Gi の RWX ボリュームを作ります。PVC 用の YAML ファイルを作成します。ここでは、hm-pvc-test.yamlという名前の YAML を用意し、作業 PC (macOS) の~/Downloads/ディレクトリに置きました。hm-pvc-test.yamlapiVersion: 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
- [参考] 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"
- パーミッションの先頭が -rwxr-xr-x のように x を含んでいれば実行可能です。もし -rw-r--r-- のように x が無ければ、下記のコマンドで設定します：
- シンボリックリンクを張って 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,688bytes ある、という メタ情報の不一致を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
- ローカルの SSH key は安全な場所 (例:
- この秘密鍵を利用して踏み台サーバー (例: 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ファイルを作成することで、ログイン情報の入力を省略できます。configHost 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 のポートが閉じているとマウントできません)。
- IBM Cloud File Storage for VPC は NFS v4.1 以上が前提のため、
注記:
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) を指定します。
- Provider の名前に使用できる文字は、小文字の英数字とハイフン (
- 作成された 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つに絞って配置した方が良いでしょう。不要な方は別ディレクトリに退避、またはリネームしておくと安全です。
- 例として仮想マシン
- ここに表示される仮想マシンの一覧は、前述で作成した File storage share (PVC/NFS) の Mount path 配下に配置した OVA ファイルを、OVA Provider がインベントリとして読み取った結果です。実際に PVC (NFS 共有) に OVA が置けているかは、マウント元の踏み台サーバーから次のように確認できます。
- 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 のドキュメントにも明記されています。
-
Basic setup > Storage map から Storage mapping を作成します。
- Source storage：それぞれの仮想マシンの OVA ファイルに含まれるディスクファイル (
*.vmdk) を選択します。 - Target storage class：移行してきた仮想マシンのディスクを置く StorageClass として
ocs-storagecluster-ceph-rbd-virtualization選択を選択します。 - Storage map name：任意の名前を付けます。使用できる文字は、小文字の英数字とハイフン (
-) のみで、先頭・末尾は小文字の英数字にしてください。
- Source storage：それぞれの仮想マシンの OVA ファイルに含まれるディスクファイル (
-
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 移行の再現や、機能の理解に繋がれば幸いです。