I have a Windows 2008 R2 X64 server running on Vmware ESXi. Originally it was running on Hyper-V, but I have since converted the VHD to a VMDK and migrated to ESXi. I also installed VMware Tools. This server is our TeamCity continuous integration server, performing nightly builds of software packages that my company develops. Since the move, occasionally certain files that the build process should delete fail to delete due to "The file is in use by another process". We are trying to delete the files using the CMD del command. Sometimes it works, others not. I fired up process monitor with the path of the directory where failures occur as the PATH filter (PATH contains C:\work ). I see a LOT of vmtoolsd.exe Createfile, FileSystemControl, and CloseFile operations occurring in quick succession, repeatedly. Has anyone heard of Vmware tools causing filesystem locks on Windows guests?
I have not been able to capture it with procmon when it actually happens yet, but I plan to try.
Also, due to running out of space, this directory C:\work, was recreated by renaming it to C:\work-old, adding a second virtual disk E:\, and mounting the disk to the directory C:\work , then copying the contents of C:\work-old to the newly mounted C:\work. I see Vmware Tools is constantly performing FSCTL_Get_Reparse_Point on C:\work.
UPDATE:
I disabled the VMware tools service last night and it still happened. I believe the C:\work directory, which is a share that is actually the E: drive mounted as a directory to C:\work is being accessed by 2 remote hosts simultaneously and perhaps this is causing a lock on the directory by the first host. This did not used to happen before I mounted the E: to the work directory,, Are there any known issues with file locking and volumes mounted as directories?
Best Answer
It turns out that the problem was not caused by VMware Tools. It is more likely that the windows Application Experience service caused this issue, but I am not positive. I ultimately resolved the issue by adding a virtual disk and creating a new share, then pointing the build to look to this share. If the build step leaves an open handle for this share, it wont affect the subsequent step which does not refer to that share again (previously everything was done from the same share, so if there was an open handle, file operations would fail).