2024年4月には、これまでのVMwareパートナープログラムが終了し、現在は新たにBroadcomのパートナープログラムに移行している段階にある。現時点では、新たなライセンスに伴う影響度の把握はもちろん、クラウド環境への移行や他のハイパーバイザー含めた別の基盤を比較するといったアプローチが多く、保守期間の切れる数年先を見据えて、新たな環境をどう設計していくべきなのか、多くの企業が検討を重ねている。業務に関連したワークロードを動かす根幹となるプラットフォーム部分の改変となってくるため、VMwareを使い続けて大丈夫なのかといった不信感が大きく膨れ上がっている。

　VMwareを販売するリセラーの視点では、ライセンス変更に伴い顧客に新たな予算化を依頼せざるを得ないという課題がある一方で、安定稼働している基盤領域を他のベンダーに切り替える機会が少ない顧客に対して、新たな提案を行える貴重なチャンスでもある。

　Broadcomから提示されているライセンスについては、大きくエンドユーザーを基準が非公開なカテゴリーに分けて販売可能なエディションが用意されている。これまで必要な機能だけを購入していた企業にとっては、必要な機能が含まれたエディションを丸ごと購入せざるを得なくなり、実質的な値上げにつながっているケースも少なくない。カテゴリーは「Strategic」「Corporate」「Commercial」の3つが設定されており、カテゴリーごとに購入できるエディションが限定されている。Commercialであれば、全てのエディションから選択できるが、Strategicの場合は多くの機能が内包されているVMware Cloud Foundationしか購入できない。

　また変更ポイントの一つは、これまで永続ライセンスと別売のサポートで利用できた環境から、サポートが付属した期限付きのサプスクリプションのライセンスに移行したことだ。そして課金単位がCPU課金からCore数単位となったことも大きな変更点の一つだろう。

　エディション選択については、管理対象となる「VMware ESXi」の台数やネットワーク仮想化を実現する仮想スイッチのVMware NSXの利用があるかどうかなど既存の構成から購入すべきエディションが限定されてくる。さらに、Add-onとして選択できる製品がエディションによって異なっており、特定の機能が必要であれば購入するエディションが自ずと絞られてくることになる。自社の運用環境を十分把握したうえで、改めて費用に関して検討したいところだ。

　なお、最小構成の「VMware vSphere Essentials Plus」（VVEP）については、2024年11月に販売終息のアナウンスが発表されている。

　ライセンス変更に伴って考えうる大きな選択肢としては、主に3つほどが挙げられる。

　1つ目は、新たなライセンスを受け入れて継続してオンプレミスでVMwareを使い続けるというもの。2つ目は「Amazon Web Services」（AWS）や「Microsoft Azure」「Google Cloud」などクラウド環境でVMwareを稼働させる方法。そして3つ目が、「Hyper-V」や「Azure Stack HCI」「Nutanix AHV」といった異なるハイパーバイザーへの移行、いわゆる“脱VMware”としてのプラットフォーム移行だ。

　これら以外にも、Kubernetesを中心にコンテナ環境への移行も視野に入ってくるが、新たなサービス開発の領域で検討するケースが多く、既存環境を一気にコンテナ化するという選択肢を取るケースは多くないと見られる。

仮想化基盤を見直す際に考えるべき視点

　ライセンス変更で仮想化基盤の在り方を改めて考えるべき状況にあるが、そもそもどういった目線で基盤見直しを検討していくべきなのだろうか。今回取材に協力いただいた富士ソフトでは、独立系の強みを生かして特定のソリューションにこだわらず、顧客に最適なソリューションとプラットフォームを提案し、多数の移行実績がある。その知見を基に、考慮すべきポイントを紹介する。

脱VMwareを前提にしない

　ライセンスが変更されたことで費用が大幅にアップすることに言及する情報が多いが、本当にコストアップになるのかを冷静に判断すべきだ。Strategicにカテゴリー分されたエンドユーザーの場合は、基本的には全ての機能が含まれた「VMware Cloud Foundation」を購入せざるを得ないため、小規模で使っている場合は機能過多のエディションを利用することになり、コストアップは必至だろう。一方で、「Commercial」であれば既存の機能が利用できるシンプルなエディションが選択できる可能性はあり、コストアップにならないケースも当然出てくる。

　また、既存のVMware環境が数年前に構築されたものであれば、現時点でハードウェアリソースが大きく向上していることからもサイジングが大きく変わってくる可能性がある。構築し直すことでライセンス数を減らすことができる可能性もあるため、改めてリセラーが提供する各種アセスメントを利用して、環境の最適化を検討したいところだ。

　新たな環境への移行リスクや学習コストなども考慮しながら、コストをしっかり見極めることが必要で、最初から脱VMwareを念頭において考えることは避けるべきだ。

現状のワークロードが稼働するかどうかを見極める

　ハイパーバイザーを中心とした仮想化基盤の見直しが注目されているが、本来であればその上で稼働しているワークロードがしっかり維持できるかどうかが重要になってくることは間違いない。ハイパーバイザーによっては、アプリケーション側がサポートしていない、古いゲストOSなどは限定的なサポートにとどまっている、といった制約もある。

　例えば「Windows 2000 Server」といった古いゲストOSは、VMware vSphereでは非推奨ながら限定サポートされているバージョンも残されているが、最新のHyper-Vではサポート外となる。「Red Hat Enterprise Linux」やすでにプロジェクトが終了した「Cent OS」といったRed Hat系Linux OSもバージョンによってはサポートの有無が異なってくるため、現在利用しているゲストOSが継続的に利用できるかどうかはしっかり確認したいところだ。

　ものによっては古いアプリケーションが安定して稼働し続けている環境も残されているため、仮想化基盤上で稼働しているワークロード全体をしっかりと棚卸したうえで見極めたい。

クラウド環境への移行、見ておくべきはデータの置き場所やネイティブサービス

　クラウド環境への移行先としては、AWSやMicrosoft Azure、Google Cloud、「Oracle Cloud Infrastructure」（OCI）などがメジャーな選択となってくるが、IaaSとしてのVMware環境の移行先という意味では、それほど大きな違いは見出しづらい。

　ここで考えるべきは、保有しているデータを既存業務でどう活用させていくのか、そしてそのためにはどこにそのデータを置くことがよいのかという視点だろう。また、DWHやBI、機械学習含めたAIといったクラウドそのものが提供するネイティブなサービスをどう使うのかという視点で移行先を考えることが大切になってくる。もちろん、ベンダーに依存したアプリケーションを利用している場合は、ライセンス的なメリットから特定のクラウド環境を選択していくことになるだろう。

Microsoftを前提とした移行の選択肢

　ここで一例として、Microsoftへの移行という観点から取りうる選択肢について見ていこう。

　既存のVMware環境がオンプレミスなのか、AWSに展開されている「VMware Cloud on AWS」といったクラウド環境にあるのかを理解した上で、オンプレミスで環境を整備するのか、クラウド環境であるAzureサービスに移行するのかといったことが候補になってくる。

　オンプレミス環境に展開する場合、スイッチや外部ストレージを組み合わせた従来型の3層アーキテクチャ構成の仮想基盤としてHyper-Vを選択するパターンと、オンプレミスとAzureサービスをハイブリッドで連携する「Microsoft Azure Stack HCI」を利用する方法が検討できる。

　クラウド環境であれば、IaaSやPaaSとしてMicrosoft Azureにワークロードを移行する方法と、VMwareのワークロードをそのままプライベートクラウドとしてAzureサービスを利用するAzure VMware Solutionを活用するといった選択肢が挙げられる。

　なお、VMware環境からHyper-V環境へ移行する際には、仮想ディスクのフォーマット変換が必要となるため、ベンダーから提供されている変換ツールを利用する方法が一般的だ。

　Microsoftからは、移行ツールとして「System Center Virtual Machine Manager」（SCVMM）や「Azure Migrate」が提供されている。変換するVMware VMを選択し、リソースやパス、ネットワークを選択したうえでデプロイを実行することで、シンプルに移行することが可能だ。

　またVMware ESXiホスト上で仮想マシンのバックアップを取得し、用意したHyper-V環境へリストアするといったソリューションもある。例えばVeeam Softwareが提供する「Veeam Backup & Replication」は、バックアップやレプリケーション、ストレージスナップショットなどデータ保護に関連したソリューションだが、Hyper-V環境への移行も支援している。事前作業としてVeeamを利用して移行したいVMware VMを定期的にバックアップしておき、移行実施のタイミングで差分のバックアップと取得したバックアップデータからHyper-V環境にインスタントリカバリーを実施。起動が確認された段階で、ストレージに実データを移行するといった流れとなる。

　上記の方法以外にもアプローチは検討できるが、いずれにせよ事前の移行検証をしっかり行ったうえで実施したい。

運用コスト低減や新たな付加価値に価値を見出すNutanix

　VMwareのライセンス変更をきっかけに、VMwareから脱却して新たなプラットフォームへの移行の受け皿として注目されるのが、プラットフォームにビルトインされたハイパーバイザーとしてNutanix AHVを提供し、3層アーキテクチャからの脱却が可能になるNutanixのNutanix Cloud Platform（NCP）ソリューションだ。共有ストレージを別途持つことなく、汎用x86サーバへNutanixのソフトウェアをインストールすることで利用できるNutanixのソリューションだが、オンプレミスでの利用はもちろん、AWSやMicrosoft AzureなどパブリッククラウドでNutanixソフトウェアを起動させ、VMをオンプレミス-パブリッククラウド間で自由に移動させるといった柔軟な環境整備が可能なソリューションとなっており、短時間での本格的なパブリッククラウド移行へも活用できるものとなっている。

　実際のビジネス状況については、Broadcomによる買収が完了した2023年11月以降からNutanix社への問い合わせが急増しており、買収以前は週1～2回ほどだったNutanixのソフトウェアを無料体験できるNutanix Community Editionのダウンロードが毎月3桁に到達するなど、VMwareからの移行を検討する材料として注目されていることが見て取れる。

　主な問い合わせは、既存のオンプレミスで稼働するVMwareをNutanix環境に移行するというものが中心になるが、なかにはパブリッククラウドへの移行の際に、Nutanixソフトウェアをパブリッククラウド環境で起動させて仮想マシンをそのまま移行する「Nutanix Cloud Clusters（NC2） on AWS」と呼ばれるソリューションやマルチクラウドに対応するKubernetesプラットフォームである「Nutanix Kubernetes Platform」（NKP）を利用してVMwareを新たな環境に移行するといった相談も増えているという。

　もともとハイパーバイザーである「Nutanix AHV」は「Nutanix Cloud Platform」（NCP）へビルトインされており単独での提供は行われていない。VMware環境では外部共有ストレージハードウェアが提供していた機能を実現するソフトウェアも含めてシンプルな環境構築が可能なソフトウェアプラットフォームソリューションだ。

　ハードウェアは各サーバプラットフォームベンダーのプラットフォームを自由に選択することができる。そのため、既存のストレージのうえでNutanix AHVを動かすというシンプルに移行というアプローチではなく、ハードウェア統合や統合的な運用管理によって調達や運用に関連した管理コスト全体を大幅に低減していくことが可能なソリューションとして、Nutanix AHVへの移行を検討していくことが必要だ。一方、Nutanixとして今後外部共有ストレージや既存の他社ソフトウェアが動作しているサーバやHCIハードウェアへ対応を拡大してゆく方向性も発表されている。

　外部ストレージをスイッチでつなぎ合わせて複数のコンソールで運用することでインフラの火をともし続けてきた複雑な運用から、できるだけ手間をかけずにDXを含めた新たな領域へシステム部門のリソースをかけていける環境づくりの一環として、Nutanix Cloud Platform（NCP）が1つの選択肢となってくるわけだ。

　また、管理コストの削減だけでなく、イノベーションを加速させるためのソリューションを中心にリリースを進めており、「NVIDIA NIM」や「Hugging Face」などのAIモデルハブで提供されているLLM（大規模言語モデル）を自動的に展開し、LLM向けの APIの提供、LLMの展開から導入、管理を容易に実現するNutanix Enterprise AI（NAI）と呼ばれるソリューションや、買収したD2iQ社（旧Mesosphere社）のソリューションを取り込み、Nutanix Cloud Platform（NCP）と統合したマルチクラウド環境をシンプルに実現するコンテナプラットフォームであるKubernetes上のクラスタを柔軟に管理できる「Nutanix Kubernetes Platform」（NKP）ソリューションなど、VMwareのライセンス変更への対応だけにとどまらない、将来のビジネスを支える基盤として検討することができる。

Nutanix Cloud Platform（NCP）への移行について

　最も気になるところが既存のVMware環境の移行プロセスだが、移行を強力にサポートするツールとして長年提供しているのが「Nutanix Move」と呼ばれるソリューションだ。かつては「Xtract for VM」と呼ばれていたツールで、すでにグローバルで数千社がこのNutanix Moveでの移行を実現しており、仮想マシン数では数百万規模の数を移行させている実績を持っているツールだ。

　Nutanix Moveでは、ターゲットとなるVMと新たに立ち上げる環境の設定を行う、その後は自動でスナップショットが取得され、データの初期同期が実施される。その後も既存のワークロードを止めることなく裏側で定期的にデータの同期が行われる。実際に仮想マシンを移行させる場合、ターゲットとなるVMがシャットダウンされ、最後の差分が同期された後、AHV上で仮想マシンが起動されるため、ダウンタイムを最小限（再起動1回分程度）におさえた移行が可能となっている。

移行における注意点

　多くのケースは移行ツールを使うことでスムーズに新たな環境への移行が完了するが、例えば仮想マシンから物理的なストレージに直接アクセスするRDM（Raw Device Mapping）などを利用している場合、当然ハイパーバイザーを経由しないためにシンプルな移行ツールでは環境を移行できない。

　ただし、パススルーの環境はNutanixでも再現できるため、同じような設定を施していくことで移行は問題なく実現できる。また、VDI環境をはじめ移行ツールを使わないワークロードであっても、Windowsのプロファイルを移行することでスムーズな移行が可能になるなど、多くの実績を持っている。

　前述した通り、移行にはワークロードだけでなく、今使っているバックアップツールが利用できるのかといった既存のエコシステムとの統合をはじめ、新たな環境で既存ベンダーのサポートが継続して受けられるのかといったサポート性、そして既存のライセンス体系との違いなど、さまざまな観点を考慮したうえで判断することが求められる。実は移行そのものよりも、移行にまつわる周辺の環境整備に時間を割く必要があり、移行そのものをシンプルに実現するNutanix Moveのような存在があることで、その他の部分にシステム部門のリソースを割くことができるのは大きいだろう。

　移行の決断は、ツールによる移行のようにシンプルではないものの、いずれVMwareのライセンス変更に端を発した新たな環境づくりに向けては、少なくとも投資に対して見合った新たな付加価値が生み出せる環境づくりを意識したい。