- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hm, just a wild guess, but can you try to connect to Converter Server using IP address instead of connecting to local server? I mean you would still connect to the local server, but through the network interface. If you have installed it locally on the source then you can connect to 127.0.0.1. If you have installed Converter in local mode (default) then you would need to run the installer again, select the Modify option and add the Remote connection feature.
If this doesn’t help you can try to install the Converter Server on another machine and point it to the physical source.
__________
It is worse!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It’s very likely you have a problem with the DNS for one or more of your hosts. Check in C:ProgramDataVMwareVMware vCenter Converter Standalonelogs and look for the vmware-converter-worker-*.txt files. You’ll probably find strings such as «Error: Host address lookup for server <yourhostname> failed: No such host is known» Fix these DNS issues (NB: you might have the DNS records setup correctly, but an incorrect search suffix on your converter server) and vConverter will magically start working.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Many thanks!! That was exactly the problem I was having. The host I was trying to convert wasn’t resolving the FQDN for the VMware host that the converter had chosen as a destination. Once I fixed that (by changing the DNS primary entry in the nic configuration on the host I was trying to convert) all worked well!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes this seems to be a bug in the Converter 6.1 as well. Only seen it so far with Windows XP conversion, since i don’t do much converting. There is some strange DNS dependency in the chain somewhere. Go ahead and edit the *hosts* file on the machine you are converting «source». (if you aren’t update-able DNS servers). You will want to add an entry for the ESXi host you are using as a destination. <ip-address> <FQDN>
10.10.10.2 host.domain.com
If you are using a Vcenter server to connect with, i would add that in as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On my windows where I installed vcenter converter I added the vmware hypervisor names to the c:WindowsSystem32driversetchosts file:
192.168.1.5 Hypervisor.local
You find the Domain Name of the hypervisor in the:
— vSphere Client => hypervisor name or IP => configuration => DNS and Routing:
Name: Hypervisor
Domain: local
— vSphere Web Client => in the title of the left window
After adding the HOSTS entry converter worked perfectly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got the same error message. 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Gibson, I got the issue before, to fix this you have to make sure the following > Firewall have to be disabled for both Converter Host Server, Destination Server and Source Server > vCenter Port (443) and ESXi Port (902) should be allowed in the Firewall > Update your Host File putting all the Host Name and Its IP of the Destination and vCenter Converter Server to Source Server > Update your Host File putting all the Host Name and Its IP of the Source to vCenter Server > Make sure Anivirus for both Source and vCenter Converter server/host is disabled. In some cases, Any antivirus will unexpectedly close/block the connection. *** Source (Can be Physical or Virtual) *** Destination (Your ESXi Host/DataStore) Let us know if it works. Good Luck Man! Keep Virtualizing! Regards, JOf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Обновлено 23.07.2018
Добрый день! Уважаемые читатели и гости блога pyatilistnik.org. Продолжаем с вами изучать технологии виртуализации компании Vmware. В прошлый раз мы с вами успешно устранили ошибку: The host returns esxupdate error code:99. Сегодня я же хочу вам показать, из-за чего вы в VMware vCenter Converter Standalone, можете на последнем шаге мастера увидеть ошибку «A File I/O error occurred while accessing«, не дающую вам произвести преобразование физического сервера в виртуальный, так называемый P2V от Vmware. Уверен, что данный материал, хоть и не большой по объему, окажется полезным, для начинающих администраторов.
Как выглядит ошибка I/O в VMware vCenter Converter Standalone
Как видите, когда я дошел до самого последнего шага на вкладке «Summary» и только осталось нажать на кнопку «Finish», чтобы запустить процесс конвертации физического сервера в виртуальный, у меня выскочило оповещение в виде ошибки:
A File I/O error occurred while accessing
Которое дальше не позволяет, что либо сделать.
Вся проблема в том, что у вас при конвертации P2V, должны быть соблюдены три вещи:
- У вас должны быть права локального администратора, на том физическом сервере, который вы будите преобразовывать
- У вас должны быть права на Vmware ESXI хост или vCenter сервер, который будет конечной точкой
- Вы должны отключить UAC, либо же запустить VMware vCenter Converter Standalone от имени администратора
Если у вас не соблюдены все эти требования, то вы и будите получать данную ошибку. Зачастую, самой частой причиной является, именно третий пункт с UAC, так что щелкайте по ярлыку конвертера правым кликом и открывайте его от имени администратора, проблем с конвертацией не будет. Надеюсь, эта маленькая заметка помогла вам и позволила создать еще одну виртуальную машину. Если у вас есть альтернативные методы решения ошибки «A File I/O error occurred while accessing», то не поленитесь, о них написать в комментариях, давайте делиться знаниями. Материал сайта pyatilistnik.org.
Июл 23, 2018 21:37
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.
But 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 ‘\.pipevmware-converter-server-soap’>, <pipe ‘\.pipevmware-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 255.0.0.0 and the 10.1.1.* subnet to 255.0.0.0 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.
#convert, #esxi, #file-io-error, #vmware, #windows
- Home
- Virtualization
- VMware
- How-tos
-
Share
Opens a new window
-
Facebook
Opens a new window -
Twitter
Opens a new window -
Reddit
Opens a new window -
LinkedIn
Opens a new window
-
Sign Up
-
-
December 21 2016, 14:31
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:
, >, 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 255.0.0.0 and the 10.1.1.* subnet to 255.0.0.0 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.
Казалось бы всё правильно сделал разделив сети, а нет, вот они ньюансы.
взято отсюда:
На чтение 6 мин. Просмотров 50 Опубликовано 15.12.2019
Содержание
- Обычный блокнот админа
- [VMware] vCenter Converter Standalone error
- Ошибка A File I/O error occurred while accessing
- Ошибка A File I/O error occurred while accessing
- Как выглядит ошибка I/O в VMware vCenter Converter Standalone
Обычный блокнот админа
[VMware] vCenter Converter Standalone error
Привет, %username% ! Бывают ситуации когда единственное решение это конвертировать физический сервер в виртуальный. Ошибка с которой я столкнулся при работе с конвертером звучит вот так A file i/o error occurred while accessing . Рассмотрим когда она возникает и как её лечить.
Все довольно просто, но далеко не очевидно. Первое: Возникает она в случае если у вас установлен конвертер последней (на текущий момент) версии 6.2.0.1 , а сам vCenter установлен версии 6.0 . Вылечить это можно простым понижением версии (удалить новую и поставить старую) самого конвертера. Второе и это совсем не очевидно (по крайней мере для меня было совсем не очевидно): в наших реалиях на площадке где был развернут кластер ESXi , для самих хостов ESXi использовалась одна подсеть, а для доступа к ней через vCenter использовалась совершенно другая подсеть.
Что было
У нас была виртуала с Windows 10 и vCenter Converter Standalone в нашей сети (на площадке нашего офиса), а кластер из хостов ESXi расположен в ЦОДе. Доступ к веб-морде vCenter есть, но этого оказалось не достаточно. При добавлении задания в конвертер (использовалась версия 6.0 Release date 2015-05-14 ), вылетала ошибка гласящая “A file i/o error occurred while accessing”. Задание на конвертацию включало в себя примерно следующее: конвертировать физический сервер в виртуальный с небольшими изменениями (название ВМ, IP/DNS). Сервер на CentOS 7 x64 с установленным PostgreSQL в режиме slave база которого занимает около 2TB. Доступ к самому серверу из конвертера осуществляется по ssh с ключом (не буду признаваться, что пароль root’а никто не помнит, а сбрасывать его лень).
Что делать
Так вот: ошибка эта должна вам говорить о том, что ваш конвертер не может достучаться до хостов на которых развернут ESXi. И решением этой проблемы будет внесение записей в файл hosts на вашей Windows с IP-адресами и hostname самих хостов ESXi (ну очевидно же). После внесения соответствующих записей задание добавляется и запускается. Объяснили мне это тем, что конвертер при добавлении задания выбирает подходящий хост ESXi и запихивает на него эту новую виртуалку.
Ошибка A file i/o error occurred while accessing решается добавлением записей о хостах ESXi в файл hosts
Ошибка A File I/O error occurred while accessing
Ошибка A File I/O error occurred while accessing
Добрый день! Уважаемые читатели и гости блога pyatilistnik.org. Продолжаем с вами изучать технологии виртуализации компании Vmware. В прошлый раз мы с вами успешно устранили ошибку: The host returns esxupdate error code:99. Сегодня я же хочу вам показать, из-за чего вы в VMware vCenter Converter Standalone, можете на последнем шаге мастера увидеть ошибку «A File I/O error occurred while accessing«, не дающую вам произвести преобразование физического сервера в виртуальный, так называемый P2V от Vmware. Уверен, что данный материал, хоть и не большой по объему, окажется полезным, для начинающих администраторов.
Как выглядит ошибка I/O в VMware vCenter Converter Standalone
Как видите, когда я дошел до самого последнего шага на вкладке «Summary» и только осталось нажать на кнопку «Finish», чтобы запустить процесс конвертации физического сервера в виртуальный, у меня выскочило оповещение в виде ошибки:
Которое дальше не позволяет, что либо сделать.
Вся проблема в том, что у вас при конвертации P2V, должны быть соблюдены три вещи:
- У вас должны быть права локального администратора, на том физическом сервере, который вы будите преобразовывать
- У вас должны быть права на Vmware ESXI хост или vCenter сервер, который будет конечной точкой
- Вы должны отключить UAC, либо же запустить VMware vCenter Converter Standalone от имени администратора
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: ,
>, 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 255.0.0.0 and the 10.1.1.* subnet to 255.0.0.0 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.
Казалось бы всё правильно сделал разделив сети, а нет, вот они ньюансы.
Итак, как видно из названия, рассмотрим проблемы с vCenter Converter при конвертировании физических Windows серверов. Очень часто сталкиваюсь с проблемами виртуализации серверов 2008 и 2008 R2, на 2012 не сталкивался и пока везло и вопросы с виртуализацией 2003-го динозавра тоже не появлялись. Как правило симптомы и их причины достаточно одинаковы от случая к случаю и в комьюнити широко известны, да и блоги не молчат. Итак, вот список часто встречающихся проблем, по крайней мере мне.
При установки vCenter Converter Agent на виртуализируемую Windows машину возникает длительное ожидание процесса установки а в конце победоносно прилетает ошибка — ERROR 1053 “ The service did not respond to the start or control request in a timely fashion ”. Данная проблема известна VMware как ни странно это из-за отсутствия доступа в интернет с машины, на которой устанавливается служба конвертера, это кстати относится как к машине, на которой разворачивается консоль vCenter Converter, так и виртуализируемой машину, на которуя в процессе ставиться vCenter Converter Agent. Смотрим цитату из Release Notes. Собственно, в ней же и решение. Запустив regedit в CMD и создать параметр реестра (DWORD) по пути HKEY_LOCAL_MACHINESystemCurrentControlSetControl с именем ServicesPipeTimeout и деситичным (decemical) значением не ниже 300000 (5 minutes), после этого перезагрузить машину для применения изменений. После этих манипуляций проблема решается.
Проблема, появляющаяся так же, как и предыдущая при инсталляции агента конвертации на виртуализируемую Windows машину. «Error 1603: A fatal error occurred during installation» преследует нас по причине слишком долгого ожидания старта службы vCenter Converter Agent после ее установки. Решение то же самое, что и для предыдущей проблемы.
При конфигурировании задачи конвертации (Job), в самом начале, после того как мы заполнили данные логин и пароля source машины и нажали Next, нам вываливается “Permission to perform this operation was denied”, и даже после того как мы запустим конфертер от имени администратора, данная проблема не уходит. Досконально в чем причина сказать не могу, но есть решение, которое мне помогло. Итак, логинимся на конвертируемый Windows сервер, заходим в Local Security Policy (открывая в cmd secpol.msc), идем в Local Policies > Security Options, пункт «User Access Control: Run all Administrators in Admin Approval Mode» переводим в Disable, перезагружаем машину. И после этого у Вас должно все получиться.
Когда мы уже запустили наш Job по конвертации Windows машины и радостные пошли пить кофе, на 1% прогресса появляется «A file I/O error occurred while accesssing» и задача останавливается. Странная проблема, в комьюнити грешат на некорректную насройку DNS на конвертируемой машине, в следствии чего машина по имени не могла достучаться до ESXi, но в моем случае с DNS было все в порядке. Мне помог запуск Job через включение галочки PROXY при настройке подключения в vCenter, этот же метод помог и нескольким другим людям.
На всякий случай приложу список необходимых портов для работы vCenter Converter:
Windows P2V
| Communication Paths | Communication Ports | Notes |
| Converter Standalone server to powered on source machine | TCP — 445, 139, 9089 UDP — 137, 138 | If the source computer uses NetBIOS, port 445 is not required. If NetBIOS is not being used, ports 137, 138, and 139 are not required. When in doubt, make sure that none of the ports are blocked. Note: Unless you have installed Converter Standalone server or agent on the source computer, the account used for authentication to the source computer must have a password, the source computer must have network file sharing enabled, and it cannot be using Simple File Sharing. |
| Converter Standalone server to vCenter Server | TCP — 443 | Required only if the conversion destination is vCenter Server. |
| Converter Standalone client to vCenter Server | TCP — 443 | Required only if the Converter Standalone server and client components are on different machines. |
| Converter Standalone server to the destination ESXi | TCP — 902 | Converter server always requires access to ESXi at port 902. |
| Powered on source machine to ESXi | TCP — 443, 902 | If the conversion destination is vCenter Server, only port 902 is required. If the proxy mode feature is on, port 902 is not required. |
Linux P2V
| Communication Paths | TCP Ports | Notes |
| Converter Standalone server to powered on source machine | 22 | Used to establish an SSH connection between the Converter Standalone server and the source machine. |
| Converter Standalone client to Converter Standalone server | 443 | Required only if the Converter Standalone server and client components are on different machines. |
| Converter Standalone server to vCenter Server | 443 | Required only if the conversion destination is a vCenter Server. |
| Converter Standalone server to ESXi | 443, 902 | If the conversion destination is a vCenter Server, only port 902 is required. |
| Converter Standalone server to helper virtual machine | 443 | |
| Helper virtual machine to powered on source machine | 22 | Used to establish an SSH connection between the helper virtual machine and the source machine. By default, the IP address of the helper virtual machine is assigned by DHCP. If no DHCP server is available on the destination network, you must manually assign the helper virtual machine an IP address. |