Windows 2003 SP2 box. It has 4 drives in it. It fails on C:
I attached the logs but I cannot make any sense of them. Perhaps someone else can point me in the right direction?
SOLUTION: Downloaded 3.0.3 and did a hot import after chaning NIC speed\duplex from auto to 100\full. Worked like a charm. Only issue is the AMD PCI nic showing the mesage "device cannot start (code 10)"
Message was edited by: brettcw23
Connecting to host wshq-vcs25 on port 443 using protocol https
NfcNetTcpWrite: bWritten: -1 err: 10054
NfcFssrvrSend: failed
NfcFssrvr_Close: failed to send close message
NfcNetTcpWrite: bWritten: -1 err: 10054
NfcNet_Send: requested 264, sent only 8 bytes
NfcSendMessage: send failed:
Download the newer converter ISO version 3.0.3
Point the conversion directly to ESX via IP instead of FQDN and using "root" instead of to VC using "wescohq\bwilliams".
Then you only need to verify that ports 443 and 902 are open to the ESX host from that physical machine.
Also make sure that your duplex/speed settings are correct.
Connecting to host wshq-vcs25 on port 443 using protocol https
NfcNetTcpWrite: bWritten: -1 err: 10054
NfcFssrvrSend: failed
NfcFssrvr_Close: failed to send close message
NfcNetTcpWrite: bWritten: -1 err: 10054
NfcNet_Send: requested 264, sent only 8 bytes
NfcSendMessage: send failed:
Download the newer converter ISO version 3.0.3
Point the conversion directly to ESX via IP instead of FQDN and using "root" instead of to VC using "wescohq\bwilliams".
Then you only need to verify that ports 443 and 902 are open to the ESX host from that physical machine.
Also make sure that your duplex/speed settings are correct.
I downloaded the 3.0.3 version and ran the conversion. It still fails at 2% but it takes 2 hours now instead of 1 hour to fail. I used the ip of the host instead of the Virtual Center server. The source is getting its ip from DHCP, the NIC is set to auto-detect. I used PortQueryUI to verify that the ports 443/902 are open between the source server and destination host. Attached are the logs from my most recent failure.
I've corrected this problem on HP servers by upgrading the controller firmware and drivers on the source server to the latest levels.
Good Luck!
Maybe something on ESX - does it work when you choose to save the image as a VM for workstation version 5x (choose "other" for destination type)?
How good are you with ESX?
If you search your /var/log/vmware/hostd.log files for the occurances of "Write failed curSector" and confirm the exact time of where this line appears (with respect to when you ran the converter task) .... Take that time and use it to pinpoint any linked failures within your /var/log/vmkernel.log files. For example, you might see something like this in your vmkernel logs:
May 30 15:07:16 xxx vmkernel: 13:16:28:54.906 cpu6:1036)SCSI: vm 1036: 109: Sync CR at 64
May 30 15:07:17 xxx vmkernel: 13:16:28:55.884 cpu6:1036)SCSI: vm 1036: 109: Sync CR at 48
May 30 15:07:18 xxx vmkernel: 13:16:28:56.860 cpu6:1036)SCSI: vm 1036: 109: Sync CR at 32
May 30 15:07:19 xxx vmkernel: 13:16:28:57.846 cpu6:1036)SCSI: vm 1036: 109: Sync CR at 16
May 30 15:07:20 xxx vmkernel: 13:16:28:58.888 cpu6:1036)SCSI: vm 1036: 109: Sync CR at 0
May 30 15:07:20 xxx vmkernel: 13:16:28:58.888 cpu6:1036)WARNING: SCSI: 119: Failing I/O due to too many reservation conflicts
May 30 15:07:20 xxx vmkernel: 13:16:28:58.888 cpu6:1036)WARNING: J3: 1625: Error freeing journal block (returned 0) for 47xxxhashxxx: SCSI reservation conflict
I tried just tried converting just the c: but it still fails. I am running another attempt to a different destination host now. Next attempt I will do the firmware upgrade and then try it again.
Latest update....after spinnning my wheels since Monday trying everything under the sun I called VMware. They narrowed it down to a "network" issue. I changed the Speed\duplex from auto to 100\full. The conversion (hot) is currently at 7%.