Tengo un servidor Windows 2008 R2 X64 ejecutándose en Vmware ESXi. Originalmente se ejecutaba en Hyper-V, pero desde entonces convertí el VHD a un VMDK y migré a ESXi. También instalé VMware Tools. Este servidor es nuestro servidor de integración continua de TeamCity, que realiza compilaciones nocturnas de paquetes de software que desarrolla mi empresa. Desde la mudanza, ocasionalmente ciertos archivos que el proceso de compilación debería eliminar no se eliminan debido a que "el archivo está siendo utilizado por otro proceso". Estamos intentando eliminar los archivos usando el comando CMD del. A veces funciona, otras no. Encendí el monitor de procesos con la ruta del directorio donde ocurren las fallas como filtro PATH (PATH contiene C:\work ). Veo MUCHAS operaciones vmtoolsd.exe Createfile, FileSystemControl y CloseFile que ocurren en rápida sucesión, repetidamente. ¿Alguien ha oído hablar de las herramientas de Vmware que provocan bloqueos del sistema de archivos en los invitados de Windows?
Todavía no he podido capturarlo con procmon cuando realmente sucede, pero planeo intentarlo.
Además, debido a que se quedó sin espacio, este directorio C:\work se volvió a crear renombrándolo a C:\work-old, agregando un segundo disco virtual E:\ y montando el disco en el directorio C:\work. luego copie el contenido de C:\work-old al C:\work recién montado. Veo que Vmware Tools realiza constantemente FSCTL_Get_Reparse_Point en C:\work.
ACTUALIZAR: Anoche desactivé el servicio de herramientas VMware y aún así sucedió. Creo que 2 hosts remotos acceden al directorio C:\work, que es un recurso compartido que en realidad es la unidad E: montada como directorio en C:\work simultáneamente y tal vez esto esté provocando un bloqueo en el directorio por parte del primero. anfitrión. Esto no solía suceder antes de montar el E: en el directorio de trabajo. ¿Hay algún problema conocido con el bloqueo de archivos y los volúmenes montados como directorios?
Respuesta1
Resulta que el problema no fue causado por VMware Tools. Es más probable que el servicio Windows Application Experience haya causado este problema, pero no estoy seguro. Finalmente resolví el problema agregando un disco virtual y creando un nuevo recurso compartido, luego señalé la compilación para buscar este recurso compartido. Si el paso de compilación deja un identificador abierto para este recurso compartido, no afectará el paso posterior que no hace referencia a ese recurso compartido nuevamente (anteriormente todo se hacía desde el mismo recurso compartido, por lo que si había un identificador abierto, las operaciones con archivos fallarían).