私は、VMware ESXi 上で実行されている Windows 2008 R2 X64 サーバーを持っています。元々は Hyper-V 上で実行されていましたが、その後、VHD を VMDK に変換し、ESXi に移行しました。また、VMware Tools もインストールしました。このサーバーは、TeamCity 継続的インテグレーション サーバーで、会社が開発するソフトウェア パッケージの夜間ビルドを実行しています。移行後、ビルド プロセスで削除する必要がある特定のファイルが、「ファイルは別のプロセスで使用中です」という理由で削除に失敗することがあります。CMD del コマンドを使用してファイルを削除しようとしています。うまくいくときもあれば、うまくいかないときもあります。失敗が発生したディレクトリのパスを PATH フィルターとして (PATH に C:\work が含まれています)、プロセス モニターを起動しました。vmtoolsd.exe の Createfile、FileSystemControl、および CloseFile 操作が、次々と繰り返し発生しているのがわかります。Windows ゲストでファイルシステムがロックされる原因が VMware ツールにあるという話を聞いたことがありますか?
実際に発生したときに procmon でキャプチャすることはまだできていませんが、試してみるつもりです。
また、容量不足のため、このディレクトリ C:\work は、名前を C:\work-old に変更し、2 番目の仮想ディスク E:\ を追加し、ディスクをディレクトリ C:\work にマウントし、C:\work-old の内容を新しくマウントした C:\work にコピーすることで再作成されました。VMware Tools が C:\work で FSCTL_Get_Reparse_Point を継続的に実行していることがわかります。
アップデート： 昨夜 VMware ツール サービスを無効にしましたが、それでも同じことが起こりました。C:\work ディレクトリ (実際には E: ドライブが C:\work にディレクトリとしてマウントされている共有) が 2 つのリモート ホストから同時にアクセスされており、これが最初のホストによるディレクトリのロックを引き起こしていると考えられます。E: を work ディレクトリにマウントする前は、このようなことは起こりませんでした。ファイル ロックとディレクトリとしてマウントされたボリュームに関する既知の問題はありますか?
答え1
結局、この問題は VMware Tools が原因ではなかったことが判明しました。Windows Application Experience サービスが原因である可能性が高いのですが、確信はありません。最終的には、仮想ディスクを追加して新しい共有を作成し、ビルドがこの共有を参照するように指定することで問題を解決しました。ビルド ステップでこの共有のハンドルが開いたままになっても、その共有を再度参照しない後続のステップには影響しません (以前はすべてが同じ共有から実行されていたため、ハンドルが開いているとファイル操作は失敗していました)。