VM起動時にスタック-スナップショットが存在していてもCTKファイルを削除しますか？
私は、予期しない電源障害の後に、VM（最も重要なもの）...）が起動時にスタックしたVMWare 6.5クラスターをリカバリするタスクを担当しています。
から vmware.logファイル、問題は破損したCTKファイルに関連しているようです。 this vmware KB で読んだように、影響を受けたCTKファイルを削除するだけで十分なはずです（実際にはsoシンプルですが、十分シンプルです...）
ただし、影響を受けるVMにはいくつかのスナップショットがアクティブであり、 another（older）KB で読んだように、このような手順はスナップショットが存在する場合に試行されます。
VMを解放し、起動プロセスを完了するための正しいパス/手順は何ですか？
この場合、解決策は最も単純で奇妙なものでした。夜を待つことです。数時間後、VM "unstuck"と正しく起動しました。
変更追跡ファイル（CTK）の質問については、スペアのVMWareハイパーバイザーを使用して問題をシミュレートし、VMWareの独自のドキュメントを読んだ後（詳細はかなりわかります...）重要な点はあなたcanは、仮想マシンにアクティブなスナップショットがある場合でもCTKファイルを削除しますが、そのような変更により、後続のCTK対応のバックアップが破損する可能性があります。そのため、このような場合は、VMとディスクレベルでCTKを無効にし、スナップショットを統合し、フルバックアップを実行し、CTKを再度有効にする必要があります（両方ともVMおよびディスクレベル）、増分バックアップを再度有効にします。
CTKを無効にすると、最後のCTKファイルのみに影響があるように見えます（注：各VMDKフラットファイルとデルタファイルにCTKファイルが存在するため、各スナップショットが新しいCTKファイルをコマンドします）。これが、VMWareがスナップショットを持たないときに推奨される理由です。ブロック変更追跡の有効化/無効化。 ここ から：
注：変更の追跡を有効にする前に、仮想マシンにスナップショットがないことを確認してください。 CBTを有効にする前にスナップショットを作成すると、QueryChangedDiskAreas APIがエラーを返さなかったり、QueryChangedDiskAreasから返されたデータが正しくなかったりすることがあります。