VMware Cloud Community
Fred_Weston
Contributor
Contributor

Error: Unable to clone volume C:

I'm using converter standalone v5.5 build 1362012 and am trying to copy a VM that is presently in Amazon Web Services to my local vSphere environment.  I've done it successfully before with this exact same VM as a test, but now I'm actually trying to move the VM and encountering this problem.

The error message is FAILED: An error occurred during the conversion: converter.fault.FileIOFault

At first I was trying to use converter to directly copy the VM from AWS to vSphere.  When that failed twice, I tried using converter to convert the VM to a Workstation VM, which I could later import into vCenter and that failed as well.

The VM in question is Win2008R2.  It has three disks, each with one basic volume that takes up the entire disk:

C: 30 GB

😧 20 GB

E: 40 GB

I am not trying to resize volumes as part of the conversion.  There is plenty of free space on the volume I am writing the VM files to (that folder is on a shared volume on the host running converter).

I've tried running chkdsk on the VM being converted and it did not report any errors.  I also tried defragmenting the volumes but it made no difference.

Here is the log bundle from converter:

https://lpga.box.com/s/1e62weqjzq6lkv87eis9

Any suggestions on how I can fix this problem?

Tags (1)
Reply
0 Kudos
8 Replies
POCEH
VMware Employee
VMware Employee

Your error is:
2014-10-02T14:05:54.323-04:00 [01912 error 'task-3'] BlockLevelVolumeCloneMgr::ReadAndSkipBadBlocks(): Error (type: 2, code: 2) reading 655360 bytes starting at 0x000000023f83a000 from the source volume C:
2014-10-02T14:05:54.323-04:00 [01912 error 'task-3'] BlockLevelVolumeCloneMgr::ReadAndSkipBadBlocks(): Unrecoverable error (type: 2, code: 2) reading 655360 bytes starting from 0x000000023f83a000 from the source volume C:
so you need to do 'chkdsk c: /B' in order to fix errors on disk, probably the chkdsk will be performed on boot of machine.
HTH

Reply
0 Kudos
Fred_Weston
Contributor
Contributor

Hello POCEH.  Thank you for the reply.  Since I already ran chkdsk without any flags, wouldn't that have shown an error and prompted me to run it again?  I am just trying to avoid any unnecessary reboots since this is a production server.

Thanks

Reply
0 Kudos
POCEH
VMware Employee
VMware Employee

Chkdks without flags checks only FS metadata, the /B re-evaluates bad clustes on volume, which is necessary in your case. Reboot is required because the volume is in use and can not be checked...

HTH

Reply
0 Kudos
Fred_Weston
Contributor
Contributor

I ran chkdsk /b and rebooted the machine, I am still getting the same error but as I retry the job the failure occurs at different points for example, sometimes at 25% sometimes at 11%, sometimes at 86%.  Any further suggestions?

Reply
0 Kudos
POCEH
VMware Employee
VMware Employee

I'll say that disk is going to die... (could you verify the similar error as before in the logs?).

The other possibility is to use some other supported 3rd party to produce image and then convert it to ESX/VS.

HTH

Reply
0 Kudos
Fred_Weston
Contributor
Contributor

It's actually given the error on different volumes as I retry the job and all the volumes are on different disks (SAN), seems unlikely that all three of the disks are suspect.  I've had a lot of similar problems with other VMs as well, but if I retry them 10 or so times they usually complete successfully.  Maybe it's an AWS specific problem.

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee

I don't think the disks in AWS have bad sectors. The error in the log is 2 (The system cannot find the file specified.) returned by ReadFile Windows API f-n. Since this is block level cloning, the 'file' being read is actually the volume block device. There is something else going on, probably related somehow to AWS, unfortunately I have no idea how to find out what it is.

Regards

Reply
0 Kudos
Fred_Weston
Contributor
Contributor

The best I can figure is the problem may somehow be related to load in AWS since it's a shared environment and I don't necessarily have the ability to see what other workloads may be stealing I/O cycles.

Reply
0 Kudos