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

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

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

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

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

Broadcom は 2023 年 11 月 22 日に VMware の買収完了を発表しました。その後、VMware は VMware by 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、分散 FW、仮想ネットワーク設計の再設計
運用	既存手順、監視、バックアップ、担当者経験	製品移行ではなく運用モデル移行になる

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

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

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

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

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

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 へ移るにしても、クラウドへ寄せるにしても、仮想化の仕組みを理解し、自分たちの要件と責任範囲を明確にする必要があります。今回の買収は、その当たり前を改めて突きつけた出来事だったと思います。

関連する記事

• VMware と OpenStack の違い – 仮想化基盤とクラウド基盤を同じものとして扱わない
• 自宅サーバー用ハードウェアを新調した記録 – 小型ベアボーンで KVM 基盤を作る
• Ubuntu 26.04 で KVM / libvirt / OVS / OVN を構成する
• CPU ピニングを外すと何が変わるのか – 専有実行から共有実行へ変わるということ
• クラウドを AWS だけで理解してはいけない – 本質は場所ではなく運用モデルである

参考情報

• Broadcom: Broadcom announces successful acquisition of VMware
• VMware: VMware Fusion and Workstation are Now Free for All Users