これは ESXi のマニュアルに記載されている。
さて、ではサイズが異なると ESXi のインストレーションはどう変わっていくのだろうか?
VMware Fusion 上に ESXi をインストールし、その時の VMDK のサイズを変えて試してみた。
● 1,2,4GB の場合
これら 5.2 GB 未満のメディアの場合は、まったく同じサイズで5つのパーティションが作成される。
| ID | 開始セクタ | 終了セクタ | サイズ | 形式(FS) | 用途 |
| 1 | 64 | 8191 | 4MiB | systemPartition (FAT32) | EFI |
| 5 | 8224 | 520191 | 250MiB | linuxNative (FAT32) | /boot |
| 6 | 520224 | 1032191 | 250MiB | linuxNative (FAT32) | /altboot |
| 7 | 1032224 | 1257471 | 110MiB | vmkDiagnostic | Coredump |
| 8 | 1257504 | 1843199 | 286MiB | linuxNative (FAT32) | /store |
IDはパーティション番号を意味する。
1は要するに EFI システムパーティションで、FAT である。
5 が実際の ESXi のシステムが入ってる bootbank で、6 は altbootbank である。
7 は診断パーティションとも呼ばれているもので、要するにコアダンプ用だ。
8 は visorfs の /store にマウントされるパーティションで、VMware Tools のインストール用 CDイメージなどが格納されている。
linuxNative とGUIDで記載されているパーティションが何故 FAT32かというと、GUIDパーティションテーブルでは、Windows のパーティションと Linux のパーティションに同じGUID が割り当てられており、区別できないからだ。
全体で1GiB も使ってないが、これは 1,2,4 GB どの場合も同じだった。
つまり、5.2GB 未満では、どの容量のメディアを使おうと、先頭 0.9 GiB程度しか使われない訳だ。
● 8GB の場合
さて、8GBのメディアにインストールすると、こうなる。
| ID | 開始セクタ | 終了セクタ | サイズ | 形式(FS) | 用途 |
| 1 | 64 | 8191 | 4MiB | systemPartition (FAT32) | EFI |
| 5 | 8224 | 520191 | 250MiB | linuxNative (FAT32) | /boot |
| 6 | 520224 | 1032191 | 250MiB | linuxNative (FAT32) | /altboot |
| 7 | 1032224 | 1257471 | 110MiB | vmkDiagnostic | Coredump |
| 8 | 1257504 | 1843199 | 286MiB | linuxNative (FAT32) | /store |
| 9 | 1843200 | 7086079 | 2.5GiB | vmkDiagnostic | 拡張Coredump |
| 2 | 7086080 | 15472639 | 4GiB | linuxNative (FAT32) | /scratch |
| 3 | 15472640 | 16777182 | 約0.6GiB (残り全部) |
vmfs | datastore01 |
前半のパーティションはそのままで、あらたに9, 2, 3 の三つのパーティションが追加された。
ID:9 はESXi 5.5 で新たに用意されたコアダンプパーティションだ。従来の110MiBのダンプでは全てを取りきれないため、2.5GBもの容量が確保されている。
ID:2 がいわゆる Scratch パーティションで、ログなど様々な情報が格納される。
このパーティションが存在しないと、ESXi が警告を発するのはご存じの通りだ。
ID:3 は VMFS であり、datastore1 となる部分だ。ここは、ディスクの残り領域がすべて割り当てられる。8GBのメディアの場合、600MiB程度が VMFSとして確保される。
ここであれ?っと疑問に思われた方は正しい。そう、VMFS は 600MiB なんてサイズでは構成できない。vSphereClient から datastore1 を削除した後、再作成は失敗する。
この制限以下の小さな VMFS は、インストール時にのみ現れる特別なものらしい。
閑話休題、scratch が必要な場合は 5.2GB 以上のメディアを使うようドキュメントにはあるが、0.9GiB + 2.5GiB(拡張ダンプ) + 4GiB(scratch) では、7.4GB 程度が必要に見える。
そこで、6GB の場合を試してみた。
● 6GB の場合
6GB では、パーティションテーブルはこうなった
| ID | 開始セクタ | 終了セクタ | サイズ | 形式(FS) | 用途 |
| 1 | 64 | 8191 | 4MiB | systemPartition (FAT32) | EFI |
| 5 | 8224 | 520191 | 250MiB | linuxNative (FAT32) | /boot |
| 6 | 520224 | 1032191 | 250MiB | linuxNative (FAT32) | /altboot |
| 7 | 1032224 | 1257471 | 110MiB | vmkDiagnostic | Coredump |
| 8 | 1257504 | 1843199 | 286MiB | linuxNative (FAT32) | /store |
| 2 | 1843200 | 10229759 | 4GiB (FAT32) | linuxNative (FAT32) | /scratch |
| 3 | 10229760 | 12582878 | 約1.1GiB (残り全部) |
vmfs | datastore01 |
ID9 の拡張ダンプパーティションが消えている。その分、余りが増えるため VMFS 領域が拡大しているのが分かる。VMFS領域を抜くと、約 4.9 GiB になる。つまりは、SI単位系で言うところの約 5.2GB である。厳密に言うなら、scratch の最終セクタが 10229759 であり、1セクタが 512バイトのため、5237636608 バイトが必要である。これを1024 で割っていくと 4.87GB となり、1000 で割ると 5.2GB となる訳だ。
そして余った分が VMFS の領域になる。
もし、余りが 2.5GiB 以上あれば、拡張ダンプパーティションが作成され、そこからの残りで VMFS が作成される。
共有ディスクに、複数 ESXi のログまとめて管理したり、syslog で飛ばして LogInsight を使う、とかでも無い限り、scratch はあるに越したことない。
このため、おとなしく 5.2GB以上、実質的には 8GB のフラッシュメディアを用意しておくのが正解、となる。
なお、こちらのKBには面白いことが書いてある。
リテール購入品の 16 GB 以上の USB フラッシュ ドライブを使用すると、「予備の」フラッシュ セルで起動メディアを長持ちさせることができるのでお勧めしますが、コアダンプの拡張パーティションの保持には 4 GB 以上の高品質ドライブがあれば十分です。16GB にしておくことで、ウェアレベリングが効いてより長持ちすると言うことだ。
後半の文章が謎だが、8GB の誤植ではないかと思われる。
