テンプレートからVMをプロビジョニングするとき、「熱心」と「遅延」のゼロ化にはるかに長い時間がかかるのはなぜですか？
シックプロビジョニングとシンプロビジョニング に関する以前の質問と少し関係がありますが、クローン対象のゼロ化を積極的に行うVM遅延ゼロ化よりも時間がかかるのはなぜですか？
たとえば、最近実行したテストでは、ゼロゼロに設定されたクローンは完了するまでに約85分かかりましたが、遅延ゼロに変更すると、約50分で完了しました。
熱心なゼロ化と遅延の場合、どのくらいのオーバーヘッドが発生しますか？
「熱心な」はいつ使用するのが適切なモードですか？
Eager Zeroingは、すべての空のブロックに0を書き込みます。これにより、後でそれらのブロックに初めて書き込む必要があるときに、パフォーマンスがわずかに向上します。
Lazy Zeroingは、未割り当てのブロックに対しては何もしません。 80GB VMDKと10GB相当のデータしかない場合、10GB相当のブロックのみが使用され、残りは必要になるまでそのままです。この例が完全にゼロに設定されている場合、作成時にすべての80GBが書き込まれ、残りの70GBはゼロで埋められます。
ストレージレベルでシンプロビジョニングを使用している場合、シンプロビジョニングの目的を完全に無効にするため、積極的なゼロを回避する必要があります。
「熱心な」はいつ使用するのが適切なモードですか？
Eagerは、LUNをシンプロビジョニングしておらず、VMDKが作成されるのをもう少し待つ必要がない場合に使用する適切なモードです。
言い換えると、これを少し混乱させないように少し減らします：
When would 'eager' be the right mode to use?
重複排除、圧縮、またはシンLUNを使用している場合は、シンプロビジョニングされたVMを使用する代わりに、またはそれに加えて、VMFSストアの基礎となるSAN.
通常、これは、この方法でデプロイされた追加のディスクを作成してvmfsボリュームのすべての空き領域を再利用する場合にのみ使用します。
Eager Zeroは、VMDKストアがVMFSストアで使用するスペースをゼロにするために使用され、新しいVMのデプロイではあまり役に立ちません。
なぜ他にそれを使用するのかという典型的な例は、常にかなり極端/ニッチであり、今日はなおさらです。
あれは：
VMが実行されている場合、ディスクに0を書き込むときのVCPU負荷とディスク書き込みレイテンシを削減するように、VMによって書き込まれるセクターを事前にゼロ化します。
ただし、この利点は、VMがディスクの未使用セクションに書き込みを行っている間のみであるため、一度だけ読み取りが多かったアプリケーションで最大の利点が得られます。