Перенести машину из vmware workstation в esxi

Обновлено: 07.07.2024

Доброго времени суток! Миграция физических серверов на VMware ESXi через VMware Converter Standalone дело довольно обычное и каждый системный администратор рано или поздно с этим столкнётся. Сейчас я вам покажу как можно перенести вашу физическую рабочую машину или сервер на гипервизор VMware ESXi при помощи Converter Standalone. А также постараюсь сразу же рассмотреть все возможные трудности при переносе.

Установка Converter Standalone

Для начала нам необходимо будет скачать и установить саму программу vCenter Converter Standalone.

О переносе систем на ESXi

Для переноса системы в виртуальную среду ESXi есть два типа: Powered off и Powered on.

  • Powered off
  • VMware Infrastructure virtual machine — инфраструктура на базе VMware (другая ESXi)
  • VMware Workstation or other VMware virtual machine — любая виртуальная машина от VMware
  • Hyper-V Server — с виндового гипервизора
  • Powered on
  • Remote Windows machine — удалённая машина на ОС Windwos
  • Remote Linux machine — удалённая машина на ОС Linux
  • This loacl machine — текущая система, на которой мы запустили Standalone

Powered off

В случае переноса с гипервизора на гипервизор тут всё очень просто и зачастую без сюрпризов. Выбираем источник (гипервизор с которого будем переносить виртуалку) и назначение (гипервизор куда будем переносить виртуалку), конфигурируем машину если это нужно и запускаем процедуру переноса. Соответственно вас программа будет спрашивать данные для подключения к гипервизорам. И не забываем, что предварительно нужно потушить переносимую виртуалку!

Powered on

Для начала не забываем запускать сам Converter Standalone от имени Администратора!

Перенос операционной системы в гипервизор ESXi при помощи This loacl machine

При нажатии Convert machine перед нами появляется окно настроек для конвертации машины/сервера на гипервизор ESXi. Сейчас нас интересует тип источника Powered on. А если конкретно , то This local machine (Эта локальная машина). Это значит, что мы будем переносить текущую систему из под которой и запустили Standalone Converter.

VMware vCenter Converter Standalone нужно запускать от имени Администратора!

source system: this local machine

Далее всё просто. Destination System это то, куда мы собираемся перенести нашу рабочую среду. Указываем VMware Infrastructure virtual machine и чуть ниже прописываем параметры для подключения к гипервизору (ip адрес, имя пользователя и пароль).

Destination System

Обзываем нашу систему.

Destination Virtual Machine

В Destination Location указываем в какое хранилище мы будем переносить систему. Отображаются для информации: объём хранилища, занимаемое и свободное место.

Destination location

А вот тут я бы остановился поподробнее. Так как у нас на гипервизоре место не резиновое, то его нужно экономить. В настройках Data to copy справа прожимаем кнопку Edit и проваливаемся в настройки наших томов.

options

Тут то мы и пошаманим немного. Для начала отсекаем все ненужные тома. В моём случае это был том D, так как все 232,32 Gb были абсолютно неиспользованные и раздувать ими образ виртуальной машины нет никакого желания. Идём дальше. Системный диск занимает 43,41 Gb, но к нему я сделаю +10 Gb. Так как совсем ужиматься тоже не стоит.

Select volumes

Дальше запускаем конвертацию и можем наблюдать в колонке Status прогресс конвертации/переноса вашей рабочей машины на гипервизор ESXi.

Start convertation job

Перенос операционной системы в гипервизор ESXi при помощи Remote Windows machine

Тут процедура точно такая же, только вместо Powered on выбираем Powered off и Remote Windows machine, а поскольку это машина удалённая, то нам нужно будет дополнительно прописать доступы к ней (ip адрес, имя пользователя и пароль). После того как соединение с машиной-источником установим нам будет предложено выбрать в диалоговом окне каким образом мы удалим с конвертируемой машины агента Standalone. Автоматически после переноса или самостоятельно своими ручками чуть позже.

Conver Standalone agent

Дальше процесс никак не отличается от клонирования локальной машины. Не вижу смысла повторять одно и тоже по нескольку раз.

Возможные проблемы

Рекомендую для начала проверить саму систему на наличие повреждений системных файлов. Запускаем командную строку от имени администратора и выполняем sfc:

Unable to contact the specified host

VMware vCenter Converter Standalone Unable to contact the specified host 'ip_address'. The host might not be available on the network, there might be a network configuration problem, or the management services on this host are not responding.

Зачастую это связано с тем, что на вашей системе или на удаленной ОС закрыты порты 443 и/или 80.

А также причиной может быть фаервол или встроенный Windows Defender. На время миграции машины на гипервизор попробуйте отключить защиту.

Permission to perform this operation was denied

Permission to perform this operation was denied

Тут говорится, что нехватает прав. Но почему? Я ведь и так администратор, в чём дело? Мы знаем, что Standalone был запушен от имени администратора, да и к удаленной системе мы также подключаемся к учётной записи администратора. Так вот. Причиной такого поведения может послужить UAC (контроль учётных записей).

Permission to perform this operation was denied

Insufficient permissions to connect to admin$

ошибка Insufficient permissions to connect to admin$

Решение. Способ 1

Открываем в реестре regedit следующую ветку:

Открываем и редактируем реестр

Там необходимо создать параметр DWORD 32-bit LocalAccountTokenFilterPolicy и присвоить ему параметр 1. После сохранения перезагрузите ОС для применения изменений.

Решение. Способ 2

Также в каких-то случаях помогает следующая процедура: Открываем групповые политики gpedit.msc и переходим в раздел

Открываем и редактируем групповые политики

И нас в этом разделе интересует политика Сетевой доступ: модель общего доступа и безопасности для локальных учетных записей. Политику необходимо изменить на Обычная - локальные пользователи удостоверяются как они сами. После сохранения перезагрузите ОС для применения изменений.

Решение. Способ 3

Открываем оснастку общих папок fsmgmt.msc и смотрим что папка ADMIN$ присутствует в списке общих ресурсов. Если её нет — возвращаем. По итогу у вас должен открываться каталог:

fsmgmt.msc проверяем доступ в оснастке общих папок

Решение. Способ 4

Установить Convertor agent на машине, которую собираетесь переносить на гипервизор.

Установка convertor agent

Ошибка в процессе переноса Error code: 225

В процессе переноса виртуальной машины я получил следующую ошибку где-то на 50%.

FAILED: An error occurred during conversion: 'File-level volume clone error failed with sourcevolume id \WindowsBitmapDriverVolumeId=[. ] and target volume id 44=494. Error code: 225 '

Данную ошибку я решил путем отключения встроенного защитника Windows через стандартное приложение "Настройки".


Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
  • VMware Technology Network
  • :
  • Global
  • :
  • Russian
  • :
  • Russian Discussions
  • :
  • Конвертация физической машины в ESXi
vadr999
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Скачал для экспериментов VMware vCenter Converter Standalone - попробовать сконвертировать физическую машину для переноса на виртуалку. Столкнулся с проблемой (экспериментировал на виртуалке под vmware workstation): можно сконвертить в образ виртуалки, но только под ws. А если есть необходимость переносить под esxi - нужна готовая установка, на которую сразу делается перенос. А что делать, если во время переноса у меня ещё нет установленного esxi? То есть (как я уже писал в другой теме) я хочу перекинуть винчестера с физического сервера (к моменту снятия дисков уже образ должен быть готов) на внешнюю СХД (только после этого можно будет ставить esxi)?

Finikiez
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Возможно в 6.1 убрали поддержку конвертирования имеджей.

Попробуйте 6.0, по крайней мере там в release notes про них еще пишут.

Finikiez
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Хороший способ - сделать образ, например, акронисом.

Далее ставите ESXi, куда-нибудь конвертер и в качестве источника указываете образ, сделанный акронисом.

Список поддерживаемых версий акрониса есть в релиз нотс к конвертеру.

vadr999
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Спасибо, вариант интересный.

vadr999
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Ещё попутно вопрос. Понятно, что всё железо, представленное в физическом сервере, будет заменено на виртуальные драйвера esxi - не будет там никаких raid-контроллеров, ибо об этом собственно esxi и заботится. Но вот в моём случае - в системе 2 сетевых адаптера от intel, которые объединены в team с функцией switch fault tolerance, объединены в виртуальный адаптер, которому собственно и назначены все настройки. Что будет в esxi? Понятно, что те же 2 адаптера так же будут включены в 2 свитча, переключение будет настроено в esxi - и по сути виртуальному серверу уже понадобится только одна виртуальная сетевуха, ибо все остальные функуии отданы "наверх". Это получается - небольшая доработка вручную после конвертации?

Finikiez
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

В процессе прохождения визарда вам нужно будет просто указать виртуальный сетевой адаптер и куда его подключать.

Неиспользуемые сетевые соединения просто удалите изнутри гостевой ОС после конвертации.

vadr999
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Чойто не могу найти найти правильный пункт в визарде. В документации написано - поддерживаются "Third-party virtual machines or system images", надо выбрать "B ackup image or third-party virtual machine", а в визарде такого пункта нет (см. скриншот). Версия - 6.1.1 build-3533064. Пробовал на виртуальной win7 x64 под vmware workstation 12 и на физической под win8.1 x64.

Хочу поделиться опытом своей команды по миграции с древнего VMware Server 2.0 на ESXi 4.1. В ходе оптимизации расходов на обслуживание перед нами встала задача уйти с сильно подтормаживавшего VMware Server под виндой на бесплатный ESXi. Задача усложнялась территориальной распределённостью серверов (по всей России) и сжатыми сроками, в которые необходимо было это сделать.

  1. Полтора десятка серверов в удалённых локациях. Возьмём за данность, что они имеют интерфейс удалённого управления (DRAC/ILO/IP KVM). Без этого миграция сильно усложняется большим количеством командировок.
  2. На серверах крутится по 3 виртуальных машины — контроллер домена, работающий также как DNS и DHCP-сервер (виртуальный диск 40 гигабайт), WSUS + хранилище дистрибутивов (150 гигабайт), и сервер, сканирующий сеть филиала на уязвимости (ещё 40 гигабайт).
  3. Промежуточных серверов, на которые можно было бы временно поставить ещё один ESXi и осуществить конвертацию на него «живых» машин у нас нет, но для хранения слитой информации у нас есть файлсервера, подключённые с нашими серверами в тот же свитч — в лучшем случае гигабитный, но чаще всего 100 мегабит.
  4. На все сервера у нас есть админские права через AD-группы (в большой компании это не всегда так, но в данном случае мы их получили). Паролей локального админа на эти сервера у нас нет.

Вопрос «как» после курения манов и чтения выдачи гугла был решён в пользу копирования всей директории виртуальной машины с гипервизор-сервера на файл-сервер с последующей её обратной заливкой на свежеустановленный ESXi при помощи VMware Converter. На пилотном сервере выяснилось, что скорость конвертации (а точнее, заливки конвертером vmdk-файла на хост-машину с ESXi) оставляет желать лучшего — всё-таки SCP. Но другие варианты (например, были идеи включить самбу на ESXi и залить образы напрямую в датастор) в итоге утыкались в неподдерживаемые VMware сценарии вроде правки vmdk и vmx-файлов, к которым прибегать не хотелось. Вариант с использованием VMware-vdiskmanager не понравился по причине того, что не хотелось пересоздавать конфигурацию виртуалки с нуля, да и не на всех дисках почему-то получилось безболезненно его прогнать.

Ответ на вопрос «сколько времени займёт» на пилотном сервере показал, что суммарное время занимает около трёх суток, включая время копирования виртуальных машин туда и обратно. Это много, нужно ускорять, а главное — не мешать работать бизнесу. Первая мысль — делать на выходных, а операции копирования производить ночью. Бизнес будет недоволен только при отсутствии DHCP/DNS, значит эта машина у нас приоритетнее, и ей надо уделить наибольшее внимание — даже на выходных есть желающие поработать.

Итак, что получилось в итоге, по шагам:

Подготовка
Проверяем удалённый доступ через DRAC/ILO, свободное место на файлсервере, на файлсервер же ставим VMware Standalone Converter и VSphere Client. На контроллер домена также устанавливаем Standalone Converter. Копируем на файлсервер ISO-дистрибутивы (в случае если у нас DRAC/ILO) или режем болванку. Очень желательно сделать бэкап System State контроллера домена. Записываем сетевые настройки всех виртуалок.

  1. Необходимо зайти под админским AD-логином на все виртуалки — это очень пригодится, если что-то случится с сетевыми настройками (а оно случится — сетевая карточка под ESXi увидится гостевой ОС как новое устройство), можно будет зайти с закешированным паролем.
  2. Гасим все машины, кроме контроллера домена. Ждём, пока VMware удалит временные рабочие файлы машин (минут 5), затем на ночь ставим копирование папок со второй и третьей виртуалками на файлсервер
  1. Выключаем и копируем контроллер домена аналогично пятничным серверам.
  2. Устанавливаем ESXi и апдейты, конфигурируем сеть, датасторы итд.
  3. Запускаем Standalone Converter на файлсервере. Конвертируем контроллер домена. Это примерно 5 часов при 100-мегабитном линке. Восстанавливаем сетевые настройки контроллера.
  4. Теперь у нас есть гостевая винда, а с неё-то конвертер будет работать быстрее. Как показала практика, в несколько раз. С контроллера домена конвертируем наш WSUS, а на файлсервере в параллели — третий сервер. Закончится их конвертация примерно одновременно.

Итого, мы получили схему с крайне небольшим временем человеческого участия и распараллеливанием задач, что позволило одному человеку за выходные «окучить» 3 и более филиалов.

Если кто-то найдёт недочёты в том, что мы напридумали или знает, как ещё ускорить процесс — буду только рад, учиться всегда хорошо.

With only three VMs on my local machine, it was eating up more than three-fourths of my SSD drive. Instead, I purchased a refurbished Dell PowerEdge server, installed VMware ESXI and then transferred my Workstation virtual machines to the server.

Step 1: Connect to ESXi Server

The first thing we will do is connect Workstation to the local ESXi server. To do this, just click on File and then Connect to Server.


A window will popup where you will need to enter the ESXi server hostname or IP address and the login info.


Click Connect and you should see some basic info about the ESXi server at the top and a list of any virtual machines at the bottom.


Step 2: Change Hardware Compatibility

Before we upload the virtual machine, we first need to change the hardware compatibility. You only need to do this if you are running the latest VMware Workstation 14 and have already upgraded the hardware compatibility to 14.


I would choose the latest version that works, such as 12.x or ESXi 6.5 from the list.


Step 3: Upload the VM to ESXi

Now we are ready to upload the VM. To do this, again click on VM, then Manage and now click on Upload.


If you connected to the ESXi server in step 1, then you should see the IP address or hostname listed in the Upload Virtual Machine Wizard.


Click Next and then choose which Datastore you want to use for storing the new VM. It should tell you the amount of free space left on that datastore also.


Click Finish and the upload process will begin. Note that it can take a significant amount of time to upload the VM, especially if it is very large.


Once it has been uploaded, you should see it listed when you click on the tab for the ESXi server you are connected to.



Founder of The Back Room Tech and managing editor. He began blogging in 2007 and quit his job in 2010 to blog full-time. He has over 15 years of industry experience in IT and holds several technical certifications. Read Aseem's Full Bio

Читайте также: