Казалось бы, не должно быть ничего сложного, берем содержимое папки, переименовываем пару файлов и готово. Но из-за наличия точек восстановления ситуация резко усложняется: в результате нам нужно получить виртуальную машину со снапшотами (по одному на каждую точку восстановления), а в папке имеются только vmdk-файлы с GUID в названиях, которые согласно документации VMware являются redo-логами, которые преобразовываются в снапшоты при восстановлении машины из реплики. Процесс преобразования нигде не описывается, поиск в Интернете мало что дал.

У виртуальной машины VMware со снапшотами в папке должен лежать текстовый файл с расширением .vmsd, содержащий описания всех снапшотов, и несколько бинарных файлов с расширением .vmsn, по одному на каждый снапшот. В папке с репликой всего этого нет, зато есть текстовый файл hbrgrp.<здесь длинный GUID>.txt, в котором имеется информация по всем точкам восстановления. Я написал скрипт на питоне, который использует информацию из этого файла и создает соответствующие .vmsd и .vmsn, плюс к этому файлы с конфигурацией виртуальной машины – .vmx и .nvram. Получается готовая к использованию виртуалка, которую остается только зарегистрировать в vCenter через vSphere Datastore Browser. Но есть нюанс – работает только если при репликации не использовался quiescing, так как разбираться с бинарной структурой .vmsn ни времени, ни желания нет. Скрипт выложил на гитхаб, на случай если еще кому-нибудь пригодится:

https://github.com/avnast/vr-recover

С помощью этого скрипта можно восстановить виртуальную машину из папки с данными vSphere Replication прямо из командной строки ESXi, благо в версии 6.5 имеется python 3 на борту.

При настройке автоматического завершения работы кластера на обновленной vSphere выяснилось, что скрипт отказывается соединяться с хостами ESXi из-за недоверия к их самоподписанным SSL-сертификатам. Пришлось его доработать – теперь при установке и сохранении паролей для доступа к хостам скрипт также пытается сохранить сертификаты хостов в папке /etc/ssl/vCluster, и при последующих соединениях считает эти сертификаты доверенными. Если в инфраструктуре используются подписанные централизованным CA сертификаты, то можно просто положить корневой сертификат центра сертификации в вышеуказанную папку. Вручную скачать сертификаты хостов можно по ссылкам вида https://<адрес хоста>/host/ssl_cert

Архив с инсталлятором скрипта: vCluster.tar.gz

В VMware vSphere есть такая (полезная?) вещь, как High Availability Cluster – несколько ESX/ESXi хостов следят друг за дружкой и в случае неожиданного выхода из строя одного из них крутившиеся на нем виртуальные машины автоматически запускаются на пока еще работающих физических серверах. Все это прекрасно работает, не требуя особого внимания, пока такому кластеру не отключают электричество на дольше, чем может продержаться ИБП, на котором все это дело висит.

И вот тут-то выясняется, что в VMware совершенно не озаботились автоматизацией корректного выключения кластера (не положено ему выключаться!). Поддержки ИБП не предусмотрено, с настройками по умолчанию при выключении хоста работающим на нем виртуальным машинам грубо отрубается питание, при этом они тут же пытаются перезапуститься на соседнем сервере, которому админ еще не успел дать команду на выключение. Можно, конечно, прописать виртуальные машины в автоматический старт/стоп в настройках каждого хоста, но если важен порядок выключения/включения виртуалок, то этот вариант не подходит: при перемещении виртуальной машины с одного хоста на другой она всегда попадает в раздел «Any Order». Поэтому в общем случае порядок действия при выключении High Availability кластера такой:

• вручную с помощью vSphere Client выключить в правильном порядке виртуальные машины
• выключить физические сервера

После восстановления питания придется вручную выполнять действия в обратном порядке, причем если vCenter живет в виртуальной машине, то чтобы его запустить нужно подключаться клиентом vSphere напрямую к хостам.

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

В результате был написан скрипт для корректного выключения VMware HA Cluster с помощью apcupsd, установленного в виртуальной машине VIMA:

vCluster.tar.gz

Общая концепция автоматизации выключения/включения кластера такова:

• выделяется отдельная виртуальная машина (далее – VIMA), на которой устанавливается vSphere CLI (можно скачать готовый virtual appliance c http://www.vmware.com/support/developer/vima/) и поднимается apcupsd для слежения за состоянием UPS, обслуживающим кластер;
• в VIMA устанавливается скрипт, при установке он прописывается в конфиге apcupsd и стартовых скриптах;
• в ini-файле прописывается порядок останова/запуска виртуальных машин  при выключении/включении кластера;
• когда apsupsd дает  команду shutdown, скрипт останавливает виртуальные машины в порядке, указанном в ini-файле, затем дает команду на выключение хостам (при этом сама VIMA НЕ ОСТАНАВЛИВАЕТСЯ, то есть хосты выключаются c одной-единственной включенной виртуальной машиной);
• после подачи питания  VMware HA Cluster запускает виртуальные машины, которые были включены на момент выключения хостов, то есть в нашем случае это VIMA;
• стартовый скрипт VIMA запускает виртуальные машины кластера в порядке, указанном в ini-файле.

Подробности в файлике INSTALL.txt и в исходниках