VMware ESXi が初めて登場したのは 3.5 で 年月日、現在は 11世代後の 8.0 になっています。最初はとても小さくて軽かった ESXi もこの間にどんどん肥大化してきて、現在は ESXi 3.5 の約 5倍のサイズになってしまっていますが、これを調べている Web ページがありますのでご紹介します。
VMware ESXi 3.5 - 8.0 ハイパーバイザーのサイズ比較
VMware ESXi が登場した背景として、当時の ESX と ESXi はどう違うのかなどが記載された資料もまだ公開されているので、見てみると「なるほど」と思うことがあるかもしれません。
VMware ESX および VMware ESXi 本番環境で実績のある、業界をリードするハイパーバイザー
資料を読まないで「どこが違うの？」ということを知りたい方のために簡単に説明すると、VMkernel上で動く CentOS (RHEL) ベースのサービスコンソール (Console Operating System : COS) が ESXi では無くなったことで、ハイパーバイザーとしてのサイズが小さくなる（ESX は当時数ギガバイトにまで肥大していたのが、ESXi になることで 47 MB まで小さくなった）ことでソースの見通しもよくなり、その結果セキュリティインシデントになりがちなバグなども発生しにくくなるメリットがあると説明されっるようになりました。
以下の図は ESXi 登場当時の VMware の資料で良く説明されていた図です。ESXi については、この図の右側のサービスコンソールと呼ばれる部分が無くなっています。この変化についてはサービスコンソール上で行っていた管理系の処理が出来なくなるため、あえて ESXi ではなく ESX を選択するなども当時はありました。
ESX のアーキテクチャ
このソースのサイズが小さくなるという点については ESXi 6.7くらいまでグローバルでの説明資料でも言われ続けていた話で実際私もそのようにプレゼンをしていましたが、5.0 や 5.5 そして 7.0 のように新しい機能を加えたタイミングでサイズはどんどん大きくなり、それとともにバグも頻繁に出てくるようになってしまったのが、今の ESXi の実情ではないかと感じています。
ちなみに ESX は数ギガバイトに肥大と書きましたが、その大部分をサービスコンソールが占めていました。全体の 9割以上がサービスコンソールだったので、その部分を切り捨てることで ESXi は USB メモリーや SD カードにインストールすることが出来るようになり、各ハードウエアベンダーから USB DOM を使ったブートや SD カードを使ったブートができる製品が登場することになります。
ESXi の今後は
ESXi 登場時に使えるようになったUSB メモリーや SD カードは高頻度の Read / Write には不向きでかつ耐久性も低いため、ブートデバイスとして使う場合でも信頼性の低いデバイスでした。そのため vSphere 7 からはそれまで可能だった ESXi 本体を格納する ESXi の OS パーティション（ROM や RAM の部分）をそれらのデバイスに配置するのは vSphere 7 U3 以降非推奨となりました。そして vSphere 8 ではサポート対象外になっていますので、USB や SD カードからのブートをする場合でサポート対象の構成にするにはそれらの媒体の中にはブートに必要なパーティションのみしか配置できません。ということは、今までは最小構成としてブートデバイスのUSB メモリーや SD カードを用意すれば、HDD や SSD は全てデータストアに使えたのですが、今後はブートデバイスに USB メモリーや SD カードを使用したとしても、ESXi の OS 領域のために HDD や SSD が必要になり、その分データストアとして使える分が減る構成にならざるを得ないということになりました。これは VMware のベストプラクティスとされている構成で「USBメモリーや SD カードを使うのは「レガシー」な構成で、今後も長くサポートされるのを期待するなら USBメモリーや SD カードを排除し、HDD や SSD、PCIe の永続的ストレージデバイスを使え」という方向になっています。なので NUC を使ってディスクが足りないから USB ブートと内蔵ディスクでと済ますことが出来た家ラボ環境などでは、今後 vSphere 8 を検証したい場合内蔵 M.2 SSD / NVMe SSD をブートデバイスにして SATA をデータストア用にする、またはその逆にするなどの対応が必要になるでしょう。個人で検証環境を持つには厳しいプロダクトに vSphere はなりつつあります。また vSphere 8 以降はハードウエアについてもさまざまな制限が出てくるようになってきていますので、今までのような古いハードウエアにもインストールできるということが無くなる可能性も考えなければなりません。ということは、vSphere の新しいバージョンが出たら既存の環境でアップグレードができないハードウエアも出てくる可能性も考えられるということで、オンプレミスでの vSphere を運用している場合で vSphere のアップグレードなどを考える場合は十分な注意と検討が必要になってくるかなと感じています。つまり、業務システム側やゲスト OS は変わらないのに、vSphere のサポート関係で vSphere をアップグレードしようとしたら、長期のリース契約や買取の古めのハードウエアでは新しい vSphere がサポート対象外だったということも今後は頻繁に発生することになりそうかなとも感じてます。業務システムやゲスト OS の延命ができるのでプラットホームを仮想化したということも多いはずが、vSphere 8 とかになってくるとプラットホームとしての vSphere 側の都合でハードウエアなどの環境へも影響が出てしまうというのは、海外のように頻繁にプラットホームも取り換えていくならまだしも長期契約でリースコストを下げるとかがメインな今の日本企業の IT インフラにはちょっと厳しすぎるかなと感じます。なので、場合によっては仮想マシンで動く業務システムはそういう影響を受けにくいクラウド利用へリフトアンドシフトも検討したり、いっそのこと全部作り変えてクラウドネイティブへとかも考える必要があるかもしれないですね。
