I have a VMware ESXi 4 server and 2 storage servers (mounted via nfs).

Between the storage servers (Fedora 14) is a drbd cluster (dual primary) and ocfs2 filesystem; also every server has a local partition with an ext4 filesystem, both are mounted via nfs on the esxi server.

When I tried to copy a virtual machine (naturally it was powered off) from the ext4 partition to the ocfs2 partition, the vmdk total file size is different, but the md5sum is the same.

On the ext4 partition:

# ls -la
total 28492228
-rw-------  1 root root 42949672960 Jan 14 14:46 disk-flat.vmdk

# md5sum disk-flat.vmdk

On the ocfs2 partition:

# ls -la
total 13974660
-rw------- 1 root root 42949672960 Jan 14 16:16 disk-flat.vmdk

# md5sum disk-flat.vmdk

When I power on the virtual machine from the ocfs2 partition it dosn't work. I have a windows on the virtual machine and it freezеs after the windows logo. From the ext4 partition the virtual machine workes.

I tested with linux (created and installed on ext4 partition and then copied to the ocfs2) and the same problem appears.

When I create a virtual machine directly from ocfs2 partition, there are no problems.

I tried to copy via vSphere client, and I have the same problem.

Any suggestions?

  • That's really odd! – Josh Jan 15 '11 at 16:20
  • 3
    Are these sparse disks or fully pre-committed? Copying sparse files around can have... interesting side effects. – David Mackintosh Jan 16 '11 at 1:29
  • Did you also copy over the 496 byte (something around there) .vmdk file associated with that disk? – Univ426 Aug 24 '12 at 14:01
  • You should copy your VMDK files with the vmware tools (look at the ghettoVCB backup script to get an idea), anyway if they are thin or thick (lazy zeroed) the VMDK might get corrupted based on the implementation of the sparse file technology. – Martino Dino Feb 2 '13 at 19:48

As it was stated above: vmdk files are sparsed. ie. they have "holes" in them. Try to compare file sizes using "du".


How are you copying the files around?

The only supported method is using vmkfstools. Any other method, including cp and mv, can corrupt the disks and make them useless.

Of course, I discovered this the hard way.


I feel a good first test to try to diagnose this would be to provision a new VM on that same OCFS partition to see how VMware works when its created natively there. It may be an overarching problem with OCFS or your NFS permissions instead of one limited to this specific VM data. Also, ensure MTU consistency between the vSwitch your VMkernel is connecting to NFS over and the actual drbd cluster.

Also, per your paste, the file sizes ARE the same. The 'total' figure listed above is not what you should be using; thats a total of Blocks not the file size.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.