Set-up:- 
1) Create a Replicate Volume with count 2 on the Server
2) Start the replicate volume
3) Create a mount point /vm on the Dom0
4) Mount the replicate volume on /vm of the Dom0

Execution:-
Step1:-
-----
1) check the md5sum of the VM image file(GuestOS) on each brick
2) Check the extended attributes of the image file on each brick

The md5sum and extended attributes of the VM image file are same.

Step2:-
------
3) Start the Guest OS (VM)
4) Perform IO Operations
5) Bring down brick1 while IO operation is still in progress
6) Shutdown the Guest OS once the IO operation is complete
7) Calculate the md5sum of the VM image file(GUestOS) on live brick
8) Bring back the brick1
9) Self-heal automatically initiated (proactive self-heal on)
10) Self-heal successfully completed

Step3:-
------
11) Check the extended attributes of the image file on each brick

The extended attributes of the image file on each brick is same

Step4:-
-----
12) check the md5sum of the VM image file(GuestOS) on each brick

The MD5SUM of the VM image file doesn't match.

Observed the failure on 3.3.0qa14. Updated the Google doc with the new data https://docs.google.com/spreadsheet/ccc?key=0AlvBPsMsaL6edFlBX0xQY0dTUGZRU0FLaGlDUVFJcWc&hl=en_GB#gid=2

Created attachment 722

Created attachment 723

Can you please reproduce this with 3.3.0qa24?

I found that the self-heal of files with holes has a bug. I am suspecting this issue is the result of that. Could you confirm if the vm image type you are using has holes in it.

Pranith

CHANGE: http://review.gluster.com/3065 (cluster/afr: Handle self-heal of files with holes) merged in master by Anand Avati (avati)

I havent experienced any md5mismatch issue after this fix. Closing the bug. Please feel free to re-open the bug if you find another way to hit this issue.

I will try to recreate this bug post 3.3 release. Hence moving it to Modified state.