I'm trying to move a 32-bit Ubuntu 10.0.4 VM from an ESX 3.5 host to an ESX 4.1 host. The source VM is powered off during the conversion.
Both machines are on the same subnet connected to the same switch.
The conversion fails at 1% with a network error after about 6 hours.
Source host is a Dell 2850 and the destination is a Dell 1950.
The worker log is attached, any help would be greatly appreciated!
What I can see in the log is that it seems than name resolution is not the problem (adding the relevant hosts names in the hosts file wouldn't do no harm) but the only error I saw was with your disk controler being paravirtual. Is this correct?
Check this out, maybe it can help you.
The source is currently configured with LSI Logic for its SCSI Controller type. When doing the conversion I'd been using Auto Select for the convert.
I'll try setting the type on conversion and using the different controller type you suggested. I'll update again tomorrow at after re-trying the cold clone.
The log you have attached doesn't show the problem.
In case of V2V the traffic goes through converter worker, which means it (the worker) should be able to connect to both hosts on port 902. Check this article for more details: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101005...
Did you retry the conversion? It may have been some temporary network issue. In case it reproduces, please export the logs for the failed task (from the tasks view, not the jobs view!) and attach it.
I was unable to change the controller type from LSI Logic to Paravirtual. My 3.5 Host only gave me options for LSI Logic and BUS Logic. I'm assuming it may be a build issue on 3.5 since i haven't updated it since 2009 (my bad)
I did retry the conversion specifying the correct SCSI controller on the destination but the job again sat at 1% with no apparent progress. I canceled the job after about 30 minutes.
Which specific logs do you need from the Task view or do you just want the whole zip?
Usually the worker log is most useful, however given it is not clear what is going on the whole archive might be a good idea.
Sent the logs as a PM since I didn't want to attach them to the forum, please let me know if there's any other information you need.
Got it. Will investigate and will post the result.
It looks your source ESX host is quite old (version 3.0?). Converter 5.0 is trying to encrypt the data traffic while transferring disks, but unfortunately ESX 3.0 sometimes is having problems with this encryption. I would suggest to try one of the following:
1. Use an older Converter version that does not encrypt data traffic (all versions before 5.0 does not encrypt the traffic and for Linux V2V conversions there are really no changes since Converter 4.0)
2. Disable the SSL encryption on data traffic in Converter 5.0. Instructions how to do this are available at http://communities.vmware.com/thread/333786.
3. If the source ESX host is managed by a (newer) vCenter Server try to select the source VM through specifying the vCenter Server as a source instead of the ESX host.
It is a wild guess, but it might work. If none of these solves the problem I would ask you to switch the worker logging level to "verbose" (instructions are available at http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2008019), retry the conversion and export a new log bundle.
Sorry for the delayed respone, I needed to try all of the methods you suggested.
1. I ran converter 5.0 without SSL encryption and the job progressed 2% after 8 hours and showed a remaining time of around 16 days.
2. I ran converter 4.0.3 and 4.0.1 and had similar results. I ran the jobs using both thin and full disk based copies.
3. Both of the hosts are stand alone and not managed through a vCenter server.
Since I had similar results on all versions of converter I have a feeling it may be a network issue.