目次
- はじめに
- 1. 概要
- 2. ROKS インスタンスの作成
- 3. OpenShift Data Foundation（ODF）のインストール
- 4. OpenShift Virtualization (OCPv) のインストール
- 5. 仮想マシンの作成と起動
- A. ネットワークの制約と将来見通し
- おわりに (予告)
はじめに
VMware を取り巻く状況が大きく変化する中で、代替の仮想化基盤として Red Hat OpenShift Virtualization (OCPv) に関心が集まっています。IBM Cloud の世界でも、VMware on IBM Cloud (VMware Solutions) が 2025年10月31日をもって新規顧客向けの販売 (マーケティング) を終了することが公表され、仮想化基盤の選択肢を改めて見直す機運が高まっています。
[参考] IBM Cloud Docs > End of Marketing for VMware on IBM Cloud
OpenShift Virtualization は Kubernetes ネイティブの仮想化プラットフォームであり、組織が コンテナ化されたアプリケーションと仮想マシン (VM) を、単一かつ統合されたプラットフォーム上で並行して実行できるようにします。 IBM Cloud のマネージド OpenShift サービスである Red Hat OpenShift on IBM Cloud (ROKS) 上で OCPv を利用できるようになったことは、単なる機能追加に留まりません。ROKSクラスタに OpenShift Virtualization Operator を導入することで、Linux/Windows VM の作成・管理、Pod と VM の並行稼働、VM のクローン／インポート、NIC・ディスク管理、ノード間移行など、VM運用に必要な機能を OpenShift の運用モデル (名前空間、RBAC、監視など) に統合できます。
この統合は、デジタルトランスフォーメーション (DX) の観点でも戦略的です。組織は次のような価値を得られます。
- アプリケーションを書き換えることを強制することなく、モダナイゼーションの取り組みを加速できる
- Kubernetes を「共通インフラレイヤー」として標準化できる
- セキュリティ、コンプライアンス、グローバル提供能力を含む IBM Cloud のエンタープライズ機能を活用できる
- クラウドネイティブな基盤の上にインフラを構築し、将来にわたって利用可能な環境を整備できる
- ハイブリッド／マルチクラウド環境の複雑さが増す中で、従来型アーキテクチャとモダンアーキテクチャの橋渡しができる
ここで重要なのは、「仮想化かコンテナ化か」を二者択一で選ぶことではなく、モダンでスケーラブルなアーキテクチャの中で両者をいかに効果的に活用するかです。OpenShift Virtualization on IBM Cloud (ROKS) は、VMベースの既存投資を活かしつつ、クラウドネイティブな運用・自動化へ段階的に寄せていくための現実的な選択肢になり得ます。
1. 概要
本記事では、ROKS 上に OCPv を構築し、まずは KubeVirt VM を任意の名前空間に作成して起動確認できるところまでを、再現可能な形でまとめます。
構築・検証の流れは下記の通りです：
- ROKS インスタンス (クラスタ) のデプロイ
- クラスタへの OpenShift Data Foundation (ODF) のインストール
- クラスタへの OpenShift Virtualization Operator のインストール
- KubeVirt VM (仮想マシン) の作成・起動
1-1. 構築するクラスタ (ROKS / OpenShift) 環境の情報
- プラットフォーム：Red Hat OpenShift on IBM Cloud (ROKS)
- OpenShift：
4.18.30(Kubernetes:1.31.13) - 基盤：IBM Cloud Bare Metal Server for VPC
- Workerノード：3台（Ready）
kube-...-workerp-000001dfkube-...-workerp-00000222kube-...-workerp-0000033f
- ストレージ（VMディスク用）：ODF (OpenShift Data Foundation)
- VM向けStorageClass：
ocs-storagecluster-ceph-rbd-virtualization
- VM向けStorageClass：
- ネットワーク：ROKS のコンテナネットワーク (Calico)
- 2026年2月時点での制約 (詳細は本記事の付録Aを参照)
2. ROKS インスタンスの作成
2-1. 必須前提
ROKS 上で OCPv を動かすために外せない最低条件を記載します。下記の前提は、本記事内で対処するため、あらかじめ実施する必要はありません。
[参考] Red Hat OpenShift on IBM Cloud クラスタに OpenShift Virtualization Operator をインストールする > 前提条件
- ROKS の基盤が VPC で、OpenShift が 4.17 以降であること
- IBM Cloud Docs (OCPv Operatorの手順) に、対象として “Virtual Private Cloud 4.17 and later” と書かれています。
- ワーカーノードは ベアメタルのみ (VPC では必須)
- IBM Cloud Docs に “Baremetal worker nodes only” と明記されています。つまり、VPC の仮想サーバ (VSI) ワーカーノードでは OCPv の動作はサポートされません。
- ノード OS は Red Hat CoreOS (RHCOS) のみ
- IBM Cloud Docsに “Red Hat CoreOS only” とあります。
- アウトバウンド・トラフィック保護の無効化
- アウトバウンド・トラフィック保護は、ROKS (VPC) における Secure by default (SBD) の一部で、クラスタ (特にワーカーノード) から インターネット方向への通信を既定で制限する仕組みです。
- OCPv の導入は OperatorHub からの Operator 取得・イメージ取得・カタログ参照など、クラスタから外部への通信が前提になることが多い。
- CSI ストレージとして OpenShift Data Foundation (ODF) を利用
- OCPv 自体は「ODF 以外の CSI ストレージ」でも動かせます（例：RBD/他社 CSI など）。ただし “ROKSでサポートされる形” としては、IBM Cloudの公式手順が ODF を前提にしています。
2-2. 手順
ROKS の構築する際に作業者が持っていなければならない権限が存在します。
[参考] Qiita > [IBMCloud] IKS/ROKSクラスタ作成時に必要なオプション権限について
- IBM Cloud Web コンソール にアクセスします。
- ハンバーガーメニューをクリックし、[Containers] > [Clusters] を選択します。
- 画面右上の [Create cluster] ボタンをクリックし、設定入力の画面に遷移します。
- Orchestration Platform として「Red Hat OpenShift」(ROKS) を選択します。
- Infrastructure として VPC を選択します。
- リージョンと利用したいゾーンを選択します。
- 筆者が検証したタイミングでは選択したシングルゾーンに十分なリソースが無かったため、下記のエラーに遭遇しました。
確実にデプロイを成功させたい場合、選択した VPC のリージョンとゾーンに十分なベアメタルキャパシティがあるかどうか、IBM Cloud サポートにチケットを起票して確認を依頼すると無難です。筆者の場合、最初のデプロイ試行は、選択したフレーバーのベアメタルがゾーン内に十分存在しなかったため失敗しました。そのため筆者の環境では、ワーカーノードが us-south-1 内のワーカープールに２台、us-south-3 のワーカープールに１台ある構成になっています。
Infrastructure instance status is 'failed': Insufficient capacity within the selected zone - The 'vpc-gen2' infrastructure instance failed to provision.
- 筆者が検証したタイミングでは選択したシングルゾーンに十分なリソースが無かったため、下記のエラーに遭遇しました。
- OpenShift のバージョンを選択します。ここでは「4.18.30」としましたが、基本的には新しいバージョンかつ「default」と併記されるバージョンを利用する方が無難です。また、現時点で OCPv は「4.17」以降である必要である点も注意してください。
- [参考] IBM Cloud Docs > Installing the OpenShift Virtualization Operator on Red Hat OpenShift on IBM Cloud clusters > Prerequisites
- OCP のライセンス形態を選択します。ここでは「Purchase a license」としました。
- ワーカープールを設定します。
- 任意のワーカープール名を付けます。
- ゾーン毎のワーカーノードの数を決めます。少なくとも合計で複数のワーカーノードが存在しないと、 KubeVirt VM の動的リソーススケジューリングの検証ができないので注意してください。
- 適切なワーカーノードのフレーバー (flavor) を選択する必要があります。現時点で、OCPv はベアメタル ワーカーノード (
Machine = Bare metal) でのみサポートされています。また、Ceph／ODF のソフトウェア定義ストレージに使うため、追加ストレージ (Additional storage) を搭載している必要があります。また、OS はRed Hat Enterprise Linux CoreOS (RHCOS)のみがサポートされています。ここではフレーバーとして「bx2d.metal.96x384」を選択しました。
- 必要に応じて、Key Protect を使ってワーカーノードストレージの暗号化を有効にします。
- Networking の設定において、ここでは
Both private & public endpointsを選択しました。
- イメージレジストリ用に IBM Cloud Object Storage インスタンスをアタッチしました。
- セキュリティ項目の設定について、特に
Outbound traffic protectionは無効にする必要があります。これは OCPv の前提条件となっています。- その他の
Cluster encryption、Ingress secrets management、VPC security groupsは適宜設定します。
- その他の
- クラスタの詳細として、クラスタ名、リソースグループ、タグを設定します。FinOps の観点でもタグ付けは重要です。
- 必要に応じてアクティビティトラッキング、ロギング、モニタリングを有効にし、画面右下 の [Create] をクリックします。
- ROKS クラスタの作成には数時間かかります。作成が完了すると、IBM Cloud のクラスタ一覧に表示され、クラスタの情報にアクセスできます。
2-3. NVMe ディスクの確認
Reh Hat CoreOS カーネルバージョンにおいて、いくつかの ワーカーノードの NVMe ドライブ (Additional storage) が正しくマウントされない事例が報告されています。後述の OpenShift Data Foundation (ODF) で Local storage タイプのディスクを使う場合、未フォーマットのディスク（例: NVMe）が必要です。
例えば、デプロイしたワーカーノードのフレーバーでは8台の Additional storage (NVMe ディスク) が存在するはずなのに、５台しか認識されていないといった状態です。筆者の環境では遭遇しませんでしたが、念の為、確認してください。
- クラスタがプロビジョニングされた後で、IBM Cloud Web コンソールのクラスタ画面右上からOpenShift Web コンソールにログインします。
- [Compute] > [Nodes] > 各ホスト（ノード）で Terminal にアクセスします。
- そのシステムにすべての NVMe ディスクが見えているかどうかを確認してください。
- もしディスクが欠けている場合は、エラーメッセージに表示される ID を使って再検出を行う必要があります。
sh-5.1# dmesg | fgrep error [ 9.133039] pci 10000:01:00.0: BAR 0: error updating (0xb6010004 != 0xffffffff) [ 9.140352] pci 10000:01:00.0: BAR 0: error updating (high 0x00000000 != 0xffffffff) [ 9.987954] pci 10001:01:00.0: BAR 0: error updating (0xc2010004 != 0xffffffff) [ 9.995260] pci 10001:01:00.0: BAR 0: error updating (high 0x00000000 != 0xffffffff) [ 10.749558] pci 10002:01:00.0: BAR 0: error updating (0xde010004 != 0xffffffff) [ 10.756870] pci 10002:01:00.0: BAR 0: error updating (high 0x00000000 != 0xffffffff) sh-5.1# echo 1 > /sys/bus/pci/devices/10000:01:00.0/remove sh-5.1# echo 1 > /sys/bus/pci/devices/10001:01:00.0/remove sh-5.1# echo 1 > /sys/bus/pci/devices/10002:01:00.0/remove sh-5.1# echo 1 > /sys/bus/pci/rescan sh-5.1# lsblk | fgrep -c nvme 8 sh-5.1#
すべての NVMe ドライブが認識されていることを確認できたら、OpenShift Data Foundation (ODF) のインストールに進むことができます。現時点では、ODF は OpenShift Virtualization の必須コンポーネントです。
[参考] ベアメタル・サーバーがサポートする NVMe ドライブの数はいくつですか?
3. OpenShift Data Foundation（ODF）のインストール
OpenShift Virtualization を利用するためには、仮想マシン (KubeVirt VM) にアタッチするディスクとして、ストレージサービスが必要になります。IBM Cloud OpenShift クタスターを構築すると、今回のインフラである ROKS on VPC では、クラスタに IBM Block Storage for VPC CSI driver が入り、ブロックストレージ系の StorageClass を持つ Persistent Volume (PV) / PVC が払い出されます。しかし、ストレージのアクセスモードとして ReadWriteOnce (RWO) のみをサポートしており、ストレージをアタッチした単一のノードからしか PV のデータへアクセスできません。OpenShift Virtualization の 仮想マシンのノード間移行を実現するライブマイグレーション機能などを利用する場合、複数ノードから PV への読み書きが可能なストレージが必要になります。したがって、ここでは ReadWriteMany (RWX) のアクセスモードに対応した OpenShift Data Foundation (ODF) を仮想マシンのストレージサービスとして利用します。
3-1. 前提知識
- ODF (OpenShift Data Foundation) は、Ceph ベースのソフトウェア定義ストレージ (SDS) を統合的に提供するプラットフォームであり、VMware vSAN に相当する存在です。筆者の構成では 2 つのゾーンにデプロイし、デフォルトの 3 重ミラーリング構成を採用していますが、ODF はマルチゾーンをまたぐフォルトドメイン構成など、可用性要件に応じたさまざまな構成を選択できます。
- ODF は、オープンソースの Rook-Ceph、Ceph CSI Driver、NooBaa を統合したストレージサービスで、幅広いユースケースに対応可能な SDS 基盤です。一般的なストレージの 3 形態 (Block、File、Object) をすべてサポートしており、オンプレミス／クラウドを問わず一貫した利用が可能です。そのため、アプリケーション側は実行環境を意識することなく、同一のストレージインターフェースを利用できます。
[参考] IBM Cloud Docs > Red Hat OpenShift on IBM Cloud > Understanding OpenShift Data Foundation
[参考] Red Hat Documentation > Red Hat OpenShift Data Foundation > 7.3. Resource requirements
3-2. 手順
- IBM Cloud Web コンソール (作成した ROKS クラスタのページ) から ODF をインストールを開始します。
ROKS では、ODF を OperatorHub から直接入れることはサポート外です。クラスタ・アドオンとしてIBM Cloudコンソール (UI) から導入する方式に限定されています。IBM Cloud 公式ドキュメントにも「重要: IBM Cloud クラスタでは、OperatorHub からの OpenShift Data Foundation のインストールはサポートされていません。 ODF をインストールするには、以下の手順を実行して、クラスタ・アドオンをデプロイします。」と明記されています。ODF はライセンス管理が必要であり、IBM Cloud とのその他のカスタム統合を行うため、OpenShift Web コンソールの OperatorHub からインストールしないでください。
[参考] VPC クラスターへの OpenShift Data Foundation のデプロイ
- IBM Cloud Web コンソールで、先ほど作成したクラスタの [Overview] タブを開きます。
- 画面を下にスクロールして、[Add-ons] リストの中の [OpenShift Data Foundation] カードにある [Install] ボタンをクリックします。
- ODF のバージョンとプランを選択します。
- バージョンは基本にデフォルトの設定で問題ありません。
- プランについても利用したい機能の有無で選択してください。機能差については、IBM Cloud Docs の Feature support by billing type を参照ください。
- ストレージタイプとして Local storage を選択してください。
-
ODF には下記の２つのデプロイメントモードがあります。
- 内部デプロイメントモード：ODF をワークロードと同じクラスタで稼働
- 外部デプロイメントモード：ODF をワークロードと別のクラスタで稼働
2026年2月時点での ROKS では内部デプロイメントモード (Local storage) しかサポートしていません。よって、ROKS 上では OCPv と ODF を同一クラスタで稼働させる必要があります。
-
ODF で Local storage タイプのディスクを使う場合、未フォーマットのディスク (NVMe) が必要です。
-
- このクラスタにおける Storage のキャパシティとワーカーノードの設定を行います。
- ローカルストレージを選択したので、[CSD pod size (Gi)] のフィールドがグレーアウトされます。Pod サイズが「1GiB」で固定されていても、その値は ODF が試みる最小要求サイズを示しているにすぎません。実際には ODF は「欲張り」で、NVMe ドライブ全体を使用しようとします。
- ディスク数については、各ホスト (ノード) で利用したい NVMe ディスクの数を指定します。筆者が構築した ROKS 環境では、ホストが3台あり、それぞれに8台の NVMe ディスクがあります。ディスク数は少なくとも「1」以上である必要があります。例えば、アタッチされたすべての NVMe ディスクを利用したい場合は「8」と指定します。
- 各フィールドの説明
-
OSD pod size (Gi)- ODF（Ceph）の OSD（Object Storage Daemon）Pod が使うディスク容量（= OSD 用にプロビジョンされるボリュームサイズ）です。Cephは通常レプリカ (例: 3副本) を持つので、“使える容量” は総容量より小さくなる点は意識しておくと良いです（ODF 内部の冗長化分が差し引かれます）。
-
Number of OSD disks required- 各ワーカーノードに対して OSD 用のディスク（= OSD 用に作るボリューム）を何本用意するか指定します。指定した数に対して ODF は3倍の OSD を作ります（例: 「1」を指定すると OSD が3つ作成される）。
- ワーカー3台だと、直感的には「各ノード1本 (numOfOsd=1)→合計3本」となります。
-
Local Disk discovery- これは (Bare Metal Server for VPC などで) ローカルディスクを使う場合に、ワーカーノード上の利用可能なストレージデバイスを自動検出してODFで使うオプションです。自動検出は便利ですが、「ODF に渡したくないディスク」まで拾うと事故り得るため、ディスク設計と合わせて使うのが安全です。
-
Taint nodes- 選択したワーカーノードに taint (汚染) を付けて、ODF 関連 Pod しかそのノードで動けないようにするオプションです。OCPv/VM も同じノードに載せたい設計だと、ここを true にすると逆に邪魔になることがあります。
-
Use Ceph RADOS block device (RBD) as the default storage class- ODF 導入時に Ceph RBD の StorageClass をクラスタのデフォルト StorageClass にするオプションです。デフォルト StorageClass を変えると、StorageClass を指定せずに作られる PVC の行き先が変わります。OCPv では「VM 用は
ocs-storagecluster-ceph-rbd-virtualizationを明示」など運用で制御するケースも多いため、デフォルト変更は意図（全体を Ceph へ寄せたい等）があるときだけが無難です。
- ODF 導入時に Ceph RBD の StorageClass をクラスタのデフォルト StorageClass にするオプションです。デフォルト StorageClass を変えると、StorageClass を指定せずに作られる PVC の行き先が変わります。OCPv では「VM 用は
-
- セキュリティとネットワークの設定
- 内容に問題がなければ、画面右下の [Install] ボタンをクリックして ODF のインストールを開始します。すべてのコンポーネントのインストール、デプロイ、設定には、ある程度時間がかかることに注意してください。
- ODF が正常にインストールされたことを確認します。
- IBM Cloud Web コンソールのクラスタ (例: acs-osv-cluster-dal1) のページの右上部から、OpenShift web console を開きます。
- OpenShift web console > [Storage] > [Data Foundation] > [Topology] タブから、ODF のステータスを確認します。アラートなどが出ていなければ、インストールが正常に完了しています。
- IBM Cloud Web コンソールのクラスタ (例: acs-osv-cluster-dal1) のページの右上部から、OpenShift web console を開きます。
4. OpenShift Virtualization (OCPv) のインストール
OpenShift Virtualization Operator は、OpenShift 上で仮想マシン（VM）を扱うための機能群を一括で有効化・管理するための メタ Operator です。単体で何か1つの機能を追加するというよりも、VM の作成・起動・停止、VMI (VirtualMachineInstance) の管理、virt-launcher Pod を用いた実行、ライブマイグレーションなど、OpenShift Virtualization に必要な複数コンポーネントをまとめて導入し、設定を統合的に管理します。
このメタ Operator の実体は、KubeVirt コミュニティで開発されている HyperConverged Cluster Operator (HCO) です。OpenShift ではこれが「OpenShift Virtualization Operator」として提供されており、HCO が中心となって KubeVirt をはじめとする関連コンポーネントのインストールやバージョン整合性、設定 (CR; カスタムリソース) 反映を担います。つまり、OpenShift Virtualization を使い始める第一歩は「KubeVirtを個別に入れる」ことではなく、OpenShift Virtualization Operator を導入し、クラスタで仮想化機能を有効化することになります。
以降の手順では、OperatorHub から OpenShift Virtualization Operator をインストールし、インストール後に作成される代表的なリソース（例：HyperConverged カスタムリソースや、openshift-cnv 名前空間のPod群）を確認することで、「仮想化機能がクラスタに正しく組み込まれた」状態を検証します。
インストール後、VM自体は Kubernetes のカスタムリソース (例: VirtualMachine / VirtualMachineInstance) として扱えるようになります。実体は Pod（virt-launcher）としてスケジューリングされるため、OpenShift の標準機能（監視、ログ、RBAC、名前空間分離等）と自然に統合できます。
4-1. 手順
- [Administrator] パースペクティブから、[Operators] > [OperatorHub] をクリックします。
- [Filter by keyword…] に、例えば「Virtualization」と入力します。
- Red Hat ソースラベルが示されている [OpenShift Virtualization] タイルをクリックします。
- インストールする OpenShift Virtualization Operator の情報 (更新チャンネル、バージョンなど) を確認し、Install をクリックします。
- 更新チャンネルには「stable」を選びます。Red Hat公式ドキュメントでも「Update Channel に stable を選ぶことで、OCP バージョンと互換性のある OpenShift Virtualization をインストールできる」と説明されています。
- バージョンはデフォルト (stable チャンネルの最新) を選びます。OpenShift Virtualization は OCP のマイナー（4.18）に揃うので、例えば 4.18 クラスタでは 4.18 系が入ります。参考までに、Red Hat の 4.18 Virtualization ドキュメントでは「最新 stable release of OpenShift Virtualization 4.18 は 4.18.23」と記載があります。
- [Install Operator] ページに遷移します。適切な設定を選択し、[Install] ボタンをクリックします。
- 選択可能な Update channel オプションの一覧から stable を選びます。これにより、OpenShift Container Platform バージョンと互換性がある OpenShift Virtualization のバージョンをインストールできます。
- [Installed Namespace] で、[Operator recommended Namespace: <提示された名前空間>] オプションが選択されていることを確認します。これにより、必須の名前空間 “openshift-cnv” にOperator がインストールされます。この名前空間は、存在しない場合でも自動的に作成されます。
- Update approval オプションは、”stable” Update channel で新しいバージョンが利用可能になったときに OpenShift Virtualization が自動更新されるように、デフォルト値である “Automatic” を選択することを推奨します。
OpenShift Virtualization Operator を “openshift-cnv” 以外の名前空間にインストールしようとすると、インストールに失敗します。
- OpenShift Virtualization Operator が正常にインストールされると、Operator を利用するための “HyperConverged” カスタムリソース (CR) の作成を求められるので、[Create HyperConverged] をクリックします。
[Create HyperConverged] ページに遷移した後、[Name] フィールドはデフォルト値のまま変更しないでください。変更すると「InvalidRequest: Request does not match expected name (kubevirt-hyperconverged) and namespace (openshift-cnv)」のようなエラーが発生します。
- HyperConverged CR まで正常にインストールされると、OpenShift web console 画面に [Virtualization] パースペクティブが追加され、左ペインに [Virtualization] メニューが現れます。
- 左ペインの [Virtualization] > [Overview] をクリックし、OpenShift Virtualization の Welcome ページが表示されることを確認します。
- 以上で、OpenShift Virtualization のインストールは完了です。
5. 仮想マシンの作成と起動
OpenShift Virtualization では、仮想マシン (VM) は Kubernetes のカスタムリソースとして管理されます。代表的には VirtualMachine (vm) と、その実行状態を表す VirtualMachineInstance (vmi) です。
VM を起動すると、内部的には VM をホストするための Pod (virt-launcher Pod) が作成され、通常の Pod と同じようにスケジューラによってノードに配置されます。つまり、VM は「Kubernetes の運用モデル（名前空間、RBAC、監視、ログ、スケジューリング）」の上に統合されて動作します。
ここでは、任意の名前空間にテスト用VMを作成し、起動できること (VMI が Running になり、virt-launcher Pod が起動すること) までを確認します。
5-1. 手順
- 既存の名前空間を利用しても良いですが、ここでは検証用の名前空間を作成し、この名前空間に仮想マシンを作成します。
- Webコンソール (GUI) で作成する場合、OpenShift web console > Administration > Namespaces から、右上部の [Create Namespace] ボタンをクリックし、名前空間の名前を入力して [Create] ボタンをクリックします。
- 補足情報として、
ocバイナリで名前空間を作成する方法も紹介します。ocは OpenShift を操作するための公式 CLI (コマンドラインツール) です。Webコンソールでも多くの操作はできますが、実機検証では「状態確認」「ログ取得」「差分確認」を素早く行えるため、ocを使えるようにしておくと便利です。- まず、 OpenShift web console 右上部の「❔」アイコンから [Command Line Tool] をクリックし、
ocバイナリを取得します。作業端末に応じてインストールを実施します。
-
ocでクラスタにログインします。OpenShift web console 右上部の IAM 名のプルダウンから [Copy login command] をクリックすると、新規にブラウザのサブが開きます。"Display Token" をクリックして、"Log in with this token" に記載されているoc login --token=...コマンドをコピーします。
- ターミナルでコマンドを実行します。実行例は下記の通りです。
# hiroaki.mishima @ HiroakinoMacBook-Pro in ~ [13:34:30] $ oc login --token=sha256~■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ --server=https://■■■■■■.us-south.containers.cloud.ibm.com:31060 Logged into "https://■■■■■■.us-south.containers.cloud.ibm.com:31060" as "IAM#■■■■■■■■■■■■■■@ibm.com" using the token provided. You have access to 81 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". - 名前空間を作成します。ここでは
ocpv-labという名前の名前空間 (プロジェクトとも云う) を作成した際の実行例を記載します。# hiroaki.mishima @ HiroakinoMacBook-Pro in ~ [17:51:30] $ oc new-project ocpv-lab Now using project "ocpv-lab" on server "https://■■■■■■.us-south.containers.cloud.ibm.com:31060". You can add applications to this project with the 'new-app' command. For example, try: oc new-app rails-postgresql-example to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application: kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname
- まず、 OpenShift web console 右上部の「❔」アイコンから [Command Line Tool] をクリックし、
- Webコンソール (GUI) で作成する場合、OpenShift web console > Administration > Namespaces から、右上部の [Create Namespace] ボタンをクリックし、名前空間の名前を入力して [Create] ボタンをクリックします。
- 作成された名前空間に仮想マシンを作成します。Web コンソール > Virtualization > VirtualMachines から [Create VirtualMachine] プルダウンを開いて [From InstanceType] 項目をクリックします。このとき、左上部の [Project: <名前空間>] に先ほど作成した名前空間が指定されていることを確認してください。
- OS をブートするボリュームを選択します。ここでは「rhel9」 (Red Hat Enterprise Linux 9) を選択しました。
OpenShift Virtualization 環境を構築した直後では、Windows OS のボリュームが存在しません。Windows OS の仮想マシンをボリュームから作成するためには、Windows 用のボリュームを別途追加する必要があります。
- InstanceType と仮想マシンの詳細を入力して [Create VirtualMachine] ボタンをクリックします。
- InstanceType はデフォルトの設定を選びました。
- 名前にはアルファベットの大文字や日本語は使えません。不正な文字が含まれている場合、Kubernetes のリソース名 (
metadata.name) が RFC 1123 の “小文字サブドメイン” 形式に合っていないために、下記のエラーが表示されます。An error occurred Error "Invalid value: "rhel-9-orange-dragonfly-41-Aあ": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')" for field "metadata.name". - ディスクサイズを小さくし過ぎると仮想マシンが作成されません。
- ストレージクラスは基本的に「
ocs-storagecluster-ceph-rbd-virtualization」を選択してください。OpenShift Virtualization 向けに “デフォルト／最適設定” として用意される RBD 系ストレージクラスで、仮想マシンのディスクに推奨される “RBD Block” の前提を満たしやすいためです。Red Hat の Virtualization の Storage ドキュメントでは、ODF を使う場合に仮想マシンのディスクは CephFS や RBD の filesystem-mode よりも、RBD の block mode が効率的で性能面でも良い、と明記されています。- [参考] Red Hat Documentation > 11.2. Configuring storage profiles
- 仮想マシンが作成されたことを確認します。
- 仮想マシン (VirtualMachine) を作成すると、仮想マシンの現在の実行状態を表す VirtualMachinceInstance (VMI) リソースが作成され、Compute ノードでは virt-launcher Pod (VM 1台毎の「入れ物」) が起動します。 virt-launcher Pod の中で qemu-kvm (VM 本体)や、それを制御するコンポーネントが動き、ノード上の KVM を使ってゲスト OS を起動します。つまり VM は “virt-launcher Pod 上で動くプロセス” **として実体化します。
- 仮想マシンが正常に起動していることを確認します。
- 仮想マシンの [Overview] ページだけでも、正常性確認の作業としてはおおよそ十分ですが、 VM が「起動している / 正しく動いている」ことを Kubernetes 観点で一番確実に確認するためには、virt-launcher Pod の状態を見るべきです。
- 方法はいくつかありますが、OpenShift web console から確認するためには、[Overview] ページ右側の [General] パネル内の [Pod] のハイパーリンクをクリックして、作成された仮想マシンに紐づいた virt-launcher Pod の詳細ページを表示します。特に下記を確認します。
-
StatusがRunningであること -
ConditionがすべてTrueであること - [Logs] タブからログを確認し、エラーが出ていないこと
-
以上で、OpenShift Virtualization を IBM ROKS 上に構築し、KubeVirt VM (仮想マシン) を起動するところまで実施しました。
A. ネットワークの制約と将来見通し
A-1. 現状の制約
ROKS (Red Hat OpenShift on IBM Cloud) では、コンテナネットワーク (CNI) はこれまで Calico が標準でした。これは OpenShift Virtualization (OCPv / KubeVirt) のネットワーク機能 (複数 NIC、ネットワーク分離など) に直接影響します。OCPv 自体は本来 Multus を利用して VM に複数 NIC を持たせたり、用途に応じてネットワークを分離したりできますが、ROKS 側の制約により、現時点では「OCPv が本来想定する高度なネットワーク構成」を前提にした網羅的な検証・提案が難しい状況にあります。
一方で、IBM Cloud のリリースノート (2026年2月4日) には、ROKS 4.20 以降の VPC クラスタ (RHCOS ワーカーノード) で、クラスタ CNI として Open Virtual Network（OVN）を選択できることが明記されています。このオプションは現時点では CLI / API からのみ指定可能です。ただし、OVN-Kubernetes を選べるようになったことは前進ではあるものの、だからといって直ちに複数 NIC や VPC への直接接続 (VNI) 等の要件が満たされるとは限りません。OCPv を“VMware の代替基盤”として提案できるレベルまでネットワーク要件を満たせるかは、引き続きアップデートを追う必要があります。
本記事は OpenShift 4.18 (ROKS) での検証結果をベースにしており、CNI 選択 (4.20+) は将来のアップデート情報として本付録に記載しています。
[参考] IBM Cloud Release Notes > 04 February 2026
[参考] IBM Cloud Docs > Selecting a container network interface
A-2. 将来見通し
OpenShift Container Platform の標準的なネットワーク実装は OVN-Kubernetes であり、Red Hat は OVN-Kubernetes を軸にネットワーク機能を強化しています。ROKS 側でも 4.20+ から OVN を CNI として選択できるようになったことは、OpenShift 標準の前提に近づくという意味で重要なアップデートです。
ただし、OCPv を「VMware の代替」として網羅的に検証・提案するには、複数 NIC、ネットワーク分離、固定 IP 設計、VPC ネットワークへの “足” など、実運用要件に関わる機能を揃う必要があります。現時点では、OVN 選択が可能になった一方で、これらの要件をどこまで満たせるかは継続してアップデートを追うべき領域です。
おわりに (予告)
ここまでで、ROKS 上に OCPv を構築して「VMが OpenShift の運用モデル（名前空間／RBAC／Podとしての実体）に統合されて動く」ことを、実機で確認できました。
次回以降で、MTV (VM の移行ツール) による VMware vSphere からの VM の Cold/Warm 移行、Velero/OADP による VM のバックアップ／リストア、Descheduler による VM のノード間動的再配置へと解説範囲を広げつつ、検証中に得られた気づきや小ネタも別記事で投稿予定です。