「脱VMware」なんて望んでいなかった――それでも考えざるを得ない人のための“3つの筋道”：宮原徹のITインフラ現場ノート（1）

Broadcomによるライセンス変更を受けて、「脱VMware」はITインフラ担当者にとって現実的な検討課題になりました。状況に応じた対策として、私が最近よくお話ししている3つの筋道を紹介します。

[宮原徹（日本仮想化技術）, 編集：鳥越武史，＠IT]

　皆さん、こんにちは。日本仮想化技術の宮原徹と申します。今回、「宮原徹のITインフラ現場ノート」というタイトルでコラムを連載することになりました。ITインフラに関わる日々の話題の中から気になったことを取り上げて、私なりの考えを述べていこうと思います。ITインフラに携わる皆さまにとって、日々の業務の一助になれば幸いです。

　第1回は、何かと話題になる「脱VMware」、つまりVMwareの仮想化製品群からの脱却についてお話ししたいと思います。

著者プロフィール

宮原徹（みやはら・とおる）

日本仮想化技術　代表取締役社長兼CEO。中央大学法学部法律学科卒。日本オラクルでLinux版Oracleのマーケティングに従事。2006年に日本仮想化技術を設立し、仮想化技術に関する情報発信やコンサルティングを手掛ける。

脱VMwareは“避けて通れない道”に

　2025年から2026年にかけて、急速に脱VMwareが現実的な話になり、私にも講演依頼が急に増えるようになりました。BroadcomはVMware製品群の永続ライセンスの新規販売を終了し、サブスクリプションライセンスに移行しました。その結果、更新時にライセンス費用が大幅に増えたという声をよく聞くようになったのです。

　このライセンス変更自体は、急な話というわけではありません。これまでのいきさつを振り返ると、BroadcomがVMwareの買収を発表したのは2022年で、買収完了は2023年11月。Broadcomには買収した企業の製品や事業を整理し、ライセンス体系や価格を大きく見直した前例がありましたし、VMware製品についても、ライセンス体系を見直す方針を買収完了直後にアナウンスしていました。

VMwareビジネスは“ロングテール”になるとみていたが……

　私自身は、実はここ数年、VMware関連のビジネスからは遠ざかっていました。もちろん既存のお客さまには、引き続きVMware製品群の運用保守サポートなどのサービスを提供していましたが、新規構築案件は皆無。既存のお客さまが運用するVMware製品群についても、バージョンアップをしない塩漬け運用の状態で、保守契約を更新しないまま運用するといった状況でした。

　お客さまがVMware製品群で運用していたシステムのほとんどは、クラウドサービスへの移行が済んでいました。どうしても移行できないシステムだけを、そのシステム自体が不要になるまで、何とか既存のVMware製品群で動かし続ける……という状態だったのです。

　そんな状態でしたので、VMware関連のビジネスは、今後はいわばロングテール化するのではないかとみていました。それがまさか、このような形になるとは思ってもいませんでした。そういう意味では、ビジネスを作るBroadcomの手腕は大したものだと言えます。今どきの言い方をすれば、VMware関連ビジネスには「ワンチャンあった」というところでしょうか。

　ただし、それは良くも悪くも既存のユーザーやパートナーを犠牲にした「焼き畑農業」的なものでもあります。「企業倫理としてどうなのか？」という疑問を抱く人がいるのも仕方がないかもしれません。このあたりが、VMware問題を割り切れないものだと感じる理由なのでしょうね。

　そんなビジネスの話はともかく、ITインフラ担当者は現実的な問題として、VMware製品群の今後を考えなければなりません。ここ最近、私がよくお話ししているのは、以下の筋道のいずれかです。

筋道1．とにかく塩漬け継続

　今のところ大幅な増強が必要なく、「とにかく現在のVMware製品群が動き続けてくれればいい」という塩漬け運用が可能なのであれば、後ろ向きではありますが「あえて動かない」、つまり既存のVMware製品群の運用を維持することが最適解ではないかと思います。

　それでもVMware製品群を動かすハードウェアは、使い続ければ故障リスクが高まりますので、どのように保守を確保するかを考えなければなりません。ハードウェアベンダーが延長保守をいつまでも提供できるわけではないので、いつまで延長保守を受けられるのか、あらためてベンダーに確認して調整する必要があるでしょう。

　特殊なハードウェアを使っていなければ、中古市場で保守パーツを入手することはできます。場合によっては、故障時の“部品取り”用として同型のサーバを丸ごと確保することもできるでしょう。私の会社でも、こうした方法でお客さまのシステムを延命することがあります。ハードウェアベンダーによる純正保守を受けるのがベストですが、難しい場合には第三者保守ベンダーを探すか、自社で保守できるように準備を進める必要があるかもしれません。

筋道2．最低限の更新で時間稼ぎ

　塩漬け運用が難しい場合や、ベンダーによる技術サポートが必要な場合には、最低限の更新をして時間稼ぎをしつつ、次のシステム更改に備えるのが現実解でしょう。

　前述の通りBroadcomによるライセンス変更で、VMware製品群では永続ライセンスの新規販売が終了となり、サブスクリプションライセンスのみになってしまいました。サブスクリプションライセンスへの移行に伴ってライセンス費用が増加したとの声も目立ちます。まずは見積もりを取り、どの程度の費用になるのかを把握する必要があるでしょう。

　場合によっては、既存環境の全ノードでライセンスを維持するのではなく、ノード数を減らしてライセンス費用を抑えるといった工夫が必要になるかもしれません。現行のVMware製品群は、プロセッサのコア数に応じたライセンス体系を採用しています。ライセンス費用を抑えるには、必要な仮想マシンを維持しながらノード数をどれだけ減らせるかがポイントになります。

　その際は、現在のCPUやメモリの使用状況を確認した上で、オーバーコミットメント（物理リソースを超えて仮想マシンにリソースを割り当てること）をどこまで許容できるかを見極める必要があります。あらためて現在のリソース使用状況をモニタリングして、必要となるリソースをサイジングし直すことになるでしょう。

筋道3．脱VMwareで次世代仮想化基盤を構築

　最低限の更新による延命さえも難しい場合、脱VMwareは待ったなしになります。今のところ、脱VMwareには幾つかの選択肢があります。私なりに以下のように整理しました。

Nutanix

　脱VMwareで、まず候補として挙がるのがNutanixのHCI（ハイパーコンバージドインフラ）製品群でしょう。当社のお客さまの中にも、移行先として導入する企業があります。

　実はNutanix製品群はそれほど安くないので、VMware製品群のライセンスを更新して使い続ける場合と比べても、費用面で大きな差が出ないことがあります。特に昨今はメモリやストレージの価格が高騰しており、ハードウェアの更改を伴う場合は、導入費用が大きく膨らむという声も聞こえてきます。こうした費用面の課題は、移行をためらう要因の一つになりそうです。

Hyper-V

　システム全体としてMicrosoft製品を中心に利用しており、既に「Windows Server」を搭載したサーバを運用している場合、Windows Serverの仮想化機能である「Hyper-V」が自然な選択肢になり得るでしょう。というよりも、そのようなユーザーは、既にVMware製品群ではなくHyper-Vで仮想インフラを構築している可能性があります。そういう意味では、Hyper-Vは脱VMwareの選択肢として挙がるものの、全てのユーザーにとって現実的な選択肢になるわけではないのかもしれません。

KVM

　よく名前が挙がるようになったのが、「Linux」に搭載されたオープンソースの仮想化機能「KVM」です。KVM自体はかなり以前からありますが、脱VMwareの文脈で、KVMをベースにした仮想化製品が次々と登場しています。

　代表的な製品が、Proxmox Server Solutionsの「Proxmox Virtual Environment」（Proxmox VE）でしょう。Linuxディストリビューションの「Debian GNU/Linux」をベースにしており、管理用のUI（ユーザーインタフェース）を備え、サブスクリプションライセンスなしでも利用できることなどから、脱VMwareの移行先として検討されるようになりました。

　その他にも、Red Hatの「OpenShift Virtualization Engine」やNTTデータの「Prossione Virtualization」、Hewlett Packard Enterprise（HPE）の「HPE Morpheus VM Essentials Software」など、KVMをベースにした仮想化製品が登場しています。VMware製品からこれらへの移行を検討する動きが広がっており、今後は移行事例が増えるかもしれません。

脱VMwareで本当に考えなければいけないこと

　主に費用面から脱VMwareを考えなければいけない状況になっていますが、忘れてはいけないのは、今後どのようなシステムを実現するのかという観点です。そういう意味で重要なのは、システムの内製化によって開発スピードを高めることだったり、業務システムでAIをどのように活用するかを考えることだったりします。

　脱VMwareを一つのきっかけにして、今後のシステムのあるべき姿を考えてみてもいいのではないでしょうか。