BroadcomによるVMware買収後のライセンス体系変更で、仮想化基盤の運用者は強制的な選択を迫られています。永久ライセンス廃止、最小72コアサブスク、年間更新の20%ペナルティといった条件変更が、運用部門の年間予算を直撃しているからです。
この記事では、脱VMware候補として実務界で最も話題に上がるRed Hat OpenShift Virtualization（KubeVirt基盤）の技術アーキテクチャを整理し、vSphereとの機能比較、100VM／500VM規模のコスト試算、Nutanix AHV／Proxmox VE／Hyper-Vとの位置づけ、PoCから本番までの移行ステップまで、現場担当者目線で踏み込みます。20年以上クラウドインフラ運用に携わってきた筆者の経験を踏まえ、見積比較の前段で押さえるべき技術的な勘所を共有します。
Broadcom買収後のVMware値上げ／ライセンス体系の現状
まず脱VMware検討の前提となる、2025年時点でのライセンス変更内容を整理します。憶測ではなく、ライセンス監査各社が公開した事実ベースの情報のみを扱います。
永久ライセンスの新規販売停止とサポート上限
Broadcomは2023年末のVMware買収完了とほぼ同時に、永久ライセンスの新規販売を停止しました。既存の永久ライセンスは無効化されたわけではありませんが、サポート更新は既存契約の継続のみで、新規にはサブスクリプション契約が必須です。さらに永久ライセンス側はvSphere v5.x相当で固定され、上位バージョンを使うにはサブスクへの移行が必要になります。
これは「使い続けることはできるが、新しい機能・新ハードウェア対応・公式セキュリティパッチからは取り残される」という、緩やかな強制移行に近い設計です。
2025年4月施行: 最小72コア要件
2025年4月10日施行のライセンス改訂で、購入時の最小コア数が16コアから72コアに引き上げられました。これは中小規模で1台の物理サーバ（例: 32コア機）にvSphereを入れて使っていた事業者にとって、実質的な大幅値上げを意味します。複数のライセンス監査ベンダーが、小規模事業者における年間コスト350～450%増を試算として公開しています。
2025年11月施行: 更新期日逸失で20%ペナルティ
2025年11月から、サブスクリプションの更新期日を逸失すると、初年度サブスク価格に対して20%が追加課金される条項が施行されました。複数年契約の途中で予算承認が遅れた場合などに、運用部門の責任ではない理由で発生しうる追加コストです。
これらの変更が重なった結果、「予算規模の予測可能性」がVMware最大の弱点になっています。代替を検討する動機は、価格そのものよりも「年単位で値上げ幅が読めない構造」にあります。
OpenShift Virtualization（KubeVirt）の技術アーキテクチャ
Red Hat OpenShift Virtualizationは、CNCFのKubeVirtプロジェクトを統合したOpenShift（Kubernetes）の機能拡張です。「VMをKubernetesのPodとして動かす」という、従来の仮想化基盤とは設計思想が異なるアプローチを採ります。
レイヤー構成
下位から順に以下のスタックです。
・物理ホスト: Red Hat Enterprise Linux CoreOS（RHCOS）
・ハイパーバイザ: KVM（Linuxカーネル組込のType-1相当）
・VM管理: libvirt + virt-launcher Pod（KubeVirtコンポーネント）
・オーケストレーション: Kubernetes（OpenShift）コントロールプレーン
・運用UI: OpenShift Console（VMとコンテナを単一画面で管理）
KubeVirtは、Kubernetes CRD（カスタムリソース定義）としてVirtualMachineとVirtualMachineInstance（VMI）を定義します。VMはPodの中でvirt-launcherがlibvirt経由でKVMを起動する形で実行されるため、Kubernetesのスケジューラ、ネットワーク、ストレージ抽象化（CSI/CNI）をそのままVMに適用できる構造です。
vSphereとの設計思想の違い
vSphereはESXi（独自Type-1ハイパーバイザ）+ vCenter（管理サーバ）という「VM専用設計」のスタックです。VMライフサイクル、vMotion、DRS、HA、すべてVMを前提に20年以上磨かれてきた完成度を持ちます。
一方OpenShift Virtualizationは「Kubernetesにとって、VMは大きめのPodの一種」という発想です。コンテナとVMを同じノード上で同じスケジューラで動かせるので、レガシーVMワークロードとクラウドネイティブを段階的に同居・移行できます。ただし、VM特化機能（DRSのVM単位最適化、vMotionの透過性）は、vSphereの成熟度には2026年時点でまだ追いついていません。
PR
VMware vSphereから仮想マシンを移行しよう！Red Hat OpenShift Virtualization 入門
KubeVirtの基本概念、vSphereからのVM移行設計、コンテナとVMの共存戦略までを実務目線でまとめた入門書。脱VMwareの初動検討資料として手元に置いておくと、社内説明のたたき台を作る時間を大幅に短縮できます。
vSphere ↔ OpenShift Virtualization 機能比較表
実務で必ず話題になる主要機能を、現時点の到達度で並べます。「成熟度」はあくまで2026年5月時点の筆者主観評価です。製品アップデートが速い領域なので、見積時には最新リリースノートで再確認してください。
| 機能カテゴリ | VMware vSphere | OpenShift Virtualization |
|---|---|---|
| ハイパーバイザ | ESXi（独自） | KVM（Linux組込） |
| ライブマイグレーション | vMotion（成熟） | 対応（ストレージ・NW調整要） |
| リソーススケジューラ | DRS（VM最適化） | Kubernetesスケジューラ |
| 高可用性 | HA（VM単位フェイルオーバ） | Pod再スケジューリング |
| 統合管理UI | vCenter | OpenShift Console（VM＋コンテナ単一画面） |
| コンテナ統合 | Tanzu（別ライセンス） | 標準機能（同一クラスタ） |
| 移行支援ツール | VMware Converter等 | MTV（Red Hat純正・無償） |
| 運用ノウハウ普及度 | 国内エンジニア層厚い | Kubernetesスキル必須・要育成 |
| ライセンスモデル | サブスク（最小72コア） | サブスク（仮想化Engine版あり） |
表だけ見ると「vSphereの方がVM運用は楽そう」に映るかもしれません。ただ、コンテナ統合とライセンス予測可能性をどう評価するかで、組織ごとの結論は変わります。
移行ステップ（PoC → pilot → 本番）
OpenShift Virtualizationへの移行は、いきなり全VMを動かす作戦は失敗します。Red HatのMigration Toolkit for Virtualization（MTV）を軸に、3段階で進めるのが定石です。
Phase 1: PoC（1ヶ月想定）
OpenShiftクラスタを3ノード（コントロール3 + ワーカー3、HCI構成ならODF統合）で構築し、本番影響のない開発系VMを5～10台MTVで移行します。狙いは「vSphereの自社カスタム設定（NSXセグメント、vSANポリシー、特殊なvNICドライバ）がOpenShift Virtualization上でどこまで再現できるか」の机上検証です。
・成功基準: 開発VMがOSログインできて、業務アプリが起動する
・失敗パターン: 特殊PCIパススルー（GPU、専用ボード）が再現できない場合は要設計再考
・担当者要件: KubernetesとLinuxを両方触れる人を最低1名アサイン
Phase 2: パイロット（2～3ヶ月想定）
業務影響の小さい本番ワークロード（社内ファイルサーバ、CI/CDビルドサーバ、開発DB等）を20～50台移行します。この段階で運用手順書、バックアップ、監視（Prometheus + Grafana統合）、認証連携（Active Directory / LDAP / OIDC）を本番想定で整備します。
パイロットの本当の目的は技術検証ではなく、運用部門のKubernetesスキル習得です。Day-2 Operationsで戸惑わない体制ができていないと、本番移行で必ず詰まります。
Phase 3: 本番移行（6～12ヶ月想定）
業務クリティカルなVM（基幹DB、ERP、メールサーバ等）を、業務影響の少ない順にウェーブ分けして移行します。MTVのコールドマイグレーション（VM停止 → イメージ変換 → OpenShift側起動）が標準ですが、停止許容時間が短いシステムはWarm Migration（変更差分追従）を選びます。
・並行運用期間: vSphereとOpenShiftを最低3ヶ月並行運用してロールバック余地を確保
・VMware側ライセンス: 移行完了VM分から段階的に減らしてサブスクコストを削減
・失敗時の戻し手順: MTVは元VMを残せるので、戻すこと自体は容易
コスト試算例（100VM / 500VM規模）
コストはコア数、サブスク年数、サポートレベルで大きく変動するため、ここでは構造の比較に絞ります。具体的な金額は契約条件依存ですので、必ず見積で確定してください。
100VM規模（中堅企業想定）
| 項目 | VMware vSphere（更新時） | OpenShift Virtualization |
|---|---|---|
| 前提コア数 | 最小72コア課金 | 実コア数課金（最小要件緩い） |
| ライセンス予測性 | 年単位で値上げ幅変動 | サブスク条件は明示 |
| 移行初期投資 | なし（継続） | PoC + 人材育成費 |
| 運用ツール | 既存vCenter | OpenShift（再学習必要） |
| 3年TCO傾向 | 最小72コア課金で割高 | 運用人件費次第で同等～割安 |
100VM規模では、移行コスト（人材育成と並行運用）を回収できるかが分水嶺です。Kubernetesスキルを社内で持たない場合、3年TCOで逆転するケースも珍しくありません。
500VM規模（大企業・データセンタ事業者想定）
| 項目 | VMware vSphere | OpenShift Virtualization |
|---|---|---|
| スケール効果 | 単価交渉余地あり | スケールで単価下がる |
| 並行運用コスト | 既存継続 | 12～18ヶ月の二重投資 |
| 運用体制 | 既存人員継続 | Kubernetes専任チーム必須 |
| 将来拡張性 | VM単機能継続 | コンテナ統合で資産活用 |
| 3年TCO傾向 | 継続更新の方が割高化 | 移行完了後はメリット顕在化 |
500VM規模では、Red Hat公式が言及する「VMwareフル機能比で圧倒的に安い」という主張が現実味を帯びます。海外で1万台超のVM移行事例が出ているのも、この規模感のメリットを取りに行く動きです。
ただし、二重投資の期間と専任チーム編成は組織の体力が問われます。「経営層の覚悟が固まる前に走り出さない」のが鉄則です。
他の脱VMware候補との比較（Nutanix AHV / Proxmox VE / Hyper-V）
脱VMwareの選択肢はOpenShift Virtualizationだけではありません。組織特性別に候補を整理します。
| 候補 | 向く組織 | 弱み |
|---|---|---|
| OpenShift Virtualization | コンテナ統合・クラウドネイティブ志向 | Kubernetesスキル必須 |
| Nutanix AHV | ターンキー志向・HCI前提 | 小規模では割高 |
| Proxmox VE | 中小規模・コスト最優先 | エンタープライズ運用は要設計力 |
| Microsoft Hyper-V | Windows・AD・Azure中心 | Linux/コンテナ統合は弱め |
OpenShift Virtualizationは「3年後にコンテナとVMを統合運用したい」というクラウドネイティブ志向の組織に向きます。逆に「とにかくシンプルにVMを動かす箱が欲しい」場合、Proxmox VEやNutanix AHVの方がフィットします。
FAQ: 脱VMware検討時によく出る疑問
Q1. KubernetesスキルがないチームでもOpenShift Virtualizationは運用できますか？
運用は可能ですが、トラブルシュート時に必ず詰まります。最低1名はKubernetesのkubectl、Pod、Service、PersistentVolumeを業務として扱えるエンジニアが必要です。育成期間として最低6ヶ月は確保してください。
Q2. vSphereのvSANやNSXに依存した構成でも移行できますか？
機能等価では移れません。vSANはOpenShift Data Foundation（ODF / 旧Rook-Ceph）、NSXはOpenShift SDN・OVN-Kubernetes・KubeVirt User Defined Networkで「同等機能を再設計」する形になります。マイクロセグメンテーションや特殊なオーバーレイ要件は、PoC段階で必ず再現可能性を確認してください。
Q3. 永久ライセンスをそのまま延命する選択肢はないのですか？
セキュリティパッチが新規提供されない時点で、本番運用の選択肢ではありません。「2027年頃まで使い切ってその間に移行する」という時間稼ぎ目的なら現実的ですが、移行先の選定と人材育成を並行して進めることが前提です。
Q4. OpenShift VirtualizationはAWS・Azure・GCP上でも動きますか？
動きます。ROSA（Red Hat OpenShift Service on AWS）、ARO（Azure Red Hat OpenShift）、OpenShift Dedicated on GCPでマネージドOpenShiftが提供されており、その上でOpenShift Virtualizationを有効化できます。オンプレ・クラウド両対応がOpenShift陣営の強みです。
Q5. MTV（Migration Toolkit for Virtualization）はどんなツールですか？
Red Hat純正のVMware → OpenShift Virtualization移行ツールです。OpenShiftサブスク契約者なら無償で使えます。vCenterからVMインベントリを取得し、ネットワーク・ストレージのマッピングを定義してバッチ移行を実行します。コールド・ウォーム両方のマイグレーションに対応します。
Q6. 100VM規模だと移行コストを回収できないと聞きました
「人材育成コストを回収できるか」が論点です。Kubernetesスキルを今後3～5年使い続ける戦略があるなら、VM移行費だけでなく組織全体の技術投資として正当化できます。逆に「VMさえ動けば良い」目的なら、Proxmox VEやNutanix AHVの方が学習コスト面で有利です。
Q7. Broadcomが値下げに転じる可能性はありませんか？
2026年5月時点では値下げの兆候はありません。Broadcomは利益率の高い大口顧客に注力する戦略を公言しており、小規模顧客向け価格改善は期待しにくい状況です。
移行検討チェックリスト
脱VMwareを意思決定する前に、以下7項目を必ず社内で確認してください。
・現状のコア数とライセンス更新タイミング: 72コア最小要件と更新月を棚卸し
・VM台数と業務クリティカリティ分類: 移行ウェーブ計画の基礎
・Kubernetesスキル保有者の有無: 0名なら採用または外部支援契約が前提
・並行運用12～18ヶ月の予算: 二重投資の覚悟
・vSphere固有機能の依存度: NSX・vSAN・特殊PCIパススルー
・3年TCO比較: 単年度ではなく3年トータルで判断
・経営層の覚悟: 失敗時の戻し計画と継続合意
このチェックリストで赤信号が3つ以上出る場合、OpenShift Virtualization一択ではなく、Nutanix AHVやProxmox VEも含めた候補比較に戻すことを推奨します。
PR
OpenShift Virtualizationサーバ仮想化実践ガイド（impress top gear）
LinuxにおけるKVMの基礎知識から、Kubernetes上でVMを運用するメカニズム、実践的な構築・運用手順までを体系化した実践ガイド。PoCフェーズに入った後、運用担当者に1冊配っておくと社内の認識合わせが格段に早くなります。
まとめ: 脱VMwareは技術選定ではなく組織選定
OpenShift Virtualizationは、Broadcom買収後のVMwareから移行する有力候補です。KubeVirtベースのKVM仮想化、MTVによる移行支援、コンテナとVMの統合運用が強みで、500VM規模以上なら3年TCOで明確なメリットが見えてきます。
ただし、技術的に動かすこと自体は誰でもできても、「Kubernetesスキルを内製で持つ運用体制」を組織として持てるかが本当の判断軸です。PoC → パイロット → 本番の3段階で、最低10ヶ月、できれば12～18ヶ月の並行運用を許容できる組織体力が前提になります。
100VM規模で運用人員が薄い組織は、いきなりOpenShiftに飛び込まずProxmox VEやNutanix AHVを比較候補に入れる判断も合理的です。500VM以上で「VMもコンテナも一つのプラットフォームで動かしたい」というクラウドネイティブ戦略を持つ組織には、OpenShift Virtualizationが最適解になり得ます。
クラウドマスターズでは、こうした仮想化基盤の実務移行ノウハウや、AWS・Azure・GCPとのハイブリッド設計のメルマガを配信しています。脱VMwareの検討段階で社内議論のたたき台が欲しい方は、ぜひ無料メルマガで実務情報を受け取ってください。
