Установка Nutanix Community Edition в ВМ VMware ESXi

Update 04.2018: Если вы устанавливаете Nutanix ce-2018.01.31, то вам потребуется сделать ряд дополнительных настроек перед запуском команды install. Детали смотрите ниже по тексту. За workaround спасибо автору блога http://blog.ntnx.jp/entry/2018/02/24/163626

Не так давно стала доступна бета версия Nutanix Community Edition. Мне захотелось посмотреть на этого зверя, но т.к. под рукой не было доступного физического сервера, то я решил попробовать запустить Nutanix CE в виртуальной среде VMware ESXi 5.5.

Для тех, кто не в курсе, Nutanix CE представляет собой ПО, которое позволяет создать виртуальную инфраструктуру с нуля, используя стандартные x86 серверы с локальными жесткими дисками и SSD накопителями. В качестве гипервизора в Nutanix CE используется KVM с собственной системой управления Acropolis. Для организации распределенной системы хранения данных используются специальные служебные машины CVM (Controller VM), они обеспечивают доступ к интерфейсу управления Prism UI конвергентной платформы.

Более подробно о Nutanix CE вы можете узнать на сайте Nutanix и в блоге http://blog.in-a-nutshell.ru

Подготовка к установке

Nutanix CE имеет следующие системные требования:

• В кластере может быть от 1 до 4 серверов.
• Процессоры должны иметь минимум 4 ядра и поддержку аппаратной виртуализации (Intel VT-x).
• Минимальный объем ОЗУ - 16 ГБ (из которых минимум 12 будет отведено CVM).
• Контроллер LSI или AHCI.
• Минимум один SSD накопитель объемом 200 ГБ.
• Минимум один жесткий диск объемом 500 ГБ.
• Один сетевой адаптер Intel 1 Гбит/с или выше.

Для получения дистрибутива Nutanix CE вам надо зарегистрироваться на сайте http://www.nutanix.com/products/community-edition/

После загрузки и распаковки архива с дистрибутивом (последняя актуальная версия ce-2015.06.06) вы получите образ диска в формате .img, который можно записать на USB flash, если вы собираетесь устанавливать его на физический сервер, либо конвертировать в vmdk.

Конвертировать образ можно различными способами, например, воспользовавшись бесплатным конвертером StarWind V2V Converter, но более простым способом будет переименовать файл ce-2015.06.08-beta.img в ce-flat.vmdk, а также создать в файл метаданных ce.vmdk со следующим содержанием, как описано в данной статье:

# Disk DescriptorFile
version="4"
encoding="UTF-8"
CID="a63adc2a"
parentCID="ffffffff"
isNativeSnapshot="no"
createType="vmfs"
 
# Extent description
RW 14540800 VMFS "ce-flat.vmdk"
 
# The Disk Data Base
# DDB
 
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "905"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "2e046b033cecaa929776efb0a63adc2a"
ddb.uuid = "60 00 C2 9b 69 2f c9 76-74 c4 07 9e 10 87 3b f9"
ddb.virtualHWVersion = "10"

Если вы сохраняете файл под ОС Windows, не забудьте об отличиях в формате переноса строк в Windows и Unix (CRLF / LF). Для корректного сохранения используйте редактор, который поддерживает Unix переносы строк (например, Notepad++).

Используя Datastore Browser, скопируйте оба файла в папку на одно из хранилищ.

Создайте ВМ с гостевой ОС Red Hat Enterprise Linux 7 (64-bit), версия Hardware ID: 10, выделите ВМ минимум 4 процессора и 16 ГБ памяти. Не забудьте включить Expose hardware assisted visualization to the guest OS. В качестве SCSI контроллера выберите LSI Logic SAS. В качестве сетевого адаптера выберите E1000 (не перепутайте с E1000E).

Для версии Nutanix CE 2018.01.31 также включите опцию Performance counters: Enabled virtualized CPU performance counter.

В группе портов виртуального коммутатора, к которой будет подключаться сетевой адаптер, включите Promiscuous Mode и Forge Transmits - Enable.

Подключите ранее скопированный диск ce.vmdk к ВМ, а также создайте два новых виртуальных диска, один на SSD хранилище, второй на HDD.

Запустите ВМ, если вы все сделали правильно, то начнется процесс загрузки.

Если при загрузке ВМ возникает ошибка "dracut emergency shell", добавьте в ВМ виртуальный SATA контроллер и подключите загрузочный диск Nutanix CE к нему, а SSD и HDD диски назначьте на SCSI0:0 и SCSI0:1 каналы соответственно.

Установка и настройка

При установке версии Nutanix CE 2018.01.31 после загрузки ВМ выполните вход под учетной записью root с паролем nutanix/4u. Отредактируйте файл /home/install/phx_iso/phoenix/svm_template/kvm/default.xml и измените в нем в восьмой строчке значение machine='pc' на machine='pc-i440fx-rhel7.2.0'.

Выйдите из системы, используя команду exit.

В окне ввода логина введите install

Запустится мастер установки. Укажите раскладку клавиатуры, задайте IP адрес для узла и для CVM. Не выбирайте опцию Create single-node cluster, в текущей версии это приводит к ошибке установки. Пролистайте лицензионное соглашение до конца (иначе получите ошибку), примите его и запустите процедуру установки.

После завершения установки подключитесь к IP адресу CVM с помощью SSH, используя учетную запись "nutanix", пароль: "nutanix/4u".

Создайте кластер, введя команду:

cluster -s <IP_адрес_CVM> -f create

Добавьте информацию о DNS сервере (потребуется для доступа к порталу Nutanix):

ncli cluster add-to-name-servers servers=<IP_адрес_DNS>

Запустите web-браузер и подключитесь к CVM (https://<IP_адрес_CVM>:9440). При первом входе запустится мастер автоматической настройки.

Задайте пароль для учетной записи admin. В новых версиях Nutanix CE сначала требуется выполнить вход под учетной записью admin с паролем nutanix/4u.

Выполните вход под учетной записью admin.

Введите e-mail и пароль, который вы использовали при регистрации на сайте (NEXT Credentials).

Задайте произвольное имя для кластера.

На этом настройку можно считать завершенной.

Работа с Nutanix CE

Ниже приведено несколько советов для тех, кто ни разу не работал с Nutanix.

Настройка виртуальных сетей, к которым подключаются ВМ, выполняется из меню настроек Network Configuration в правом верхнем углу интерфейса Prism UI.

Для настройки сети достаточно указать VLAN ID (0 - для native VLAN), идентификатор сети (UUID) будет сгенерирован автоматически.

Для создания и управления ВМ используется вкладка VM, доступная в левом верхнем углу интерфейса.

Для получения списка ВМ следует перейти на отображение Table.

При создании ВМ требуется указать ее имя, кол-во процессоров и объема памяти. Также к ВМ можно подключить виртуальные диски и сетевые адаптеры.

Для загрузки дистрибутивов можно использовать NFS. Для начала следует добавить IP адрес клиента или целой подсети, откуда будет выполнять подключение к NFS в список доверенных (опция Filesystem Whitelists в меню настроек).

После этого можно будет смонтировать сетевой каталог по протоколу NFS (по умолчанию имя сетевого каталога NTNX-NFS-DEFAULT, посмотреть имя можно во вкладке Storage > Table).

Подключить ISO к виртуальному CDROM приводу можно из свойств ВМ, выбрав в списке Operation -> Clone from NDFS file и в поле Path, указав путь к ISO образу (например, "/NTNX-NFS-DEFAULT/windows2008r2.iso").

Загрузить компоненты интеграции (агент для ВМ, драйвер для виртуального SCSI контроллера, сетевого адаптера и Balloon драйвер) можно по ссылке: https://fedoraproject.org/wiki/Windows_Virtio_Drivers

Работаем с VMware vRealize Orchestrator через REST API

Добрый день. Сегодня я хотел бы рассказать вам о том, как можно работать с VMware vRealize Orchestrator через REST API.

REST API, реализованный в Orchestrator, позволяет с помощью сгенерированных HTTP запросов выполнять различные операции, например:

• запускать Workflow;
• отслеживать статус работающих или уже выполненных Workflow;
• создавать задания, которые запускают Workflow по расписанию;
• проверять входные параметры для workflow на корректность.
• получать информацию о различных объектах, присутствующих в иерархии Orchestrator.

Через REST API можно выполнить интеграции vRealize Orchestrator с любыми сторонними системами, будь то системы автоматизации, порталы самообслуживания, CMDB системы или другие средства оркестрации.

Подготовка к работе

Для демонстрации возможностей работы с REST API я буду использовать web-браузер Google Chrome и web-приложение Postman, которое можно загрузить из Интернет-магазина Chrome.

Для доступа к REST API требуется выполнить HTTP GET запрос, введя адрес сервера Orchestrator, порт для подключения и каталог REST API (в моем случае: "https://ora01.company.local:8281/vco/api").

Поскольку я использую сервер Orchestrator с самоподписанными сертификатами, то REST клиент не будет подключаться к недоверенному HTTPS серверу.

Чтобы обойти это ограничение можно добавить сертификат в список исключений на компьютере, с которого производится подключение, но лучшим решением будет выдать серверу Orchestrator сертификат от доверенного удостоверяющего сервера. В тестовых целях я временно добавлю сертификат в список исключений, используя web-браузер Chrome.

Повторно выполним HTTP GET запрос. Сервер вернет ответ в формате JSON.

Мне не очень нравится JSON, при наличии возможности, я предпочитаю XML разметку. Поэтому мы можем попросить Orchestator, чтобы он предоставлял данные в формате XML.

Для этого нужно добавить заголовок в наш запрос:
Accept: application/xhtml+xml

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

Для данного REST клиента я включил сохранение заголовков, чтобы не прописывать их каждый раз заново.

Общие сведения при работе с Orchestrator REST API

REST API предоставляет доступ к иерархии Orchestrator с каталогом верхнего уровня "/vco/api/".

Выполняя запросы к дочерним каталогам мы можем получить от Orchestrator интересующую нас информацию.

Например, добавив в адресную строку about и выполнив GET запрос, мы получим информацию о версии сервера Orchestrator и поддерживаемой версии API.

Для получения информации о всех доступных workflow требуется выполнить GET запрос:
GET https://ora01.company.local:8281/vco/api/workflows/

Orchestator отказал нам в доступе, поскольку данная информация предоставляется только авторизованным пользователям.

Orchestrator поддерживает аутентификацию OAuth (при интеграции с VMware SSO), а также Basic аутентификацию.

Basic аутентификация выполняется путем добавления специального заголовка в каждый запрос:
Authorization: Basic <учетные_данные>

Учетные данные пользователя (домен\логин:пароль) должны быть закодированы в формате Base64.

Для преобразования логина и пароля в формат base64 можно использовать разные инструменты, я воспользуюсь обычным онлайн сервисом.

Выполним запрос еще раз.

После успешной аутентификации, Orchestrator выдаст список всех доступных Workflow, а их могут быть десятки и даже сотни. Чтобы сузить список выдаваемых workflow можно использовать специальный фильтр.

Для этого изменим запрос, добавив в строку адреса условие поиска, например, по имени:
?conditions=name~Get virtual machine

Вот с этим уже можно работать.

Для каждого Workflow отображается несколько параметров: имя (name), краткое описание (description), номер версии Worklow (version). Также можно увидеть уникальный идентификатор (id), который присваивается каждому workflow при создании, и ссылку для запроса (down), пройдя по которой, можно получить более детальную информацию о Workflow.

Идентификатор workflow можно посмотреть через клиент Orchestrator.

Выберем тестовый workflow и выполним к нему запрос:
GET https://ora01.company.local:8281/vco/api/workflows/BB808080808080808080808080808080A180808001322751030482b80adf61e7c/

Внутри каталога с workflow отображаются уже ранее виденные свойства, но что самое важно, входные параметры, которые задаются при запуске workflow (<input-parameters>...</input-parameters>), и выходные параметры (<output-parameters>...</output-parameters>), которые Workflow выдает в результате своей работы.

Данный workflow я взял в качестве примера, поскольку он очень простой. Его задача - принимать в качестве входного параметра (criteria) строку с именем виртуальной машины, а качестве выходного параметра возвращать массив объектов-виртуальных машин (Array/VC:VirtualMachine), которые подошли под указанный критерий поиска.

Помимо параметров в каталоге Workflow содержатся ссылки на дочерние каталоги, реализующие различные различные запросы.

О каталогах executions и presentation мы поговорим чуть позже.

В каталоге tasks содержится информация о всех заданиях, которые запускают данный workflow по расписанию. Оттуда же можно настроить запуск новых заданий по расписанию.

icon отображает специальную иконку workflow. У всех workflow по умолчанию используется стандартная иконка, но если вы хотите визуально выделить workflow, то в настройках можете указать одну из специальных иконок, которые есть в Orchestrator.

Выполнив запрос в schema можно увидеть рисунок схемы в формате png.
GET https://ora01.company.local:8281/vco/api/workflows/BB808080808080808080808080808080A180808001322751030482b80adf61e7c/schema/

В каталоге permissions можно видеть разрешения, которые были назначены непосредственно на данный workflow.
GET https://ora01.company.local:8281/vco/api/workflows/BB808080808080808080808080808080A180808001322751030482b80adf61e7c/permissions/

Например, к workflow предоставлен доступ на просмотр и выполнение для доменной группы Domain Users.

Аналогичные разрешения (плюс унаследованные) можно увидеть из вкладки Permissions в клиенте Orchestator.

Наконец, запрос interactions выдаст данные о workflow, которые выполняются в данный момент, и для которых требуется интерактивный ввод данных от пользователя.

Запуск Workflow

Вернемся к executions.
GET https://ora01.company.local:8281/vco/api/workflows/BB808080808080808080808080808080A180808001322751030482b80adf61e7c/executions/

Данный каталог позволяет выполнить две задачи. Во-первых, с помощью HTTP POST запроса можно запустить данный workflow. Во-вторых, здесь можно получить информацию о предыдущих попытках запуска workflow.

Идентификатор задачи (id), дата начала (startDate) и окончания (endDate), имя пользователя, который запускал workflow, текущий статус задачи, ссылку на детальное описание.

Давайте посмотрим на последнюю задачу, добавив ее id в адресную строку.
GET https://ora01.company.local:8281/vco/api/workflows/BB808080808080808080808080808080A180808001322751030482b80adf61e7c/executions/402881e74db4b27c014dce08f84408a2/

Здесь также можно увидеть детальные результаты работы workflow - входные значения параметров, которые ввел пользователь, и полученные результаты.

Давайте вернемся к запросу executions.

Как уже было сказано ранее, для запуска workflow через REST API нам потребуется правильно сформировать и выполнить HTTP POST запрос.

В теле POST запроса требуется указать входные данные - те параметры и их значения, которые мы ходим передать workflow. Для данного workflow в качестве входных значений используется один параметр типа строка, в котором можно указать имя виртуальной машины или некий шаблон для поиска.
POST https://ora01.company.local:8281/vco/api/workflows/BB808080808080808080808080808080A180808001322751030482b80adf61e7c/executions/

Я добавлю ранее сформированные данные в формате XML в тело запроса. В данном примере мы попробуем найти ВМ, имена которых содержат строку "testvm01".
<execution-context xmlns="http://www.vmware.com/vco">
<parameters>
<parameter name="criteria" type="string">
<string>testvm01</string>
</parameter>
</parameters>
</execution-context>

Откуда берутся теги для оформления XML? Самый простой вариант - посмотреть в официальной документации.

Помимо самих данных, нам также нужно объяснить Orchestator в каком формате они предоставляются.

Для этого создадим соответствующий заголовок в запросе:
Content-Type: application/xml

Отправим запрос на исполнение.

Если все было сделано правильно, то в качестве ответа мы получим один из заголовков, который содержит ссылку (Location) на созданную нами задачу по выполнению Workflow.

Выполним запрос по указанной ссылке. Не забываем использовать для этого метод GET.

Видим, что задача завершилась успешно (<state>completed</state>).

В качестве выходного параметра (<output-parameters>...</output-parameters>) мы получи массив, который содержит один объект - виртуальную машину.

Проверить задачу можно через клиент Orchestrator.

Давайте рассмотрим другой workflow (Reload virtual machine).

Для этого воспользуемся известным нам фильтром, чтобы узнать id данного workflow:
GET https://ora01.company.local:8281/vco/api/workflows?conditions=name~Reload virtual machine

А затем выполним запрос, чтобы получить детальную информацию о workflow.
GET https://ora01.company.local:8281/vco/api/workflows/BD8080808080808080808080808080806BC280800122528313869552e41805bb1/

Данный workflow в качестве входного параметра принимает объект типа виртуальная виртуальная машина (vm).

Возникает вопрос - как правильно в запросе указать тип и входное значение параметра?

Для этого можно воспользоваться одной небольшой уловкой.

Из клиента Orchestrator можно запустить данный workflow на выполнение и указать какие-нибудь тестовые значений.

После чего через rest api посмотреть на выполненную задачу.
GET https://ora01.company.local:8281/vco/api/workflows/BD8080808080808080808080808080806BC280800122528313869552e41805bb1/executions/402881e74cf6cbaf014d3f5b68bd0691/

Вот искомый формат ввода данных, достаточно скопировать его, подставив свое значение в качестве идентификатора ВМ. Атрибут href - ссылка на объект в иерархии Orchestrator, указывать не требуется, она генерируется самим Orchestrator автоматически.

Выполним POST запрос. Тело нашего запроса будет выглядить следующим образом.
<execution-context xmlns="http://www.vmware.com/vco">
<parameters>
<parameter type="VC:VirtualMachine" name="vm" scope="local">
<sdk-object type="VC:VirtualMachine" id="vc01.company.local/vm-49"/>
</parameter>
</parameters>
</execution-context>

Адрес для запроса:
POST https://ora01.company.local:8281/vco/api/workflows/BD8080808080808080808080808080806BC280800122528313869552e41805bb1/executions/

Как видите, задача успешно запущена.

Возникает вопрос - где можно взять значение ID виртуальной машины или другого объекта виртуальной инфраструктуры?

Во-первых, можно воспользоваться workflow, который мы запускали ранее (Get virtual machines by name), и который возвращает объекты виртуальных машин в качестве результата работы.

Во-вторых, Если посмотреть на вкладку Inventory в Orchestrator, то видно, что в ней отображаются объекты vCenter, в частности, виртуальные машины. При выборе одной из виртуальных машин можно увидеть ее идентификатор.

Аналогичным образом можно искать объекты в инвентаре Orchestrator через REST API. Для этого нужно выполнить цепочку GET запросов в каталоге Inventory.
GET https://ora01.company.local:8281/vco/api/inventory/

Вернет перечень объектов интвентаря Orchestrator. Нас интересует объект vCenter (VC).
GET https://ora01.company.local:8281/vco/api/inventory/VC/

Вернет перечень подключенных серверов vCenter. Выполняем запрос к интересующему серверу.
GET https://ora01.company.local:8281/vco/api/inventory/VC/SdkConnection/vc01.company.local/

Вернет перечень объектов, среди которых будет каталог, содержащий виртуальные ЦОД. Выполняем запрос к каталогу.
GET https://ora01.company.local:8281/vco/api/inventory/VC/SdkConnection/vc01.company.local/DatacenterFolder/vc01.company.local%252Fgroup-d1/

Вернет перечень виртуальных ЦОД. Выполняем запрос к интересующему ЦОД:
GET https://ora01.company.local:8281/vco/api/inventory/VC/SdkConnection/vc01.company.local/DatacenterFolder/vc01.company.local%252Fgroup-d1/Datacenter/vc01.company.local%252Fdatacenter-28/

Вернет перечень объектов виртуального ЦОД. Выполняем запрос к каталогу, содержащему ВМ.
GET https://ora01.company.local:8281/vco/api/inventory/VC/SdkConnection/vc01.company.local/DatacenterFolder/vc01.company.local%252Fgroup-d1/Datacenter/vc01.company.local%252Fdatacenter-28/VmFolder/vc01.company.local%252Fgroup-v29/

Вернет перечень ВМ, которые хранятся в каталоге, а также перечень дочерних каталогов. Искомая ВМ и ее id.

Проверка входных параметров

Помимо запуска workflow, REST API предоставляет возможность проверки входных параметров на корректность с помощью Presentation. Presentation используется в следующих случаях:

1. Настройка отображения входных параметров, их порядка, группировка по вкладкам и так далее.
2. Контроль за значением входных параметров. Мы можем выбирать - какие параметры являются обязательными, указывать значения по-умолчанию, задавать минимальные и максимальные значения и огранивать выбор пользователя определенными значениями из списка.

Через REST API мы можем получить информацию о всех ограничениях, которые Presentation накладывает на входные параметры.

Давайте рассмотрим еще один workflows (Rename virtual machine), который изменяет имя виртуальной машины. Чтобы получить информацию об ограничениях, которые накладывает presentation на входные параметры, выполним GET запрос.
GET https://ora01.company.local:8281/vco/api/workflows/BD808080808080808080808080808080F0C280800122528313869552e41805bb1/presentation/

Для данного workflow можно увидеть, что параметры - виртуальная машина и ее новое имя является обязательным (mandatory).

С помощью Presentation, мы можем проверить входные данные, не запуская сам workflow на выполнение.

Делается это через HTTP POST запрос в подкаталог instances:
POST https://ora01.company.local:8281/vco/api/workflows/BD808080808080808080808080808080F0C280800122528313869552e41805bb1/presentation/instances/

В теле запроса укажем входные параметры, которые нуждаются в проверке.
<execution-context xmlns="http://www.vmware.com/vco">
<parameters>
<parameter type="VC:VirtualMachine" name="vm" scope="local">
<sdk-object type="VC:VirtualMachine" id="vc01.company.local/vm-49" />
</parameter>
<parameter type="string" name="newName" scope="local">
<string>testvm03</string>
</parameter>
</parameters>
</execution-context>

Если запрос был сформирован правильно, то в ответе мы получим valid = true.

Если же при формировании запроса мы где-нибудь ошибемся, например, неправильно укажем тип параметра или передадим несуществующий объект, то в ответе будет написано, что запрос не прошел проверку (valid = false), а также причину.

Это, пожалуй, все, что я хотел рассказать о работе с Orchestrator через REST API. Если вас заинтересовала данная тема, то настоятельно рекомендую ознакомиться с официальной документацией, доступной на сайте VMware.

Автоматическое назначение статических IP адресов для ВМ в VMware vCenter

Довольно часто при создании новой ВМ из шаблона возникает необходимость задать для нее статический IP адрес и другие сетевые настройки.

Делать это вручную, особенно, если таких ВМ много - весьма утомительно. Нужно внимательно следить за тем, чтобы не ошибиться с маской сети, маршрутом по умолчанию, DNS, или не выдать нескольким ВМ одинаковые IP.

К счастью, VMware vCenter Server предоставляет механизм, которые позволяет автоматизировать данную рутинную процедуру, реализовав своеобразный IPAM (IP Address Management) для виртуальных машин.

При выполнении кастомизации ВМ через Customization Specification можно настроить vCenter на запуск скрипта для генерации IP адреса. vCenter передаст скрипту данные в формате XML, содержащие имя ВМ, тип ОС, MAC адрес сетевого адаптера, имя виртуальной сети и пр.

<generator>
     <datacenter>/New Datacenter</datacenter>
     <vm>/New Datacenter/vm/New Virtual Machine</vm>
     <vm-moref>vim.VirtualMachine:vm-249</vm-moref>
     <hostname/>
     <uuid>502081ef-91df-7455-e570-be1f6d4f5abc</uuid>
     <guest>winXPProGuest</guest>
     <nics>
        <nic id="0">
           <ipaddress/>
           <iparg>ip.txt</iparg>
           <macaddress>00:50:56:a0:70:15</macaddress>
           <network>VM Network</network>
        </nic>
     </nics>
</generator>

Скрипт, в свою очередь, должен вернуть данные вместе с IP адресом, который vCenter будет использовать при кастомизации ВМ.

<generator>
     <datacenter>/New Datacenter</datacenter>
     <vm>/New Datacenter/vm/New Virtual Machine</vm>
     <vm-moref>vim.VirtualMachine:vm-249</vm-moref>
     <hostname>New-Datacenter-15</hostname>
     <uuid>502081ef-91df-7455-e570-be1f6d4f5abc</uuid>
     <guest>winXPProGuest</guest>
     <nics>
        <nic id="0">
           <ipaddress>193.168.1.15</ipaddress>
           <iparg>ip.txt</iparg>
           <macaddress>00:50:56:a0:70:15</macaddress>
           <network>VM Network</network>
        </nic>
     </nics>
  </generator>

В качестве примера можно использовать скрипт sample-generate-name-ip.pl, который доступен для загрузки с сайта VMware.

Данный скрипт берет свободный IP адрес из текстового файла, путь к которому указывается в параметре <iparg>, и затем записывает в этот же файл информацию о ВМ, которой был назначен адрес.

Для работы скрипта требуется выполнить следующие настройки:

1) Загрузить скрипт с сайта и сохранить его на сервере vCenter (например, в C:\sample-generate-name-ip.pl).

2) Установить и настроить Perl на сервере vCenter.

Для vCenter Server на Windows загрузить Active State Perl с сайта и установить его на сервер vCenter Server, а затем установить модуль XML-DOM XPath, запустив в командной строке сервера vCenter:
ppm install XML-DOM-XPath

Для vCenter Server Appliance установка Perl и модуля выполняется командами:
yum install expat-devel
perl -MCPAN -e 'install XML::DOM::XPath'

3) Создать на сервере vCenter тестовый файл (C:\ip.txt) в следующем формате:
192.168.1.1,*,*
192.168.1.2,*,*
192.168.1.3,*,*
192.168.1.4,*,*
, где 192.168.1.x - IP адреса, который требуется выдавать.

4) В Advanced Settings сервера vCenter требуется создать следующие параметры:
config.guestcust.name-ip-generator.arg1, в качестве значения, указав путь с скрипту, например, c:\sample-generate-name-ip.pl.
config.guestcust.name-ip-generator.arg2, в качестве значения, указав путь с скрипту, например, c:\sample-generate-name-ip.pl.
config.guestcust.name-ip-generator.program, в качестве значения, указав путь к исполняемому файлу Perl, например, c:\Perl64\bin\perl.exe.

5) Создать или отредактировать один из существующих сценариев Customization Specification, указав на этапе редактирования сетевых настроек ВМ (Network), вариант Manually select custom settings, а затем открыть свойства сетевого адаптера.

6) В свойствах сетевого адаптера выбрать тип назначения IP адреса Use an application configured on the vCenter Server to generate the IP address и указать в качестве параметра путь к текстовому файлу с IP адресами, созданному на шаге 3. Обязательно экранируйте все спецсимволы, в пути к файлу (пример корректного пути: "C:\\ip.txt").

7) Сохранить изменения в сценарии кастомизации.

Теперь, при запуске подготовки ВМ при клонировании из шаблона с указанным сценарием кастомизации, скрипт автоматически возьмет первый доступный IP адрес из текстового файла, а vCenter назначит его при кастомизации ВМ в качестве статического адреса сетевого интерфейса ВМ. Выданные IP адреса в текстовом файле выглядят следующим образом.

Если вам потребуется выдавать адреса из разных подсетей, то просто создайте несколько текстовых файлов и несколько сценариев кастомизации, каждый из которых будет указывать на нужный файл.

Кроме того, вы можете написать собственный сценарий на любом языке (Perl, Powershell), с необходимым вам функционалом.