I was recently playing around with vmkfstools, checking out a few things for one of our storage partners. I noticed that I was using some undocumented options to look at a few things, and thought I would share them with you here.
1. Display hosts which are actively using a volume
~ # vmkfstools –activehosts /vmfs/volumes/VNX-20
Found 1 actively heartbeating hosts on volume '/vmfs/volumes/VNX-20'
(1): MAC address 98:4b:e1:0a:24:d8
This option will show the management interface MAC address of any hosts which is actively using a datastore. This is exactly what vSphere HA uses to see if a host is still active. It walks through the heartbeat records on the VMFS and checks which are active. This might take a few moments to run as it has to wait for the heartbeat record to age and refresh. It then it displays the MAC address of the owner.
2. Display File Metadata, including Lock Information
~ # vmkfstools -D /vmfs/volumes/VNX-20/COR-XP-PRO/COR-XP-PRO.vmdk
Lock [type 10c00001 offset 236560384 v 44, hb offset 4091904
gen 6155, mode 0, owner 00000000-00000000-0000-000000000000 mtime 23668 nHld 0 n Ovf 0]
Addr <4, 558, 4>, gen 6, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 492, nb 0 tbz 0, cow 0, newSinceEpoch 0, zla 4305, bs 8192
Note that when you run this command, the information is also captured in the vmkernel.log. In fact, the vm-support log utility will run this command to capture this information in the log bundle:
~ # tail -f /var/log/vmkernel.log
2012-07-31T10:05:00.366Z cpu6:5140275)FS3: 171: <START COR-XP-PRO.vmdk>
2012-07-31T10:05:00.366Z cpu6:5140275)Lock [type 10c00001 offset 236560384 v 44, hb offset 4091904 gen 6155, mode 0, owner 00000000-00000000-0000-000000000000 mtime 23668 nHld 0 nOvf 0]
2012-07-31T10:05:00.366Z cpu6:5140275)Addr <4, 558, 4>, gen 6, links 1, type reg, flags 0×0, uid 0, gid 0, mode 600 len 492, nb 0 tbz 0, cow 0, newSinceEpoch 0 zla 4305, bs 8192
2012-07-31T10:05:00.366Z cpu6:5140275)FS3: 173: <END COR-XP-PRO.vmdk>
The owner field would again display the MAC address of the lock owner. All 0's in the owner field implies that the host which ran the vmkfstools command owns the lock. The mtime field gives you an indication on whether the lock is getting updated or not.
3. VMDK Block Mappings
This command is very useful for displaying the mappings of VMFS file blocks to a VMDK. It can also be used to display the layout of a VMDK if you are concerned that a thin provisioned VMDK might be fragmented from a block allocation perspective.
~ # vmkfstools -t0 /vmfs/volumes/VNX-20/COR-XP-PRO/COR-XP-PRO.vmdk
Mapping for file /vmfs/volumes/VNX-20/COR-XP-PRO/COR-XP-PRO.vmdk (21474836480 bytes in size):
[0: 157286400] –> [VMFS -- LVID:4f438ba4-a4d98058-16d5-984be10a24d8/4f438ba3-53edb654-b1b1-984be10a24d8/1:(33206304768 --> 33363591168)]
[157286400: 51380224] –> [VMFS -- LVID:4f438ba4-a4d98058-16d5-984be10a24d8/4f438ba3-53edb654-b1b1-984be10a24d8/1:(33153875968 --> 33205256192)]
[208666624: 21266169856] –> [VMFS -- LVID:4f438ba4-a4d98058-16d5-984be10a24d8/4f438ba3-53edb654-b1b1-984be10a24d8/1:(33363591168 --> 54629761024)]
The first set of numbers are the VMDK block mappings, and the second set of numbers at the end of the line are VMFS block mappings. In my setup, even though the range of VMFS blocks seem contiguous, they map to the VMDK in a different order:
- VMDK chunk 0 -> VMFS chunk 1 (150MB)
- VMDK chunk 1 -> VMFS chunk 0 (49MB)
- VMDK chunk 2 -> VMFS chunk 2 (~2TB)
The double dashes between the VMFS & LVID represent features of the VMDK. For example, an upper-case Z represents a lazy zeroed VMDK chunk, and an R would represent a read-only chunk. The long numbers following LVID represent the Device UUID and the VMFS UUID respectively. The /1 is the snapshot ID and is incremented when the volume is resignatured.
The VMFS UUIID can also be observed using the esxcli storage vmfs extent list command which shows both the VMFS UUID and NAA ID (SCSI identifier).
The -t0 option can only be pointed at VMDK files. To look at attributes of other files on a VMFS volume, the -p0 option can be used.
4. Display VMFS File Block Details
~ # vmkfstools -P -v10 /vmfs/volumes/VNX-20
VMFS-5.54 file system spanning 1 partitions.
File system label (if any): VNX-20
Mode: public
Capacity 209648091136 (199936 file blocks * 1048576), 88965382144 (84844 blocks) avail
Volume Creation Time: Tue Feb 21 12:18:44 2012
Files (max/free): 130000/129954
Ptr Blocks (max/free): 64512/64379
Sub Blocks (max/free): 32000/31994
Secondary Ptr Blocks (max/free): 256/256
File Blocks (overcommit/used/overcommit %): 0/115092/0
Ptr Blocks (overcommit/used/overcommit %): 0/133/0
Sub Blocks (overcommit/used/overcommit %): 0/6/0
UUID: 4f438ba4-018084e0-11a1-984be10a24d8
Partitions spanned (on "lvm"):
naa.6006048cb898fa77617c749e6aef2e5b:1
DISKLIB-LIB : Getting VAAI support status for /vmfs/volumes/VNX-20
Is Native Snapshot Capable: NO
~ #
This is a useful command to see how many file, pointer and sub-blocks on a VMFS are available and consumed. It is also a nice way to get VMFS version and extent count information as well as the file block size. Although this is now 1MB (1048576) in newly created VMFS-5, it could be 1,2,4 or 8MB in VMFS-3 or VMFS-5 upgraded from VMFS-3.
Useful options – I'm not sure why we hide them.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage

Thanks, I tried this and I noticed only the last section of the owner part gives the mac address.
what does the rest of it mean?
My test is below
http://sparrowangelstechnology.blogspot.com/2012/08/esxi-find-which-host-has-lock-on-file.html
Hi there,
concerning point 2. (-D switch) I’m a bit confused, because while testing in a 4.1 environment the owner field is always “00000000-00000000-0000-000000000000″ regardless on which host I am running the command on.
An ideas, what could be the reason?
I’m running HP blades in an HA/DRS-cluster.
tia
Tia,
I noticed that unless the host has a lock on the file, you will get 00000000-00000000-0000-000000000000.
That is because when you run the command, the host you run the command on then locks that file.
If you run the -D on all the files in a dir, you will find one that is locked.
Sparrow, unfortunately much of the output will not make much sense without a deep understanding of VMFS metadata and layout, and that is not something I can share.
The interesting part is the lock, and thank you for replying to Tia in the previous post – you are correct. If no-one has a lock on the file, then the host which runs the command will lock it which is why you see that list of zeros.
Hello Cormac
Is there a way to acquire the info we get via vmkfstools -t0 when the VMFS headers are damaged ? – at the moment I can only recover unfragmented vmdks when the VMFS headers are damaged but with this details we could reassemble vmdks from several chunks – which would be very useful.
Thanks Ulli
Hi Ulli, I don’t believe so. I think we did something in the past to save off this mapping info via a cron job, but it wasn’t carried into later releases.
Can I run the vmkfstools -t0 command against a dd-dump of the first 1.5 Gb of a VMFS-volume ?
That would be very useful
Ulli
Hi Cormac,
I tried out the –activehosts option on a test machine (v4.1 – 348481) of mine for the local datastore and curiously I received the MAC ID of the vmnic1. This NIC incidentally is not even connected and the management NIC is vmnic0. However, they are both connected to the same vSwitch.
I removed vmnic1 from the switch and ran the command again and received the same output. Could provide some insight?