はじめまして。
今年からSB C&SでNutanixを中心としたプリセールスエンジニアを担当しています。
戸高です。

私は、これまで約7年間、インフラエンジニアとしてVMware、Nutanixなどの仮想化基盤に携わり、設計・構築から運用保守まで一通り経験してきました。資格については、Nutanix Certified Professional（NCP）のほか、VMwareではVCP-DCV、VCP-NV（NSX）、VCP-DTM（Horizon）などを取得しています。

そんなVMwareとNutanixの両方に携わってきたエンジニアの視点から、今回は「VMwareからNutanixへ移行すると、インフラエンジニアの設計や運用はどう変わるのか？」をテーマにお話ししたいと思います。

※前編では、Nutanixに変えると、普段の設計・管理はどう変わる？について記載していきます。

---

目次　（前編：設計・管理・アップデート）

1. はじめに ― なぜ今、VMwareからNutanixなのか
2. 【設計】基盤設計 ― 考え方はどう変わる？
3. 【管理】vCenterからPrismへ ― 仮想マシンだけじゃない、インフラ管理はどう変わる？
4. 【アップデート】LCMでアップデート運用はどう変わる？
5. 前編・まとめ

---

１． はじめに ― なぜ今、VMwareからNutanixなのか

昨今、仮想化基盤を取り巻く環境が大きく変化する中で、VMware環境を継続するのか、

Nutanixをはじめとした別の仮想化基盤へ移行するのか、検討されている方も多いのではないでしょうか。

製品の機能を比較した記事はすでに多くありますので、本記事では単純な機能比較ではなく、

「VMwareではこうしていたけれど、Nutanixではどうする？」

という、実際に設計・構築・運用するエンジニアの目線から両者の違いを見ていきます。

Nutanixの便利なところだけではなく、VMwareから移行する際に注意したいポイントや、機能・考え方が異なる部分をどのように補うのかについても触れていきたいと思います。

※VMwareとNutanix、どちらが優れているかを決める記事ではありません。
VMware環境を運用してきたエンジニアがNutanixへ移行するとき、「今までやっていたこの運用はどうなる？」という視点から、実際に感じた違いを紹介します。

またライセンスの話や細やかなロジックは、記載しないようにします。

▼VMwareからNutanixを選択する上で考えておきたいポイントを表にまとめてみました。

ごく一部のポイントです。

VMware経験者が気になること	Nutanixでは？	エンジニア目線で見るポイント
管理・操作	Prism Element / Prism Central	vSphere Client / vCenter Serverとの操作性や管理方法の違い
健全性チェック	NCC（Nutanix Cluster Check）など	チェック結果をどう確認し、必要に応じてKBなどから原因・対処方法を調べるか
ソフトウェア・FW更新	LCM（Life Cycle Manager）	複数コンポーネントのライフサイクル管理を集約できるメリットと注意点
閉域環境での更新	Dark Site環境向けの更新方法	インターネット接続できない環境では、通常環境と何が変わるのか
アップデート後の切り戻し	コンポーネントごとの仕様確認が必要	「問題があれば簡単にダウングレードすればよい」という前提で考えない
稼働中VMの移行	Live Migration	vMotionとの共通点・相違点、運用時に注意すること
HA・障害時のVM再起動	AHVのHA	vSphere HAに慣れたエンジニアが押さえておきたい考え方の違い
仮想ネットワーク	AHV Virtual Networking / Flowなど	vSS・vDS・NSX等で実現していた要件をNutanixではどう実現するか
監視・障害対応	Prism / Pulse / NCCなど	何が標準機能で確認でき、既存の外部監視とどう組み合わせるか
サポート連携	Pulse等	インターネット接続の可否によって運用方法がどう変わるか

2.【設計】基盤設計 ― 考え方はどう変わる？

VMware環境では、外部ストレージを利用する3Tier構成だけでなく、vSANを利用したHCI構成もあります。
一方、NutanixではAOSによる分散ストレージがプラットフォームの中核となっています。

そのため、VMwareからNutanixへの移行では、単純に「ESXiをAHVへ置き換える」と考えるのではなく、ストレージを含めた基盤全体をNutanixのアーキテクチャに合わせて設計する必要があります。

AOSの分散ストレージなど、Nutanixのアーキテクチャについて掘り下げるとそれだけで一つの記事になってしまうため、今回は詳細についてはいったん置いておきます。

ここでは、VMware環境からNutanixへ移行する際に、インフラエンジニアとして選定・設計時に押さえておきたいポイントに絞って見ていきます。

この後が重要で、いきなり製品機能を並べるのではなく、設計者が実際に考える順番で並べると面白いと思います。

※全体イメージです、Nutanixってざっくりこういうものだとイメージ用

たとえば、

① ハイパーバイザーをどうするか

ESXiを継続するのか、AHVへ移行するのか。AHVにする場合、既存VMの移行方法やゲストOS、バックアップ製品など周辺製品の対応状況も確認する。

Point.
対応可否だけでなく、利用予定のAOS/AHVのバージョンまで含めて互換性（Compatibility）を確認しておくことをおすすめします。

そもそもAHVとはという人は、下記をご参考ください！

参照blog：

Nutanix 「AHV」とは

---

② 何ノード構成にするか

必要なCPU・メモリ・ストレージ容量だけではなく、ノード障害時に残りのノードでVMを稼働できるかまで考える。

Point.
「必要なリソースが収まるから○ノード」ではなく、1ノード障害時などの縮退運転まで想定して構成を検討します。

③ ストレージ容量をどう見積もるか

単純な物理ディスク容量ではなく、RF、予約容量、データ削減機能(重複排除機能を使用される場合)などを踏まえて必要容量を考える。

Point.
RF2、RF3のどちらを採用するのかによって、データ保護の考え方や必要となるクラスタ構成も変わります。

「どの程度の障害まで想定し、データを保護する必要があるのか」という要件から考える必要があるため、RFについてはサイジングを始める前の要件定義・基本設計の段階で検討しておきたいポイントです。

詳細については、下記をご参照ください！

参考blog：

Nutanix HCIにおけるデータの冗長化

---

④ ネットワークをどう設計するか

物理NIC、ToRスイッチ、VLAN、冗長化など、VMware環境でvDSやNSXを使用しているなら、現在利用している機能をNutanix環境でどう実現するかも確認する。

Point.
特に既存環境でvDSやNSX固有の機能を利用している場合は、AHVへの移行後も同じ要件を満たせるのか、事前に整理しておくことが重要です。

---

⑤ 既存の運用・周辺製品をそのまま利用できるか

バックアップ、監視、DR、ウイルス対策など、「VMwareで使えていたからNutanix/AHVでも使える」とは限らないので確認する。

Point.
単純な製品の対応有無だけではなく、Nutanix/AHVへの対応ライセンス、エディション、利用予定バージョンとの互換性まで確認しておくことをおすすめします。

特にバックアップや監視など、日々の運用に関わる製品については、基盤を移行した後に「今までの運用ができない」とならないよう、設計段階で確認しておきたいところです。

　

　私自身、設計するうえで重要だと感じているのは、単純にVMware環境のスペックをそのままNutanixへ当てはめないことです。

「現在どのような構成だから」ではなく、「なぜその構成・機能を利用しているのか」という要件まで戻って考えることで、Nutanixに適した構成を検討しやすくなります。

３．【管理】vCenterからPrismへ ― 仮想マシンだけじゃない、インフラ管理はどう変わる？

ここでは、日々の管理・運用という観点から、VMwareとNutanixではどのような違いがあるのか、私が特に押さえておきたいと感じた4つのポイントに分けて紹介します。

① VMの日常操作はどう変わる？

まずは、VMware環境でも日常的に行う仮想マシン（ゲストマシン）の操作について見てみます。

※検証環境でCVMのみ表示されています。

VM管理画面です。ここで以下の操作が可能です。

• VMの作成・削除

• 電源操作

• Webコンソール接続

• スナップショット

• クローン

• Live Migration

• CPU・メモリ・ストレージなどのリソース変更

vSphere Clientに慣れていると、最初は「この操作はPrismのどこにあるんだ？」と戸惑うこともありますが、基本的なVM運用で必要となる操作はPrismから実施できます。

また、VMware環境ではゲストOSにVMware Toolsを導入することがありますが、NutanixにもNGT（Nutanix Guest Tools）というゲストOS向けのツールが用意されています。

ただし、VMware ToolsとNGTは同じものではなく、提供される機能や役割にも違いがあります。

そのため、「VMware ToolsがNGTに置き換わる」と考えるのではなく、それぞれがどのような機能を提供しているのかを理解しておくことが重要です。

Point.
VMwareとAHVでは、仮想CPUの指定方法など細かな考え方・操作方法に違いがあります。

また、スナップショットについてもVMwareとNutanixでは仕組みや考え方に違いがあるため、こちらは後ほどバックアップの観点から触れたいと思います。

参考blog：

新人SEと学ぶ！Nutanixの構築 第8回 仮想マシン作成とゲストOSインストール

Prism Central と Prism Element の操作比較PART①

よくある質問からひも解くNutanix 第2回~ストレージ構造とバックアップ編~

---

② クラスタ・ホストの状態確認

PrismではVMだけでなく、

• クラスタ

• AHVホスト

• CVM

• ストレージ

• CPU / メモリの使用状況

• アラート

など、Nutanix基盤全体の状態を確認できます。

上記画像のように表示でき、検証環境では、電源冗長されていないことがわかります。

私がVMware環境からNutanixへ移って感じた違いの一つが、Prismは単なる「VMを操作するための管理画面」というより、Nutanix基盤全体の状態を確認するための管理インターフェースという点です。

UIも視覚的に把握しやすく、例えばハードウェア障害が発生した場合には、アラートだけでなく対象となるディスクの位置などを確認できるケースもあります。

そのため、日々の運用ではまずPrismを確認し、クラスタ全体で何が起きているのかを把握する、という使い方が多くなります。

---

③ ハードウェアの状態も確認する

Nutanixでは、仮想マシンだけでなく、ノードやディスク、NICなど、ハードウェアに関する状態やアラートもPrismから確認できます。

では、「Prismがあればハードウェア管理もすべて完結するのか？」というと、そうではありません。

Prismと、物理サーバーに搭載されているBMC（Baseboard Management Controller）では役割が異なるため、目的に応じて使い分けます。

▼ Prismから確認するもの

• ノード / ホストの状態

• ディスクの状態

• CPU・メモリなどのリソース使用状況

• ストレージ容量・使用状況

• NICなどの状態

• ハードウェア関連のアラート

• クラスタ全体のHealth

日常的な監視では、Prismを起点として異常の有無を確認できます。

一方、より物理サーバー側の状態確認や操作が必要な場合はBMCを利用します。

▼ BMC（IPMI等）で確認・操作するもの

• 物理サーバーの電源状態・電源操作

• POST / ブート時の状態確認

• BIOS / UEFI設定

• ハードウェアベンダー固有のイベントログ

• リモートコンソール

• AHVなどが起動していない状態での確認

• Prism / CVMへアクセスできない場合の調査

例えば、AHVやCVMが正常に動作しておらずPrismへアクセスできない場合には、BMC側から物理サーバーの状態を確認することがあります。

Point.
普段はPrismを起点としてインフラ全体の状態を確認できますが、「Prismで確認できること」と「BMCで確認・操作すること」を分けて考えておくことが重要です。

特に障害対応を考える際には、

「Prismにアクセスできなくなった場合、どこから状態を確認するのか？」

まで運用設計に含めておくと安心です。

これはVMware環境でも同じで、vCenterだけですべての物理障害を調査するわけではなく、必要に応じてiLOやiDRACなどを確認することがあったと思います。

Nutanixでも同様に、PrismとBMCを目的に応じて使い分けます。

---

④ 障害が起きたらどう調べる？ ― アラートとNCC

では、実際にPrism上にアラートが表示された場合、どのように確認・対応していくのでしょうか。

まずはPrismに表示されているアラートから、「どのコンポーネントで」「何が発生しているのか」「どのような影響があるのか」を確認します。

※画像では、検証環境でデフォルトパスワードと電源冗長について、アラートが出ています。

アラートの内容によって対応方法は異なりますが、必要に応じてNCC（Nutanix Cluster Check）によるヘルスチェックを実施し、クラスタの健全性を確認します。

例えば、障害調査は以下のような流れになります。

① Prismでアラートを確認
↓
② アラートの内容・影響範囲を確認
↓
③ 必要に応じてNCCによるヘルスチェックを実施
↓
④ NCCのチェック結果やNutanix KBを確認
↓
⑤ 解決が難しい場合はNutanixサポートへ問い合わせ

NCCは、Nutanixクラスタに対してさまざまなヘルスチェックをまとめて実施できるため、障害調査だけでなく日常的な健全性確認にも便利なツールです。

一方で、NCCを実行して「PASSではなかったから即障害」というわけではありません。

チェック結果の内容を確認し、必要に応じてNutanix KBなどから原因や対処方法を確認する必要があります。

また、チェック結果に関連する情報が一般公開されていなかったり、公開情報だけでは判断が難しかったりするケースもあります。

そのような場合は、無理に自己判断で対応するのではなく、Nutanixサポートへ問い合わせることをおすすめします。

NCCの取得方法については、詳しく解説されていますので、下記参考blogをご確認ください。

参考blog:

新人SEと学ぶ！Nutanixの構築 第6回 Prism初回ログインとNCC・LCMについて

Point. サポートへ問い合わせる前にログを準備しておく

サポートへ問い合わせる際には、

• 事象が発生した日時

• 表示されたアラート

• 影響範囲

• 実施した確認内容

• すでに実施した対処

などを整理しておくと、その後のやり取りを進めやすくなります。

また、必要に応じてログバンドルを事前に取得しておくことで、サポート側での調査をスムーズに進めやすくなります。

ただし、必要となるログや取得方法は事象によって異なるため、状況に応じてサポートの案内に従って取得することも重要です。

VMware環境でも、vCenterにアラートが表示されたらイベントやログを確認し、必要に応じてKBを調べたり、サポートへ問い合わせたりしていたと思います。

Nutanixでも、「事象を確認する → 切り分ける → 情報を調べる → 必要ならサポートへ問い合わせる」という障害対応の基本的な考え方は大きく変わりません。

一方で、NCCによってクラスタ全体の健全性をまとめてチェックできる点は、Nutanixを運用するうえで覚えておきたいポイントです。

4.【アップデート】LCMでアップデート運用はどう変わる？

インフラを運用していくうえで避けて通れないのが、ソフトウェアやファームウェアのアップデートです。

VMware環境でも、ESXiやvCenter Serverだけでなく、サーバーのBIOS、BMC、NIC、ストレージコントローラーなど、

さまざまなコンポーネントや3rdパーティー製品や対応ゲストＯＳのバージョンや互換性を確認しながらアップデートを実施していたと思います。

Nutanixでは、このアップデート運用を支援する機能としてLCM（Life Cycle Manager）が用意されています。

※ざっくりとした流れです。LCM画像は、あくまでもイメージですので実際の画面と異なります。

私もインフラエンジニア時代は、バックアップ基盤のクラスターから適用したり、影響の少ない基盤からアップデートしておりました。

最初対応していた頃は、サポートにNCCチェックしたものを事前に送付して確認いただいたりしておりました。

① LCMでは何をアップデートできる？

LCMでは、Nutanix環境を構成するソフトウェアや、対応するハードウェアのファームウェアなどをまとめて管理できます。

例えば、

• AOS
• AHV
• NCC
• Foundation
• BIOS / BMC
• NICなどのファームウェア
• その他LCMに対応しているコンポーネント

などです。

※LCMで管理・アップデートできる対象は、利用しているNutanix製品やハードウェア、バージョンなどによって異なります。

VMware環境でも各種アップデートを行いますが、Nutanixで私が便利だと感じるポイントの一つが、ソフトウェアから対応するファームウェアまで、LCMを起点としてアップデートを管理できることです。

② アップデートの依存関係もLCMが確認してくれる

インフラのアップデートで大変なのが、各コンポーネントの互換性や依存関係の確認です。

例えば、

「このAOSに、このAHVのバージョンは対応しているのか？」

「このファームウェアを先にアップデートして問題ないのか？」

といった確認が必要になります。

LCMではInventoryを実行することで、現在使用しているソフトウェアやファームウェアのバージョンを確認し、利用可能なアップデートを確認できます。

また、アップデートするコンポーネント間に依存関係がある場合は、LCMが依存関係を考慮してアップデートを実施します。

Point. 「1クリック＝何も確認しなくてよい」ではない

LCMによってアップデート作業はかなり簡素化できますが、エンジニアとしては「ボタンを押せば全部お任せ」と考えない方がよいと思います。

アップデート前には、対象バージョンのリリースノートや既知の問題、アップグレードパス、周辺製品との互換性などを確認したうえで実施することをおすすめします。

③ 実際のアップデートはどう進む？

基本的にはPrismからLCMを開き、Inventoryを実行して現在の環境と利用可能なアップデートを確認します。

イメージとしては、

① LCMでInventoryを実行
↓
② 現在のバージョンと利用可能なアップデートを確認
↓
③ アップデート対象を選択
↓
④ 事前チェック・依存関係などを確認 (事前にPre-Updateを選択できます。)
↓
⑤ アップデートを実施
↓
⑥ 完了後にクラスタの状態を確認

という流れになります。

アップデート中には、必要に応じてVMのLive Migrationやホスト単位での処理などが行われるため、クラスタ全体を停止して一斉にアップデートする、という考え方ではありません。

とはいえ、本番環境で実施する以上、事前の影響確認やメンテナンス時間の確保は必要です。

NutanixのLCMについて、詳しく解説されていますので、下記参考blogをご確認ください。

参考blog:

若手SEと学ぶ！Nutanixの基本機能 LCM(Life Cycle Manager)

④ インターネットに接続できない環境では？

ここは、実際のインフラ設計・運用では気になるポイントではないでしょうか。

すべてのNutanix環境がインターネットへ接続できるとは限りません。　（私がインフラエンジニア時代のE/U様は、ほぼインターネット接続はダメでした。）

特に、セキュリティ要件などによって外部ネットワークへ接続できないDark Site（閉域環境）もあります。

Nutanixでは、このようなDark Site環境でもLCMを利用したアップデート方法が用意されています。

Connected SiteではNutanix側から更新情報や依存関係などを取得できますが、Dark Siteでは必要なアップデートファイルなどを別途準備し、環境へ持ち込んでアップデートを実施します。

Point. 閉域環境でもLCMは利用できるが、運用方法は同じではない

「インターネットに接続できない＝LCMが使えない」というわけではありません。

一方で、Connected Siteと比較すると、必要なファイルの準備や持ち込みなどが発生するため、閉域環境ではそれを考慮したアップデート運用を設計しておく必要があります。

⑤ アップデートしたら簡単に元へ戻せる？

ここは個人的に、アップデート前に必ず意識しておきたいポイントです。

アップデート後に問題が発生した場合、

「とりあえず前のバージョンに戻せばいい」

と考えたくなりますが、Nutanixではすべてのコンポーネントについて簡単にダウングレードできることを前提とした運用にはしない方がよいでしょう。

コンポーネントやバージョンによって対応方法が異なるため、アップデート前にリリースノートやアップグレードパス、既知の問題などを確認することが重要です。

また、アップデート後に問題が発生した場合は、必要に応じてNutanixサポートへ問い合わせることをおすすめします。

Nutanixとしてダウングレードはサポートされていないため、事前チェックが必要であり、そのためのPre-Updateでもあります。

参考記事：

Information on Nutanix Cloud Infrastructure (NCI) Releases

引用：Upgrade paths MUST always be to a later release. Downgrades are not supported. The best way to determine if an upgrade path is supported is to go to the Upgrade Paths page on the Nutanix Portal.

Point. アップデートは「戻せる前提」ではなく「事前確認」が重要

LCMによってアップデートの操作自体はシンプルになります。

しかし、操作が簡単になることと、アップデートのリスクがなくなることは別です。

これはVMwareでもNutanixでも変わらない、インフラエンジニアとして押さえておきたいポイントだと思います。

かならず手順を固めて置いて不測事態に備えることが重要です。（私は、作業時間帯のサポート有無を含めて確認しておりました。）

◆VMwareからNutanixへ移って感じるアップデート運用の違い

VMware環境でも、さまざまな仕組みを利用してアップデートを効率化できます。

そのため、「VMwareでは手作業、Nutanixなら全部自動」という単純な比較ではありません。

私がNutanixを触って感じるのは、AOSやAHVといったNutanixソフトウェアだけでなく、対応するハードウェアのファームウェアも含めて、LCMという一つの入口からライフサイクルを管理できることの分かりやすさです。

一方で、LCMが便利だからこそ、

「アップデートボタンが押せる＝今アップデートして問題ない」

とは考えず、事前確認を行ったうえで計画的にアップデートすることが重要です。

５． 前編・まとめ

今回は前編として、VMwareからNutanixへ移行する際の違いについて、「設計」「日々の管理」「アップデート」という3つの観点から、私自身のエンジニア経験も交えながらご紹介しました。

ここまでの内容を簡単に振り返ってみます。

項目	VMwareからNutanixへ移行する際に感じる変化
設計	VMware環境の構成をそのまま置き換えるのではなく、Nutanixのアーキテクチャや要件に合わせて基盤全体を設計する
日々の管理	Prismを起点として、VMだけでなくクラスタ、ホスト、ストレージ、ハードウェアなどNutanix基盤全体を確認する
アップデート	LCMを活用することでソフトウェアや対応するファームウェアのライフサイクル管理を効率化できる一方、事前の互換性確認やアップデート計画は引き続き重要

◆VMwareで培った知識はNutanixでも活かせる

私自身、VMwareとNutanixの両方の基盤について設計・構築・運用を経験してきましたが、Nutanixへ移行したからといって、これまでVMware環境で培ってきたインフラエンジニアとしての知識が使えなくなるわけではないと感じています。

例えば、

• CPU・メモリなどのリソース設計

• 障害時を想定した冗長化

• ストレージ容量のサイジング

• VLANや物理ネットワークの設計

• 周辺製品との互換性確認

• アップデート前の影響確認

など、インフラ基盤を設計・運用するうえで考えなければならない基本的な部分は大きく変わりません。

一方で、NutanixではAOS、AHV、Prism、LCMなど、VMware環境とは異なるアーキテクチャや機能を利用します。

そのため、VMwareでの経験をそのまま当てはめるのではなく、これまでの知識をベースにしながら、Nutanixではどのように実現するのかを理解していくことが重要だと思います。

◆「VMwareの○○はNutanixの何？」だけで考えない

VMwareからNutanixへの移行を検討すると、

「vCenterの代わりは何？」
「ESXiの代わりは？」
「このVMwareの機能はNutanixにもある？」

と、どうしてもVMwareの機能とNutanixの機能を1対1で比較したくなります。

もちろん、移行を検討するうえで機能比較は必要です。

しかし、私自身が両方の環境を経験する中で重要だと感じているのは、

「現在、その機能を何のために利用しているのか？」

という要件まで一度戻って考えることです。

例えば、

「vCenterを使っている」

ではなく、

「VMの管理、クラスタの状態確認、アラートの確認などを一元的に行いたい」

という要件に戻して考える。

そうすることで、

「その要件をNutanixではどのように実現するのか？」

という視点で比較できるようになります。

これは、設計だけではなく、運用や周辺製品を検討するときにも重要な考え方だと思います。

◆Nutanixの機能を使えば「何も考えなくてよい」わけではない

今回ご紹介したLCMは、Nutanix環境のアップデート運用を効率化できる便利な機能です。

しかし、

「1クリックでアップデートできる＝エンジニアが何も確認しなくてよい」

ということではありません。

対象バージョンの互換性やリリースノート、既知の問題、周辺製品への影響、メンテナンス時間など、アップデート前に確認すべきことは残ります。

これは設計や日々の管理についても同じです。

Nutanixによって操作や管理がシンプルになったとしても、「なぜこの構成にするのか」「障害が起きたらどうするのか」「どのように運用するのか」を考えるエンジニアの役割は変わりません。

むしろ、Nutanixの機能をうまく活用することで、定型的な操作を効率化し、設計や運用改善といった部分に時間を使いやすくなるのではないかと感じています。

◆後編では「実際の運用」にもう一歩踏み込みます

前編では、設計・管理・アップデートを中心にご紹介しました。

しかし、実際にNutanixを運用していくと、

「障害が起きたらどう対応する？」
「vMotionやHAでやっていたことはAHVではどうなる？」
「vDSやNSXを使っていたネットワークはどう考える？」
「UPSやバックアップなどの周辺製品はそのまま使える？」

といった疑問も出てきます。

後編では、

• Pulse・NCCを活用した障害対応

• Live MigrationやHAなどの可用性

• AHVのネットワークとVMwareとの考え方の違い

• UPS・バックアップ・DRなどの周辺運用

• 実際の設計・構築で私自身が苦労したポイント

など、より実際の運用に近い部分についてご紹介したいと思います。

特に周辺製品については、

「Nutanix/AHVに対応している」ことと、「自分たちが実現したい運用ができる」ことは必ずしも同じではありません。

私自身の経験も交えながら、機能比較だけでは分かりにくいポイントについてお伝えできればと思います。

後編もぜひご覧いただければ幸いです。