glandium / vmfs-tools Goto Github PK

I am working on investigating whether it is possible to apply "debugvmfs" on vmfs-6. I found lots of on-disk structures are enlarged from 512B to 4096 or even 8192B.

However, I cannot figure out how to parse the on-disk data of the vmfs6' dirent. The on-disk data is supposed to be a sequence of vmfs_dirent_raw structures. It is true in vmfs5 but not int vmfs6!!!

For example, as shown below, the size of each vmfs_direct_raw is 0x8c bytes. So, the first 8c bytes describe the vmfs_direct_raw structure of the file "." and then the next 8c bytes describe that of the file "..". Then, the third 8c bytes describe that of the file "fbb.sf".

However, in vmfs6, the byte to describe the vmfs_direct_raw of the file "." starts from 0x3b8th. And, it is more difficult to figure out that lots of zero bytes are filled between the vmfs_direct_raw of file ".." and the vmfs_direct_raw of file "fbb.sf"!!!! (btw, i guess the size of the direct in vmfs6 is enlarged to 0x120 from 0x8c)

Does anyone have the idea to hack the data structure?

"vmfs 5"
01600000 02 00 00 00 04 00 00 00 01 00 00 00 2e 00 00 00 |................|
01600010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600080 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 |................|
01600090 04 00 00 00 01 00 00 00 2e 2e 00 00 00 00 00 00 |................|
016000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
016000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
016000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
016000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
016000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
016000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600110 00 00 00 00 00 00 00 00 05 00 00 00 04 00 40 00 |..............@.|
01600120 01 00 00 00 2e 66 62 62 2e 73 66 00 00 00 00 00 |.....fbb.sf.....|
01600130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01600190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
016001a0 00 00 00 00

"vmfs6"
01900000 01 00 f5 00 0a 00 00 00 0a 00 00 00 01 00 00 00 |................|
01900010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
........(all zero).....
019003b0 00 00 00 00 00 00 00 00 02 00 00 00 04 00 00 00 |................|
019003c0 01 00 00 00 00 00 00 00 b8 03 00 00 00 00 00 00 |................|
019003d0 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019003e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019004a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019004c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019004d0 00 00 00 00 00 00 00 00 02 00 00 00 04 00 00 00 |................|
019004e0 01 00 00 00 00 00 00 00 d8 04 00 00 00 00 00 00 |................|
019004f0 2e 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01900500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
.............(lots of zero and then lots of 88)
01910fd0 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 |................|
01910fe0 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 |................|
01910ff0 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 |................|
01911000 01 00 01 00 0e 00 06 00 00 3f 00 00 00 00 00 00 |.........?......|
01911010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
(the direct of "fbb.sf" starts here)
01911040 05 00 00 00 04 00 40 00 01 00 00 00 00 00 00 00 |......@.........|
01911050 40 10 01 00 00 00 00 00 2e 66 62 62 2e 73 66 00 |@........fbb.sf.|
01911060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019110a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019110b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019110c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019110d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019110e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
019110f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
01911150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

In testing I ran into a crash in vmfs-fuse (the 0.2.5 version) when mounting a volume with some linked clone VMs on it. I have a patch below, and can submit a pull request if you like, but since this project doesn't seem active I wanted to check here fist. The backtrace from the core was this:

(gdb) bt
#0 vmfs_inode_get_block (inode=0x60d8c0, pos=0, blk_id=0x7fffb322a3fc) at libvmfs/vmfs_inode.c:314
#1 0x0000000000404609 in vmfs_file_pread (f=0x60dda0, buf=0x7fffb322a600 "", len=512, pos=0)

at libvmfs/vmfs_file.c:149
#2 0x0000000000402a23 in vmfs_bitmap_open_from_file (f=0x60dda0) at libvmfs/vmfs_bitmap.c:521
#3 0x0000000000404ee2 in vmfs_open_all_meta_files (fs=0x60c380) at libvmfs/vmfs_fs.c:124
#4 vmfs_read_fdc_base (fs=0x60c380) at libvmfs/vmfs_fs.c:187
#5 0x0000000000405355 in vmfs_fs_open (paths=Unhandled dwarf expression opcode 0xf3

) at libvmfs/vmfs_fs.c:255
#6 0x0000000000401999 in main (argc=Unhandled dwarf expression opcode 0xf3

) at vmfs-fuse/vmfs-fuse.c:498

The crash was caused by this line in vmfs_inode.c:
DECL_ALIGNED_BUFFER_WOL(buf,fs->pbc->bmh.data_size);

buf.fs->pbc is null here, because the init code is reading the FBB file - it hasn't processed the PBC file yet. The following patch will fix the problem by reorganizing the code to read the PBC file first. This doesn't seem to cause any other problems.

diff --git a/libvmfs/vmfs_fs.c b/libvmfs/vmfs_fs.c
index f355526..36750fb 100644
--- a/libvmfs/vmfs_fs.c
+++ b/libvmfs/vmfs_fs.c
@@ -121,6 +121,14 @@ static int vmfs_open_all_meta_files(vmfs_fs_t *fs)
       return(-1);
    }

+   /* Read pbc first, because FBB may have blocks in it that will require access
+      to the pbc to read. */
+   fs->pbc = vmfs_open_meta_file(root_dir, VMFS_PBC_FILENAME,
+                                 VMFS_BLK_PB_MAX_ITEM, VMFS_BLK_PB_MAX_ENTRY,
+                                 "pointer block bitmap (PBC)");
+   if (!fs->pbc)
+      return(-1);
+
    if (!(fs->fbb = vmfs_bitmap_open_at(root_dir,VMFS_FBB_FILENAME))) {
       fprintf(stderr,"Unable to open file-block bitmap (FBB).\n");
       return(-1);
@@ -136,12 +144,6 @@ static int vmfs_open_all_meta_files(vmfs_fs_t *fs)
    if (!fs->fdc)
       return(-1);

-   fs->pbc = vmfs_open_meta_file(root_dir, VMFS_PBC_FILENAME,
-                                 VMFS_BLK_PB_MAX_ITEM, VMFS_BLK_PB_MAX_ENTRY,
-                                 "pointer block bitmap (PBC)");
-   if (!fs->pbc)
-      return(-1);
-
    fs->sbc = vmfs_open_meta_file(root_dir, VMFS_SBC_FILENAME,
                                  VMFS_BLK_SB_MAX_ITEM, VMFS_BLK_SB_MAX_ENTRY,
                                  "pointer block bitmap (PBC)");

Hi There,

I'm using VMFS-FUSE (direct from github) to mount a VMFS 5 volume (5.54 according to VMware) over iscsi.

For some reason the large files (vmdks) can't be read and seem to have an unknown size:
'''
drwxr-xr-x 2 root root 1400 2011-11-04 10:03 .
drwxr-xr-t 10 root root 2240 2011-11-15 11:28 ..
-????????? ? ? ? ? ? ns1-flat.vmdk
-rw------- 1 root root 8684 2011-11-04 10:04 ns1.nvram
-rw------- 1 root root 609 2011-11-04 10:05 ns1.vmdk
-rw-r--r-- 1 root root 0 2011-11-01 13:15 ns1.vmsd
-rwxr-xr-x 1 root root 3071 2011-11-04 10:04 ns1.vmx
-rw-r--r-- 1 root root 258 2011-11-01 13:15 ns1.vmxf
-rw-r--r-- 1 root root 73176 2011-11-04 10:14 vmware.log
-rw------- 1 root root 59768832 2011-11-04 10:03 vmx-ns1-1992708965-1.vswp
'''

If I try output the inode information I get nothing, however displaying other file info works fine:
'''
root@Ubuntu:/mnt/ns1# debugvmfs /dev/sdc1 show 'inode["ns1/ns1-flat.vmdk"]'
root@Ubuntu:/mnt/ns1# debugvmfs /dev/sdc1 show 'inode["ns1/ns1.vmdk"]'
ID: 0x5808a44
ID2: 0x19
Links: 1
Type: 3
Flags: 0
Size: 609
Block size: 8 KiB
Block count: 0
UID: 0
GID: 0
Mode: 0600 (-rw-------)
ZLA: 4305
TBZ: 0
COW: 0
Access Time: 2011-11-04 10:05:17
Modify Time: 2011-11-04 10:05:17
Change Time: 2011-11-01 13:29:22
RDM ID: 0x0
'''

I then thought maybe it was because the VM was still running (I'm mounting a snapshot), so tried looking at another VM that was powered off and that worked, but wasn't conclusive as I then tried a 3rd VM that was powered off, but when I tried to ls the folder it displayed a completely different VMs folder.

'''
root@Ubuntu:/mnt# cd delila-debian/
root@Ubuntu:/mnt/delila-debian# ls
ls: cannot access ns1-flat.vmdk: No such file or directory
ns1-flat.vmdk ns1.vmdk ns1.vmsd ns1.vmx ns1.vmxf vmx-ns1-1992708965-1.vswp
'''
(As you can see its displaying ns1's folder instead of delila-debian)

I then tried a 4th vm (delila) and doing an ls in that folder started printing the contents of the vmx file, instead of the directory.

More dumps
'''
root@Ubuntu:/mnt# debugvmfs /dev/sdc1 show 'inode["delila-debian"]'
ID: 0x24c08a44
ID2: 0xaf
Links: 2
Type: 2
Flags: 0
Size: 1.09 KiB
Block size: 8 KiB
Block count: 1
UID: 0
GID: 0
Mode: 0755 (-rwxr-xr-x)
ZLA: 2
TBZ: 0
COW: 0
Access Time: 2011-11-15 11:18:48
Modify Time: 2011-11-15 11:18:48
Change Time: 2011-11-15 11:18:48
RDM ID: 0x0
root@Ubuntu:/mnt# debugvmfs /dev/sdc1 show 'inode["delila"]'
ID: 0x25008a44
ID2: 0xb0
Links: 2
Type: 2
Flags: 0
Size: 1.37 KiB
Block size: 8 KiB
Block count: 1
UID: 0
GID: 0
Mode: 0755 (-rwxr-xr-x)
ZLA: 2
TBZ: 0
COW: 0
Access Time: 2011-11-15 11:41:21
Modify Time: 2011-11-15 11:41:21
Change Time: 2011-11-15 11:41:21
RDM ID: 0x0
root@Ubuntu:/mnt#
'''

fsck.vmfs complains about file blocks lost, when they aren't.

Hi,

We are clonezilla/partclone developer, and try to use library of vmfs to clone full vmfs partition. Basically, partclone will check bitmap and find all used block which will be backup.
Lately, we found some (vmfs5) clone/restore failure, and try to do more debug. I found a strange result of df from debugvmfs and esxi :

ESXi:
~ # df
Filesystem Bytes Used Available Use% Mounted on
VMFS-5 37580963840 3346006016 34234957824 9% /vmfs/volumes/datastore1
df -m
Filesystem 1M-blocks Used Available Use% Mounted on
VMFS-5 35840 3191 32649 9% /vmfs/volumes/datastore1

vmfs-tools/debugvmfs
./debugvmfs/debugvmfs /dev/sdb3 df
Block size : 1048576 bytes
Total blocks : 35840
Total size : 35840 MiB
Allocated blocks : 2990
Allocated space : 2990 MiB
Free blocks : 32850
Free size : 32850 MiB

The df show me total block(35840) is right, but Allocated blocks/space are different(3191>2990)!

Partclone based on vmfs-tools, and only backup 2990 blocks, so get clone/restore failure. We try to follow vmfs-fsck .c and debugvmfs.c to dump all blk_id, position and size from bitmap (fbb, fdc, pbc and sbc), still get same result.

We are confuse for the situation, could you check why they are different?

I also do some study from VMware KB and found the new bitmap file named .pb2.sf, it is...

• new PB2 system file, for double indirect PB file capability
  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004223
  I don't know it's same issue or not, but i can't check any function about pb2 from vmfs-tools.
  please help to found really problem, thank you.

Hello,

i'm trying to mount some vmfs datastores via vmfs-fuse on a FreeBSD 10 box. Exactly the same datastores work fine under CentOS 6, but on FreeBSD I get this:

# vmfs-fuse  /dev/da29s1 /datastores/lhstor11
VMFS: Unable to read FS information
Unable to open filesystem

But when I use debugvmfs to list files, for example, it outputs the expected list of files:

# debugvmfs /dev/da29s1 ls
.
..
.fbb.sf
.fdc.sf
.pbc.sf
.sbc.sf
.vh.sf
.vSphere-HA
[...]
aims-bbp-001
FOM
geoc-ags3

The binaries compiled fine with clang, but I also tried with gcc, with the same result. Maybe someone can give me a push in the right direction?

Cheers, J.

Since my .vmdk-files where created with thin provisioning, they are stored as sparse files. When I try to use tar with the --sparse option on a filesystem mounted with vmfs-fuse, the compression is impressive - but not realistic. A 100Gb virtual disk (containing about 2.2 Gb data) resulted in a tar file of 10240 bytes, and that is without gzip compression...
I now realize that "du" reports that the files uses 0 bytes on disk. If I use tar without the "--sparse" option, tar works fine but takes a very long time since it has to read the whole 100Gb and compress it to reduce the size of all those zeros.
Is this a known problem?

I am using vmfs-tools 0.2.1-1 on a ubuntu 11.10 rescue remix.

I have been trolling for a user forum for making a post on this but did not find anything (active). As such maybe you can point me in the correct direction, or provide some ideas….

We have a lab, one of the more junior admins had a vSphere 4 farm. Took a vmfs v3 volume, single 300GB partition, and extended it via the iSCSI SAN controller to 2TB. This of course orphaned the vSphere 4 hosts from mounting the volume. I am trying to recover the data off the volume and move it onto a new VMFS 5 volume (had him upgrade his systems to vSphere 5). I was able to recover the first VM, but subsequent VMs have certain files which will not copy. The shell seems to “hang” with zero bytes transferred.

Steps:

1. Ubuntu VM with two virtual disks. One OS, One mounted for repository which will later be exported as NFS for the vSPhere 5 systems to mount.
2. Mount original vmfs3 volume via iSCSI and run a basic cp command to transfer the files from the vmfs3 volume to the local formatted virtual disk which is exported via NFS.
3. Via network, transfer from “NFS” volume that the new vSphere host mounts, to the new VMFS5 volume.

root@ubuntu12:/home/ibm/vmfs-tools-0.2.5# dpkg -s vmfs-tools
Package: vmfs-tools
Status: install ok installed
Priority: extra
Section: otherosfs
Installed-Size: 232
Maintainer: Ubuntu Developers [email protected]
Architecture: amd64
Version: 0.2.1-1
Depends: libc6 (>= 2.7), libfuse2 (>= 2.8.1), libuuid1 (>= 2.16)
Description: Tools to access VMFS filesystems
VMFS is a clustered filesystem designed to store virtual machine disks for
VMware ESX or ESXi Server hosts. This set of tools allows to access these
filesystems from some other non ESX/ESXi host for e.g. maintenance tasks.
.
Only read access is available at the moment, but write access is under
works. Multiple extents are supported.
.
The VMFS can be accessed with a command line tool or mounted through a
userspace filesystem (FUSE-based).
Original-Maintainer: Mike Hommey [email protected]
root@ubuntu12:/home/ibm/vmfs-tools-0.2.5# mount
…
/dev/fuse on /media/vmfs type fuse (rw,nosuid,nodev,default_permissions)
/dev/sdb1 on /media/floppy0 type ext3 (rw)

root@ubuntu12:/home/ibm/vmfs-tools-0.2.5# exportfs
/media/floppy0 .
root@ubuntu12:/home/ibm/vmfs-tools-0.2.5# ls -alh /media/vmfs/hpdc02/
total 0
drwxr-xr-x 2 root root 2.8K Mar 8 13:50 .
drwxr-xr-t 36 root root 5.7K Jun 29 11:10 ..
-rw------- 1 root root 2.2G Jul 7 19:46 hpdc02-000001-delta.vmdk
-rw------- 1 root root 321 Feb 8 2012 hpdc02-000001.vmdk
-rw-r--r-- 1 root root 37 Mar 8 13:50 hpdc02-606787e8.hlog
-rw------- 1 root root 4.0G Jul 7 15:46 hpdc02-606787e8.vswp
-rw------- 1 root root 35G Feb 8 2012 hpdc02-flat.vmdk
-rw------- 1 root root 8.5K Apr 26 10:15 hpdc02.nvram
-rw------- 1 root root 4.1G Feb 8 2012 hpdc02-Snapshot1.vmsn
-rw------- 1 root root 522 Dec 17 2010 hpdc02.vmdk
-rw-r--r-- 1 root root 422 Feb 8 2012 hpdc02.vmsd
-rwxr-xr-x 1 root root 3.2K May 4 10:59 hpdc02.vmx
-rw-r--r-- 1 root root 261 Dec 28 2011 hpdc02.vmxf
-rw-r--r-- 1 root root 137K Jul 11 2011 vmware-30.log
-rw-r--r-- 1 root root 60K Jul 11 2011 vmware-31.log
-rw-r--r-- 1 root root 130K Aug 23 2011 vmware-32.log
-rw-r--r-- 1 root root 128K Oct 11 2011 vmware-33.log
-rw-r--r-- 1 root root 128K Dec 5 2011 vmware-34.log
-rw-r--r-- 1 root root 324K Mar 2 14:33 vmware-35.log
-rw-r--r-- 1 root root 205K May 11 11:31 vmware.log
root@ubuntu12:/home/ibm/vmfs-tools-0.2.5# ls -alh /media/floppy0/hpdc02/
total 14G
drwx------ 2 root root 4.0K Aug 23 13:29 .
drwxr-xr-x 6 root root 4.0K Aug 30 11:20 ..
-rw------- 1 root root 0 Aug 23 11:59 hpdc02-000001-delta.vmdk
-rw------- 1 root root 321 Feb 8 2012 hpdc02-000001.vmdk
-rw-r--r-- 1 root root 37 Mar 8 13:50 hpdc02-606787e8.hlog
-rw------- 1 root root 128K Aug 23 12:59 hpdc02-606787e8.vswp
-rw------- 1 root root 35G Feb 8 2012 hpdc02-flat.vmdk
-rw------- 1 root root 8.5K Apr 26 10:15 hpdc02.nvram
-rw------- 1 root root 0 Aug 23 13:23 hpdc02-Snapshot1.vmsn
-rw------- 1 root root 522 Dec 17 2010 hpdc02.vmdk
-rw-r--r-- 1 root root 422 Feb 8 2012 hpdc02.vmsd
-rwxr-xr-x 1 root root 3.2K May 4 10:59 hpdc02.vmx
-rw-r--r-- 1 root root 261 Dec 28 2011 hpdc02.vmxf
-rw------- 1 root root 0 Aug 23 13:29 vmware.log
root@ubuntu12:/home/ibm/vmfs-tools-0.2.5#
root@ubuntu12:/home/ibm/vmfs-tools-0.2.5# cd /media/
root@ubuntu12:/media# ls
cdrom floppy0 hp nfs vmfs
root@ubuntu12:/media# chmod 770 /media/vmfs/hpdc02/vmware.log
root@ubuntu12:/media# ls -alh /media/vmfs/hpdc02/vmware.log
-rw-r--r-- 1 root root 205K May 11 11:31 /media/vmfs/hpdc02/vmware.log

<…hmm… chmod not working as expected…>
root@ubuntu12:/media#
root@ubuntu12:/media# cp -a /media/vmfs/hpdc02/vmware.log /media/floppy0/hpdc02/

<>> Review via other shell below.
Before Shell cp command started After / During (as shell becomes orphaned)
root@ubuntu12:# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/ubuntu12-root 15400892 1322480 13305704 10% /
udev 500692 4 500688 1% /dev
tmpfs 203900 248 203652 1% /run
none 5120 0 5120 0% /run/lock
none 509748 0 509748 0% /run/shm
/dev/sda1 233191 24965 195785 12% /boot
/dev/fuse 1610350592 825751552 784599040 52% /media/vmfs
/dev/sdb1 309633052 29085696 264818920 10% /media/floppy0
root@ubuntu12:# root@ubuntu12:# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/ubuntu12-root 15400892 1322480 13305704 10% /
udev 500692 4 500688 1% /dev
tmpfs 203900 248 203652 1% /run
none 5120 0 5120 0% /run/lock
none 509748 0 509748 0% /run/shm
/dev/sda1 233191 24965 195785 12% /boot
/dev/fuse 1610350592 825751552 784599040 52% /media/vmfs
/dev/sdb1 309633052 29085696 264818920 10% /media/floppy0
root@ubuntu12:#

(( bytes do not change so shell seems to be in some kind of unknown state))

Are there any tools or ideas on how to further debug this so I can recover these files. Obviously without these files, I cannot recover the VM(s). It worked without issue on hpdc01 but on subsequent VMs file copies have all had one or more failures, but not yet seeing pattern.

Thanks,

Hello,

Recently, We try to use vmfs-fuse access file, but get "cannot access" or "No such file or directory" in a folder. The strange is the listed file not really my file's name. I try to run fsck and get some error message like unsupported type..., but I think the partition is healthful in esxi5 system.

There is my steps and error messages:

1. follw the setps (http://www.virtuallyghetto.com/2011/07/how-to-format-and-create-vmfs-volume.html) to create vmfs by command.
2. scp two folder and some file to new created partition
3. reboot to clonezilla-live and compile new vmfs-tools from git repository
4. run vmfs-fuse /dev/sdc1(the new vmfs5)
5. ls -lR /mnt

and there is the error messagefrom ls, fsck, debugvmfs:
ls: cannot access /mnt/drbl-live/functions
/auto/scripts
/config
/config/binary
/config/binary_debian-installer
/config/binary_debian-installer-includes
/config/: No such file or directory
ls: cannot access /config/binary_local-debs
/config/binary_local-hooks
/config/binary_local-hooks/efi-binary-hook
/config/binary_local-includes
/c: No such file or directory
ls: cannot access /mnt/drbl-live/_local-packageslists
/config/binary_local-udebs
/config/binary_rootfs
/config/binary_syslinux
/config/bootstrap
/config/chroot
/: No such file or directory
ls: cannot access /mnt/drbl-live/t_apt
/config/chroot_local-hooks
/config/chroot_local-hooks/ocs-live-hook
/config/chroot_local-includes
/config/chroot_local-inc: No such file or directory
ls: cannot access /mnt/drbl-live/ook-dir
/config/chroot_local-includes/live-hook-dir/drbl.conf
/config/chroot_local-includes/live-hook-dir/drbl-live-hook
/config: No such file or directory
/config/binary_local-debs?/config/binary_local-hooks?/config/binary_local-hooks/efi-binary-hook?/config/binary_local-includes?/c
functions?/auto/scripts?/config?/config/binary?/config/binary_debian-installer?/config/binary_debian-installer-includes?/config/
_local-packageslists?/config/binary_local-udebs?/config/binary_rootfs?/config/binary_syslinux?/config/bootstrap?/config/chroot?/
ook-dir?/config/chroot_local-includes/live-hook-dir/drbl.conf?/config/chroot_local-includes/live-hook-dir/drbl-live-hook?/config
t_apt?/config/chroot_local-hooks?/config/chroot_local-hooks/ocs-live-hook?/config/chroot_local-includes?/config/chroot_local-inc

1. run fsck
   Scanning 130000 FDC entries...
   Block 0x32386539 is used but not allocated.
   Block 0x2e412f4e is used but not allocated.
   Block 0x20746f4e is used but not allocated.
   Block 0x66356563 is used but not allocated.
   Block 0x61636561 is used but not allocated.
   Block 0x5335444d is referenced by multiple inodes:
   0x06405104 0x0d005104 0x11005104 0x13805104 0x16c05104 0x18405104 0x1d005104 0x1fc05104 0x23005104
   Block 0x5335444d is used but not allocated.
   Block 0x64343539 is used but not allocated.
   ....
   Block 0x32353263 is used but not allocated.
   Data collected from inode entries:
   File Blocks : 16422
   Sub-Blocks : 36
   Pointer Blocks : 29
   Inodes : 156

Orphaned inode 0x00000000
Orphaned inode 0x00000000
....
Orphaned inode 0x00000000
Invalid . entry in /clonezilla-live/alternative
Invalid .. entry in /clonezilla-live/alternative
Invalid .. entry in /clonezilla-live/alternative/testing
Invalid .. entry in /clonezilla-live/alternative/stable
Unallocated blocks : 25
Lost blocks : 0
Undefined inodes : 5
Orphaned inodes : 88
Directory errors : 5

1. ./debugvmfs /dev/sdc1 ls /drbl-live
   functions
   /auto/scripts
   /config
   /config/binary
   /config/binary_debian-installer
   /config/binary_debian-installer-includes
   /config/
   /config/binary_local-debs
   /config/binary_local-hooks
   /config/binary_local-hooks/efi-binary-hook
   /config/binary_local-includes
   /c
   _local-packageslists
   /config/binary_local-udebs
   /config/binary_rootfs
   /config/binary_syslinux
   /config/bootstrap
   /config/chroot
   /
   t_apt
   /config/chroot_local-hooks
   /config/chroot_local-hooks/ocs-live-hook
   /config/chroot_local-includes
   /config/chroot_local-inc
   ook-dir
   /config/chroot_local-includes/live-hook-dir/drbl.conf
   /config/chroot_local-includes/live-hook-dir/drbl-live-hook
   /config

---- the really content is
/vmfs/volumes/4f3292bd-11d213f0-f55d-000c29266f11/drbl-live:
drwxr-xr-x 1 root root 1820 Feb 8 15:39 stable
drwxr-xr-x 1 root root 2240 Feb 8 15:38 testing
drwxr-xr-x 1 root root 280 Feb 8 15:39 unstable

/vmfs/volumes/4f3292bd-11d213f0-f55d-000c29266f11/drbl-live/stable:
-rw-r--r-- 1 root root 578 Feb 8 15:39 CHECKSUMS.TXT
-rw-r--r-- 1 root root 11053 Feb 8 15:39 ChangeLog-DRBL-live.txt
-rw-r--r-- 1 root root 5 Feb 8 15:39 Known-issues-DRBL-live.txt
-rw-r--r-- 1 root root 264 Feb 8 15:39 MD5SUMS
-rw-r--r-- 1 root root 296 Feb 8 15:39 SHA1SUMS
-rw-r--r-- 1 root root 412008448 Feb 8 15:39 drbl-live-xfce-1.0.5-6-i486.iso
-rw------- 1 root root 411237638 Feb 8 15:39 drbl-live-xfce-1.0.5-6-i486.zip
-rw-r--r-- 1 root root 412229632 Feb 8 15:39 drbl-live-xfce-1.0.5-6-i686.iso
-rw------- 1 root root 411457760 Feb 8 15:38 drbl-live-xfce-1.0.5-6-i686.zip
-rw-r--r-- 1 root root 16942 Feb 8 15:39 packages-1.0.5-6-i486.txt
-rw-r--r-- 1 root root 16942 Feb 8 15:38 packages-1.0.5-6-i686.txt
....

Do you have any idea to fix this issue? Please let me know if you need more information or image the partition, Thank You.

Hi,

First I want to appreciate the team who developed this tool, it helps us a lot in our environment, the issue i am facing is related to the read speeds i am getting when I am trying to copy a large file from VMFS datastore through VMFS-tools , it is giving me 20 Mb read speed i don't know whether this is maximum capability of the tool are i will be able to fine tune some settings to get a better speed.

VMS Datastore(Flash)--->VMFS-tools(Mount as read only dir)----> copy to another Flash Directory local to Linux OS

Need some expert advice

I've been trying to compile vmfs-tools on Win7-x64 to no avail. The issue appears to be centred around uuid.h, which is missing. I've installed mingw-w64 and have tried to compile in cmd and cygwin. I've installed libuuid1 and configure says that uuid is installed (see below), but it cannot find the uuid.h refererenced in libvmfs/utils.h.

I tried renaming the uuids.h in the mingw folder, but it didn't work. (It spat out loads of errors.) I also tried commenting out the #include in utils.h, and changing the reference, but then it lost all the pointers to the 'uuid' objects later on.

Any ideas? Has anyone successfully compiled the latest vmfs-tools on Windows 7? (And if they have, I would _LOVE_ to have an already working, compiled binary...

Configure output:
$ ./configure
Checking for pkg-config...no
Checking for uuid...yes
Checking for fuse...no
Checking for asciidoc...no
Checking for xsltproc...no
Checking for docbook.xsl...no
Checking for strndup...no
Checking for dlopen in -ldl...no
Checking for dlopen...no
Checking for posix_memalign...no
make: 'config.cache' is up to date.

Make output:
$ make install
echo "#if 1" > version
echo "#define VERSION "v0.2.5-patched"" >> version
echo "#else" >> version
echo VERSION := v0.2.5-patched >> version
echo "#endif" >> version
install -d -m 0755 /usr/local/sbin
gcc -Wall -O2 -g -D_FILE_OFFSET_BITS=64 -DNO_STRNDUP=1 -Idebugvmfs -Ilibvmfs -I/usr/include/uuid -Ilibreadcmd -c -o debugvmfs/variables.o debugvmfs/variables.c
In file included from libvmfs/vmfs.h:53:0,
from debugvmfs/variables.c:20:
libvmfs/utils.h:23:18: fatal error: uuid.h: No such file or directory
#include <uuid.h>
^
compilation terminated.
: recipe for target 'debugvmfs/variables.o' failed
make: *** [debugvmfs/variables.o] Error 1

new issue about file I/O error here

I use clonezilla-live to mount vmfs with vmfs-tools and found special vmdk file can't be read. The fsck also show me some errors but the vmdk work well under esxi. I can't make sure is't a bug of vmfs-tools or not. Could you help me to fix the issue?

I am already do some work and dump the error message below:

root@debian:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 2039276 372256 1667020 19% /
...
/dev/fuse 971505664 542525440 428980224 56% /mnt

oot@debian:~# mount
/dev/fuse on /mnt type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions)

oot@debian:~# find /mnt -type f -exec md5sum ...
3b6d3b0c8c96be3395dbe138f06464a1 /mnt/linux/linux.vmdk
md5sum: /mnt/linux/linux_1-flat.vmdk: Input/output error

cp /mnt/linux/linux_1-flat.vmdk ./
cp: error reading ‘/mnt/linux/linux_1-flat.vmdk’: Input/output error
cp: failed to extend ‘./linux_1-flat.vmdk’: Input/output error

Scanning 130000 FDC entries...
vmfs_bitmap_get_entry -1vmfs_bitmap_get_entry -1vmfs_bitmap_get_entry -1Block 0x6d783f3c is used but not allocated.
Block 0x69442023 is referenced by multiple inodes:
0x01405e84 0x01c05e84
Block 0x69442023 is used but not allocated.
Data collected from inode entries:
File Blocks : 17810
Sub-Blocks : 2
Pointer Blocks : 18
Inodes : 21

./fsck.vmfs/fsck.vmfs /dev/sda3 > fsck.log

Orphaned inode 0x00000000
File Block 0x006d69c1 is lost.
File Block 0x006d6a01 is lost.
File Block 0x006d6a41 is lost.
File Block 0x006d6a81 is lost.
File Block 0x006d6ac1 is lost.
File Block 0x006d6b01 is lost.
..........multiline complain same error but different file block
File Block 0x02715fc1 is lost.
File Block 0x02716001 is lost.
Pointer Block 0x0003da43 is lost.
Pointer Block 0x1003da43 is lost.
Pointer Block 0x2003da43 is lost.
Pointer Block 0x3003da43 is lost.
..........multiline complain same error but different Pointer block
Pointer Block 0x3003e203 is lost.
Pointer Block 0x4003e203 is lost.
Unallocated blocks : 2
Lost blocks : 527389
Undefined inodes : 0
Orphaned inodes : 1
Directory errors : 0

root@debian:/home/partimag/dev/vmfs-tools# stat -f /mnt
File: "/mnt"
ID: 0 Namelen: 0 Type: fuseblk
Block size: 1048576 Fundamental block size: 1048576
Blocks: Total: 948736 Free: 418926 Available: 418926
Inodes: Total: 130000 Free: 129979

root@debian:/home/partimag/dev/vmfs-tools# stat /mnt/linux/linux_1-flat.vmdk
File: ‘/mnt/linux/linux_1-flat.vmdk’
Size: 536870912000 Blocks: 1048576000 IO Block: 4096 regular file
Device: 16h/22d Inode: 25190020 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-10-29 22:25:29.000000000 +0000
Modify: 2013-10-29 08:56:02.000000000 +0000
Change: 2013-10-03 23:12:58.000000000 +0000
Birth: -

vmfs-fuse can't read files with type Pointer Block (PB). Is this an oversight?

This would be sooo great :/

Update request (not a bug):
Will VMFS 6 be supported in the future (or maybe it is already, and I just can't find it in the release notes)?
I was using Clonezilla to replicate a ESXi 6.5 install with VMs and the datastore just won't mount when I restore the image; the VSphere web client freezes when I try to do in manually and throws "unexpected error" message. If there is interest, I'll dig around for any relevant log files.

Thanks!

I recently discovered this project and was hoping to add it to Gentoo. I work in digital forensics, so sometimes such capability is needed. Some time has passed since the last release, I combed through the issues and other forks and here is what I found:

• large file support
  Work done by @mlsorensen and standing PR #14 I guess this will need to be reworked a bit to include fix for 1TB or even better, merge his master.
  This will resolve issues #8, #12, #3 (and of course #14); may be #9 and #1 as well.

• order of lookup
  Discovered by @trapgate, that is inside #15, may be no need for PR and based on the comments there and the code change I guess it is obvious.

@glandium: Let me know if I can make it easier for you to get the release out!

(Disclaimer: I have no ESX access at the moment to test :-/ )

This is more of a feature request than a bug. Currently I'm trying to get access to a really old VMFS 2 volume, but it seems like it's not possible currently with vmfs-tools. It'd be awesome if this were supported.

We mount our VMFS 5 image on the loop back, then use vmfs-fuse to mount it. We can see directory listings and can look at small files. When we look at anything larger than a few kilobytes it is always all 0s. This is on ubuntu 12 64-bit. Do you have any ideas? We're using winhex to look at the files because when we copied them directly we had all 0s. We're using the 0.2.5 release.

I'm having trouble reading data from a certain vmfs5 datastore, I've successfully migrated many machines all varying sizes from another datastore, also vmfs5.

The problem seems to be any file between 8KB and 512GB (though the 512GB is a guess, 500GB doesn't work but 718GB and larger images work)

My testcase is a small text file that I appended until it became unreadable through vmfs-fuse.

Test case: a 2784 byte file is readable with vmfs-fuse, on a Vmware node I copy the file to a new file, still works, now I append the original file to the copy, data is still correct, I once more append the data and I have a 8352 byte file that has 'garbage' content but stays the same md5sum if I re-read the file.

Editing the file and reducing the size does not make it readable again.

With vmfs-fuse in debug mode nothing obvious (for me) changes, still same node id.

I've tried applying pull request #14 (which I needed anyway for 256GB+) but that does not help for the issue of the 8KB file.

Any suggestions on how to further debug this issue would be greatly appreciated.

This is the debug log of the successful and failed reading of a file.

Start vmfs-fuse -d

FUSE library version: 2.9.7
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.26
flags=0x001ffffb
max_readahead=0x00020000
INIT: 7.19
flags=0x00000001
max_readahead=0x00020000
max_write=0x00020000
max_background=0
congestion_threshold=0
unique: 1, success, outsize: 40

cd /to/dir

unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 3917
unique: 2, success, outsize: 120
unique: 3, opcode: LOOKUP (1), nodeid: 1, insize: 50, pid: 3917
unique: 3, success, outsize: 144

Copy test file on the Vmware node to a new file and then read it through vmfs-fuse.

unique: 4, opcode: GETATTR (3), nodeid: 239090948, insize: 56, pid: 4727
unique: 4, success, outsize: 120
unique: 5, opcode: LOOKUP (1), nodeid: 239090948, insize: 46, pid: 4727
unique: 5, success, outsize: 144
unique: 6, opcode: OPEN (14), nodeid: 318806468, insize: 48, pid: 4727
unique: 6, success, outsize: 32
unique: 7, opcode: READ (15), nodeid: 318806468, insize: 80, pid: 4727
unique: 7, success, outsize: 2800
unique: 8, opcode: FLUSH (25), nodeid: 318806468, insize: 64, pid: 4727
unique: 8, error: -38 (Function not implemented), outsize: 16
unique: 9, opcode: RELEASE (18), nodeid: 318806468, insize: 64, pid: 0
unique: 9, success, outsize: 16

Append the data on the Vmware node once more and read through vmfs-fuse.

unique: 10, opcode: GETATTR (3), nodeid: 239090948, insize: 56, pid: 4734
unique: 10, success, outsize: 120
unique: 11, opcode: LOOKUP (1), nodeid: 239090948, insize: 46, pid: 4734
unique: 11, success, outsize: 144
unique: 12, opcode: OPEN (14), nodeid: 318806468, insize: 48, pid: 4734
unique: 12, success, outsize: 32
unique: 13, opcode: READ (15), nodeid: 318806468, insize: 80, pid: 4734
unique: 13, success, outsize: 5584
unique: 14, opcode: RELEASE (18), nodeid: 318806468, insize: 64, pid: 0
unique: 14, success, outsize: 16

Append the data on the Vmware node once more and read through vmfs-fuse.

unique: 15, opcode: GETATTR (3), nodeid: 239090948, insize: 56, pid: 4735
unique: 15, success, outsize: 120
unique: 16, opcode: LOOKUP (1), nodeid: 239090948, insize: 46, pid: 4735
unique: 16, success, outsize: 144
unique: 17, opcode: OPEN (14), nodeid: 318806468, insize: 48, pid: 4735
unique: 17, success, outsize: 32
unique: 18, opcode: READ (15), nodeid: 318806468, insize: 80, pid: 4735
unique: 18, success, outsize: 8368
unique: 19, opcode: RELEASE (18), nodeid: 318806468, insize: 64, pid: 0
unique: 19, success, outsize: 16

I tried to compile vmfs-tools on Mac OS X 10.6.8. In its current state, it fails, but fixing it is rather simple:

Missing u_char typedef: #include <sys/types.h>
Missing strnlen(): #define strnlen(s, maxlen) (strlen (s) < maxlen ? strlen (s) : maxlen)
Missing timersub() and gettimeofday(): #include <sys/time.h>
Missing libuuid: Download e2fsprogs, ./configure it, cd lib/uuid, make, copy the uuid folder to vmfs-tools. (e2fsprogs from MacPorts does not help as it gets built without libuuid)
FUSE: Install osxfuse

Below is a diff file for these changes. The changes to C code have ifdef around them and could thus easily go into the official code. The changes required to configure.mk to find fuse and uuid are more invasive; I don't know much about automake, but I'm sure you could wrap some kind of if-clause around it.

diff --git a/configure.mk b/configure.mk
index 710816c..2dbfa6f 100644
--- a/configure.mk
+++ b/configure.mk
@@ -9,8 +9,8 @@ datarootdir := $$(prefix)/share
 mandir := $$(datarootdir)/man

 # configure rules really start here
-$(call PKG_CONFIG_CHK,uuid,-I/usr/include/uuid,-luuid)
-$(call PKG_CONFIG_CHK,fuse)
+$(call PKG_CONFIG_CHK,uuid,-I./uuid,-L./uuid,-luuid)
+$(call PKG_CONFIG_CHK,fuse,-I/usr/local/include/osxfuse/fuse,-L/usr/local/lib -lfuse)
 $(call PATH_LOOKUP,asciidoc)
 $(call PATH_LOOKUP,xsltproc)

diff --git a/imager/imager.c b/imager/imager.c
index e2963ba..f7c60c5 100644
--- a/imager/imager.c
+++ b/imager/imager.c
@@ -48,6 +48,9 @@
 #include <fcntl.h>
 #include <errno.h>
 #include <inttypes.h>
+#ifdef __APPLE__
+#include <sys/types.h>
+#endif
 #include <string.h>

 static void die(char *fmt, ...)
diff --git a/libvmfs/utils.h b/libvmfs/utils.h
index 8daca31..61f8460 100644
--- a/libvmfs/utils.h
+++ b/libvmfs/utils.h
@@ -22,6 +22,10 @@
 #include <string.h>
 #include <uuid.h>
 #include <inttypes.h>
+#ifdef __APPLE__
+#include <sys/types.h>
+#define strnlen(s, maxlen) (strlen (s) < maxlen ? strlen (s) : maxlen)
+#endif

 /* Max and min macro */
 #define m_max(a,b) (((a) > (b)) ? (a) : (b))
diff --git a/libvmfs/vmfs_host.h b/libvmfs/vmfs_host.h
index bffc6f5..8834135 100644
--- a/libvmfs/vmfs_host.h
+++ b/libvmfs/vmfs_host.h
@@ -18,6 +18,10 @@
 #ifndef VMFS_HOST_H
 #define VMFS_HOST_H

+#ifdef __APPLE__
+#include <sys/time.h>
+#endif
+
 /* Initialize host info (UUID,uptime,...) */
 int vmfs_host_init(void);

Now everything compiles without warnings or errors. debugvmfs works fine on test.img, but I have not tested yet whether vmfs-fuse works on an actual volume (as far as I can tell, it does not mount bitmap files like test.img, so I can't test it right now). If someone sends me a dd image of a VMFS, I can test that and the other tools.

I tried copy files from a big (~4TB) VMFS6 datastore to an Ext4 formatted HDD but reading files with vmfs6-tools very buggy.

Steps:

1. Stop all VM-s completly in my ESXi homelab server.

2. Make md5 list in every VM folder from every files, in ESXi SSH shell (md5sum command).

3. Shut down ESXi cleanly.

4. Put a destination HDD in my server, and boot Debian 10 Live

5. Set source VMFS HDD as read only (just for safe), and mount the VMFS with vmfs6-fuse as read only.

6. Mount the destination HDD.

7. Copy all files/folders from VMFS6 to destination (Ext4) HDD

8. Check the md hashes on destination HDD and found lot of errors!
   Almost all big xxxx-flat.vmdk files had bad md5 value!

This means.. read files within ESXi and with vmfs6-tools in Linux make different result! Without any sign. This cause data corruption/lost.

(Remarks: Finally, I solved the problem. I made a Linux based NFS server, and copied all files from running ESXi to the destionation Ext4 HDD, through NFS. Faster xfer than SSH. I checked the md5 hashes again in Linux, and with this method all files was good. )

Hello,
I compiled vmfs-tools w/o any errors, but when i try to use it crashes with core dump. Is it possible to do something to make it work under solaris?

I've discovered that when reading large files from a vmfs volume, vmfs-tools does not consistantly present the same data to the reading application (i.e. corruption). For example, after copying a large vmdk file to an external disk, I ran sha1sum on the source and destination 3 times. As you can see below, the source (vmfs) presents a different sum on almost every run:

Compare 1 failed on file [/mnt/vmfs/dvr/dvr-flat.vmdk]. MD5/SHA source=c8809289e7e48549c9594400a66e1b987947c326, destination=15a78ae7140b3ab82009a35bc64f32bc32a60274
Compare 2 failed on file [/mnt/vmfs/dvr/dvr-flat.vmdk]. MD5/SHA source=c8809289e7e48549c9594400a66e1b987947c326, destination=15a78ae7140b3ab82009a35bc64f32bc32a60274
Compare 3 failed on file [/mnt/vmfs/dvr/dvr-flat.vmdk]. MD5/SHA source=7d1d7ce34910758ae75545da8b0decbafdcb2b02, destination=15a78ae7140b3ab82009a35bc64f32bc32a60274

I ran the sha1sum under valgrind using debugvmfs but found only one error (not sure it's related):

valgrind --leak-check=full --show-reachable=yes /usr/local/sbin/debugvmfs /dev/sda3 cat /PBX2/PBX2-flat.vmdk | sha1sum -b ==4945== Memcheck, a memory error detector ==4945== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4945== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==4945== Command: /usr/local/sbin/debugvmfs /dev/sda3 cat /PBX2/PBX2-flat.vmdk ==4945== ==4945== Warning: noted but unhandled ioctl 0x5382 with no size/direction hints
==4945== This could cause spurious value errors to appear.
==4945== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==4945== Conditional jump or move depends on uninitialised value(s)
==4945== at 0x40A303: vmfs_vol_open (vmfs_volume.c:223)
==4945== by 0x407A9F: vmfs_fs_open (vmfs_fs.c:203)
==4945== by 0x40295D: main (debugvmfs.c:675)
==4945==

This same problem presents on 3 different VMware ESXIi 4.1 hosts (we are hoping to use vmfs-tools as our bare metal backup). We are running vmfs-tools 0.2.5 under Centos 6.2 x86_64..