当出现问题时，我正在将file upload到ESXi 5主机上的数据存储。 我重新启动主机，但现在不能删除该文件。 （我把它改名为BADFILE）。 正如你从下面的命令中可以看到的，我做了所有正确的事情，但是不能删除它！ 有任何想法吗？
请注意，此文件位于ESXi主机上 – 不被VM guest虚拟机使用。 lsof显示没有使用该文件的进程。
/vmfs/volumes/4ed306ea-ac7ce83d-0559-001731f8a1de/ISO Images # touch BADFILE touch: BADFILE: Device or resource busy /vmfs/volumes/4ed306ea-ac7ce83d-0559-001731f8a1de/ISO Images # vmkfstools -D BADFILE Lock [type 10c00001 offset 10063872 v 215, hb offset 3579904 gen 133, mode 2, owner 00000000-00000000-0000-000000000000 mtime 480 num 1 gblnum 0 gblgen 0 gblbrk 0] RO Owner[0] HB Offset 3579904 511c5a3a-8cabaab1-ae4c-001731f8a1de Addr <4, 3, 170>, gen 206, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 3695179776, nb 441 tbz 0, cow 0, newSinceEpoch 441, zla 3, bs 8388608 /vmfs/volumes/4ed306ea-ac7ce83d-0559-001731f8a1de/ISO Images # tail /var/log/vmkernel.log len 3695179776, nb 441 tbz 0, cow 0, newSinceEpoch 441 zla 3, bs 8388608 2013-02-14T04:15:13.635Z cpu0:5826)FS3: 173: <END BADFILE> 2013-02-14T04:16:57.856Z cpu0:2105)FS3Misc: 1465: Long VMFS rsv time on 'MIRROR1' (held for 331 msecs). # R: 1, # W: 1 bytesXfer: 2 sectors 2013-02-14T04:23:34.691Z cpu1:6190)FS3: 171: <START BADFILE> 2013-02-14T04:23:34.691Z cpu1:6190)Lock [type 10c00001 offset 10063872 v 215, hb offset 3579904 gen 133, mode 2, owner 00000000-00000000-0000-000000000000 mtime 480 num 1 gblnum 0 gblgen 0 gblbrk 0] 2013-02-14T04:23:34.692Z cpu1:6190)Addr <4, 3, 170>, gen 206, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600 len 3695179776, nb 441 tbz 0, cow 0, newSinceEpoch 441 zla 3, bs 8388608 2013-02-14T04:23:34.692Z cpu1:6190)FS3: 173: <END BADFILE> /vmfs/volumes/4ed306ea-ac7ce83d-0559-001731f8a1de/ISO Images # lsof | grep BADFILE /vmfs/volumes/4ed306ea-ac7ce83d-0559-001731f8a1de/ISO Images # vmkvsitools lsof | grep BADFILE /vmfs/volumes/4ed306ea-ac7ce83d-0559-001731f8a1de/ISO Images # ls BADFILE Windows_Server_2012_x64.iso /vmfs/volumes/4ed306ea-ac7ce83d-0559-001731f8a1de/ISO Images # rm -f BADFILE rm: can't remove 'BADFILE': Device or resource busy 该文件可能被单个虚拟机locking。 作为一个.ISO文件，它可能是连接到正在运行的虚拟机之一吗？
你通过进入维护模式解决了这个问题（因此closures了所有正在运行的虚拟机）。 通过打开虚拟机的设置并从CDROM设备字段中删除.ISO，也可以在没有停机的情况下完成同样的任务。
该文件被locking，你必须尝试释放锁。 vmkernel日志表明所有者标识符的MAC地址全部为零，即mtime前面的最后12个零。
gen 133, mode 2, owner 00000000-00000000-0000-000000000000 mtime 480
根据调查ESXi / ESX上的虚拟机文件locking（10051） ：
如果所有者标识符全部为零，则可能是基于服务控制台的锁，NFS锁或由可以使用或读取VMFS文件系统的其他系统或产品生成的锁，虚拟机。
在这种情况下，您可以尝试重新启动pipe理代理。 这样做的一个方法是：
./sbin/services.sh restart
我终于把服务器置于维护模式，然后可以删除它。