最小限の追加スペースを使用してESXi vmスナップショットを削除するにはどうすればよいですか？
Win2k8を実行する仮想マシンの約15のスナップショットのツリーがあります。データストアの空き容量が間もなくなくなると思われるかもしれません。バックアップの目的でスナップショットを使用することは大きな間違いだったと思われるので、私の目的はすべてのスナップショットを削除することです。
さて、私の質問は、スナップショットをどのように削除して、マージプロセスに使用されるスペースが最小になるようにするかです。ツリーを下から上から削除し始めますか？最新のスナップショットの削除から始めて上に移動しますか、それとも最も古いスナップショットの削除を開始して下に移動しますか？
統合中に使用されるスペースを最小限にするには：
VMをシャットダウンします。このようにして、スワップファイル（構成された予約済みRAMのサイズ）が削除され、スナップショットを削除するときに作成される一時スナップショットファイルが、スナップショットを削除しているときに空き領域を使い果たすことを心配する必要はありません。
最初に[〜＃〜] oldest [〜＃〜]スナップショットから削除します。例えば。ベースに最も近いもの。スナップショットがコミットされると、ディスク容量が増えます。ベースから最も遠い最新のスナップショットから始める場合、削除されたスナップショットの変更を前のスナップショットにロールバックし、ベースに近づくにつれて大きくなります。 ESXi 4.0 update 2以降を実行している場合は、これが行われます。 4.0 update 2より前のESXiを実行している場合は、反対の処理が行われ、すべてのスナップショットが維持されるまで終了します。さらに、スナップショットが削除されている間、アクティビティを記録するために一時的なスナップショットが維持されます。したがって、4.0 Update 2より前のバージョンを実行している場合は、[〜＃〜] critical [〜＃〜]で、最初に最も古いものを手動で削除し、最新のものに移動します一度に。
個人的に、私がその状況にいるとき、私が取り組んでいるESXiのバージョンに関係なく、この手順を使用します。
- VMをシャットダウンします。
- 最も古いスナップショットから始めて、ベースに最も近いスナップショットから一度に1つずつスナップショットを削除し、ベースから最も遠い最新のスナップショットに向かってスナップショットを削除します。
[〜＃〜]なぜ[〜＃〜]「約15のスナップショットのツリー」を持っていますか？私はあなたを知っていますcanでも、それが、クローンやバックアップのことを聞いたことがあるので、それがスマートな方法であることを意味するわけではありません。彼らは彼らが「無料」であると考えるので、彼らは訓練されていないだけで虐待されています-彼らはそうではありません。
いずれにせよ、それはあなたの混乱であり、それらをすべて新しいものから最も古いものへと手動で削除するのにかかる時間にただ生きる以外に、それから抜け出す実際の方法はありません。
VMWareのサイトに関するこの記事 は、最初のスナップショット（ESX4.0U2より前の場合）を最初に削除するか、心配しないことをお勧めします。
VMware ESX 4.0 Update-2より前のバージョンでは、すべてのスナップショットを統合するタスク（すべてのスナップショットの削除タスク）により、2番目のスナップショットデルタディスクにのみ保存された一意の変更が、スナップショットチェーンを通じて最初のスナップショットまたはそのスナップショットにコピーされました。 "親"。この効果は、先行する親ファイルごとに再帰的です。
例：サイズが8 GBのベースディスクと、それぞれ4 GBの2レベルのスナップショットがあります。すべてのスナップショットの削除タスク中に、2番目のスナップショットからのすべての新しいブロックが書き込まれるため、最初のスナップショットデルタディスクファイルは、最悪の場合、8 GBに拡大する可能性があります。両方のスナップショットレベルに保存されている一般的な変更には、追加のスペースは必要ありません。
ESX4.0 Update 2以降、スナップショットメカニズムが変更されました。 VMware ESXには、改善された統合手順が組み込まれており、空き容量の需要を減らしています。データストアの空き容量が最小限でも、仮想マシンの差分ディスクを統合できます。
スナップショットの一部のみを削除する場合、または手動で行う必要がある場合は、ディスクの使用を最小限に抑えるために、最初のスナップショットを最初に削除することをお勧めします。そうしないと、上記の例で発生する状況が発生する可能性があります。
別のオプションは、VMを使用可能な別のデータストアに複製することです。すべてのスナップショットは複製中に折りたたまれます。
スペースが足りなくなってすべてのスナップショットを削除できない場合は、仮想マシンを別のデータストアに複製します（複製ウィザードで仮想ディスクごとに別の宛先を選択できます）。すべてのスナップショットがクローン仮想マシンにコミットされます。
データストアに十分なディスク容量がない場合、すべてのスナップショットを削除すると、ヘルパーのスナップショットが統合されます
また、これらのサーバーの操作の責任者には、必ずこれをお読みください。 （多くの場合、開発者です。）
このシナリオに巻き込まれ、このフォーラムを見つけた人は、チョッパーが間違っているため、すべての回答を読んでください-IT_Architectは正しいです。
ベースディスクへのスナップショットCLOSESTで始まるスナップショットを削除する必要があります。つまり、スナップショットマネージャウィンドウのリストの一番上にあるスナップショットを削除します。これにより、スナップショットの削除プロセス中の空き領域の必要性が最小限になります。
チョッパーの方法に従った場合、すべてのスナップショットを正常に削除するには、利用可能な大量の空き領域が必要になります。15の開いているスナップショットのチェーンを表示している場合は、おそらくありません。
考えてみてください...ベースディスクは最初のスナップショットファイルに格納されているため、ディスクの変更のみです。 2番目のスナップショットファイルには、最初のスナップショットファイル以降の変更が含まれています。 3番目のスナップショットには、2番目のスナップファイル以降の変更のみが含まれます。ベースディスクファイルは、割り当てられたサイズより大きくなることはありません。各スナップショットファイルは、ベースディスクと同じサイズまで大きくなる可能性があります。以下の例を参照
ベースディスク（100 GB）-snap1（5 GB）-snap2（3 GB）-snap3（15 GB）
Snap1に格納されているすべての変更されたディスクブロックは、ベースディスクに含まれています。これらのブロックは、スナップショットが開始されてから変更されているため、snap1ファイルに保存されます。
逆に、snap3ファイルは15 GBであり、そのすべての変更を小さい3GBのsnap2ファイルに含めることはできません。最初にsnap3スナップショットを削除すると、その変更はsnap2ファイルにマージされます。このプロセスの後、snap2の最小サイズは12 GBになる可能性があり、snap3ファイルの変更のうち3 GBがsnap2ファイルのまったく同じディスクブロックであると想定しています。これが最良のシナリオです。
さらに悪いことに、snap3スナップショットの削除中、snap3ファイルは、スナップショットが正常に削除されるまでデータストアに残ります。したがって、最良のシナリオは、snap3スナップショットを削除するために少なくとも12GBの追加ディスク領域を使用することです...しかし、おそらくそれ以上の容量が必要になります。
これがベースディスクに最も近いスナップショットの削除を開始する理由です（ベースディスクファイルが大きくなることはないためです（シンプロビジョニングされていなければ、それはワームの別の缶です）。