VMwareの永続ライセンスが消えて2年。2026年、仮想化基盤の移行先はどう選ばれているのか

こんにちは、インフラエンジニアのryuです。

この2年、現場でいちばん増えた会話は何でしょうか。私の周りでは「今の仮想化基盤、更新どうします？」という一言でした。

サーバーを物理で買って、その上に仮想マシンを何十台も載せる。その土台としてVMwareのvSphereを使うのは、長いあいだ当たり前の選択でした。

その当たり前が、買収をきっかけに動いています。そして2026年のいまは、動いた結果が見えはじめた時期にあたります。

今日は、仮想化基盤の移行先がどう分かれているのかを、確認できる事実に絞って整理してみます。

まず、何が起きたのかを時系列で押さえよう¶

話の前提を揃えておきましょう。ここは推測ではなく、公開されている情報で追える部分です。

2023年11月、BroadcomによるVMwareの買収が完了しました。その直後の12月に製品ラインの整理が発表され、翌2024年1月には永続ライセンスとSaaS製品の提供終了が公式にアナウンスされています。

つまり買って所有するモデルから、契約して使い続けるモデルへ、販売の形そのものが切り替わりました。

値段の話だけではなく、契約の形が変わった¶

ここが重要な点です。値上げの幅は契約内容によって変わるので一律には言えませんが、永続ライセンスという選択肢そのものが無くなったことは、どの企業にも共通して効きます。

これまでは、いったん買ってしまえば保守を切ってでも動かし続けるという逃げ道がありました。その逃げ道が細くなったので、更新のタイミングで判断を求められるようになったわけです。

もうひとつの締め切りは、サポート期限だった¶

ライセンスとは別に、製品の寿命という締め切りもあります。

vSphere 7 は2025年10月2日に一般サポートが終了しました。セキュリティ修正が出なくなるので、使い続ける場合はリスクを抱え込むことになります。

そして次の期限も決まっています。

vSphere 8 へ上げたとしても、2027年にもう一度同じ判断が来ます。この二段構えが、多くの現場で移行の検討を前倒しさせています。

移行は起きているのか。数字で見てみよう¶

では実際に、みんな移っているのでしょうか。

調査会社のGartnerは2025年9月、VMwareのワークロードのうち35%が2028年までに他のプラットフォームへ移ると予測しています。海外メディアのThe Registerがこの見通しを取り上げていました。

35%という数字は、裏を返せば残り65%は動かないという予測でもあります。

ここは冷静に読んだほうがよいところです。全部が逃げ出すという話ではありません。

一気に移るのではなく、切り分けて移す¶

現場の感覚とも一致するのですが、移行は「全部まとめて引っ越し」にはなりません。

理由は単純で、仮想マシンの中身がそれぞれ違うからです。止められない業務システムと、検証用に立てただけの仮想マシンを、同じ計画で動かすのは無理があります。

多くの企業がとっているのは、更新契約の区切りに合わせて、動かしやすいものから順に出していく進め方です。オンプレミスへ戻す動きについては2026年のオンプレミス回帰を数字で読み解くでも触れましたが、判断の軸は結局コストと手間の見積もりになります。

移行先は大きく4つの系統に分かれている¶

移行先の候補は無数にあるように見えますが、性格で分けると4つほどの系統に整理できます。

それぞれの立ち位置を並べてみます。

このほかに、そもそも仮想マシンをやめてパブリッククラウドへ移す道もあります。ただしクラウドへ移す場合は、仮想化基盤の入れ替えではなくシステムの作り直しに近い話になります。

共通の土台になっているのはKVMだった¶

4つを見比べると、ひとつ気づくことがあります。

Nutanix AHV、OpenShift Virtualization、Proxmox VE は、いずれもLinuxカーネルの仮想化機能であるKVMを土台にしています。つまり移行先の多くが、Linuxの上に載っているわけです。

これはインフラエンジニアにとって、地味ですが大きな話です。仮想化基盤の知識がLinuxの知識と地続きになるので、これまで積んできたものが効いてきます。

Proxmox VE は2025年8月にバージョン9.0が公開され、Debian 13をベースに、Linuxカーネル6.14系を標準として採用しました。土台がそのままDebianなので、コマンドの世界はいつものLinuxです。

ベースとなるディストリビューションの選び方は2026年のLinuxディストリビューション選びとサポート期限にまとめてあります。移行先を選ぶときは、その下のOSの寿命まで見ておくと安心です。

手間がかかるのはネットワークとストレージ¶

移行の見積もりで甘く見られがちなのが、この2つです。

仮想マシンのディスクを変換してコピーするだけなら、道具が揃っています。難しいのは、仮想スイッチの構成や、VLANの割り当て、ストレージの接続方式といった周辺の作り込みです。

ここは自動では移りません。だから移行プロジェクトの多くが、仮想マシンの台数ではなくネットワーク設計の複雑さで工数が決まります。

選ぶときの判断材料は、だいたい4つに絞られる¶

では、どうやって選んでいるのでしょうか。相談を受けるときに私が確認しているのは、次の4点です。

ひとつめは規模です。仮想マシンが数十台なのか、数百台を超えるのかで、候補ががらりと変わります。数十台ならProxmox VEのような身軽な選択肢が現実的ですが、数百台を超えると運用の自動化や統合管理の作り込みが要るので、商用サポートのある製品に寄っていきます。

ふたつめは、動かしているOSの内訳です。Windows Serverが大半なら、Hyper-VやAzure Localのほうが管理の相性がよくなります。

3つめは、支える人の数です。オープンソースの基盤は費用を抑えられますが、困ったときに自分たちで調べて直す体制が要ります。ライセンス費と人件費のどちらを選ぶか、という話になります。

4つめが、止められる時間の長さです。深夜に数時間止められるのか、1分も止められないのか。ここで移行手法の選択肢が決まります。

移行の段取りは、棚卸しから始まる¶

実際の進め方も、大枠は決まっています。

最初にやるのは移行元の棚卸しです。仮想マシンごとに、OS・用途・停止できる時間・接続先を書き出していきます。この一覧がないまま移行先を選ぶと、後から必ず想定外が出てきます。

次に、いちばん条件のゆるい仮想マシンで試験移行を1台やってみます。ここで変換にかかる時間や、起動後のネットワーク設定の癖が見えてきます。

そして本番の移行は、業務への影響が小さい順に並べて進めます。このとき忘れてはいけないのが、切り戻しの手順です。移行後に問題が出たとき元へ戻せるように、移行元の仮想マシンはしばらく消さずに残しておきます。

AI基盤の増設が、判断を前倒しさせている¶

もうひとつ、2026年らしい事情があります。

GPUを積んだサーバーの増設が増えたことで、データセンターの電力や設置スペースに余裕がなくなってきました。既存の仮想化基盤を減らして場所を空ける、という判断が混ざるようになっています。

AI向けの基盤づくりが運用側に何をもたらしているかはAI推論基盤がインフラエンジニアの仕事を変えるにまとめました。仮想化基盤の更新とAI基盤の新設が、同じ予算の取り合いになっている現場は珍しくありません。

エンジニアとして、今から何を触っておくか¶

ここまでは市場の話でした。では、私たちの手元では何をしておけばよいのでしょうか。

いちばん効率がよいのは、KVMを実際に触っておくことです。移行先の多くが同じ土台なので、どれを選ぶ会社に行っても無駄になりません。

自分の検証機やクラウドの小さなインスタンスがあれば、次のようなコマンドで様子を見られます。

# KVM が使える CPU かどうかを確認する
grep -c -E 'vmx|svm' /proc/cpuinfo

# libvirt 管理下の仮想マシンを棚卸しする
virsh list --all
virsh dominfo web01

# ディスクイメージの形式と実サイズを確認する
qemu-img info /var/lib/libvirt/images/web01.qcow2

# VMware の vmdk を KVM 用の qcow2 に変換する（移行の定番作業）
qemu-img convert -p -f vmdk -O qcow2 web01.vmdk web01.qcow2

最後の qemu-img convert は、実際の移行作業でもよく登場します。手元で一度通しておくと、移行計画を読むときの解像度がかなり変わります。

移行の後に残る宿題は、バックアップと監視¶

移行作業そのものより、見落とされがちなのが移行後の運用です。

仮想化基盤を替えると、バックアップの取り方が変わります。これまで使っていたバックアップ製品が新しい基盤に対応していなければ、道具ごと入れ替えになります。復旧手順も当然変わるので、机上での確認だけでなく、実際に1台戻してみる訓練が要ります。

監視も同じです。ホストやデータストアの状態をどこから取るかが変わるため、監視項目とアラートの閾値を作り直すことになります。

ここまで含めて見積もると、移行は「仮想マシンを運ぶ作業」ではなく「運用の作り直し」だと分かります。逆に言えば、この作り直しをやりきった経験は、そのまま市場価値になります。

仮想化とコンテナは、対立していない¶

もうひとつ意識しておきたいのが、仮想マシンとコンテナの関係です。

OpenShift Virtualization のように、Kubernetesの上で仮想マシンを動かす形が選択肢に入ってきました。コンテナに寄せたいけれど、動かしたままにしたい仮想マシンも残っている。その現実に合わせた作りです。

そのため、これから学ぶ人はどちらか一方ではなく、両方の言葉が分かる状態を目指すのが得になります。コンテナ側の入口はDockerをLinuxにインストールする方法あたりから触れます。

学び直すなら、Linuxを土台に置くのが早い¶

移行先がKVMに寄っているという事実は、学習の順番にも答えをくれます。

仮想化の仕組みを追う前に、Linuxのプロセス・ストレージ・ネットワーク周りを固めたほうが、結局は速いです。土台が同じなので、そこで得た知識がそのまま使えます。

体系的に組み直したい方は、InfraAcademy のLinux学習ロードマップを土台づくりに使ってみてください。ブラウザ上で実際にコマンドを打ちながら進められるので、検証環境を用意する手間なく手を動かせます。VMwareそのものを学び直したい場合はVMwareおすすめ本5選も参考になります。

移らないという判断も、普通に存在する¶

最後に、公平に書いておきたいことがあります。

Broadcomは2025年6月17日に VMware Cloud Foundation 9.0 を一般提供として出しました。単体の仮想化製品ではなく、プライベートクラウドの基盤として売る方向にまとめた製品です。

大規模な環境で、すでにVMwareの運用体制と人材が揃っているなら、そのまま使い続けるほうが総額では安いという結論も十分あり得ます。

移行そのものにも費用と時間がかかりますし、慣れた道具を捨てることで事故が増える可能性もあります。移行するかどうかは、思想ではなく見積もりで決まる話です。

まとめ¶

2026年の仮想化基盤は、ひとつの正解が消えた状態にあります。

永続ライセンスという逃げ道が無くなり、vSphere 7 のサポートも切れました。だから更新のたびに、移るか残るかを判断することになります。

移る場合の行き先は、Nutanix・Hyper-V・OpenShift Virtualization・Proxmox VE という4つの系統に整理できて、その多くがKVM、つまりLinuxを土台にしています。

だからインフラエンジニアとしての備え方は、はっきりしています。どの製品が勝つかを当てにいくのではなく、下にあるLinuxとネットワークを固めておくことです。

土台が分かっていれば、次に何が来ても読み替えられます。今日は virsh list --all を一度打ってみるところから始めてみませんか。

参考記事¶

• VMware End Of Availability of Perpetual Licensing and SaaS Services（VMware Cloud Foundation Blog）
• Two Options for Upgrading VMware vSphere 7 to vSphere 8（VMware Cloud Foundation Blog）
• VMware to lose 35 percent of workloads in three years（The Register, 2025年9月11日）
• Broadcom Delivers the Modern Private Cloud with VMware Cloud Foundation 9.0（Broadcom News）
• Proxmox Virtual Environment 9.0 with Debian 13 released（Proxmox プレスリリース）