View Composerのリンク クローン用に用意された機能の一つとして、ストレージ・オーバーコミット（Storage Overcommit）がある。これは何なのか？
ストレージ・オーバーコミットの対象は？
リンク クローンでは、仮想デスクトップOS（事実上、C：ドライブ）と、その仮想デスクトップが依存している親仮想マシンOS（事実上、C：ドライブ）との間のデータの差分（デルタ）を、それぞれの仮想デスクトップが別々に持つ。この仕組みこそが、ストレージ容量を節約しながらも個々の仮想デスクトップの独立性を提供しているのだ。
で、その差分（デルタ）を格納するためにディスクを、デルタ ディスクと呼ぶ。
そのデルタ ディスクが、ストレージ・オーバーコミットの対象となる。
なので、UDD（User Data Disk）とかはストレージ・オーバーコミットの対象外だ。
なぜ、UDDが対象外なのか？
それは、そもそもストレージ・オーバーコミットが「View Composerを使うってことは、管理者は定期的にRecomposeかRefreshをするんだよね〜。故に、デルタ ディスクは定期的にクリアになるんだよね〜。」ということを前提にした機能だからだ（たぶん）。
あたりまえながら、ユーザーとしては、UDDが（意図せず）クリアされたら、困っちゃう。なので対象外。
デルタ ディスクに溜まるもの
「管理者が定期的にRecomposeかRefreshをする」ことを前提にするならば、 各仮想デスクトップのOS（事実上、C：ドライブ）部分には、どれくらいのストレージ容量を確保しておけばよいのだろうか。
ユーザーが自信のデータを保存する先は、すべてUDDだ。とすると、デルタ ディスクには、たとえばOSのパッチやらサービスパックやら、が入ることになる。使い方によって増加率は変わるだろうけれど、（RecomposeかRefreshをするまでは）時系列に従ってデルタ ディスクは増えることはあっても減ることはない。けれど、RecomposeかRefreshをすれば、これがクリアされる。
分かり易くするために、あえて極端な例を挙げてみる。たとえば、元々の親仮想マシンがWindows 7 Service Pack1で、次のRecomposeのタイミングで Service Pack2にするとしよう。当初は、Windows 7 SP1の状態でリンク クローンされているので、SP2は、各仮想デスクトップにインストールされる。このSP2は、そのまんまデルタ ディスクの増加につながる。1,000台仮想デスクトップがあったら、1,000個分のSP2の容量くらい、デルタ ディスクの総容量が増加してしまう。でも、親仮想マシンをWindows 7 Service Pack2にして、Recomposeすれば、デルタディスクの総容量は限りなく小さくなる。もちろん、各仮想デスクトップは、この時点でWindows 7 Service Pack2になっている。
で、ストレージ・オーバーコミットって、何をどうオーバーコミットするの？
たとえば、親仮想マシンOSが、20GBだとしよう。 上述の流れのとおりにいくならば、RecomposeやRefreshをせずに放置しない限りは20GBは間違いなく使わなそうだ、ということがわかるだろう。どんなに増えても5GB（1/4に該当）かそこいらしか使わないのでは、と推測できる。
マニュアルどおりの説明に従えば、ストレージ・オーバーコミットは、以下の4段階で設定できる。
None：オーバーコミットなし
Conservative：データストアのサイズの 4 倍（デフォルト）
Moderate：データストアのサイズの 7 倍
Aggressive：データストアのサイズの 15 倍
データストアのサイズのx倍、という表現だとわかりにくい（？）かもしれない。これと逆の表現をしてみよう。たとえばConservativeでは「デルタ ディスクは、親仮想マシンOS（事実上、C：ドライブ）の容量の、1/4程度までしか膨らまないだろう。1/4程度になる前に、RecomposeかRefreshをしよう」と、システム管理者が判断した、に等しい。
そんなんしか使わないのであれば、もったいないからそれなりの数の仮想マシンをデータストアに入れておこうよ、というわけだ。
「ほんじゃあ一番いっぱい仮想マシンを詰め込めるAggresiveがいいじゃん」という意見もあるだろうけど、それはすなわち、いっぱい仮想マシンを詰め込んだ場合は、RecomposeかRefreshの間隔を、より短くすることも同時に示している。
ストレージ・オーバーコミット、直訳すれば「ストレージの過度な約束」。
つーわけで、無理は禁物。
