Hi
> I tried the convert cd 3.0 and 4.0, trilead backup, veeam and vcenter, I have tried in copying files and browsing the datastore, I tried to clone from the shell ...
Thats the problem.
All those attempts are coming from a user that demands writeable files. So ESXi may deny access on a file-level.
In this case it helps to use readonly access on a blocklevel.
When I do a remote support session I create when ever possible a small Linux VM with direct ssh-access to the ESXi in question.
I mount the whole esxi-filetree readonly.
Next step is to find out where the "bad.vmdk" actually is located on the phsical storage.
If you are lucky you get one fragment starting at offset x with the full 2tb following.
If you have to pay for thin provisioning and snapshots you may also get a 1.000.000 single fragments scattered all over the place.
Anyway - once you know how to read the volume by one mb-pieces you can start to work around the failing locations.
just an example ...
IF=/esxi/dev/disks/naa.50012345678
OF=/vmfs-out/mailserver-flat.vmdk
CMD=dd if=$IF of=$OF bs=1M conv=notrunc
$CMD seek=185379 count=1 skip=226434 # fragment=19510#
$CMD seek=185395 count=19 skip=226435 # fragment=19515#
$CMD seek=185415 count=1 skip=226454 # fragment=19517#
$CMD seek=185417 count=2 skip=226455 # fragment=19519#
$CMD seek=185421 count=1 skip=226457 # fragment=19522#
$CMD seek=185378 count=1 skip=226458 # fragment=19509#
$CMD seek=185423 count=1 skip=226459 # fragment=19524#
$CMD seek=185394 count=1 skip=226460 # fragment=19514#
What was uncopieable before now is a bunch of pieces and if cmd1 does not work you have a small list of alternative commands.
I am quite busy at the moment - if you have any urgent issues call via skype
Ulli