Broadcom による VMware 買収は、単なる企業買収ではなく、オンプレミス仮想化基盤をどう設計するかという前提を大きく揺らした出来事だったと思います。
VMware は長く、企業向け仮想化の標準に近い存在でした。だからこそ、ライセンス、サポート、製品体系、パートナー制度が変わると、単に製品を買い替える話では済みません。設計、運用、コスト、技術者の経験まで影響します。
書籍
作って理解する仮想化技術 ── ハイパーバイザを実装しながら仕組みを学ぶ
ハイパーバイザ、CPU 仮想化支援、メモリ仮想化、仮想デバイスなど、VM の性能設計を低レイヤから理解したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
買収後に何が変わったのか
Broadcom は 2023 年 11 月に VMware の買収を完了しました。その後、VMware by Broadcom として製品ポートフォリオが大きく整理され、VMware Cloud Foundation(VCF)と VMware vSphere Foundation(VVF)を中心にした構成へ寄せられました。
特に大きかったのは、永続ライセンスからサブスクリプション型への移行です。従来のように、必要な製品を必要な範囲で買い、保守を更新していく感覚から、より包括的なバンドルと継続課金を前提にしたモデルへ変わりました。
- 永続ライセンス中心からサブスクリプション中心へ移行した
- 製品体系が VCF / VVF を中心に再編された
- スタンドアロン製品や無償版の扱いが変わった
- パートナーやサービスプロバイダーにも影響が出た
- 顧客側では更新費用や移行先の検討が現実的な課題になった
問題は価格だけではない
この話は、単に VMware が高くなったというだけではありません。価格上昇はもちろん重要ですが、より本質的なのは、インフラ基盤の意思決定を特定ベンダーの事業方針に強く依存していたことが露出した点です。
仮想化基盤は、一度導入すると簡単には変えられません。VM、ストレージ、ネットワーク、バックアップ、監視、運用手順、障害対応、担当者のスキルセットがすべて結びつくからです。
そのため、ライセンス体系やサポート方針が変わった時に、すぐに別の製品へ移ることは難しいです。ここに、VMware 依存のリスクがあります。
VMware 依存の設計リスク
VMware は非常に完成度の高い仮想化基盤です。vSphere、vCenter、vSAN、NSX、Aria などを組み合わせた世界は、企業向けとして強力です。
しかし、その完成度の高さは、同時にロックインにもなります。製品間の統合が深いほど、別の基盤へ移る時には、単なるハイパーバイザ移行ではなく、運用思想そのものの移行になります。
- VM フォーマットや管理基盤の移行
- vCenter 前提の運用手順の見直し
- vSAN や NSX に依存した設計の再検討
- バックアップ製品や監視製品との連携確認
- 運用担当者のスキル再設計
- ライセンス更新時期に合わせた移行計画
代替候補は何か
Broadcom 買収後の変更を受けて、Proxmox VE、KVM / libvirt、Nutanix、OpenShift Virtualization、クラウド移行などが代替候補として語られるようになりました。
ただし、どれか一つが VMware の完全な置き換えになるわけではありません。VMware が担っていた範囲が広いからです。単に VM を動かすだけなら KVM でも十分ですが、企業運用に必要な管理、可用性、バックアップ、ネットワーク、権限管理、監査、サポートまで含めると、設計の難易度は上がります。
私自身の環境では、Ubuntu 26.04 で KVM / libvirt / OVS / OVN を組み合わせた仮想化基盤 を構成しています。これは一般的な VMware 代替というより、自分で理解し、制御できる基盤を作るという方向です。
KVM や Proxmox が注目される理由
OSS 系の仮想化基盤が注目される理由は、単に無料だからではありません。ライセンスや製品戦略に振り回されにくく、自分たちで設計を理解し、必要な範囲を組み合わせられるからです。
Proxmox VE は、KVM と LXC を Web UI で扱いやすくまとめた基盤として魅力があります。KVM / libvirt は、より低いレイヤで自由に構成できます。どちらも、VMware のような統合製品とは別の思想です。
ただし、OSS を選ぶなら、運用責任も自分たちで持つ必要があります。サポート、設計、障害対応、自動化、バックアップ、監視をどう作るかを考えなければなりません。OSS は自由ですが、自由は責任とセットです。
エンジニアのキャリアにも影響する
この話は、エンジニアのキャリアは良い経験を積めるかで決まる という話にもつながります。VMware だけを前提にした運用経験と、仮想化そのものを理解して設計できる経験は違います。
VMware を使えることは価値があります。しかし、VMware の画面操作や手順実行だけに閉じていると、ベンダーの方針が変わった時に応用が利きにくくなります。
一方で、仮想化の仕組み、ストレージ、ネットワーク、CPU、メモリ、I/O、HA、バックアップ、運用設計を理解していれば、VMware でも KVM でも Proxmox でも、設計の考え方を移せます。
オンプレ仮想化は終わらない
VMware の変化を見て、すぐに全部クラウドへ移ればよいという話にもなりません。クラウドにはクラウドのコスト、ロックイン、ネットワーク、セキュリティ、運用の難しさがあります。
オンプレミス仮想化は、今後も必要です。特に、自宅ラボ、社内基盤、閉域網、低遅延、既存システム、コスト予測、データ所在を重視する環境では、オンプレ基盤の価値は残ります。
重要なのは、VMware かクラウドかという二択ではなく、自分たちの要件に対して、どの基盤をどの責任範囲で使うのかを考えることです。
まとめ
Broadcom による VMware 買収は、VMware ユーザーに対して、ライセンス、コスト、製品体系、サポート、移行計画を再検討させる大きなきっかけになりました。
ただし、本質は VMware が高くなったという話だけではありません。仮想化基盤を特定ベンダーの製品戦略にどこまで依存してよいのか、という設計上の問題です。
VMware を使い続けるにしても、KVM や Proxmox へ移るにしても、クラウドへ寄せるにしても、仮想化の仕組みを理解し、自分たちの要件と責任範囲を明確にする必要があります。今回の買収は、その当たり前を改めて突きつけた出来事だったと思います。



