Resolving VMWare Converter File I/O Error

Posted: January 21, 2016 in Servers, VM
Tags: , , , ,

Here at CF Webtools we’ve been shifting towards Virtual Machines to replace our dedicated “iron” as Mark Kruger likes to say. Let me say for starters that I’m very impressed with the Dell PowerEdge VRTX Shared Infrastructure Platform. There is so much back-end power in that thing we’ve been able to move our entire set of staging platforms onto one M620 Server Node along with a RAID 6 shared PERC disk array. It handles it like a champ and each virtual server is extremely fast. After about a year of testing and no real issues we’ve been able to move some of our production servers onto another server node. We’re looking forward to adding a couple more server nodes as well. Each node runs VMware ESXi HyperVisor 6.0 via RAID 1 SD cards.

In addition we’re also migrating some workstation VM’s away from Hyper-V and onto a separate Dell Server that we’ve reclaimed.

vcenterconverter61But here’s the real reason I’m writing today:

FAILED: A file I/O error occurred while accessing ”.

I get this error when using “WMware vcenter Converter Standalone 6.0.0” to convert any powered-on Windows machines onto one of the ESXi instances. I don’t get this issue when converting power-on Linux machines. Very odd and Google results of forums haven’t been very helpful. Mostly just a lot of run chkdsk and check for fully qualified domain resolutions.

I’m not going to cover Linux conversions here since they work. But basically what a powered-on Windows conversion does is it installs a helper VM on the machine to be converted. It’s run as a service and you have the option to manually uninstall when finished or let it automatically uninstall.

Something, probably this helper service, then takes a snapshot of the source system. Then the helper VM does a block-level clone for each volume it finds.

Mine always failed after the snapshot and before the clone.

What I did was used the “Export logs…” link in the converter. The line I found interesting, reading the file vmware-converter-server-1.log, was:

error vmware-converter-server[01288] [Originator@6876 sub=Ufa.HTTPService] Failed to read request; stream: <io_obj p:0x03dc40ac, h:-1, <pipe ‘\\.\pipe\vmware-converter-server-soap’>, <pipe ‘\\.\pipe\vmware-converter-server-soap’>>, error: class Vmacore::TimeoutException(Operation timed out)

After some Google searching it dawned on me that I am using two IP subnets. One for the general network and one for management. My machine runs 10.0.0.* (general) and 10.1.1.* (management) subnets. The source system has 10.0.0.* assigned to it while the destination ESXi server has 10.1.1.* assigned to it.

Because my system can communicate with both networks, everything could communicate just fine with both the source and destination machines.

However once things get rolling, the process moves from my machine to communicating between the source and destination. My machine merely monitors the progress. Which makes sense. Keep out the middle man and you have efficient network data transfer.

So the fix here was to bind a temporary management subnet address (10.1.1.*) to the source machine’s NIC. Now the helper VM is able to communicate with the destination server over that management subnet.

Full disclosure: I’m writing this as the first successful one is still working. I did change the 10.0.0.* subnet to and the 10.1.1.* subnet to to cover all ground. In addition I installed the converter application on the source machine. However I’m 99% positive that only the addition of the management network subnet to the source machine was the true fix.

Notes: I also just noticed that 6.1 was released. The above is for 6.0. I had been trying to convert some Hyper-V VM’s but those were a pain and Windows 7 just never got past the “Blue Screen of Death”. That’s why I revisited converting a “powered on” machine error. Hopeful that gets me somehwere.

  1. msteurer says:

    Ran into exactly the same situation with different subnets, using Converter 6.1.1.
    Enabling direct communication between source and target machine removed the “Failed to read request”-error, but the I/O-Error persists.
    What got it working is the “Proxy mode” – not efficient, but at least it works.

    • moss5000 says:

      Hi, any chance of some elaboration on how to enable /setup ‘proxy mode’?


    • nixman says:

      I got the same error message – “A File I/O Error Occurred while accessing “. ”
      We use static IP’s on our server equipment and the VMware Converter correctly identified the FQDN for my source.

      Where I used it the vCenter destination for the VMware Converter was located in a different DMZ than the source I was running the VMware Converter from. I had previously allowed TCP/443 on my firewall for traffic to the vCenter from the source, but also had to allow TCP/902 from the source I was running VMware Converter on to access the cluster (management) IP’s of my VMware hardware.

      It looks like the VMware Converter establishes the connection to the vCenter (as the destination “manager” for the clone to be created), but then allows the VMware Converter source to directly “talk to” the cluster (on one of it’s IP’s) to stream the virtual to the storage for creation.

      Probably does the same in another way as to select “proxy mode”.

  2. Sagy says:

    Thank you

  3. nikhilvolga says:

    it is very likely you have a problem with your DNS for your hosts.Check in C:\ProgramData\VMware\VMware vCenter Converter Standalone\logs and look for the vmware-converter-worker-*.txt files. you will probably find strings such as “Error: Host address lookup for server failed: No such host is known” Fix these DNS issues

    1) turn off windows firewall, create ACL in your gateway[ better provide any any bidirectional access if you are not sure abouth tcp/udp ports]
    2) Remove proxy settings from ie

    3) create dns entry for the source server or add hosts file entry as follows [c:\windows\system32\drivers\etc\hosts]
    check your source server hostname ” cmd–> hostname][real hostname of source/physical server] [vcenter fqdn]

  4. Jude says:

    Same error. Worked once the systems were placed on the same subnet with no firewall rules between

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s