Broadcom による VMware 買収をどう見るか – 仮想化基盤の標準が変わるということ

Broadcom による VMware 買収は、単なる企業買収ではなく、オンプレミス仮想化基盤をどう設計するかという前提を大きく揺らした出来事だったと思います。

VMware は長く、企業向け仮想化の標準に近い存在でした。だからこそ、ライセンス、サポート、製品体系、パートナー制度が変わると、単に製品を買い替える話では済みません。設計、運用、コスト、技術者の経験まで影響します。

この問題の本質は、VMware が高くなったかどうかだけではありません。仮想化基盤を、特定ベンダーの事業方針にどこまで預けてよいのかという設計上の問題です。

買収後に何が変わったのか

Broadcom は 2023 年 11 月 22 日に VMware の買収完了を発表しました。その後、VMware は Broadcom 傘下の事業として再編され、製品ポートフォリオや販売モデルも大きく変わりました。

特に大きかったのは、従来の永続ライセンス中心の感覚から、サブスクリプションとバンドルを中心にしたモデルへ寄っていったことです。製品そのものが急に使えなくなったというより、利用者側の調達、更新、コスト見積もり、代替検討の前提が変わりました。

• VMware は Broadcom 傘下の事業として再編された
• 製品体系は VCF / VVF などの大きな単位を中心に整理された
• 永続ライセンス中心の考え方からサブスクリプション中心へ移った
• 顧客側では更新費用、契約形態、移行先の検討が現実的な課題になった
• Workstation / Fusion のようなデスクトップ製品は別の文脈で無償化の動きも出た

問題は価格だけではない

この話は、VMware が高くなったという単純な話にすると見誤ります。価格上昇はもちろん重要ですが、より本質的なのは、インフラ基盤の意思決定を特定ベンダーの事業方針に強く依存していたことが露出した点です。

仮想化基盤は、一度導入すると簡単には変えられません。VM、ストレージ、ネットワーク、バックアップ、監視、権限管理、障害対応、担当者のスキルセットがすべて結びつくからです。

そのため、ライセンス体系やサポート方針が変わった時に、すぐに別の製品へ移ることは難しいです。ここに、VMware 依存の設計リスクがあります。

VMware は仮想化製品ではなく運用基盤だった

VMware の強さは、単に ESXi で VM を動かせることではありません。vCenter、vSAN、NSX、DRS、HA、バックアップ連携、監視連携、権限管理、運用ノウハウまで含めて、企業インフラの運用基盤として成立していた点にあります。

観点	VMware が担っていたもの	代替時に問題になること
VM 実行	ESXi による安定したハイパーバイザ	KVM などへ移せても運用手順は別物になる
管理	vCenter を中心にした統合管理	管理 UI、権限、監査、運用フローの作り直し
ストレージ	vSAN や外部ストレージ連携	性能、冗長化、バックアップ設計の再検討
ネットワーク	標準 vSwitch、分散 vSwitch、NSX	VLAN、分散 Firewall、仮想ネットワーク設計の再設計
運用	既存手順、監視、バックアップ、担当者経験	製品移行ではなく運用モデル移行になる

つまり VMware から離れるという話は、ハイパーバイザを入れ替える話ではありません。企業インフラの運用モデルを入れ替える話です。

仮想化基盤の標準が揺らいだ

VMware は、良くも悪くもオンプレミス仮想化の標準的な前提でした。多くの現場では、VMware を使えば仮想化基盤の基本機能、管理 UI、運用手順、製品サポート、技術者の経験がある程度そろう、という前提がありました。

Broadcom 買収後の変化は、その前提を揺らしました。今後も VMware を使う選択は十分にあり得ますが、以前のように「とりあえず VMware」を無条件の標準として置くことは難しくなっています。

これは VMware が悪いという単純な話ではありません。標準だと思っていたものも、企業買収、製品戦略、販売モデルの変更によって前提が変わるということです。仮想化基盤の設計では、そのリスクも含めて考える必要があります。

代替候補は単純な置き換えではない

Broadcom 買収後の変更を受けて、Proxmox VE、KVM / libvirt、Nutanix、OpenShift Virtualization、OpenStack、パブリッククラウドなどが代替候補として語られるようになりました。

ただし、どれか一つが VMware の完全な置き換えになるわけではありません。VMware が担っていた範囲が広すぎるからです。単に VM を動かすだけなら KVM でも十分ですが、企業運用に必要な管理、可用性、バックアップ、ネットワーク、権限管理、監査、サポートまで含めると、設計の難易度は上がります。

代替候補	向いている方向	注意点
KVM / libvirt	低レイヤを理解して自分で構成したい環境	管理、監視、バックアップを自分で組み立てる必要がある
Proxmox VE	OSS ベースで統合 UI を持つ仮想化基盤が欲しい環境	VMware と同じ運用思想ではない
Nutanix	商用サポート込みで HCI 的にまとめたい環境	別の商用基盤への依存になる
OpenShift Virtualization	Kubernetes と VM を同じ基盤で扱いたい環境	Kubernetes 運用能力が前提になる
OpenStack	API 中心のクラウド基盤を自分で作りたい環境	VMware 互換品ではなくクラウド基盤の運用になる
パブリッククラウド	自前基盤の保有を減らしたい環境	コスト、ネットワーク、ロックイン、運用責任の形が変わる

KVM や Proxmox が注目される理由

OSS 系の仮想化基盤が注目される理由は、単に無料だからではありません。ライセンスや製品戦略に振り回されにくく、自分たちで設計を理解し、必要な範囲を組み合わせられるからです。

Proxmox VE は、KVM と LXC を Web UI で扱いやすくまとめた基盤として魅力があります。KVM / libvirt は、より低いレイヤで自由に構成できます。どちらも、VMware のような統合製品とは別の思想です。

ただし、OSS を選ぶなら、運用責任も自分たちで持つ必要があります。サポート、設計、障害対応、自動化、バックアップ、監視をどう作るかを考えなければなりません。OSS は自由ですが、自由は責任とセットです。

私の環境で KVM を選ぶ意味

私自身の環境では、Ubuntu 26.04 上で KVM / libvirt / Open vSwitch / OVN を組み合わせた仮想化基盤を構成しています。これは一般的な VMware 代替として最短距離の選択というより、自分で理解し、制御できる基盤を作るという方向です。

一般的には、KVM を使うだけなら Open vSwitch や OVN まで組み合わせる必要はありません。むしろ少し過剰です。しかし、自宅基盤を単なる VM 実行環境ではなく、ネットワーク、仮想化、Kubernetes、ストレージまで含めた実験基盤として見るなら、下の層を自分で持つ意味があります。

VMware から離れる場合に大事なのは、VMware の代用品を探すことではなく、自分たちがどの層を自分で持ち、どの層を製品やクラウドに任せるのかを決めることです。

エンジニアのキャリアにも影響する

この話は、エンジニアの経験の質にもつながります。VMware だけを前提にした運用経験と、仮想化そのものを理解して設計できる経験は違います。

VMware を使えることは価値があります。しかし、VMware の画面操作や手順実行だけに閉じていると、ベンダーの方針が変わった時に応用が利きにくくなります。

一方で、仮想化の仕組み、ストレージ、ネットワーク、CPU、メモリ、I/O、HA、バックアップ、運用設計を理解していれば、VMware でも KVM でも Proxmox でも、設計の考え方を移せます。

オンプレ仮想化は終わらない

VMware の変化を見て、すぐに全部クラウドへ移ればよいという話にもなりません。クラウドにはクラウドのコスト、ロックイン、ネットワーク、セキュリティ、運用の難しさがあります。

オンプレミス仮想化は、今後も必要です。特に、自宅ラボ、社内基盤、閉域網、低遅延、既存システム、コスト予測、データ所在を重視する環境では、オンプレ基盤の価値は残ります。

重要なのは、VMware かクラウドかという二択ではなく、自分たちの要件に対して、どの基盤をどの責任範囲で使うのかを考えることです。

まとめ

Broadcom による VMware 買収は、VMware ユーザーに対して、ライセンス、コスト、製品体系、サポート、移行計画を再検討させる大きなきっかけになりました。

ただし、本質は VMware が高くなったという話だけではありません。仮想化基盤を特定ベンダーの製品戦略にどこまで依存してよいのか、という設計上の問題です。

VMware を使い続けるにしても、KVM や Proxmox へ移るにしても、OpenShift Virtualization や OpenStack を検討するにしても、クラウドへ寄せるにしても、仮想化の仕組みを理解し、自分たちの要件と責任範囲を明確にする必要があります。今回の買収は、その当たり前を改めて突きつけた出来事だったと思います。

関連する記事

• VMware と OpenStack の違い – 仮想化基盤とクラウド基盤を同じものとして扱わない
  VMware と OpenStack を運用モデルの違いとして整理した記事です。
• OpenShift Virtualization をどう見るか – Kubernetes 上で VM を扱う意味と VMware 代替の限界
  OpenShift Virtualization を VMware 代替だけで見ないための記事です。
• Kubernetes を前提とした仮想化アーキテクチャ – VM とコンテナの責務を分ける
  VM、Kubernetes、コンテナの責務境界を整理した記事です。
• 自宅サーバー用ハードウェアを新調した記録 – 小型ベアボーンで KVM 基盤を作る
  自宅で KVM 基盤を作る背景になる記事です。
• Ubuntu 26.04 KVM の基本設定 – libvirt / OVS / OVN の土台を作る
  KVM、libvirt、OVS、OVN を使って VM 基盤を構成する手順記事です。
• VM パフォーマンス ハブ – CPU / メモリ / ストレージ / ネットワーク設計の入口
  VM の性能を設計観点で整理したハブ記事です。
• クラウドを AWS だけで理解してはいけない – 本質は場所ではなく運用モデルである
  クラウドを場所ではなく運用モデルとして見る記事です。

参考情報

• Broadcom: Broadcom announces successful acquisition of VMware