Копирование виртуальной машины vmware esxi
Копирование виртуальной машины vmware esxi
Добрый день уважаемые читатели, не так давно, мы с вами разбирали процесс клонирования виртуальных машин Hyper-V, сегодня же мы с вами разберем, его главное конкурента, а именно гипервизор ESXI, в котором мы так же произведем клонирование виртуальной машины VMware. Сам процесс не сложный, но может у начинающих системных администраторов вызывать ряд вопросов, на которые я отвечу в этой статье.
Принцип клонирования
Ниже опишу первый метод и последний, остальные уже имеют свои подробные статьи.
Копирование файлов VM
Находим нужный ESXI хост, выбираем нужный вам дисковый массив (Datastore) и щелкаем по нему правым кликом мыши, из контекстного меню выбирает «Browse Datastore».
Выбираем нужную папку и из контекстного меню пункт «Copy», далее с помощью встроенного проводника, перемещаем ее в нужное местоположение, можно назвать это таким клонированием виртуальной машины VMware, для бедных.
Далее, на новом месте, открываете папку и щелкаете правым кликом по файлу с расширением *.vmtx, это конфигурационный файл. По сути на этом все. Лично я, чтобы получить доступ к файловой системе ESXI использую WinSCP, либо вы еще можете воспользоваться функциями OVA шаблона.
Копирование VM с помощью vCenter
У тех товарищей, кто централизованно управляет своей инфраструктурой, данная функция присутствует при установке. Ее преимущество в том, что клонировать можно как работающую, так и не работающую виртуальную машину. Выбираем нужную и щелкаем по ней правым кликом, в контекстном меню видим пункт «Clone».
На первом окне мастера вас спросят выбрать локацию (Datacenter)
Указываем хост назначения, если он подходит, вы увидите сообщение «Validation succeded»
Если же нет, то вы увидите сообщения:
На следующем шаге клонирования, вам необходимо выбрать тип дисков ESXI и место назначения копии машины.
Выбрав пункт «Customise using an existing customization specification» вы сможете применить заранее подготовленные файлы кастомизации.
Если же выберите «Custome using the Customization Wizard», то откроете мастер кастомизации, состоящий из:
Надеюсь после прочтения данной статьи, вы смогли найти ответы, как клонировать vm в VMware ESXI.
2keep.net
IT-Blog
Клонирование виртуальной машины VMware ESXi с помощью vSphere Client
Имеется бесплатная версия VMware ESXi 5.5. Необходимо клонировать существующую виртуальную машину с установленным Linux Debian на котором крутится система Service Desk OTRS.
Решение
Для того, что бы клонировать виртуальную машину на ESXi с помощью VMware vSphere Client необходимо:
VMware vSphere Client, закладка «Configuration»
Пойдет процесс копирования файлов конфигурации и диска виртуальной машины.
VMware vSphere Client, Datastore Browser
VMware vSphere Client, Add to Inventory
Важное замечание!
Если в копируемой VM присутствую snapshot’ы их нужно или удалить перед копированием или скопировать вместе с другими файлами, иначе во время загрузки новой VM будет ошибка с сообщением о невозможности подгрузить файлы с snapshot’ами.
Загружаем новую виртуальную машину и нажимаем кнопку запуска консоли виртуальной машины,
Запуск консоли виртуальной машины
появится окно с просьбой указать, данная виртуальная машины скопированная или перенесенная виртуальная машину, выберете необходимое.
Похожие записи.
Андрей Торженов
Latest posts by Андрей Торженов (see all)
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Оповещение по e-mail о новых комментариях.
Также вы можете не оставляя комментарий подписаться но новые комментарии.
Бесплатные утилиты для бэкапа с бесплатного ESXI
Как-то появилось у меня несколько персональных проектов, которые требовали относительно много дискового места — около 2TB. Подходящих VPS не нашлось (мало кто предлагает много HDD места), поэтому я взял выделенный сервер у OVH, поставил там ESXI 5.5 с бесплатной лицензией и всё работало.
Через некоторое время, с развитем проектов, я стал настраивать админские фишки — мониторинг, бэкап, и выяснил, что оказывается сервер, в котором мне обещали Soft RAID, и на который хостер (OVH) накатил свой образ ESXI — без RAID! То есть просто 2 диска. Ну да, теперь вот я знаю, что ESXI не поддерживает Soft RAID, только Hard. Стало неуютно. Да и 2TB стало не хватать. В общем взял я себе сервер побольше, с аппаратным RAID и поставил туда ESXI 6.0.
И возникло две задачи, решение которых я тут опишу:
С платной лицензией есть вариант миграции через vCenter. Ещё есть бесплатная версия Veeam Backup, которая позволяет делать бэкапы и переносить виртуальные машины с одной системы на другую и при этом не требуется их останавливать. Но с бесплатной лицензией ESXI, текущая версия — Veeam 9 — не работает вообще.
Ещё есть решение от HP — VM Explorer, у которого есть бесплатный Free Edition.
VM Explorer 6.2 умеет работать с free ESXI, но:
Уверен, что есть и много других вариантов. Будет интересно почитать комментарии опытных админов. Хотя подозреваю, что опытные работают там, где купили нужные лицензии и не парятся…
Здесь можно просто упомянуть:
Я в конечном итоге решил использовать 2 инструмента:
Xsibackup
До версии 4.4 Xsibackup был на Github, но сейчас (версия 6.0.7) с Github’а Xsibackup убрали, теперь инсталлировать надо с сайта авторов.
В бесплатной версии:
Инсталлируется Xsibackup на ESXI хост, с которого нужно делать бэкапы.
На ESXI должен быть включена служба SSH.
Регистрируетесь на сайте авторов — Download xsibackup — 33hops.com/xsibackup-vmware-esxi-backup.html
Вам на email придёт бесплатный ключ и скрипт для инсталлирования на ESXI:
secretKey у вас будет свой.
Если datastore у вас называется по другому — то надо прописать свой путь.
Увидев wget, кто-то может покачать головой, и сказать, что ставить чужой софт на ESXI хост — это несекьюрно и т.д. Однако при любом бэкапе, вы будете отдавать root пароль программе для бэкапа, то есть кому-то доверять вы будете в любом случае. При локальном копировании Xsibackup использует только shell скрипты, которые можно посмотреть и проверить…
Затем создаёте папку, куда будем складывать бэкапы — локально, или на другом сервере:
Если копировать бэкапы будет между хостами, то делимся SSH ключами:
Если хотим, чтоб был бэкапы запускались через крон, то:
Тестируем, что всё работает локально:
Чтобы протестировать работу между хостами, меняем:
Локально, то есть на одном хосте, всё работает отлично: бэкапы делаются с помощью нативной утилиты ESXI — vmkfstools. Всё быстро, и тонкие диски остаются тонкими. С жёсткими дисками, у меня получилась скорость около 60MB/s
Однако при копирование на удалённый хост я обнаружил, ту же проблему, что и с HP VM Explorer — копируется полный размер VM, даже если диск тонкий, и используется только меньшая часть.
Когда я спросил авторов, в чём причина, то они написали, что для копирования между хостами используется rsync, а он недостаточно «умён», чтобы пропускать невыделенные блоки тонких дисков.
При тестировании, я обнаружил, что при повторных бэкапах, rsync практически не сокращает время копирования — по сети опять уходит полный размер VM.
Авторы написали, что в планах у них запилить собственную утилиту вместо rsync, которая будет намного быстрей. Планируют выпустить до конца года.
В моём случае, хостер гарантирует скорость сети в 250Mb/s (
31MB/s), но реально между двумя хостами в одном датацентре бэкап у меня работал на 10-20MB/s. Не знаю в чём тут дело, — тормозит ли это сеть, rsync или что ещё, — но процесс растягивается слишком надолго.
Update: нашёл статью, — по их бенчмаркам выходит, что дело в тормознутом SSH (поверх которого работает rsync), по NFS было бы быстрее.
Радует, что в результате диски таки остаются тонкими.
Процесс переноса и бэкапа VMs
Процесс переноса VMs между хостами выглядит у меня так:
На форумах пишут, что вроде бы есть способ копировать файлы на NFS с опцией sparse так, чтобы передавать только существующие данные, но я пока ещё не разобрался.
Способа делать инкрементальный бэкап я не нашёл.
Пока я это всё делаю вручную из консоли — переношу на другой хост, делаю первый бэкап, но со временем думаю всё настроить через крон. Может позже допишу здесь пару параграфов о том, как настраивать крон. Оригинальные инструкции вот здесь: 33hops.com/xsibackup-cron-how-to.html
Таким образом сейчас у меня первая копия лежит рядом, на том же сервере, и доступна для довольно быстрого восстановления.
Вторая копия — у меня дома, то есть, как и рекомендуют — в физически другом месте. Для восстановления придётся заливать по сети, что существенно медленнее. Но вероятность нужды в этом тоже довольно низкая.
Ovftool
Полное руководство на английском здесь, там же можно и скачать. Ovftool можно ставить к себе на любой компьютер, и управлять гипервизором с него. А можно и поставить прямо на ESXI хост, хотя это и не поддерживаемая возможность.
В общем, процесс такой: сначала Ovftool ставится на Linux x64 (я делал на Ubuntu 16), а затем файлы переносятся на ESXI хост.
Ovftool не умеет копировать VM в горячем режиме, то есть требует, чтобы виртуальная машина была выключена. Поэтому — необходимость в Xsibackup выше.
Несколько особенностей работы Ovftool:
Резервное копирование виртуальных машин в VMware ESXi
Apr 4, 2016 · 11 min read
В этой заметке будет рассмотрено, как создать резервную копию виртуальных машин с помощью скрипта ghettoVCB. Скрипт предназначен для создания бэкапов виртуальных машин в ESX(i) 3.x, 4.x, 5.x и 6.x. Данный способ резервного копирования в отличии от других программных продуктов является абсолютно бесплатным.
Для хранения резервных копий ВМ можно использовать накопители, поддерживающие следующие протоколы:
Но ghettoVCB поддерживает только монтирование и размонтирование NFS-дисков. Для iSCSI следует заранее смонтировать Disk/LUN, а параметры ENABLE_NON_PERSISTENT_NFS и UNMOUNT_NFS установить в нулевое значение (см. ниже).
В данном примере буеде м копировать на NFS с IP-адресом 192.168.3.200, тогда как интерефейс управления гипервизором (Management Network VMkernel) имеет адрес 192.168.0.222 и маску подсети 255.255.0.0.
Настройка резервного копирования.
Итак, первое, что нужно сделать — это включить доступ по SSH к консоли гипервизора: открываем VMware vSphere Client, выбираем хост, открываем вкладку ‘Configuration’ и, как показано на скриншоте:
Во-вторых, убедимся, что на вашем сервере NFS включена опция ‘ async’, существенно ускоряющая процесс копирования. Правда, за скорость приходится платить: есть риск потерять данные в случае крэша NFS-сервера. Если такая вероятность, все же, есть — используйте ‘sync’. В остальных случаях:
В третьих, скачиваем скрипт ghettoVCB с github по клику на ZIP-архив и заргужаем его на ESX/ESXi хост, используя scp, или WinSCP. Советую расположить подальше от корневой директории: на ваш datastore, в папку с виртуальными машинами — будет идеально. У меня это: /vmfs/volumes/datastore1.
Теперь логинимся по SSH в консоль гипервизора под учетной записью root, распаковываем архив и выставляем права:
Создать файл конфигурации необходимо непосредственно в самой консоли гипервизора, используя vi. Ни в коем случае не редактируйте конфигурационный файл в windows-приложениях (таких как: Notepad, Notepad+) с последующей заливкой на хост из-за разных комбинаций кодов перевода строк (CR+LF / LF). Так же во избежание ошибок в работе скрипта избегайте лишних пробелов в конце строк и пустых отступов.
По окончанию редактирования последовательно нажмите: Esc, :, w, q, Enter.
Описание параметров следующее:
VM_BACKUP_VOLUME — путь на сервере ESXi, куда будет монтироваться NFS раздел (или где будет создана резервная копия виртуальных машин — см. параметр ENABLE_NON_PERSISTENT_NFS)
DISK_BACKUP_FORMAT — формат VMDK диска (zeroedthick, eagerzeroedthick, thin, 2gbsparse).
VM_BACKUP_ROTATION_COUNT=4 — количество хранимых бэкапов.
POWER_VM_DOWN_BEFORE_BACKUP=0 — отключать машину перед бэкапом (0=не отключать). Cкрипт может так же копировать и включенные ВМ.
ENABLE_HARD_POWER_OFF=0 — отключать жесткие диски перед бэкапом. Eсли не установлены VMware Tools, то “жесткое” отключение ВМ (hard power off).
ITER_TO_WAIT_SHUTDOWN=3 — если ENABLE_HARD_POWER_OFF=1, то количество минут, прежде, чем скрипт произведет “жесткое” отключение ВМ (hard power off).
POWER_DOWN_TIMEOUT=5 — количество минут, которые скрипт будет ждать при отключении ВМ, прежде, чем проигнорирует её состояние и приступит к резервному копированию.
SNAPSHOT_TIMEOUT=15 — количество минут, которое скрипт будет ждать при создании копии конкретной ВМ, прежде, чем проигнорирует её (в случае каких-либо сбоев в резервном копировании).
ENABLE_COMPRESSION=0 — включение компрессии (0=отключено и остается на zfs). В ESXi 3.x / 4.x / 5.x, существует ограничение максимального размера виртуальной машины для сжатия. При попытке восстановления ВМ свыше ограничений данные могут быть потеряны. Внимательно тестируйте процесс восстановления, прежде, чем перейти к производственным системам.
VM_SNAPSHOT_MEMORY=0 и VM_SNAPSHOT_QUIESCE=0 — используются только для снятия снапшотов с оперативной памяти. Eсли первый параметр “1”, то будет ли переведена машина на этот период в режим ожидания. Первоначально параметр добавлен с целью отладки, а сама опция никак не используется при восстановлении ВМ: любая виртуальная машина, будь то включенная (online), или выключенная (offline), при восстановлении из бэкапа окажется в сосотянии offline.
VMDK_FILES_TO_BACKUP=»my1.vmdk»,”my2.vmdk” — задает список VMDK с определенной VM. Если список пуст, то будут скопированы все VMDK (=all).
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0 — определяет, будет ли создаваться бэкап ВМ со всеми снапшотами.
VM_SHUTDOWN_ORDER=vm1,vm2,vm3 — определяет в каком порядке будут выключены ВМ (если между ними есть какая-либо зависимость).
VM_STARTUP_ORDER=vm3,vm2,vm1 — определяет порядок запуска ВМ.
ENABLE_NON_PERSISTENT_NFS=1 — позволяет подключать NFS-диски (NFS share) для создания бэкапа. Если 0, то параметры UNMOUNT_NFS, NFS_SERVER, NFS_MOUNT, NFS_LOCAL_NAME и NFS_VM_BACKUP_DIR будут проигнорированы.
UNMOUNT_NFS=1 — определяет размонтировать ли NFS-диск по завершению создания бэкапов ВМ.
NFS_SERVER=192.168.3.200 — IP-адрес или имя хоста NFS-диска. Если на сервере ESXi уже есть подключенный NFS диск с такими же координатами (сервер/путь), то диск не подключится.
NFS_MOUNT — путь к NFS диску (NFS export path).
NFS_LOCAL_NAME — имя, которое будет присвоено подключенному диску (datastores ID);
NFS_VM_BACKUP_DIR — путь, где будут создаваться копии ВМ (относительно VM_BACKUP_VOLUME).
RSYNC_LINK=0 — предназначено для синхронизации бэкапов по Rsync. Подробности расписаны здесь.
EMAIL_LOG=1 — определяет, отправлять ли логи по почте.
EMAIL_DEBUG=1 — определяет, отправлять ли отладочные логи (debug logs) по почте.
EMAIL_SERVER, EMAIL_SERVER_PORT, EMAIL_TO, EMAIL_FROM — соответственно емейл сервер, порт, адрес отправки и отправителя (например, если потребуется определенная запись домена для отправителя в зависимости от конфигурации сервера электронной почты).
Продолжим настройку. Cмотрим список активных ВМ и добавляем необходимые в список:
Для отправки логов на почту необходимо разрешить исходящий трафик в firewall на сервере ESXi, добавив строчки в конце xml-файла:
Перечитываем правила фаервола и проверяем:
Для того, чтобы назначить резервное копирование по расписанию, необходимо добавить в cron строку с командой резервного копирования. Но в нашем случае строка содержит вычисление номера недели в текущем месяце (для того, чтобы не захламлять сервер). Если добавить это выражение сразу в cron, то его значение не вычислится. Поэтому сначала нужно создать отдельный shell-скрипт, вызывающий ghettoVCB с выражением для подсчета номера недели:
Если нет необходимости в понедельной ротации логов, или расписание будет настроено несколько иначе (например, бэкап раз в месяц), то выражение
из start.sh можно убрать. Разрешаем запуск:
Бэкапить будем каждую субботу в час ночи. Системное время задается в UTC, поэтому его нужно внести с учетом поправки на Ваш часовой пояс. В моем случае — это UTC+3, значит нужно внести время на три часа раньше, то есть в пятницу в 22:00. Но если мы добавим строчку в crontab следующим образом:
то все настройки потеряются при перезагрузке сервера ESXi. Поэтому команды на изменение настроек cron’a необходимо добавить в загрузочный скрипт:
Аналогичная ситуация и с настройками firewall сервера ESXi: для их сохранения придется создать VIB-пакет с помощью утилиты VIBauthor и установить его на сервер ESXi. К сожалению, VIBauthor распространяется только для 32-х битных (нет поддержки 64 бит) RPM-based дистрибутивов Linux. Я буду использовать CentOS 6.7 i386 Minimal, вы можете использовать дистрибутив SUSE Linux Enterprise 11 SP2, рекомендованый в документации. Для того, чтобы не ругалось при устаеновке VIBauthor на зависимости (а точней, разрядность) используем ключ “nodeps” и далее подготавим дерево директорий для сборки пакета:
Фактически, то, что за папкой payload1 — это желаемый путь расположения пакета на сервере ESXi. Теперь создаем описание пакета:
и непосредственно само правило firewall’а:
Теперь можно собрать пакет:
скопировать его с помощью SCP на сервер ESXi:
установить и проверить, что получилось:
По желанию можно воспользоваться моим VIB-пакетом.
Для того, чтобы устанавливать подобные дополнения нужно, чтобы на сервере ESXi параметр Acceptance Level был выставлен в значение “Community Supported”. Для этого в клиенте vSphere открываем, как показано на скриншоте:
И финальный штрих: завершаем процесс настройки созданием бэкапа настроек сервера ESXi:
Файл настроек сервере ESXi хранится в /bootbank/state.tgz и предназначен для восстановления в случае внезапного завершения работы, или перезагрузки сервера ESXi (читайте здесь). Если настройки сервера не меняются, то можно скопировать этот файл вручную, в противном случае — настройки сервера ESXi (stage.tgz и папку ghettoVCB-master) будем так же бэкапить каждую неделю. Для этого добавим в конец start.sh перед строкой “exit 0” строки:
Создание резервных копий ВМ.
Проверить настройки и запустить тестовое создание бэкапа в ручную можно командой:
Для отдельной ВМ с именем ‘MyVirtualMachine’:
Ключи задания параметров:
-a — создание бэкапа все ВМ хоста;
-f — укзать список ВМ;
-m — имя ВМ для бэкапа;
-c — конфигурация директории бэкапа;
-g — путь к файлу конфигурации;
-l — создание файла лога;
-w — рабочая директория скрипта;
-d — уровень детализации логов (debug level): info, debug, или dryrun (по умолчанию: info).
Восстановление ВМ из резервных копий.
Следует понимать, что если бэкап ВМ производился во включенном состоянии, то после восстановления ВМ будет в абслютно том же состоянии, в каком была бы после крэша — не исключена потеря данных.
Подключаемся к серверу ESXi по SSH, монтируем NFS с бэкапами и проверяем результат. Формат команды для монтирования NFS следующий:
Для ESXi 3.x/4.x подробно расписано здесь. В моем примере NFS монтируется следующей строчкой:
Фактически, такое сообщение появляется тогда, когда скрипт не находит бэкап ВМ.
Для того, чтобы задать путь без использования симлинков необходимо узнать UUID устройств. Следующая команда выводит список каждого LUN, подключенного к серверу ESXi и его сопоставление vmfs (Volume Name) к UUID:
Таким образом вместо “backup” и “datastore1” можно использовать соответствующий UUID:
backup: 9108f6f9–353aeed8;
datastore1: 56b74f4f-85fc58fa-87fe-94de8066eda2.
Подробную информацию про идентификацию дисков и файловых систем в ESX(i) можно получить здесь.
и восстанавливаем ВМ:
где:
-c — путь к списку восстанавливаемых машин.
-l — путь расположения логов.
Через vSphere клиент открываем, как на скриншоте ниже:
Troubleshooting.
Для отладки процесса восстановления:
Могут возникнуть ситуации, когда потребуется прервать выполнение ghettoVCB.sh, запущенного в ручном (интерактивном) режиме. Нажмите cntrl+C для остановки родительского процесса и далее:
Для остановки ghettoVCB, запущенного в неинтерактивном режиме:
и завершить оба дочерних процесса по их PID:
Если виртуальная машина находилась в процессе резервного копирования, то открыт дополнительный процесс — vmkfstools:
Резервное копирование виртуальных машин ESXi с помощью скриптов ghettoVCB
В этой статье я пошагово опишу настройку автоматического резервного копирования и пример восстановления виртуальных машин, работающих на платформе ESX(i) с помощью свободных скриптов ghettoVCB. Акцентироваться буду на версии ESXi 5.x, но эти же средства работают и на версиях 3.5-6.x, правда для ранних версий настройки несколько отличаются. Бэкап будет производиться на NFS сервер. Отчёт о работе будет направлен в почту. Во время бэкапа делается снимок (snapshot) виртуальной машины (в том числе и работающей), сохраняются VMDK диски машины и снимок удаляется.
Проект ghettoVCB отлично документирован, но в процессе внедрения появились нюансы, которые и вылились в эту инструкцию. Надеюсь, статья будет полезна начинающим администраторам.
Настройка резервного копирования
Первым делом приготовьте NFS сервер по вкусу, куда будут производится бэкапы. В моём случае это FreeNAS (Freebsd 9.3) и ZFS dataset с включённой дедубликацией и сжатием, что существенно экономит место. Настройка на ESXi сервере производится по SSH от пользователя root. Можно и под другим пользователем с административными правами, но тогда не получится запустить скрипты для проверки из консоли. Приступим.
1. Для настройки необходим доступ на сервер по SSH, включаем через vSphere client:
2. Берём скрипты из github репозитория и помещаем содержимое на сервер. Обязательно ставим бит исполнения, иначе скрипты работать не будут:
5. Настраиваем cron на выполнение периодической задачи:
6. Перезапускаем cron:
Запустить тестовую проверку бэкапа машины с именем «vCenterUpdate» можно следующим образом:
Запустить в ручную для списка машин:
Каждая копия машин будет хранится в директориях, вида:
И представлять из себя диск машины в формате *.vmdk и файл конфигурации машины *.vmx.
Сохранение конфигурации сервера ESXi
Настройки ESXi, произведённые выше, будут жить до первой перезагрузки. Для сохранения конфигурации нужно сделать ещё ряд действий.
1. Добавим в загрузочный скрипт команды на изменение настроек cron-а:
2. Для сохранения настроек файрвола сделаем собственный VIB пакет и установим его на сервер. Для этого используем утилиту VIB Author. К сожалению, она только для 32-х битной архитектуры, поэтому мне пришлось воспользоваться lxc контейнером. При установке может страшно ругаться на зависимости вида:
Подготавливаем дерево директорий для сборки VIB пакета:
И создаём два файла. Первый — описание нашего пакета:
Подробную инструкцию к параметрам можно посмотреть на сайте утилиты.
Собираем VIB пакет:
При нужде, можете воспользоваться моим пакетом (на свой страх и риск).
Таким образом можно собрать и зафиксировать и другие полезные настройки сервера.
4. И в завершение, запускаем в ручную бэкап настроек сервера ESXi:
Восстановление машины из резервной копии
Сразу нужно учитывать, что машина, резервирование которой производилось на горячую, после восстановления будет как после краша — возможна потеря данных внутри машины.
1. Подключаем хранилище с бэкапом на целевой ESXi сервер по NFS, либо просто копируем туда данные по ssh.
3. Запускаем тестовый прогон:
Второй вариант. Так как бэкап представляет собой дамп машины с конфигурационным файлом, то можно просто:
1. Cкопировать его куда-нибудь на ESXi сервер.
2. Исправить файл конфигурации машины (*.vmx), изменив поля имени и местоположения диска машины:
Пути до файлов можно (и нужно) указывать относительно директории машины.
3. Через vSphereClient идём в хранилище:
и добавляем новую машину в список:
4. Если сервер восстановления другой, то в настройках машины меняем «Network Connection».
5. При первом запуске оно спросит, от куда нарисовалась машина, нужно ответить, что перенесли.
Если ответить, что клонировали — изменит уникальные данные, в том числе mac адрес сетевой карты.
Вот в целом и всё. Скрипты ghettoVCB поддерживают ещё другие интересные параметры и варианты копирования, так что полезно почитать документацию. Метод далёк от идеального, но если хочется дёшево и сердито, то вполне работоспособен.