2024 年 4 月 17 日に Red Hat OpenShift Virtualization のウェビナーへ参加しました。以前から存在は知っていましたが、正直なところ、最初は「なぜ Kubernetes 上で VM を動かすのか」という疑問がありました。
ただ、いま改めて整理すると、OpenShift Virtualization は単なる VMware 代替というより、VM とコンテナを同じ OpenShift の運用モデルへ寄せるための基盤として見る方が自然です。
OpenShift Virtualization を VMware の安価な置き換えとしてだけ見ると誤解しやすいです。主語は VM ではなく、OpenShift を中心に VM とコンテナを同じ運用面へ収容することです。
書籍
作って理解する仮想化技術 ── ハイパーバイザを実装しながら仕組みを学ぶ
KVM、ハイパーバイザ、CPU 仮想化支援、メモリ仮想化、仮想デバイスの仕組みを押さえるための参考書籍です。OpenShift Virtualization の下にある仮想化技術を理解する補助として紹介します。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
OpenShift Virtualization とは何か
OpenShift Virtualization は、Red Hat OpenShift 上で仮想マシンを実行し、コンテナワークロードと並べて管理するための機能です。Red Hat 公式でも、従来型の VM をモダンなワークロードと並べて、統一されたハイブリッドクラウドアプリケーション基盤上で管理するものとして説明されています。
技術的には KubeVirt をベースにしており、VM を Kubernetes のリソースとして扱えるようにします。VM をコンテナ化するというより、VM のライフサイクル管理を Kubernetes / OpenShift の世界へ持ち込むものだと捉えた方が分かりやすいです。
なぜ Kubernetes 上で VM を動かすのか
最初に疑問を持つのは自然だと思います。Kubernetes はコンテナのための基盤であり、VM は従来の仮想化基盤で動かせばよいのではないか、という考え方です。
しかし、現実の企業システムでは、すべてをすぐにコンテナ化できるわけではありません。既存の VM、レガシーアプリケーション、Windows Server、特殊なミドルウェア、移行に時間がかかるシステムが残ります。
その一方で、新しいアプリケーションは Kubernetes やコンテナ基盤へ寄っていきます。そうなると、VM とコンテナを別々の基盤で運用し続けるより、同じプラットフォーム上で管理したいという要求が出てきます。
KVM、KubeVirt、OpenShift の層を分ける
OpenShift Virtualization を理解するには、KVM、KubeVirt、OpenShift の層を分けて見る必要があります。
| 層 | 役割 |
|---|---|
| KVM | Linux 上で VM を実行するためのハイパーバイザ技術 |
| KubeVirt | Kubernetes 上で VM をリソースとして扱うための仕組み |
| OpenShift Virtualization | OpenShift の運用、UI、Operator、ネットワーク、ストレージ、管理モデルの中で VM を扱う機能 |
| OpenShift | コンテナ、VM、Operator、監視、権限、CI/CD などを含むアプリケーション基盤 |
KVM は VM 実行の土台です。KubeVirt は Kubernetes に VM 管理を持ち込みます。OpenShift Virtualization は、それを OpenShift の商用プラットフォームとして運用できる形にまとめます。この層を混ぜると、評価を誤ります。
KVM と仮想化基盤の違い
KVM はハイパーバイザとして非常に優れています。私自身も Ubuntu 26.04 の KVM / libvirt / OVS / OVN 基盤を構成しています。ただし、KVM 単体はあくまでハイパーバイザであり、企業向けの仮想化基盤全体ではありません。
VM の配置、可用性、ライブマイグレーション、ネットワーク、ストレージ、権限管理、監視、バックアップ、セルフサービス化まで考えると、KVM の上に管理基盤や運用設計が必要になります。
この管理基盤として、従来は VMware や OpenStack がありました。OpenShift Virtualization は、そこに Kubernetes / OpenShift の管理モデルを持ち込む選択肢と言えます。
VMware 代替として見た場合
Broadcom による VMware 買収以降、VMware のライセンスや製品体系が変わり、代替基盤を検討する企業は増えています。その文脈で OpenShift Virtualization が注目されるのは自然です。
ただし、OpenShift Virtualization を VMware の単純な置き換えとして見ると危ういです。vSphere / vCenter の操作感や運用モデルをそのまま期待するものではなく、OpenShift の上に VM 管理を統合するものだからです。
- VMware からの移行先として検討できる
- Migration Toolkit for Virtualization による移行支援がある
- VM とコンテナを同じ基盤で扱える
- ただし OpenShift の設計・運用スキルが必要になる
- VMware の置き換えというより、アプリケーション基盤の再設計に近い
利点
OpenShift Virtualization の利点は、VM とコンテナを同じプラットフォーム上で扱えることです。これは、既存 VM を抱えながら Kubernetes へ移行していく組織にとって大きな意味があります。
- VM とコンテナを同じ OpenShift クラスターで管理できる
- Kubernetes の API、RBAC、Operator、監視と統合しやすい
- 既存 VM を残しながら、新規アプリはコンテナ化できる
- VM からコンテナへの段階的な移行を設計しやすい
- OpenShift を標準基盤として使う組織では運用モデルを統一しやすい
注意点
一方で、OpenShift Virtualization は軽い基盤ではありません。OpenShift 自体が大きなプラットフォームであり、導入にも運用にも相応の知識と体制が必要です。
- 小規模な VM 基盤としては過剰になりやすい
- OpenShift / Kubernetes の運用スキルが前提になる
- ストレージとネットワーク設計が難しい
- VMware の運用手順をそのまま移せるわけではない
- VM 中心の組織では、Kubernetes 的な考え方への移行が必要になる
特に、VMware の代替を探しているだけの組織が、OpenShift Virtualization を選ぶと、別の難しさに直面する可能性があります。これは仮想化基盤だけでなく、Kubernetes 基盤を運用する覚悟が必要な選択です。
Kubernetes 基盤として見る
私の感覚では、OpenShift Virtualization は仮想化基盤というより、Kubernetes 基盤の上に VM を取り込むものとして見た方が自然です。
つまり、VMware の代替品を探している人よりも、OpenShift を標準アプリケーション基盤にしたいが、既存 VM も残っている組織に向いています。VM を中心に考えるのではなく、OpenShift を中心に考え、その中に VM を収容する発想です。
この違いを理解していないと、OpenShift Virtualization の評価を誤ります。VMware の代替としてだけ見ると重すぎる。しかし、VM とコンテナを統合するアプリケーション基盤として見ると、かなり意味があります。
まとめ
OpenShift Virtualization は、Kubernetes 上で VM を動かす変わった技術というより、VM とコンテナを同じ運用モデルに統合するための基盤です。
VMware 代替として検討されることは増えていますが、単純な置き換えではありません。OpenShift の設計、運用、ストレージ、ネットワーク、Kubernetes 的な管理モデルを受け入れる必要があります。
既存 VM を残しながらコンテナ基盤へ移行したい組織にとっては魅力的です。一方で、単に安価な VMware 代替が欲しいだけなら、Proxmox や KVM / libvirt など別の選択肢も含めて考えるべきです。OpenShift Virtualization は、VMware 代替というより、アプリケーション基盤の再設計として評価するのがよいと思います。
関連する記事
- Broadcom による VMware 買収をどう見るか – 仮想化基盤の標準が変わるということ
- Kubernetes を前提とした仮想化アーキテクチャ – VM とコンテナをどう重ねるか
- VMware と OpenStack の違い – 仮想化基盤とクラウド基盤を同じものとして扱わない
- Ubuntu 26.04 で KVM / libvirt / OVS / OVN を構成する
- VMware TKGm Bootstrap を振り返る – vSphere 上で Kubernetes 基盤を作る難しさ



