Обычный блокнот админа
[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.
Казалось бы всё правильно сделал разделив сети, а нет, вот они ньюансы.