Converter fails at 2% importing into ESX

[cgasb]

I get this same error using coldclone and the Converter from Windows. Also get the same error using the standalone download and the Converter in VC. The convert fails at 2% when it says formatting target volume C. Btw, the disk file is created, so the hangup seems to be after that. I believe the important part is this:

'P2V' 2496 error] Task failed: P2VError UNKNOWN_METHOD_FAULT(sysimage.fault.ImageProcessingTaskFault)

I am using version=3.0.2u1, build=build-62456. The log is attached. Thanks for any advice-

[cgasb]

UPDATE==

I do not get the error if I choose to leave the disk the same size. Only if I choose to resize the disk do I run into trouble. Is this a known condition?

[theanykey]

depends ... I have very little information to go on. If you need me to look at the logs I will need the vmware-converter-#.log file(s). The client logs do not hold information on cloning.

The cold clone, selecting all partitions and opting to not resize any is a standard practice for converting unsupported filesystems such as linux.

• Disk-based Block-Level (Disk-based)

This method of cloning is enabled when you choose to import all disks without selecting/resizing volumes. In this mode the disks are copied to the destination block by block. This method is the least likely to fail due to volume structure. If cloning with one of the other methods fail try getting a disk based clone which can then be used by developers for troubleshooting the bug.

This option is not available when doing Hot Clones (local or remote).

• Volume-based Block-Level (Volume-based)

This method of cloning is enabled when you choose to import all or a subset of volumes without resizing them. In this method, we examine the source partition to determine what the partition boundaries are on-disk and then copy just the selected partitions on to the target disk on a block-by-block basis. The partition order may not always be preserved in the target VM (especially if there are diagnostic partitions in the source). This means that Post-cloning related issues are more likely to show up here.

Non-windows VMs cloned with volume-based cloning are almost guaranteed to not be able to boot.

• Volume-based File-Level (File-level)

This method of cloning is enabled when you select one or more volumes for cloning and resize any one of them. Here, converter creates the target disk, partitions and formats it appropriately and copies over data from the source to the target on a file-by-file basis.

Resizing the disk smaller in size will force a file-level clone

[cgasb]

Here is the vmware-converter log from a hot clone where I tried to resize the disk. I get the same failure even when choosing to leave the disk alone. Thanks-

[cgasb]

Here is another log from a hot clone where I chose to leave the disk alone.

[theanykey]

I am seeing multiple NFC (network file copy) faults.

Could you try installing converter directly to the machine you are converting instead of converting it from a remote machine?

Could you also attach a screenshot of diskmanagment of the machine you are converting?

[mike_laspina]

Hello,

The process is failing to write to the destination vmdk. Are you using a UNC path as the destination. Try a drive map to the remote store instead.

vmounts over UNC are not reliable in my experiences.

Error 79394 writing to the destination volume

[Milton21]

Is your Windows 2003 box running Dynamic disk on the C drive?

Is the C drive set in a mirror? Using windows diskmanagement?

[cgasb]

I installed the client to the local machine and it still bombed at 2%. I am attaching the disk management screenshot. The datastore is a Windows 2003 Storage Server R2 box. The ESX host and the NAS box were connected via gigabit switch, but I just changed them over to the cross-over cable this morning (gigabit). Same problem.

[theanykey · Accepted solution]

Run a chkdsk /R on the source machine.

See if you can convert to a different LUN.

If you need a workaround:

1. Convert it to a "standalone virtual machine for workstation v5"

2. save it to NTFS on the network

3. If successful, winSCP (www.winscp.net) the .vmdk file(s) over to ESX's /vmfs

4. run the ESX commad "vmkfstools -i /path/to/source.vmdk /path/to/newname.vmdk" to convert it from workstation to ESX.

5. delete /path/to/source.vmdk

[cgasb]

This worked for now:

Remotely hot cloned the server to a standalone workstation v5 image on the NAS datastore ESX is using. Then used the converter to import the standalone image into ESX on the NAS datastore. For some reason this works, even though I am using the same network paths to import the image as when I tried to take the hot clone directly into ESX. I was even able to resize the drive using the workaround. Thanks for the help-

[theanykey]

I can not explain it. If you have the time and a support contract, you might want to file a support request with us so we can push the error to Engineering and determine if we have discovered a bug.

[madhopsman]

I am having the exact same issue here with Converter Version 3.03 build-81896

http://communities.vmware.com/message/944049#944049

[ericamar]

Make sure that your network settings are correct, so use for instance 100 full duplex. Make sure that you have a good DHCP connection and if you have 2 network adapters in your system that it uses the right adapter.

By the way VMWare converter 3.0.3 has been launched , and this is great. you can actually resize the volumes !!

[madhopsman]

Yeah, network settings are fine as far as I can tell and 3.0.3 is the build I am using. This only happens when you try to resize going to an NFS mounted storage. If I go to the local storage on the RAID array on the ESX server itself, there is not a problem.

[theanykey]

Did you say NFS storage? I am seeing a few of these pop up. I hear there is a patch comming out in around june/july that will correct an NFS storage related issues. I do not know enough about the ESX side of things (I am desktop specific in terms of support) so I am unable to provide further information to this "issue". I strongly feel this issue is what converter seems to be hitting. Keep an eye out for this patch, but you will need to file an SR to get more information on this topic. In the meantime, push out to local or SAN storage and manually move it to NFS. Again .. if you need to see if this relates to you, please open an SR and reference that you would like to get clarification to see if the converter issue is linked to ProblemReport-271717.

[madhopsman]

Thanks for the info, thats exaclty what I am going to do....as soon as I get the time that is...:|