Инсталляция vSphere 8.0 с нуля — Aleksandr Mykhalchenko`s Blog

vSphere – это основа основ для любого виртуализатора, который стремится работать с продуктами VMware. Даже не так: это литосферная плита, на которой все держится, что задает концептуальные основы и без глубоких, основательных знаний которой говорить об успешности внедрения SDDC не приходится.

Несколько месяцев тому назад VMware выпустила очередное мажорное обновление vSphere, и если вы хотите пользоваться самой свежей версией нашей среды, придется обучаться уже «восьмерке». О главных изменениях в ней мы недавно писали в «Что изменилось VMware vSphere 8.0?», а сегодня будем учиться инсталлировать с нуля все компоненты vSphere 8.0 и делать начальные настройки. Что же касается вопросов администрирования и обновления з предыдущих версий до этой, думается, опубликуем отдельные гайды следом.

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

Архитектура, компоненты и понятия

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

Глоссарий

Виртуализация – процесс создания программного представления физической единицы (сервера, десктопа, сети или устройства хранения данных). Соответственно, она бывает серверной, сетевой, виртуализацией хранилища или рабочего стола пользователей.

SDDC (Software-Defined Data Center) – дата-центр, в котором вся инфраструктура виртуализирована, а его контроль автоматизирован программным обеспечением. vSphere, как технология, является фундаментом SDDC:

Гипервизор – специальная операционная система, предназначенная для запуска виртуальных машин и виртуальных appliance.

Хост – физический компьютер, который предоставляет ресурсы для гипервизора (в нашем случае ESXi).

Виртуальная машина (ВМ) – специальное приложение, которое абстрагирует аппаратные ресурсы в программное обеспечение. Она включает следующие компоненты:

гостевую операционную систему,
VMware Tools,
виртуальные ресурсы (CPU и память, сетевые адаптеры, диски и контролеры, GPU).

Операционная система (ОС) – ПО, разработанное для выделения физических ресурсов приложениям.

Гостевая ОС – операционная система, которая запущена на ВМ.

Кластер – группа ESXi-хостов, чьи ресурсы используются виртуальными машинами сообща.

Архитектура и компоненты

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

А виртуальная вот так:

Из этого логичным образом вытекает определение самой vSphere: это платформа виртуализации, которая включает два ключевых административних компонента для запуска виртуальных машин – гипервизор (в нашем случае ESXi, его определение приводилось выше) и vCenter (центральная административная платформа для ESXi-хостов, виртуальных машин, хранилища и сетевого соединения):

Если более развернуто, ESXi – это bare-metal гипервизор, лицензированный как часть vSphere. Он обладает следующими особенностями:

Высокий уровень безопасности (файервол на основе хоста, усиление памяти, целостность модуля ядра, Trusted Platform Module (TPM 2.0), безопасная загрузка UEFI, зашифрованные дампы ядра);
Малый размер диска;
Быстрая загрузка для ускоренного патчирования и обновлений;
Инсталлируется на жетских дисках, SAN LUN, SSD, SATADOM и бездисковых хостах.

Важно! Можно использовать загрузочные устройства на базе USB, но VMware советует пользоваться вместо них SSD для увеличения надежности.

vCenter позволяет объединять в пул ресурсы нескольких хостов и управлять ими. Он запускается как appliance (ВМ на Linux), с Photon OS, БД PostgreSQL и запакованный с рядом сервисов, таких как:

vCenter Server,
vSphere Client,
сервис лицензирования,
Content Library,
vSphere Lifecycle Manager Extension и vCenter Lifecycle Manager.

Также на борту встроенные возможности аутентификации и сертификации (vCenter Single Sign-On, Lookup Service, VMware Certificate Authority), vSphere Auto Deploy, о котором очень подробно будем говорить ниже и vSphere ESXi Dump Collector. Полный список можно увидеть здесь:

Архитектура vCenter опирается на следующие компоненты:

vSphere Client (удобный интерфейс, который подключается к vCenter и централизированно управляет ESXi-хостами);
БД vCenter (критически важный компонент, что хранит объекты инвентаря, роли безопасности, данные производительности и много чего другого);
Управляемые хосты (из vCenter можно управлять ESXi-хостами и ВМ, запущенными на ESXi-хостах):

В процессе развертывания выбирается размер appliance vCenter Server для запланированной среды vSphere и размер среды по требованиям БД, что строится.

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

Сервисы аутентификации vCenter

vCenter Single Sign-On позволяет компонентам vSphere коммуницировать между собой по безопасному механизму токенов. Он может аутентифицировать пользователей через встроенные или внешние провайдеры идентификации. К встроенным принадлежит домен vsphere.local, который, по умолчанию, используется vCenter в качестве источника идентификации, а также Active Directory, которым, по желанию, можно пользоваться как источником идентификации (LDAP, LDAPS, OpenLDAP или OpenLDAPS). Внешние провайдеры идентификации используют федеративную аутентификацию – vSphere поддерживает Active Directory Federation Services (AD FS).

Аутентифицированным пользователям могут назначаться основанные на решении зарегистрированные разрешения или роли в среде vSphere.

Общение со встроенным провайдером идентификации выглядит следующим образом:

Пользователь заходит в клиент vSphere;
vCenter Single Sign-On аутентифицирует данные учетной записи по сервису каталога (например, AD);
SAML-токен посылается назад в браузер пользователя;
SAML-токен посылается на vCenter и пользователю предоставляется доступ:

vCenter Single Sign-On должен быть зарегистрирован с vCenter Server.

С учетом использования домена vCenter Single Sign-On, следует отметить, что в Enhanced linked mode можно заходить в клиент vSphere и управлять инвентарями всех инстансов vCenter в группе – до 15 таких инстансов могут быть в одном vCenter Single Sign-On:

И при этом на все связанные инстансы vCenter можно заходить одновременно с единым именем пользователя и паролем, все операции с ними осуществляются в одном клиенте vSphere, и очень удобно можно реплицировать роли, разрешения, лицензии, теги и политики по всем таким инстансам. Среди других функций решения: упрощенный процесс НА, нивелирующий нужду в балансировщиках нагрузки, очень удобное бекапирование и восстановление. Кстати, такую группу можно создать в процессе развертывания vCenter Server Appliance, либо уже после, переместив или переназначив новый инстанс vCenter, очень просто: подсоединив их к одному домену vCenter Single Sign-On – об этом поговорим ниже в соответствующем разделе. Причем, все это доступно еще со Standard-уровня лицензии.

Сервис лицензирования

Этот сервис предлагает общий инвентарь лицензий и управления возможностями для всех систем vCenter Server в домене Single Sign-On. Ниже расскажем о пакетном лицензировании в рамках разговора о vSphere Auto Deploy, а в будущем, в новой статье по администрированию продукта, обсудим по этой теме уже абсолютно все нюансы.

VMware Certificate Authority

VMware Certificate Authority (VMCA) предоставляет каждый хост ESXi с подписанным сертификатом, который обладает VMCA как корневой авторизацией сертификата, по умолчанию. Предоставление происходит, когда ESXi-хост добавляется в vCenter Server напрямую, или как часть инсталляционного процесса. Все подобные сертификаты хранятся локально на хосте.

Сервис vSphere ESXi Dump Collector

Можно настроить ESXi на хранение памяти VMkernel на сервере в сети, а не на диске, когда система сталкивается с критическим сбоем. vSphere ESXi Dump Collector собирает такие дампы памяти через сеть и является инструментом поддержки vCenter.

Сервисы управления жизненным циклом

vCenter Lifecycle Manager автоматизирует процессы ВМ и удаление из них сервиса в определенное время. Он может автоматически размещать серверы, опираясь на их расположение, среду, уровень сервиса или производительности. И когда находится решение для набора критериев, машина автоматически разворачивается. vSphere Lifecycle Manager – это превосходный, масштабный и очень полезный инструмент, который разрешает централизованную автоматизацию процессов патчирования и управления версиями для VMware vSphere, а также поддерживает ESXi-хосты, ВМ и виртуальные приложения.

Совершенно естественно, с оглядкой на все вышесказанное, будет предсказать, что далее, когда перейдем непосредственно к подготовке к инсталляции и к ней самой, будем говорить именно об установке ESXi и vCenter.

Замечание. В современной официальной документации VMware можно встретить название «vSphere+» — этот термин введено специально для обозначения комплексного продукта и с on-premises компонентами (обычная «сфера»), и с облачными. При этом on-premises рабочими нагрузками можно управлять с облачной консоли, с одновременным доступом к облачным сервисам:

Что касается управления средой, мы можем работать со следующими пользовательскими интерфейсами в vSphere:

vSphere Client,
PowerCLI,
VMware Host Client,
vSphere ESXi Shell,
ESXCLI:

Виртуализация ресурсов

Наш ESXi в своей работе не может без взаимодействия с ресурсами (CPU, память, сети, хранилище, GPU). Они выделяются на хост, благодаря чему на созданной на нем ВМ (гостевой) можно запускать любое приложение в любой поддерживаемой ОС. Множество ВМ, запущенное на физическом хосте, пользуется вычислительными ресурсами, памятью, сетевым хозяйством и возможностями хранилищ(а) хоста:

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

Важно! Виртуализация процессора – это не эмуляция. При помощи программного эмулятора программы могут существовать в компьютерной системе, отличной от той, для которой они были написаны изначально. Эмуляция обеспечивает портуемость, но может негативно повлиять на производительность. Виртуализация ЦП не является эмуляцией, так как поддерживаемые гостевые операционные системы разработаны для процессоров x64.

Используя гипервизор, ОС могут работать на физических процессорах x64 хостов. Когда виртуальных ВМ запущено на хосте ESXi много, они могут конкурировать за ресурсы ЦП. Если это происходит, время хоста ESXi разделяет физические процессоры на все виртуальные машины, чтобы каждая действовала так, как если бы имела определенное количество виртуальных процессоров.

Почти тот же принцип применяется к памяти. Когда программа запускается, она использует интерфейсы, предоставленные ОС, для выделения или освобождения страниц виртуальной памяти во время выполнения. Виртуальная память – это старая техника, которая используется в большинстве ОС общего назначения. ОС используют виртуальную память, чтобы предоставить приложениям больше памяти, чем той, к которой они имеют физический доступ. Почти все современные процессоры имеют аппаратное обеспечение для поддержки виртуальной памяти. Виртуальная память создает общее виртуальное адресное пространство для программ. При помощи ОС и аппаратного обеспечения виртуальная память может обрабатывать трансляцию адресов между виртуальным адресным пространством и физическим адресным пространством. Техника адаптирует среду исполнения для поддержки больших адресных пространств, защиты процессов, отображения файлов и обмена в современных компьютерных системах. В виртуализированной среде уровень виртуализации VMware создает непрерывное адресное пространство памяти для виртуальной машины во время ее запуска. Выделенное пространство памяти настраивается во время создания ВМ и обладает теми же свойствами, что и виртуальное адресное пространство. Благодаря подобной конфигурации гипервизор может запускать несколько ВМ одновременно, защищая память каждой от доступа других.

В отношении виртуализации сети, ВМ можно настраивать при помощи одного или нескольких виртуальных адаптеров Ethernet. ВМ используют виртуальные коммутаторы на одном и том же хосте ESXi для связи друг с другом при помощи тех же точно протоколов, которые используются через физические коммутаторы, без нужды в дополнительных аппаратных устройствах. Виртуальные коммутаторы также поддерживают VLAN, которые совместимы со стандартными реализациями VLAN от других вендоров сетевого оборудования. Благодаря виртуальной сети VMware можно связывать локальные ВМ между собой и подключать их к внешней сети через виртуальный коммутатор. Последний, как и физический коммутатор Ethernet, пересылает фреймы на уровень data link. Хост ESXi может содержать несколько виртуальных коммутаторов, и к внешней сети они могут подключаться через исходящие адаптеры Ethernet, которые называются vmnics. Виртуальный коммутатор может объединять несколько vmnic вместе, как NIC teaming на традиционном сервере, предлагая большую доступность и пропускную способность для ВМ. Виртуальные коммутаторы много в чем похожи на современные физические Ethernet. Как и физический коммутатор, каждый виртуальный изолирован и имеет собственную таблицу переадресации. Любой пункт назначения, который ищет коммутатор, может совпадать только с портами на том же виртуальном коммутаторе, с которого возник фрейм. Эта функция улучшает безопасность и усложняет взлом изоляции виртуального коммутатора. Виртуальные коммутаторы также поддерживают сегментацию VLAN на уровне порта, так что каждый порт можно настроить как порт доступа, или магистральный, обеспечивая доступ к одной или нескольким VLAN. Но, в отличие от физических коммутаторов, виртуальным не нужен протокол STP, так как применяется одноуровневая топология сети. Несколько виртуальных коммутаторов не могут быть соединены между собой, и сетевой трафик не в состоянии перетекать непосредственно от одного виртуального коммутатора к другому на том же самом хосте. Виртуальные коммутаторы обеспечивают все необходимые порты в одном коммутаторе и не нуждаются в каскадном подключении, так как не имеют общих физических адаптеров Ethernet, и между ними не возникает утечек.

Еще нужно остановиться на виртуализации ресурсов хранилища. Для хранения виртуальных дисков ESXi использует хранилища данных, которые являются логическими контейнерами, что скрывают особенности физического хранилища от ВМ и обеспечивают унифицированную модель для хранения их файлов. vSphere поддерживает такие типы хранилищ данных:

VMFS (VMware Virtual Machine File System) — файловая система виртуальной машины кластерного типа, которая обеспечивает виртуализацию хранилищ, оптимизированную под ВМ. Несколько хостов ESXi могут читать и записывать в одно и то же хранилище данных VMFS одновременно.
NFS (Network File System) – сетевая файловая система, протокол обмена файлами, который хосты ESXi используют для связи с устройством хранения данных, подключенным к сети (NAS).
vSAN — это программно-определяемое решение для хранения, которое обеспечивает общее хранилище для ВМ. vSAN виртуализирует локальное физическое хранилище в виде устройств HDD или SSD на хостах ESXi в кластере, превращая их в общее хранилище данных.
vSphere Virtual Volumes — виртуальные тома vSphere. Хранилище данных виртуализирует устройства SAN и NAS путем абстрагирования физических аппаратных ресурсов до логических пулов емкости. Массивы хранения или серверы предназначены для управления всеми аспектами хранилищ данных виртуальных томов vSphere, а хосты ESXi не имеют прямого доступа к таким хранилищам.

И наконец, напоследок, виртуализация GPU. Графические устройства GPU оптимизируют сложные графические операции, которые могут выполняться с высокой производительностью без перегрузки ЦП. Виртуальные GPU можно добавлять к ВМ в таких случаях:

Насыщенная 2D и 3D графика;
Использование виртуальных десктопов VMware Horizon;
Графические интенсивные программы;
Научные вычисления;
Рабочие нагрузки искусственного интеллекта (AI) и machine learning.

GPU могут использоваться разработчиками серверных приложений. Хотя серверы, обычно, не имеют мониторов, поддержка GPU является важной и актуальной для виртуализации серверов. Можно настроить ВМ с четырьмя устройствами vGPU, чтобы охватить такие случаи использования, которые требуют нескольких акселераторов GPU. VMware поддерживает видеокарты AMD и NVIDIA.

У VMware есть специальная технология — vSphere Bitfusion, которая виртуализирует аппаратные акселераторы (GPU), чтобы обеспечить пул общих доступных в сети ресурсов, с поддержкой рабочих нагрузок AI и ML. Благодаря ей, графические процессоры на одном хосте могут использоваться ВМ, что работают на других хостах:

Требования и совместимость

Чтобы понять, с какими другими продуктами VMware наша новая vSphere будет дружить, а какие будет считать окончательно устаревшими (теми, что требуют предварительного апгрейда до установления взаимосвязей с версией 8.0 среды), стоит воспользоваться инструментом VMware Product Interoperability Matrix:

И нужно помнить, что последний vCenter Server appliance может установиться лишь на хостах ESXi версии 6.7, или более свежей, либо на ESXi-хост или DRS-кластер из инвентаря инстанса vCenter Server версии 6.7 и более новой.

Так как сегодня мы уделяем максимум внимания именно greenfield-инсталляции, всей проблематики сосуществования, необходимых сопутствующих апгрейдов и прочего коснемся подробно в отдельном материале об обновлении vSphere до версии 8.0.

Все остальные вопросы совместимости (процессоры, устройства хранилища, SAN-массивы, I/O-устройства, другие устройства, в том числе) вендор рекомендует задавать в этой всеохватывающей табличке: VMware Compatibility Guide. Лишь заметим, что максимальный ресурсный охват ВМ, а также работа с некоторыми технологиями (Virtual NUMA Topology, Enhanced Direct Path I/O, Virtual Hyperthreading, vMotion App Notification, VM DataSets, OpenGL 4.3, UEFI 2.7A) возможны лишь при использовании 20-й версии виртуального аппаратного обеспечения, но, вообще, можно ставить и на 10-ое, при условии, что оно поддерживает 64 vCPU на каждую ВМ в ESXi.

Конфигурационные лимиты

Чтобы наша среда была работоспособной, и вообще позволила себя создать именно в таком виде, как нам нужно, в ее расчете опираться следует не только на свое видение функционала системы и ее возможностей, но и на определенные VMware максимумы конфигурации. Ознакомиться с ними можно в удобном инструменте VMware Configuration Maximus. В случае 8-й версии vSphere он выглядит так. Там можно найти все лимиты, начиная с базовых (максимумы для ВМ, vCenter Server, vSAN и вообще всего, что касается хранилищ, сети, ESXi Host и пр.), и вплоть до сотрудничества с Kubernetes и Cloud. Если вы уже имели дело с vSphere, даже с «семеркой», можете убедиться лишь не нескольких приведенных в таблице ниже примерах, насколько существенно выросли возможные параметры нашей среды:

Конфигурационный параметр	Максимальное значение
Виртуальные машины (на одну)
· vCPU	768
· память	24ТБ
· объем виртуального диска	62ТБ
· виртуальных NIC	10
· подключенных USB-устройств	20
· параллельных подключений к удаленной консоли	40
· политик хранилища	1024
· графической памяти	4ГБ
vCenter Server
· пользователей и групп	1 000 000
· задержка между связанными vCenter Server	150мс
· задержка между клиентом vSphere и vCenter Server	100мс
· групп AD или OpenLDAP на пользователя	1015
· хостов на vCenter Server	2500
· включенных ВМ на vCenter Server	40 000
· зарегистрированных ВМ на vCenter Server	45 000
· связанных vCenter Server	15
· МАС-адресов на vCenter Server	65 536
· хостов на vCenter Server управляемых vLCM	1000
· vMotion-операций на хост (при 1Гбит/с сети / 10Гбит/с)	4 / 8
· vMotion-операций на датастор	128
· библиотека контента (количество объектов на VC / размер объекта / количество библиотек на VC)	2000 / 1ТБ / 1000
· профилей хоста (созданных / прикрепленных)	500 / 500
ESXi (на хост)
· памяти	24ТБ
· виртуальных дисков	2048
· физических NIC (1Гбит/с / 10Гбит/с / 20Гбит/с)	32 / 16 / 16
· распределенных свитчей (на хост / на VC)	16 / 128
· графической памяти	16

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

Требования к уровню системного хранилища

Компоновка системного хранилища ESXi состоит из 4 партиций:

Партиция	Использование	Тип
System Boot	Сохраняет загрузчик и модули EFI	FAT16
Boot-bank 0	Системное место для хранения загрузочных модулей ESXi	FAT16
Boot-bank 1	Системное место для хранения загрузочных модулей ESXi	FAT16
ESX-OSData	Действует как общая локация для хранения дополнительных модулей. Не используется для загрузки и ВМ. Консолидирует устаревший раздел /scratch, locker-партицию для VMware Tools, и назначение основного дампа.	VMFS-L

Важно! В случае, когда медиа установки – это USB или SD-карта, по best practice нужно создать партиции ESX-OSData на устройстве постоянного хранилища, которое не используется совместно несколькими ESXi-хостами.

Том ESX-OSData поделен на две категории данных высокого уровня: постоянную и непостоянную. Первая содержит данные, которые записываются редко (VMware Tools, ISO, конфигурации и дампы ядра). К непостоянным относятся те, что записываются часто: журналы логов, глобальные трассы VMFS, данные vSAN Entry Persistence Daemon (EPD), трассы vSAN и БД в реальном времени:

Размеры партиций, за исключением раздела загрузки системы, могут изменяться в зависимости от размера загрузочного медиа. Если, например, оно емкостью 142 Гб и более, датастор VMFS создается автоматически для хранения данных ВМ.

Чтобы ограничить размер системных партиций хранилища на загрузочном медиа, можно воспользоваться загрузочной опцией ESXi-инсталлятора «systemMediaSize», которая предложит следующие варианты:

min (32 ГБ, для одного диска или встроенных серверов),
small (64 ГБ, для серверов с не менее 512 ГБ оперативной памяти),
default (128 ГБ),
max (потребляет все доступное пространство для много-терабайтных серверов).

Требования к «железу», сети и хранилищу

Соответственно, минимальными базовыми значениями ресурсов для ESXi 8.0 VMware определила следующие:

поддерживаемая серверная платформа,
2 ядра CPU,
8 Гб RAM (12Гб для продуктива),
1+ гигабитный или более быстрый Ethernet-контролер,
загрузочный диск на 32Гб постоянного хранилища.

Для максимальной производительности ESXi 8.0 желательно обеспечить устройства с, как минимум, 100Мб/с скоростью последовательной записи, а для предотвращения падения устройства он должен быть RAID 1 mirrored.

Если используется Auto Deploy метод инсталляции, либо директория логов отличается от дефолтной локации в scratch-директории на томе VMFS, может понадобится изменение размера журнала логов и параметров оборотов, чтобы иметь уверенность, что им хватит места. Дефолтные значения объема логов зависят от имеющегося места на хранилище и того, как именно настроена система логгирования. Хосты с Auto Deploy сохраняют логи на RAM диске, то есть, пространство для них выделяется довольно маленькое. В этом случае лучше перенаправлять логи по сети при помощи удаленного коллектора, или же на NAS либо NFS-хранилище. Минимальный размер и конфигурация ротации для логов hostd, vpxa и fdm:

Тип логов	Максимальный размер файла логов, МБ	Количество оборотов для сохранения	Минимальный нужный объем диска, МБ
Management Agent (hostd)	10	10	100
VirtualCenter Agent (vpxa)	5	10	50
Агент vSphere HA (Fault Domain Manager, fdm)	5	10	50

Для успешного развертывания vCenter Server Appliance нам, в свою очередь, будет нужно:

Размер среды vSphere	Кол-во vCPU	Память, Гб
Tiny (до 10 хостов или до 100 ВМ)	2	14
Small (до 100 хостов или 1 000 ВМ)	4	21
Medium (до 400 хостов или 4 000 ВМ)	8	30
Large (до 1 000 хостов или 10 000 ВМ)	16	39
X-Large (до 2 000 хостов или до 35 000 ВМ)	24	58

Важно! Если цель добавить ESXi-хост с более чем 512 LUN и 2 048 путями к инвентарю vCenter Server, разворачивать нужно, исключительно, vCenter Server appliance для Large или X-Large среды.

Насчет хранилища, в зависимости от размера среды и отталкиваясь от нужд БД, рекомендуется следующее (в Гб):

Размер среды vSphere	Дефолтный размер хранилища	Размер хранилища Large	Размер хранилища X-Large
Tiny (до 10 хостов или до 100 ВМ)	579	2 019	4 279
Small (до 100 хостов или 1 000 ВМ)	694	2 044	4 304
Medium (до 400 хостов или 4 000 ВМ)	908	2 208	4 468
Large (до 1 000 хостов или 10 000 ВМ)	1 358	2 258	4 518
X-Large (до 2 000 хостов или до 35 000 ВМ)	2 283	2 383	4 643

Требования к браузеру и ОС

Браузер, который используется, должен поддерживать VMware Host Client. В разрезе ОС клиентом хоста поддерживаются следующие версии браузера:

Браузер, версия	Mac OS	Windows	Linux
Google Chrome	89+	89+	75+
Mozilla Firefox	80+	80+	60+
Microsoft Edge	90+	90+	—

Инсталляция vCenter Server сейчас работает с такими ОС:

ОС	Версия	Минимальная конфигурация аппаратного обеспечения
Windows	Windows 10, 11 Windows 2016 x64 bit Windows 2019 x64 bit Windows 2022 x64 bit	4 GB RAM, 2 CPU с 4 ядрами 2.3 GHz, 32 GB хард-диск, 1 NIC
Linux	SUSE 15 Ubuntu 18.04, 20.04, 21.10	4 GB RAM, 1 CPU с 2 ядрами 2.3 GHz, 16 GB хард-диск, 1 NIC
Mac	macOS 10.15, 11, 12 macOS Catalina, Big Sur, Monterey	8 GB RAM, 1 CPU с 4 ядрами 2.4 GHz, 150 GB хард-диск, 1 NIC

Замечание. Клиентские машины на Mac 10.15+ не поддерживают параллельные развертывания нескольких appliances через GUI. Только последовательные.

Важно! Библиотеки Visual C++ нужно проинсталлировать, чтобы запустить инсталлятор CLI в версиях Windows, старее Windows 10. Инсталляторы Microsoft для этих библиотек находятся в каталоге vcsa-cli-installer/win32/vcredist.

И, наконец, последнее замечание: Если планируете развертываться через GUI, проследите, чтобы ваш монитор был с не меньшим 1024×768 разрешением.

Лицензирование

«Восьмерка» требует лицензирования на каждые 32 физические ядра.

Сравнение особенностей всех существующих на данный момент типов лицензий vSphere 8.0 приведено в этом документе. Все задачи лицензирования рассмотрим в запланированной отдельной статье об администрировании vSphere 8.0.

Подготовка к развертыванию vSphere 8.0

Если нами выполнены все требования насчет совместимости, куплены соответствующие лицензии (можно пока на evaluation-режиме в 60 дней – таким образом и устанавливается поначалу, а ввести их потом. Или вообще без них, если ставим на песочницу самую элементарную версию для тестирования и обзора), то переходим к непосредственной подготовке к развертыванию vSphere 8.0.

Начать ее стоит со скачивания соответствующих OVA из раздела загрузок официального сайта VMware. Сейчас никаких патчей для ESXi vSphere 8.0 еще не выходило, поэтому рабочим является билд 20513097:

а вот для vCenter Server предлагается уже версия 8.0.0а — 20519528:

Это для лицензий класса Standard, а другие образы можно найти по ссылке. Там же, кстати, и новые VMware Tools 12.1.5 и другие связанные компоненты.

Инсталлятор ESXi можно загрузить тремя способами: с CD/DVD, с USB-устройства, которое подходит, и через PXE-загрузку по сети. Для vCenter Server нужно будет подмонтировать ISO-образ к клиентской машине, с которой планируем разворачивать, или делать другие операции с ним.

Порты и протоколы

В рамках подготовки к инсталляции предварительно нужно обеспокоиться открытием необходимых портов. Прекрасный инструмент по этому поводу создан вендором на специальном ресурсе — там в фильтрах версии просто вводите «8» и получаете вест необходимый список, по которому идете, в соответствии с тем, что именно вам в результате будет нужно в системе.

Подготовка необходимой информации

Рекомендуется предварительно подготовить своеобразные worksheet и по ESXi (независимо от того, делаете ли вы вводы в процессе интерактива, или самостоятельно пишете инсталляционный скрипт), и по vCenter со всей необходимой информацией насчет нужных в процессе вводов и данных. По ESXi запишите следующее:

VLAN ID (опционально, диапазон от 0 до 4094),
IP address — IP-адрес (опционально, по дефолту DHCP – можно разрешить DHCP настраивать сеть в процессе инсталляции. Потом все это можно поменять),
Subnet mask — маску подсети (опционально, рассчитывается из IP-адреса),
Gateway — шлюз (опционально, опирается на настроенный IP-адрес и маску подсети),
Primary DNS (опционально, опирается на настроенный IP-адрес и маску подсети),
Secondary DNS (опционально),
Host name – имя хоста (нужно для настройки статического IP – клиент «сферы» может пользоваться как именем хоста, так и IP-адресом для доступа к ESXi-хосту),
Install location (должно быть, минимум, 5Гб места, если инсталлируете компоненты на один диск),
Root password (придумать от 8 до 40 символов, маленькие и большие буквы, цифры, спецсимволы – любая комбинация, нельзя целиком слова, их части, имена пользователей и т.д.).

А по vCenter Server Appliance – следующее:

FQDN и IP-адрес целевого сервера (ESXi-хоста или инстанса vCenter Server), на котором разворачиваем appliance,
HTTPS-порт целевого сервера – 443,
Имя пользователя с привилегиями администратора на целевом сервере (для ESXi-хоста – root, для инстанса vCenter Server – «user_name@your_domain_name») и пароль,
дата-центр из инвентаря vCenter Server, где разворачивается appliance. Целевой сервер должен быть инстансом vCenter Server. Опционально, можно предоставить папку дата-центра,
ESXi-хост или DRS-кластер из инвентаря дата-центра, на котором разворачивается appliance,
имя ВМ для appliance (не должно содержать символы «%», «\», «/», менее 80 знаков),
пароль пользователя root для операционной системы appliance (8-20 символов ASCII без пробелов с, минимум, одной большой и одной маленькой буквой, одной цифрой, одним спецсимволом),
размер разворачивания (дефолтное — Tiny),
размер хранилища vCenter Server appliance, учитывая среду (дефолтное — Default),
имя датастора, на котором желательно хранить конфигурационные файлы и виртуальные диски appliance (покажет доступные для целевого сервера датасторы),
Thin Disk Mode – Enable/disable (по дефолту — Disabled),
имя сети, к которой подключается appliance (продемонстрирует меню, которое выпадает) – она должна быть доступна с клиентской машины, с которой происходит все разворачивание,
IP-версия адреса appliance — IPv4/IPv6 (по дефолту IPv4),
IP-назначения для адреса appliance – static/DHCP (по дефолту static),
FQDN (если static из предыдущего пункта) – чтобы использовать в качестве имени системы (или IP-адрес),
IP-адрес,
для IPv4-сетей можно использовать или маску подсети, или префикс сети. Для IPv6-сетей – префикс сети,
дефолтный шлюз,
DNS-серверы, отделенные запятыми,
имя системы (FQDN) – только если у вас DHCP с IPv4 и Dynamic DNS (DDNS) сервер, доступный в среде,
параметры синхронизации времени (дефолтное — Synchronize time with NTP servers). Если используется более одного NTP-сервера, предоставляются их IP-адреса или FQDN, через запятую,
включить или исключить доступ по SSH (по дефолту — Disabled),
имя для нового vCenter Single Sign-On домена,
пароль для аккаунта администратора («administrator@your_domain_name» — требования см. выше),
пароль пользователя администратор vCenter Single Sign On для домена,
Join or do not participate in the VMware Customer Experience Improvement Program (CEIP) (дефолтное — Join the CEIP) – программа улучшения опыта пользователя, решаем, хотим ли присоединиться.

Важно! При использовании FQDN нужно убедиться, что клиентская машина, с которой осуществляется развертывание appliance, и сеть, на которой он разворачивается, пользуются одним и тем же DNS-сервером.

Подготовка к инсталляции хостов ESXi

В этом разделе уделим внимание подготовке ко всем трем вариантам инсталляции ESXi (интерактивному, через скрипты и vSphere Auto Deploy), а также кастомизации образов ESXi при помощи vSphere ESXi Image Builder.

Кастомизация инсталляций при помощи vSphere ESXi Image Builder

Сразу заметим, что все, что касается vSphere ESXi Image Builder требует доступ к клиенту vSphere, наличия хотя бы одного vCenter Server и, соответственно, хотя бы одного базового хоста, на котором наш vCenter разворачивался. Это не метод построения с нуля – это удобный функционал для дальнейшего расширения возможностей и автоматизации процессов разворачивания хостов в системе.

VMware vSphere® ESXi™ Image Builder CLI работает с созданием инсталляционных образов ESXi с индивидуальным набором обновлений, патчей и драйверов. Он используется с vSphere Client или PowerCLI, и дополнительно может включать в образ драйверы третье-сторонних сетей или хранилищ, которые издавались между релизами vSphere:

Разворачивается такая кастомизация при помощи записи ее на инсталляционный DVD или через vCenter Server (функция Auto Deploy). Командлеты vSphere ESXi Image Builder берут профили образов и VIB в качестве вводов и формируют разнообразные выводы, которые могут экспортироваться в виде ISO-образов или ZIP-файла оффлайн-хранилища. Профили образов определяют набор VIB, которые использует инсталляция ESXi или процесс апдейта. Они применяются к ESXi-хостам, предоставленным через vSphere Auto Deploy и должны отвечать следующим требованиям:

Уникальное имя и комбинация вендоров;
Уровень принятия (Image Builder будет проверять, совпадает ли VIB с уровнем принятия, определенным в профиле);
Если какие-то VIB нужны другим VIB, удалить их нельзя;
Две версии одного и того же VIB нельзя включать в один профиль образа (новая версия заменит существующую).

Важно! Уровень принятия каждого VIB на хосте должен быть, как минимум, таким же, как уровень принятия хоста.

Важным моментом в жизни профиля образа является валидация. Чтобы пройти ее успешно, он должен:

Состоять, минимум, из одного базового VIB и одного загрузочного модуля ядра;
Если два VIB связаны – оба должны быть включены в профиль образа;
VIB не должны конфликтовать друг с другом;
Нельзя добавлять два одинаково названные VIB, даже разных версий (происходит замещение более старого тем, что новее);
Нет никаких проблем с уровнем принятия.

Каждый раз, когда изменяется профиль образа, vSphere ESXi Image Builder проверяет, не отменяет ли это валидность профиля.

Уровень принятия (acceptance level) и его изменение

Уровень принятия – важная характеристика каждого VIB и профиля образа. Она обозначает путь, которым они были протестированы и по какому поддерживаются. В целом стоит перечислить следующие существующие уровни:

VMwareCertified (самые строгие условия, тщательное тестирование, служба поддержки VMware принимает по ним обращения в полном объеме. Сейчас лишь программные драйверы I/O Vendor Program (IOVP) принадлежат к нему);
VMwareAccepted (проверочное тестирование партнером, но не полное для каждой функции ПО, а VMware проверяет результат. Обращения в службу поддержки VMware перенаправляются партнеру. Примеры: провайдеры CIM и плагины PSA);
PartnerSupported (опубликованные партнером, которому VMware доверяет, им же протестированные, но VMware не проверенные. Обращения – также к партнеру. Пример: технологии драйверов ATAoE, SSD, другие нестандартные драйверы аппаратного обеспечения);
CommunitySupported (созданные лицами или компаниями за пределами партнерских программ VMware, не тестированные одобренным VMware образом, не поддерживаются ни VMware, ни партнерами).

Дефолтным для VIB является уровень «PartnerSupported». Его можно изменить командами ESXCLI (cmdlet «Set-EsxImageProfile» для профиля образа) по следующей процедуре:

Заходим в сессию PowerCLI и запускаем cmdlet «Add-EsxSoftwareDepot», для каждого хранилища, с которым хотим работать:

Add-EsxSoftwareDepot –DepotUrl <depot_url> — удаленное хранилище,

или загружаем ZIP-файл в локальную файловую систему и запускаем

Add-EsxSoftwareDepot -DepotUrl C:\<file_path>\<offline-bundle>.zip

Командлет вернет один или больше SoftwareDepot объектов.

Получаем уровень принятия профиля образа:

Get-EsxImageProfile -Name string

Устанавливаем уровень принятия профиля образа:

Set-EsxImageProfile -Name string -AcceptanceLevel level

А изменить уровень принятия хоста можно так:

Вызываем уровень принятия для профилю образа или VIB командами:

esxcli —server=server_name software sources vib list —depot=depot_URL – просмотреть информацию по всем VIB

esxcli —server=server_name software sources vib list —viburl=vib_URL – просмотреть информацию по указанному VIB

esxcli —server=server_name software sources profile list — depot=depot_URL – просмотреть информацию по всем профилям образов

esxcli —server=server_name software sources profile get —depot=depot_URL —profile=profile_name – просмотреть информацию по указанному профилю образа

Проверяем уровень принятия хоста:

esxcli —server=server_name software acceptance get

Изменяем уровень принятия хоста:

esxcli —server=server_name software acceptance set —level=acceptance_level , где значение «acceptance_level» — это «VMwareCertified», «VMwareAccepted», «PartnerSupported» или «CommunitySupported». Значения чувствительны к регистру.

Настройка vSphere ESXi Image Builder

Перед тем, как приступить к настройке vSphere ESXi Image Builder, нужно убедиться, достаточно ли хранилища для репозитория vSphere Auto Deploy (сервер vSphere Auto Deploy пользуется им, чтобы сохранять необходимые ему данные, включая правила и наборы правил, которые создаются для VIB и профилей образов, что указываются для этих правил). По best practice это должно быть 2Гб (каждый профиль образа занимает, приблизительно, 400Мб). Далее:

Проходим в клиенте vSphere в Home > Auto Deploy;
На странице Auto Deploy выбираем нужный vCenter Server из выпадающего меню вверху;
Кликаем на Enable Image Builder для активации сервиса – появится вкладка Software Depots;
Добавляем хранилище ПО (одно или несколько) в инвентарь vSphere ESXi Image Builder: кликаем на New – появится окно Add Software Depot, где выбираем тип хранилища (Online Depot/Custom Depot). Для первого вводим имя хранилища в инвентаре и URL онлайн-хранилища, а для второго – только имя. Нажимаем Add;
Опционально, заходим на вкладку Software Packages, чтобы увидеть содержимое выбранного хранилища и дополнительную информацию о пакетах;
Опционально, для «Online depot» можно получить самые свежие пакеты хранилища, нажав Check for Updates, или дополнительную информацию о хранилище, кликнув на More info;
Если работаете с оффлайн-хранилищем в локальной файловой системе, можно импортировать ZIP-файл в инвентарь vSphere ESXi Image Builder. На той же вкладке Software Depots кликаем на Import, вводим имя хранилища в инвентаре, после нажимаем на Browse и выбираем ZIP-файл из локальной системы и кликаем Upload.

Операции с профилем образа

Профили образа можно создавать новые, клонировать уже существующие, редактировать, сравнивать между собой, перемещать в другое хранилище ПО, экспортировать готовые в ISO или Offline Bundle ZIP, регенерировать.

Чтобы создать новый профиль образа:

Проходим в Home > Auto Deploy;
Из выпадающего меню Software depot выбираем, в каком пользовательском хранилище хотим добавить новый профиль;
На вкладке Image Profiles кликаем New Image Profile;
Вводим уникальное имя, вендора и описание, нажимаем Next – появится окно Select software packages;
Из выпадающего меню выбираем уровень принятия для профиля образа;
Выбираем VIB, которые хотим добавить в профиль образа и снимаем выбор с тех, что не нужны, после чего нажимаем на Next;

Важно! Профиль образа должен содержать загружаемый образ ESXi, чтобы быть валидным.

На странице Ready to complete просматриваем итоговую информацию о новом профиле образа. Кликаем Finish.

Чтобы клонировать уже существующий профиль образа:

Проходим в Home > Auto Deploy;
Из выпадающего меню Software depot выбираем, в каком хранилище есть профиль образа, который нужно клонировать;
Из списка профилей образов в хранилище выбираем тот, что должен быть клонирован, и нажимаем Clone;
Вводим уникальное имя профиля образа, вендора и описание;
Из выпадающего меню Software depot выбираем пользовательское хранилище, в которое хотим добавить новый профиль образа, кликаем Next – появится страница Select software packages;
Из выпадающего меню выбираем уровень принятия для профиля образа;
Выбираем VIB, которые хотим добавить в профиль образа и снимаем выбор с тех, что не нужны. Нажимаем Next;
На странице Ready to complete просматриваем итоговую информацию о новосозданном профиле образа, после чего кликаем Finish.

Чтобы отредактировать существующий профиль образа:

Проходим в Home > Auto Deploy;
Из выпадающего меню Software depot выбираем, в каком хранилище есть профиль образа, что нужно отредактировать;
На вкладке Image Profiles выбираем нужный профиль образа и кликаем на Edit – появится помощник Edit Image Profile;
Опционально, можно сменить имя, вендора и описание;
Кликаем Next – появится страница Select software packages;
Из выпадающего меню выбираем уровень принятия профиля образа;
Выбираем VIB, которые хотим добавить, и снимаем выбор с тех, что не нужны;
На странице Ready to complete просматриваем итоговую информацию и кликаем Finish.

Чтобы сравнить два профиля образов (одинаков ли в них список VIB, версия, уровень принятия, например):

Проходим в Home > Auto Deploy;
Из выпадающего меню Software depot выбираем, в каком хранилище есть профили образов, которые нужно сравнить;
На вкладке Image Profiles выбираем профиль образа и кликаем Compare To – появится помощник Compare Image Profile;
Нажимаем Change, чтобы выбрать второй профиль образа – появится страница Select Image Profile;
Выбираем хранилище ПО из выпадающего меню и нажимаем на второй профиль образа;
На странице Compare Image Profile выбираем опцию сравнения из выпадающего Software packages: левая сторона списка продемонстрирует подробности о VIB, что содержатся в первом выбранном профиле образа, а правая – то, что касается второго профиля образа. Одинаковые VIB будут промаркированы как «Same», те, что есть в одном профиле, но отсутствуют во втором – как «Missing».

Чтобы переместить профиль образа в другое хранилище ПО:

Проходим в Home > Auto Deploy;
Из выпадающего меню Software depot выбираем, в каком хранилище есть профиль образа, который нужно переместить;
На вкладке Image Profiles выбираем профиль и кликаем Move to;
Из выпадающего меню выбираем пользовательское хранилище, в которое хотим переместить профиль образа и нажимаем на OK.

Чтобы экспортировать профиль образа в ISO или Offline Bundle ZIP:

Проходим в Home > Auto Deploy;
Из выпадающего меню Software depot выбираем, в каком хранилище есть профиль образа, с которым хотим поработать;
На вкладке Image Profiles выбираем профиль образа и кликаем на Export – появится окно Export Image Profile;
Выбираем тип экспортируемого файла (ISO/ZIP);
Опционально, если хотим пропустить верификацию уровня принятия, выбираем Skip acceptance level checking;
Кликаем ОК – ссылка Download начнет генерировать колонку «Download Image Profiles» выбранного профиля образа;
Когда процесс закончится, кликаем на Download, чтобы сохранить экспортированный файл.

Чтобы регенерировать профиль образа (иногда нужно, чтобы убедиться, что все хосты обладают одинаковой спецификацией софта, ведь если спецификация образа была изменена в vSphere Lifecycle Manager, обязательно необходимо вручную проапдейтить PXE-образ):

Проходим в Home > Auto Deploy;
На вкладке Deploy Rules выбираем желаемое правило (то, что отвечает ESXi-хостам в кластере, управляемом образом);
Если правило активное, сначала деактивируем его: кликаем на вкладку Activate/Deactive Rules, в диалоговом окне выбираем правило – Deactivate и нажимаем на OK;
Выбираем Reacreate Image Profile и в диалоговом окне подтверждения кликаем Recreate;
Опционально, активируем правило снова – делаем то же самое, что в 3 шаге, но жмем на Activate.

На том, как работать с правилами развертывания относительно профилей образов остановимся подробно ниже в разделе о подготовке к развертыванию ESXi при помощи vSphere Auto Deploy.

Подготовка к скриптованной инсталляции ESXi-хостов

Иногда дефолтный скрипт, о котором разговор пойдет ниже, в разделе «Инсталляция ESXi при помощи скрипта» не устраивает администратора. Чтобы модифицировать инсталляционный скрипт, пользуемся следующим перечнем поддерживаемых команд (обязательно должна присутствовать команда «install», которая создает дефолтные партиции, включая VMFS-датастор, что занимает все свободное пространство, которое останется после создания других партиций):

accepteula / vmaccepteula (требуется) – принимает лицензионное соглашение ESXi.

clearpart (опционально) – очищает любые существующие партиции на диске. Требует указания команды install. Осторожно редактируйте команду clearpart в существующих скриптах!

—drives= (удаляет партиции на указанных дисках)
—alldrives (игнорирует требование —drives= и позволяет очищать партиции на каждом диске)
—ignoredrives= (удаляет партиции на всех дисках, за исключением указанных. Нужно, если не установлено флажок на —drives= или –alldrives)
—overwritevmfs (позволяет перезапись VMFS-партиций на указанных дисках. По дефолту, перезапись VMFS-партиций не разрешена)
—firstdisk=

disk-type1

[disk-type2,…]

Важно! Если в системе есть DPU, также указывается PCI-слот.

(Разбивает первый найденный пригодный диск. По умолчанию доступны диски установленные в следующем порядке:

1. локально подсоединенное хранилище,
2. сетевое хранилище (удаленное).

Порядок дисков можно изменить, используя приложенный к аргументу список, где диски разделены запятыми. Если дается список фильтров, дефолтные параметры переопределяются. Можно комбинировать фильтры, чтобы указать отдельный диск, включая esx для первого диска с установленным на нем ESXi, модель и информацию о вендоре или название драйвера устройства VMkernel. Например, чтоб отдать предпочтение диску с названием модели ST3120814A и любому диску, который использует драйвер mptsas, а не обычному локальному диску, аргумент будет:

—firstdisk=ST3120814A,mptsas,local

Можно использовать localesx для локального хранилища, что содержит образ ESXi или remoteesx для удаленного хранилища с ним)

dryrun (опционально) – парсит и проверяет инсталляционный скрипт. Не инсталлирует непосредственно.

install – указывает, что это свежая инсталляция. Команда install требует определения, на каком диске будет проинсталлировано ESXi.

—disk= или —drive= (Указывает диск для разбития. В команде —disk=diskname значение diskname может быть именем диска или целым путем диска в файловой системе ESXi. Например,

для имени диска: —disk=naa.6d09466044143600247aee55ca2a6405

для пути устройства: —disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0

—firstdisk=

disk-type1,

[disk-type2,…]

Важно! Если в системе есть DPU, также указывается и PCI-слот:

install —firstdisk —overwritevmfs —dpuPciSlots=

(Разбивает первый найденный пригодный диск. По умолчанию доступные диски установлены в следующем порядке:

a. локально подсоединенное хранилище,

b. сетевое хранилище (удаленное).

Порядок дисков можно изменить, используя добавленный к аргументу список, где диски разделены запятыми. Если дается список фильтров, дефолтные параметры переопределяются. Можно комбинировать фильтры, чтобы указать отдельный диск, включая с esx для первого диска с установленным на нем ESXi, модель и информацию о вендоре или название драйвера устройства VMkernel. Например, чтобы отдать предпочтение диску с названием модели ST3120814A и любому диску, который использует драйвер mptsas, а не обычному локальному диску, аргумент будет:

—firstdisk=ST3120814A,mptsas,local

—ignoressd (Включает жесткие диски, пригодные для разбивки. Эта опция может использоваться с командой install и параметром —firstdisk. Она имеет приоритет над —firstdisk. Является недействительной с опциями —drive или —disk и с командами upgrade и installorupgrade.
—overwritevsan (Используется, когда инсталлируется ESXi на диск SSD или HDD (магнитный), который есть в дисковой группе vSAN. При использовании этой опции и если не тни одной партиции vSAN на выбранном диске, инсталляция не пойдет. При инсталляции ESXi на диске из дисковой группы vSAN, результат зависит от выбранного диска. Если это SSD, обнулятся SSD и все подчиненные HDD из этой же группы. Если это HDD, а размер дисковой группы превышает 2, только выбранный HDD будет очищено. Если же выбрано HDD, но размер дисковой группы меньший или равен 2, и SSD, и выбранный HDD будут очищены.
—overwritevmfs (нужно для перезаписи существующего датастора VMFS на диске перед инсталляцией)
—preservevmfs (сохраняет имеющееся хранилище данных VMFS на диске перед инсталляцией)
—novmfsondisk (Предотвращает создание на этом диске партиций VMFS. Должен использоваться с –overwritevmfs, если на диске есть партиции VMFS)
—systemdisk (При использовании USB или SD устройства systemDisk указывает локальный постоянный диск для инсталляции партиции ESX-OSData. Например,

install —firstdisk = usb —systemDisk=<diskID>

В результате партиции boot bank помещаются на USB-устройство, в то время как партиция OSData есть на диске, указанном в параметре systemDisk)

—repartitionsystemdisk (Если используется USB или SD-устройство, а локальный диск, указанный в параметре systemDisk, не пустой или содержит датастор, можно использовать эту опцию для уверенности, что постоянный диск будет переразбит перед использованием)

Важно! Если локальный постоянный диск недоступен, или его размер меньше 32Гб, появится предупреждение, хотя инсталляция не прервется.

— forceunsupportedinstall (блокирует инсталляцию устаревших CPU)

keyboard (опционально) – устанавливает тип клавиатуры для системы.

keyboardType (Определяет схему клавиатуры для выбранного ее типа. Должна быть одной из следующих: бельгийской, бразильской, хорватской, чехословацкой, датской, эстонской, финской, французской, немецкой, греческой, исландской, итальянской, японской, латиноамериканской, норвежской, польской, португальской, российской, словенской, испанской, шведской, швейцарской французской, швейцарской немецкой, турецкой, украинской, британской, американской по умолчанию, американской Dvorak.

serialnum или vmserialnum (опционально) – команда поддерживается, начиная с ESXi 5.1. Конфигурирует лицензирование. Если не включить, ESXi будет проинсталлировано в evaluation режиме.

—esx= (Указывает на лицензионный ключ, который должен использоваться. Формат: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX).

network (опционально) – указывает сетевые адреса для системы.

—bootproto=[dhcp| static] (указывает, нужно ли получать сетевые настройки от DHCP, или вводить их вручную)
—device= (Указывает или MAC-адрес сетевой карты, или название устройства в форме vmnicNN, как у vmnic Этот вариант касается аплинк-устройств для виртуального коммутатора)
—ip= (Предоставляет IP-адрес для инсталлируемой машины в формате xxx.xxx.xxx.xxx. Нужна с опцией —bootproto=static, иначе игрорируется)
—gateway= (Назначает шлюз по умолчанию как IP-адрес в формате xxx.xxx.xxx.xxx. Используется с опцией —bootproto=static)
—nameserver= (Назначает основной сервер имен как IP-адрес. Используется с опцией —bootproto=static. Пропустите этот параметр, если не собираетесь использовать DNS. Он может принимать два IP-адреса. Например,

—nameserver=»10.126.87.104[,10.126.87.120]» )

—netmask= (Указывает маску подсети для инсталлируемой системы в формате 255.xxx.xxx.xxx. Используется с опцией —bootproto=static)
—hostname= (указывает имя хоста для инсталлируемой системы)
—vlanid= vlanid (Определяет, к какой VLAN подключена система. Используется или с —bootproto=dhcp, или с —bootproto=static опцией. Значение – целое число от 1 до 4096)
—addvmportgroup=(0|1) (Указывает, добавлять ли VM Network port group, что используется виртуальными машинами. Дефолтное значение – 1)

paranoid (опционально) – вынуждает предупреждающие оповещения прерывать инсталляцию. Если на нее не обращать внимания, предупреждающие оповещения будут просто сохранены в логах.

part или partition (опционально) – создает дополнительное хранилище данных VMFS на системе. Создается только одно хранилище на диск. Не может использоваться на том же диске в качестве инсталляционной команды. Только одна партиция может быть указана на диск и это должна быть исключительно VMFS-партиция.

datastore name (указывает, где партиция должна быть подмонтированной)
—ondisk= или —ondrive= (указывает диск или устройство, где создается партиция)
—firstdisk=

disk-type1,

[disk-type2,…]

Важно! Если в системе есть DPU, также указывается и PCI-слот:

install —firstdisk —overwritevmfs —dpuPciSlots=

(Разбивает первый найденный пригодный диск. По умолчанию доступные диски установлены в следующем порядке:

a. локально подсоединенное хранилище,

b. сетевое хранилище (удаленное).

Порядок дисков можно изменить, используя добавленный к аргументу список, где диски разделены запятыми. Если дается список фильтров, дефолтные параметры переопределяются. Можно комбинировать фильтры, чтобы указать отдельный диск, включая esx для первого диска с установленным на нем ESXi, модель и информацию о вендоре или название устройства VMkernel. Например, чтобы отдать предпочтение диску с названием модели ST3120814A и любому диску, который использует драйвер mptsas, а не обычному локальному диску, аргумент будет:

—firstdisk=ST3120814A,mptsas,local

reboot (опционально) – перегружает машину после завершения скриптованной инсталляции.

<—noeject> (CD не вынимается после инсталляции)

rootpw (требуется) – устанавливает пароль root для системы.

—iscrypted (указывает, что пароль зашифровано)
password (указывает значение пароля)

%include или include (опционально) – указывает на другой инсталляционный скрипт для анализа. Эта команда обрабатывается точно так же, как многострочная, но принимает лишь один аргумент.

filename (Например, %include part.cfg )

%pre (опционально) – указывает скрипт, который нужно запустить до оценки конфигурации kickstart. Например, этим можно воспользоваться, чтобы сгенерировать файлы, которые должен включить в себя kickstart.

—interpreter

=[python|busybox] (Определяет интерпретатор для использования. Дефолтным является busybox)

%post (опционально) – запускает указанный скрипт после завершения пакетной инсталляции. Если указать несколько секций %post, они запустятся в порядке, в котором они появились в инсталляционном скрипте.

—interpreter

=[python|busybox] (Определяет интерпретатор для использования. Дефолтным является busybox)

—timeout=secs (Определяет таймаут для запуска скрипта. Если скрипт еще не закончил свою работу к моменту, когда таймаут вышел, скрипт будет остановлено силой)
—ignorefailure =[true|false] (Если true, инсталляция будет считаться успешной, даже если скрипт %post остановится с ошибкой)

%firstboot — создает init скрипт, который запускается только при первой загрузке. Никоим образом не влияет на последовательные загрузки. Если указаны несколько секций %firstboot, они запустятся в порядке, в котором они появились в файле kickstart.

Важно! Семантика скриптов %firstboot не может быть проверена, пока система не загрузится впервые. Скрипт %firstboot может содержать потенциально катастрофические ошибки, которые не проявят себя до окончания установки.

Важно! Скрипт %firstboot не запускается, если на ESXi-хосте включена защищенная загрузка.

—interpreter

=[python|busybox] (Определяет интерпретатора для использования. Дефолтным является busybox).

Подготовка к скриптованой инсталляции ESXi с сетевой загрузкой инсталлятора

Можно использовать preboot execution environment (PXE) для загрузки ESXi-хоста с сетевого устройства, если хост использует устаревший BIOS или UEFI. Альтернативно, если хост поддерживает нативный UEFI HTTP, можно воспользоваться hypertext transfer protocol (HTTP) для загрузки хоста с сетевого устройства – вытянуть файлы инсталлятора и загрузить их по сетевому интерфейсу.

PXE использует Dynamic Host Configuration Protocol (DHCP) и Trivial File Transfer Protocol (TFTP) для загрузки ОС по сети. PXE-загрузки требует некоторую сетевую инфраструктуру и машины с PXE-совместимым сетевым адаптером. Большинство машин, которые способны запускать ESXi, имеют сетевые адаптеры, способные на PXE-загрузку.

Нативные UEFI HTTP используют DHCP и HTTP для загрузки по сети, требуют сетевую инфраструктуру, версии микропрограммы UEFI на хосте ESXi, которая включает функцию загрузки HTTP и сетевого адаптера, что поддерживает работу в сети UEFI. Загрузка по HTTP является более быстрой и надежной, по сравнению с TFTP, из-за возможностей протокола TCP, который лежит в основе HTTP, в частности, встроенной потоковой передачей и восстановлением потерянных пакетов. Если хосты ESXi не поддерживают нативный UEFI HTTP, можно использовать iPXE HTTP для процесса загрузки.

Важно! Сетевая загрузка с устаревшим BIOS возможна только по IPv4. Сетевая загрузка с UEFI BIOS возможна как по IPv4, так и по IPv6.

Для того, чтобы инсталляция пошла, сначала загружается целевой хост, он взаимодействует с разными серверами в среде, чтобы получить сетевой адаптер, загрузчик, ядро, IP-адрес для ядра и, наконец, инсталляционный скрипт:

Взаимодействие ESXi-хоста с другими серверами происходит следующим образом:

Пользователь загружает целевой ESXi-хост;
Целевой ESXi-хост делает DHCP-запрос;
DHCP-сервер отвечает с IP-информацией, локацией TFTP/HTTP-сервера, именем файла или URL начального сетевого загрузчика;
ESXi-хост контактирует с TFTP/HTTP-сервером и запрашивает имя файла или URL, указанные DHCP-сервером;
TFTP/HTTP-сервер посылает сетевой загрузчик, и ESXi-хост его запускает. Начальный загрузчик может подгрузить дополнительные компоненты с сервера;
Загрузчик ищет конфигурационный файл на TFTP/HTTP-сервере, загружает ядро и другие компоненты ESXi, что указаны в конфигурационном файле, и загружает ядро на ESXi-хост;
Инсталлятор запускается интерактивно или с использованием скрипта kickstart – так, как указано в конфигурационном файле.

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

TFTP Server. Trivial File Transfer Protocol (TFTP) похожий на FTP-сервис, и обычно используется только для систем сетевой загрузки или загрузки микропрограмм на сетевых устройствах, например, на роутерах. Доступен на Linux и Windows.

SYSLINUX и PXELINUX. При использовании PXE в устаревшей BIOS-среде важно понимать разные среды загрузки. SYSLINUX – это open-source среда загрузки для машин с устаревшим BIOS. Загрузчик ESXi для BIOS-систем («mboot.c32») запускается как плагин SYSLINUX. Можно настроить SYSLINUX для загрузки с разных типов медиа, включая диск, ISO-образ и сеть. Загрузить можно отсюда. PXELINUX – это конфигурация SYSXLINUX для загрузки с TFTP-сервера, соответственно PXE-стандарту. При использовании PXELINUX для загрузки ESXi-инсталлятора бинарный файл «pxelinux.0», «mboot.c32», конфигурационный файл, ядро и другие файлы переносятся при помощи TFTP.

iPXE. iPXE – это open-source ПО, предоставляющее имплементацию HTTP. Может использоваться в начальной загрузке. Больше почитать о нем можно здесь. Кстати, VMware включила iPXE как часть Auto Deploy (будем рассматривать ниже в соответствующем разделе про инсталляцию хоста через Auto Deploy).

UEFI PXE и UEFI HTTP. Большинство микропрограмм UEFI нативно содержат поддержку PXE, которая позволяет загрузку с TFTP-сервера. Микро-ПО можно напрямую загружать загрузчиком ESXi для UEFI («mboot.efi»). Дополнительное ПО, вроде PXELINUX, не требуется. Некоторые микропрограммы UEFI поддерживают нативную загрузку UEFI HTTP (начиная с версии 2.5). Это ПО может загружать загрузчик ESXi с HTTP-сервера, не требуя дополнительный софт, вроде iPXE.

Альтернативно, добраться к разному загрузочному сетевому ПО на различных хостах можно через:

Настройку DHCP-сервера для предоставления разнообразных начальных имен файлов загрузчиков разным хостам, в зависимости от MAC-адреса или других критериев. Подробности можно найти в документации по DCHP-серверам.
Путь использования iPXE как начального загрузчика с файлом конфигурации iPXE, который выбирает следующего загрузчика, опираясь на MAC-адрес или другой критерий.

Если планируем использовать TFTP-сервер для PXE-загрузки инсталлятора ESXi, процедура будет отличаться, в зависимости от того, работаем ли с UEFI, или с устаревшим BIOS. В другом случае один и тот же начальный загрузчик для всех целевых машин «pxelinux.0» используется для загрузки множества разных версий ESXi-инсталлятора. Но потенциально разные конфигурационные файлы PXELINUX зависят от MAC-адреса целевой машины. Для UEFI-машин процедура поддерживает разнообразные версии инсталлятора ESXi путем использования одинакового начального загрузчика «mboot.efi» для всех целевых машин, но потенциально разные файлы «boot.cfg» зависят от MAC-адреса целевой машины.

До того, как приступить к загрузке, следует подготовить:

ISO-образ инсталлятора ESXi,
целевой хост с конфигурацией аппаратной части, что поддерживается версией ESXi,
сетевой адаптер с PXE-поддержкой на целевом хосте ESXi,
DHCP-сервер, чтобы можно было настроить PXE-загрузку,
TFTP-сервер,
политики сетевой безопасности, позволяющие TFTP-трафик (UDP порт 69),
инсталляционный скрипт (файл kickstart).

Важно! Используйте нативные VLAN в большинстве случаев. Если хотите указать VLAN ID, чтобы использовался в PXE-загрузке, проверьте, поддерживает ли ваш NIC спецификацию VLAN ID.

Сама процедура выглядит так:

В случае BIOS, получаем и настраиваем PXELINUX. Получаем SYSLINUX86, распаковываем и копируем файл «pxelinux.0» на верхний уровень директории «tftpboot» на TFTP-сервере. Создаем конфигурационный файл PXELINUX по такой модели кода:

DEFAULT install

NOHALT 1

LABEL install

KERNEL ESXi-8.x.x-XXXXXX/mboot.c32

APPEND -c ESXi-8.x.x-XXXXXX/boot.cfg

IPAPPEND 2

где «ESXi-8.x.x-XXXXXX» — имя поддиректории TFTP, содержащей файлы инсталлятора ESXi

Сохраняем файл PXELINUX в директории «/tftpboot/pxelinux.cfg» на TFTP-сервере с именем, что определит, все ли хосты загрузят этот инсталлятор по умолчанию. Рекомендуется употреблять «default», если все хосты должны пользоваться этим инсталлятором, либо называть его по MAC-адресу целевой машины хоста, если хотим, чтобы конкретный хост загружал этот файл («01- mac_address_of_target_ESXi_host»).

При наличии UEFI, копируем файл «efi/boot/bootxefi» с ISO-образа ESXi-инсталлятора в папку «/tftpboot» на TFTP-сервере и переименовываем его на «mboot.efi»;
Настраиваем DHCP-сервер;
Создаем поддиректорию директории верхнего уровня «/tftpboot» на TFTP-сервере и называем ее по версии ESXi (например, «/tftpboot/ESXi-8.x.x-xxxxx»);
Копируем содержимое образа ESXi-инсталлятора в новосозданную директорию;
Редактируем файл «boot.cfg». Добавляем строку:

prefix=ESXi-8.x.x-xxxxxx

где «ESXi-8.x.x-xxxxxx» — это путь к инсталляционным файлам относительно корневого каталога сервера TFTP.

Если имена файлов в строках «kernel=» и «modules=» начинаются с символа «/», удаляем этот символ.

Если строка «kernelopt=» содержит строчку «cdromBoot», удаляем ее;

Если будем работать со скриптованой инсталляцией, в файле «boot.cfg» добавляем параметр «kernelopt» к строке после команды ядра, чтоб указать локацию инсталляционного скрипта, вида:

kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg

где «XXX.XXX.XXX.XXX» — IP-адрес сервера, где расположен инсталляционный скрипт, а «esxi_ksFiles» — директория, в которой содержится файл «ks.cfg»;

Для хостов ESXi с UEFI указываем, хотим ли, чтобы все хосты загружали одинаковый инсталлятор. Если да, то копируем или линкуем файл «boot.cfg» в «/tftpboot/boot.cfg». Если разные хосты должны пользоваться разными инсталляторами, помещаем копию (или ссылку) на файл хоста «boot.cfg» в ту директорию, например, «/tftpboot/01-23-45-67-89-0a-bc/boot.cfg».

Если планируем загрузку ESXi-инсталлятора при помощи iPXE и HTTP, подготовительные действия, кроме всего того, что касается TFTP-сервера для PXE-загрузки, должны включать такие шаги:

проверку, доступен ли HTTP-сервер с целевых ESXi-хостов,
получение пакета SYSLINUX версии 3.86, если ESXi-хост запускается на устаревшем BIOS.

Далее порядок действий:

Получаем и настраиваем iPXE – на странице загрузки iPXE будут инструкции, которым следуем, но, в случае BIOS запускаем «make bin/undionly.kpxe», а для UEFI – «make bin-x86_64-efi/snponly.efi». Копируем файл «undionly.kpxe» или «snponly.efi» в каталог «/tftpboot» на TFTP-сервере;
Если BIOS, получаем и настраиваем PXELINUX. Получаем SYSLINUX версии 3.86 и копируем файл «pxelinux.0» в каталог «/tftpboot» на TFTP-сервере. Создаем конфигурационный файл следующего вида:

DEFAULT install

NOHALT 1

LABEL install

KERNEL ESXi-8.x.x-XXXXXX/mboot.c32

APPEND -c ESXi-8.x.x-XXXXXX/boot.cfg

IPAPPEND 2

где «ESXi-8.x.x-XXXXXX» — это имя поддиректории TFTP, что содержит файлы инсталлятора ESXi. Сохраняем этот файл в директории «/tftpboot/pxelinux.cfg» на TFTP-сервере. Имя файла должно обозначать, все ли хосты будут его использовать по умолчанию (называем «default», если да, если же только указанные хосты – то «01- mac_address_of_target_ESXi_host», по МАС-адресу соответствующего хоста).

Для UEFI копируем файл «efi/boot/bootxefi» из образа инсталлятора в папку «/tftpboot» на TFTP-сервере и переименовываем его на «mboot.efi»;
Настраиваем DHCP-сервер;
Создаем директорию на HTTP-сервере с таким же именем, как версия ESXi в ней:

/var/www/html/ESXi-8.x.x-XXXXXX

Копируем содержимое образа в новосозданную директорию;
Редактируем файл «boot.cfg». Добавляем строку:

prefix=http://XXX.XXX.XXX.XXX/ESXi-8.x.x-XXXXXX

где «http://XXX.XXX.XXX.XXX/ESXi-8.x.x-XXXXXX» — это локация, где находятся файлы инсталлятора на HTTP-сервере.

Если имена файлов в строках «kernel=» и «modules=» начинаются с «/», удаляем этот символ. Если строка «kernelopt=» содержит строчку «cdromBoot», удаляем ее;

Для скриптованой инсталляции в файле «boot.cfg» добавляем параметр «kernelopt» в строку после команды ядра, чтобы указать локацию инсталляционного скрипта, вида:

kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg

где «XXX.XXX.XXX.XXX» — это ІР-адрес сервера, где находится инсталляционный скрипт, а «esxi_ksFiles» — это каталог, содержащий файл «ks.cfg».

Для UEFI указываем, хотим ли, чтобы все хосты загружали один и тот же инсталлятор. Если да, копируем или линкуем файл «boot.cfg» в «/tftpboot/boot.cfg». Если нет, создаем поддиректорию «/tftpboot», названную по МАС-адресу целевой машины хоста (01-mac_address_of_target_ESXi_host), а затем копируем или линкуем файл хоста «boot.cfg» в эту директорию, например, «/tftpboot/01-23-45-67-89-0a-bc/boot.cfg».

Если планируем загрузку при помощи нативного UEFI HTTP, подготовительные работы выглядят так же точно, как и для TFTP. Сама же процедура при этом:

Копируем файл «efi/boot/bootxefi» из образа инсталлятора в директорию на HTTP-сервере и переименовываем его на «mboot.efi»;
Настраиваем DHCP-сервер;
Создаем директорию на HTTP-сервере с именем, которое совпадает с версией ESXi, которую он содержит. Например, «http://www.example.com/esxi/ESXi-8.x.x-XXXXXX»;
Копируем содержимое образа инсталлятора в новосозданную директорию;
Редактируем файл «boot.cfg». Добавляем строку с URL новосозданной директории:

prefix=http://www.example.com/esxi/ESXi-8.x.x-XXXXXX

Для скриптованой инсталляции в файле «boot.cfg» добавляем параметр «kernelopt» к строке после команды ядра, чтобы указать локацию инсталляционного скрипта. Например,

kernelopt=ks=http://www.example.com/esxi_ksFiles/ks.cfg

Опционально, можно пользоваться конфигурационными параметрами ВМ «networkBootProtocol» и «networkBootUri», чтобы указать, откуда ВМ может загружаться. Первый параметр указывает на протокол загрузки, например, «IPv4» или «IPv6». Второй указывает HTTP URL для загрузчика ESXi («bootxefi»). Например, «networkBootUri = http://xxx.xxx.xx.x/ esxi80uc1/efi/boot/bootx64.efi».
Указываем, хоти ли, чтобы все хосты загружались с одного и того же инсталлятора. Если да, добавляем файл «boot.cfg» в ту же директорию, где находится «mboot.efi». Например, к «http://www.example.com/esxi/boot.cfg». Если нет, создаем поддиректорию директории, которая содержит файл «mboot.efi». Называться она должна по МАС-адресу машины целевого хоста («01-mac_address_of_target_ESXi_host»), и добавляем собственный файл «boot.cfg» в директорию, например, «http://www.example.com/esxi/01-23-45-67-89-0a-bc/boot.cfg».

Примеры конфигурирования DHCP для разных сценариев загрузки по сети мы приводили в статье «Обновляем ESXi до версии 7.0U2» – можете смело ими пользоваться, с тех времен ничего не поменялось в этом плане.

Подготовка к инсталляции ESXi через vSphere Auto Deploy

vSphere Auto Deploy позволяет готовить сотни физических хостов с софтом ESXi, указав образ, который должен развернуться. В этом случае хосты загружаются по сети с центрального сервера Auto Deploy (состояние не хранится на самом хосте — сервер Auto Deploy управляет информацией о состоянии для каждого хоста), но опционально они могут настраиваться по профилю хоста, о создании которого мы говорили выше, а также разворачиваться за назначенным пакетом скрипта для каждого хоста. После подгрузки и настройки такие хосты управляются vCenter Server аналогично другим ESXi-хостам.

Важно! Auto Deploy требует безопасного разделения production-сети и управляющей, или сети развертывания.

Информация для ESXi-хостов, что готовятся, которую хранит vSphere Auto Deploy, — это местонахождение профилей образов, профилей хостов или кластеров, что управляются одним образом, или конфигурации на уровне кластера, и начально она указана в правилах, которые сопоставляют машины профилям образов и профилям хостов. Архитектура vSphere Auto Deploy:

Правила и наборы правил определяют поведение сервера Auto Deploy. Механизм правил проверяет шаблоны хостов, чтобы решить, с какими объектами (профиль образа, профиль хоста, локация vCenter Server, скриптованый объект) должен предоставляться хост. Для хостов, которые еще не добавлены в систему vCenter Server, сервер vSphere Auto Deploy проверяет механизм правил к обслуживанию профилей образов, профилей хостов и информации о локации. Для хостов, что управляются системой vCenter Server, эти объекты сохраняются на vCenter Server. Если в правила вносятся изменения, при помощи vSphere Client или cmdlet vSphere Auto Deploy в сессии PowerCLI можно протестировать и исправить соответствие правил. При этом назначение профиля образа хоста и профиль хоста обновятся. В правилах можно определять следующие параметры:

Параметр	Описание
Name	Имя правила, обозначается с параметром «-Name»
Item	Один или более объектов с параметром «—Item», которые являются профилем образа, профилем хоста, локацией инвентаря vCenter Server (дата-центр, папка, кластер) для целевого хоста, или пользовательским скриптом. Множество объектов отделяются запятыми
Template	Указывает на хост или группу хостов, для которых действуют правила: vendor (имя вендора машины) model (название модели машины) serial (серийный номер машины) hostname (имя хоста) domain (имя домена) ipv4 (IPv4-адрес машины) ipv6 (IPv6-адрес машины. Если у нас PXE-загрузка с BIOS – только IPv4. Если с UEFI – можно либо то, либо другое) mac (загрузка MAC-адреса NIC) asset (тег объекта машины) oemstring (специфические строки OEM в SMBIOS)

Замечание. Если в шаблоне указать «-AllHosts», объект(ы) будут применяться ко всем хостам.

В отношении наборов правил существуют два понятия: активные и рабочие. Активные наборы проверяются сервером vSphere Auto Deploy на предмет совпадения, когда впервые запущенный хост контактирует с сервером vSphere Auto Deploy путем запроса на профиль образа. Если правилами сопоставлено более одного объекта общего типа, сервер vSphere Auto Deploy применяет первый объект в наборе правил. Рабочие же наборы правил позволяют протестировать изменения к правилам до того, как они станут активными. Чтобы создать такой набор правил, нужно добавить правило с параметром «NoActivate».

Порядок действий с правилами и наборами правил:

Делаем изменения в рабочий набор правил;
Тестируем его насчет хоста, чтобы убедиться, что все работает корректно;
Усовершенствуем и повторно тестируем правила в рабочем наборе правил;
Активируем правила в рабочем наборе.

Подробно операции с правилами рассмотрим немного ниже.

Инсталляция и настройка vSphere Auto Deploy

Перед инсталляцией vSphere Auto Deploy необходимо сделать определенную подготовку:

Включить и запустить сервис vSphere Auto Deploy на системе vCenter Server;
Подготовить хранилище таким образом, чтобы оно могло обнаружить LUN (иметь список целевых IP-адресов и информацию о целевом томе для NFS или iSCSI). Хранилище должно быть не меньшим 2Гб;
Записать информацию о хосте (список целевых IP-адресов и информацию о целевом томе для NFS или iSCSI, дефолтный маршрут, маску сети, IP-адреса первичного и вторичного DNS-сервера, IP-адреса и маску сети для определенной управляющей сети VMkernel, IP-адреса и маску сети для других сетей VMkernel – хранилища, vSphere FT или VMware vMotion)

Важно! vSphere Auto Deploy по умолчанию не перезаписывает существующие партиции.

Проинсталлировать PowerCLI (если будем работать не через клиент vSphere), что включает cmdlet vSphere Auto Deploy и vSphere ESXi Image Builder;
Записать расположение хранилища ПО ESXi (URL с веб-сайта VMware), либо загрузить ZIP-файл для работы с локальным хранилищем. Сам образ ESXi загружать не нужно!
Подготовить TFTP, DHCP и DNS серверы (последний с добавленными записями и в прямую (A Record), и в обратную (PTR Record) зоны для каждого целевого хоста), и убедиться, что ко всем серверам есть сетевое подключение. Заменить имя файла «gpxelinux.0» на «snponlyefi.vmw-hardwired» для UEFI, или на «undionly.kpxe.vmw-hardwired» для BIOS на DHCP;

Важно! Убедитесь, что кроме нужных нам, других серверов DHCP, DNS или TFTP в их подсети не существует.

Подготовить данные по привилегиям администратора для ключевых серверов среды;
Установить удаленный Syslog-сервер. Настроить первый загрузочный хост на его использование и применить профиль этого хоста для всех других целевых хостов. Опционально можно проинсталлировать vSphere Syslog Collector;
Проинсталлировать ESXi Dump Collector, настраивать первый хост таким образом, чтобы все дампы ядра направлялись на него, и применять профиль хоста ко всем другим хостам.

Сама же инсталляция vSphere Auto Deploy выглядит так:

Проходим в Home > Auto Deploy;
На странице Auto Deploy выбираем наш vCenter Server из выпадающего меню вверху;
Кликаем на Enable Auto Deploy and Image Builder, чтобы активировать сервис. Если сервис Image Builder уже является активным, выбираем вкладку Configure и нажимаем Enable Auto Deploy Service – появится страница Software Depot;
Настраиваем TFTP-сервер: кликаем на вкладку Configure, а потом – на Download TFTP Boot Zip, чтобы загрузить конфигурационный файл и распаковать его в директорию, где хранит файлы TFTP-сервер, далее, если хотим использовать прокси-сервер, на панели Auto Deploy Runtime Summary нажимаем на Add и вводим URL прокси-сервера в текстовое поле. Заметьте, что использование обратных прокси-серверов может разгрузить запросы, которые делает сервер vSphere Auto Deploy;
Настраиваем DHCP-сервер, чтобы он указывал на TFTP-сервер: указываем IP-адрес TFTP-сервера в опции 66 (часто называют «следующий сервер») DHCP, и указываем имя файла загрузчика («snponlyefi.vmw-hardwired» для UEFI или «undionly.kpxe.vmw-hardwired» для BIOS) в опции 67 DHCP (часто известный как «bootfilename»);
Настраиваем каждый хост, который хотим развернуть с vSphere Auto Deploy, на сетевую загрузку или PXE-загрузку, пользуясь инструкциями производителя;
Опционально, можно настроить нашу среду на использование режима отпечатка (Thumbprint mode), и тогда можно воспользоваться собственным Certificate Authority (CA), заместив OpenSSL сертификат «rbd-ca.crt» и OpenSSL приватный ключ «rbd-ca.key» собственными. Файлы можно найти в «/etc/vmware-rbd/ssl/». По дефолту, vCenter Server использует VMware Certificate Authority (VMCA).

Далее уже можно изменять дефолтную конфигурацию Auto Deploy Service, конфигурационные свойства, по умолчанию, Image Builder Service (рассказывали выше), определяться с правилами, которые будут назначаться профилю образа и, опционально, профилю хоста, с его локацией или пакетом скрипта для него. Также, по желанию, можно настраивать первый хост, который планируем представлять в качестве референсного, далее профиль хоста и т. д.

Использование cmdlet vSphere Auto Deploy

vSphere Auto Deploy использует cmdlet так же точно, как и другие cmdlet PowerShell. Опытные пользователи оболочки могут убедиться во всех преимуществах этого метода работы с vSphere Auto Deploy, однако, следует заметить, что в кругах виртуализаторов это считается фигурой высшего пилотирования. Но несмотря на уровень владения, не лишним будет напомнить перед тем, как перейдем к практике настройки и использования vSphere Auto Deploy с cmdlet, некоторые важные советы и моменты:

Подсказку по любому cmdlet можно получить, запустив:

Get-Help cmdlet_name

Для PowerShell безразличен регистр букв;
Используйте завершение табуляции для имен командлетов и имен параметров;
Форматируйте любую переменную и вывод cmdlet при помощи «Format-List» или «Format-Table», либо других кратких форм «fl» или «ft». Помощь в форматировании можно получить, запустив cmdlet:

Get-Help Format-List

Вообще, cmdlet PowerCLI управляют vSphere Auto Deploy, помогая создавать правила, что ассоциируют хосты с профилями образов, профилями хостов, пользовательскими скриптами и локациями на цели vCenter Server. С ними также можно обновлять хосты путем тестирования соответствия правил и исправлять проблемы несоответствия.

Перед тем, как рассмотреть конкретику операций, напомним, что список подготовительных шагов из «Инсталляции и настройки vSphere Auto Deploy», приведенный выше, является актуальным, конечно же, и здесь. И запускаем сессию PowerCLI, подключившись к системе vCenter Server, с которой зарегистрирован vSphere Auto Deploy.

Написание правила при помощи командлетов PowerCLI для vSphere Auto Deploy

Подготовка правил предваряет их назначение профилям образов и профилям хостов, и, собственно, непосредственному развертыванию хостов ESXi при помощи vSphere Auto Deploy. Для них используются следующие cmdlet:

Get-DeployCommand – возвращает список командлетов vSphere Auto Deploy

New-DeployRule – создает новое правило с указанными объектами и шаблонами

Set-DeployRule – обновляет существующее правило с указанными объектами и шаблонами. Нельзя обновлять правило, являющееся частью набора правил

Get-DeployRule – возвращает правила с указанными именами

Copy-DeployRule – клонирует и обновляет существующее правило

Add-DeployRule – добавляет одно или более правил к рабочему набору правил и, по умолчанию, также к активному набору правил. Если нужно добавить правило только к рабочему набору, используйте параметр «NoActivate»

Remove-DeployRule – удаляет одно или более правил из рабочего набора правил и с активного набора. Чтобы полностью уничтожить правило, запустите эту команду с параметром «—Delete»

Set-DeployRuleset – явно устанавливает список правил в набор рабочих правил

Get-DeployRuleset – возвращает текущий рабочий набор правил или текущий активный набор правил

Switch-ActiveDeployRuleset — активирует набор правил, чтобы любые новые запросы оценивались через него

Get-VMHostMatchingRules – возвращает правила, которые отвечают шаблону. Используется, в большинстве своем, для дебаггинга

Test-DeployRulesetCompliance – проверяет, демонстрируют ли объекты, ассоциированные с указанным хостом, соответствие активному набору правил

Repair-DeployRulesetCompliance – дает вывод Test-DeployRulesetCompliance, этот cmdlet обновляет профиль образа, профиль хоста и расположение для каждого хоста в инвентаре vCenter Server. Этот cmdlet может применяться к профилям образов, профилю хоста или перемещать хосты в наперед указанные папки либо кластеры в системе vCenter Server

Apply-EsxImageProfile – ассоциирует указанный профиль образа с указанным хостом

Get-VMHostImageProfile – возвращает профиль образа, который используется указанным хостом. Этот cmdlet отличается от Get-EsxImageProfile cmdlet в vSphere ESXi Image Builder

Repair-DeployImageCache – используйте этот cmdlet только, если кэш образа vSphere Auto Deploy был случайно удален

Get-VMHostAttributes – возвращает атрибуты для хоста, что используется, когда vSphere Auto Deploy server оценивает правила

Get-DeployMachineIdentity – возвращает значения строки, которое vSphere Auto Deploy использует, чтобы локально связать ESXi-хост в vCenter Server с физической машиной

Set-DeployMachineIdentity – логичным образом связывает объект хоста в БД vCenter Server с физической машиной. Используется для добавления хостов без указанных правил

Get-DeployOption – возвращает глобальные параметры конфигурации vSphere Auto Deploy. Этот cmdlet в данный момент поддерживает параметр vlan-id, который указывает дефолтный VLAN ID для ESXi Management Network хоста, подготовленного vSphere Auto Deploy. vSphere Auto Deploy использует значение, только если хост загружается без профиля хоста

Set-DeployOption – устанавливает значение глобального параметра конфигурации. На данный момент поддерживает параметр vlan-id для установления дефолтного VLAN ID для ESXi Management Network

Add-ProxyServer – добавляет прокси-сервер к БД vSphere Auto Deploy. Команда запускается с параметром «-Address», чтобы указать IPv4 или IPv6 адрес. Адрес может включать номер порта

List-ProxyServer – выводит список прокси-серверов, которые в это время не зарегистрированы с vSphere Auto Deploy

Delete-ProxyServer – удаляет один или более прокси-серверов из списка прокси-серверов, зарегистрированных с vSphere Auto Deploy. Можно запускать команду с параметром «-id» со списком прокси-серверов или с параметром «-Address» путем указания IPv4 или IPv6 адреса прокси-сервера, который хотим удалить

Add-ScriptBundle – добавляет один или более пакетов скриптов к серверу vSphere Auto Deploy

Get-ScriptBundle – возвращает список пакетов скриптов, доступных на сервере vSphere Auto Deploy, и скриптов, что содержатся в них

Remove-ScriptBundle – удаляет пакет скрипта из vSphere Auto Deploy. Работает для vSphere 6.7 и более свежих

Get-CustomCertificate – возвращает пользовательский сертификат хоста, подгруженный в AutoDeploy. Нужно запускать команду с параметром «—HostId [MAC_Address | BIOS_UUID]». Когда мы впервые добавляем пользовательские сертификаты, мы не видим никаких возвращенных этим командлетом сертификатов

List-CustomCertificates – возвращает информацию обо всех пользовательских сертификатах хоста, которые используются Auto Deploy. Список предоставляет данные по имени сертификата, Host ID и Associated Host Name, что отображает имя vCenter Server для сервера AutoDeploy

Add-CustomCertificate – добавляет пользовательский сертификат к VMware Endpoint Certificate Store и ассоциирует его с хостом ESXi. Сертификат становится активным после перезагрузки хоста. Можно воспользоваться Get-CustomCertificate cmdlet для возврата пользовательского ключа сертификата хоста. Можно запускать команду с параметром «—HostId [MAC_Address | BIOS_UUID]», чтобы ассоциировать сертификат с хостом, указав «—Key [file:///path/to/key.key]» и «—Cert [file:///path/to/cert.crt]». Использование этого cmdlet требует привилегий AutoDeploy.Rule.Create на корневой папке vCenter Server.

Remove-CustomCertificate – удаляет набор пользовательских сертификатов хоста из Auto Deploy. Записи сертификата удаляются из БД и файлы сертификатов удаляются из файлового хранилища. Хосты, которые уже были загружены с пользовательским сертификатом, должны перезагрузиться, чтобы получить новый сертификат. Необходимо предоставить, минимум, один из параметров «-Cert» или «—HostId». Использование этого cmdlet требует привилегий AutoDeploy.Rule.Create на корневой папке vCenter Server.

Написание правила и назначение профиля образа хостам

До того, как приступить к непосредственному предоставлению хоста, нам нужно, обязательно, создать правила и назначить их профилю образа – для каждого хоста, который должен подготовиться при помощи vSphere Auto Deploy.

Замечание. Правила расширения vSphere Auto Deploy вынуждают VIB уровня CommunitySupported содержать лишь файлы из неких предварительно определенных мест, таких как путь плагина ESXCLI, путь плагина jumpstart. Если к профилю образа добавляется VIB из другой локации, увидим предупреждение. Его можно отменить принудительно. Если вызывается командлет New-DeployRule на профиле образа, который содержит VIB из уровня CommunitySupported, что нарушает правило, можно прописать «$DeployNoSignatureCheck = $true» до того, как добавляется профиль образа. Тогда система будет игнорировать проверку подписи и не прибегнет к проверке правил расширения. Но, нужно помнить, что такие VIB, в любом случае, не поддерживаются продуктивами.

На практике наши действия будут выглядеть так:

В сессии PowerCLI, чтобы подключиться к системе vCenter Server, с которой зарегистрирован наш vSphere Auto Deploy, запускаем:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet может вернуть предупреждение сервера сертификатов;

Определяемся с местом публичного хранилища софта, или определяем пользовательский профиль образа с участием vSphere ESXi Image Builder (см. выше);
Если у нас профиль образа содержится в удаленном хранилище, вводим:

Add-EsxSoftwareDepot depot_url

Если это ZIP-файл, загружаем его, записываем его локальный путь и вводим:

Add-EsxSoftwareDepot C:\file_path\my_offline_depot.zip

В хранилище находим профиль образа, который хотим использовать, запустив cmdlet «EsxImageProfile». По умолчанию, ESXi-хранилище включает один базовый профиль образа, который содержит VMware tools и имеет строку «standard» в своем имени, и один базовый профиль образа, который не содержит VMware tools;
Определяем правило, в котором хосты с некоторыми атрибутами, например, с диапазоном IP-адресов, назначаются профилю образа:

New-DeployRule -Name «testrule» -Item «My Profile25» -Pattern «vendor=Acme,Zven», «ipv4=192.XXX.1.10-192.XXX.1.20»

Двойные кавычки требуются, если имя содержит пробелы, необязательные в другом случае. Указываем «—AllHosts» вместо шаблона, чтобы применить объект ко всем хостам. Cmdlet создаст правило, названное «testrule». Оно будет назначено профилям образа, названным My Profile25, всем хостам с вендором Acme или Zven, что также обладают IP-адресами из определенного диапазона – как прописано в команде;

Добавляем правило в набор правил:

Add-DeployRule testrule

По умолчанию правило добавлено и к рабочему набору правил, и к активному. Если применить параметр «NoActivate», рабочий набор не станет активным.

Написание правила и назначение профиля хоста хостам

vSphere Auto Deploy может назначать профиль хоста одному и большему количеству хостов. Профиль хоста должен включать информацию о конфигурации хранилища, сетевой конфигурации, или другие характеристики хоста. Когда хост добавляется в кластер, применяется профиль хоста кластера. Однако, во многих случаях удобнее назначить хост кластеру, чем указывать напрямую профиль хоста. Попробуем написать правило и назначить профиль хоста хостам:

В сессии PowerCLI запускаем командлет для подключения к системе vCenter Server, с которой зарегистрирован vSphere Auto Deploy:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet может вернуть предупреждение о сертификате сервера;

Через клиент vSphere устанавливаем хост с настройками, которые хотим, чтобы применялись к созданию профиля хоста с этого хоста;
Находим имя профилю хоста, запустив cmdlet «Get-VMhostProfile», передавая в хосте ESXi, на котором создается профиль хоста;
Определяем правило, в котором профили хоста назначаются хостам с некоторыми атрибутами, например, диапазоном IP-адресов:

New-DeployRule -Name «testrule2» -Item my_host_profile -Pattern «vendor=Acme,Zven», «ipv4=192.XXX.1.10-192.XXX.1.20»

Указанный объект назначено всем хостам с указанными атрибутами. Этот пример создает правило с именем «testrule2», которое назначает указанный профиль хоста «my_host_profile» всем хостам с IP-адресами из диапазона и с производителем Acme или Zven;

Добавляем правило к набору правил:

Add-DeployRule testrule2

По умолчанию, рабочий набор правил становится активным, и любые изменения в наборе правил становятся активными, когда мы добавляем правило. При использовании параметра «NoActivate» рабочий набор не станет активным.

Написание правила и назначение хоста папке или кластеру

vSphere Auto Deploy может назначать хост папке или кластеру. Когда хост загружается, vSphere Auto Deploy добавляет его к указанному местоположению на vCenter Server. Хосты, назначенные кластеру, наследуют профиль хоста кластера. Перед тем, как приступить непосредственно к написанию правила и назначению хоста папке или кластеру, следует убедиться, что выбранная папка содержится в дата-центре или в кластере. Назначить хост независимой папке верхнего уровня невозможно. Далее:

В сеансе PowerCLI запускаем для подключения к системе vCenter Server, с которой зарегистрирован vSphere Auto Deploy:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet может вернуть предупреждение сертификата сервера;

Определяем правило, по которому хосты с определенными атрибутами, например, с диапазоном IP-адресов, назначены папке или кластеру:

New-DeployRule -Name testrule3 -Item «my folder» -Pattern «vendor=Acme,Zven», «ipv4=192.XXX.1.10-192.XXX.1.20»

Пример передает в папке по имени. Вместо этого можно передавать в папке, кластере или дата-центре объект, который получено командлетами «Get-Folder», «Get-Cluster» или «Get-Datacenter»;

Добавляем правило к набору правил:

Add-DeployRule testrule3

По умолчанию, рабочий набор правил становится активным, и любые изменения в наборе правил становятся активными, когда добавляем правило. Если применить параметр «NoActivate», рабочий набор правил не станет активным.

Тестирование и восстановление соответствия правила после его модификации

Когда мы добавляем правило к набору правил vSphere Auto Deploy, либо изменяем одно или больше из них, хосты автоматически не обновляются. vSphere Auto Deploy применяет новые правила только, когда мы тестируем из соответствие и выполняем исправление. Рассмотрим, как это делается:

В сессии PowerCLI запускаем для подключения к системе vCenter Server, с которой зарегистрирован наш vSphere Auto Deploy:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet может вернуть предупреждение сертификата сервера;

Проверяем, какие из правил vSphere Auto Deploy сейчас доступны:

Get-DeployRule

Система вернет правила и ассоциированные с ними объекты и шаблоны;

Изменяем одно или более правил. Например, меняем профиль образа и имя правила:

Copy-DeployRule -DeployRule testrule -ReplaceItem MyNewProfile

Если правило уже добавлено к активному набору правил, редактировать его нельзя. Вместо этого, можно его скопировать и заместить объект или шаблон в нем так, как нужно;

Проверяем, имеем ли доступ к хосту, на котором хотим протестировать соответствие набору правил:

Get-VMHost -Name MyEsxi42

Запускаем cmdlet, который тестирует соответствие набору правил для хоста, и привязываем значение, что вернулось, к переменной для дальнейшего использования:

$tr = Test-DeployRuleSetCompliance MyEsxi42

Исследуем разницу между содержимым набора правил и конфигурацией хоста:

$tr.itemlist

Если хост отвечает активному набору правил, система вернет таблицу текущих и ожидаемых объектов:

CurrentItem ExpectedItem

———— ————

My Profile 25 MyNewProfile

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

Repair-DeployRuleSetCompliance $tr

Пакетное лицензирование через vSphere Auto Deploy в PowerCLI

Лицензионные ключи можно назначать хосту при добавлении его к системе vCenter Server, или в процессе управления хостом этой системой при помощи vSphere Client. Когда мы говорим об одиночных случаях, это оправданная схема, но, если у нас множество хостов в системе, адекватнее было бы рассматривать использование пакетного лицензирование. Оно работает, по правде говоря, для любых хостов ESXi, однако чаще всего встречается в случае предоставления хостов при помощи vSphere Auto Deploy.

Как подготовиться к работе с vSphere Auto Deploy и разворачивать с ней когорту хостов упоминалось выше в соответствующих разделах.

В целом, определенный набор лицензионных ключей может быть добавлен к набору хостов. Сами ключи добавляются в БД vCenter Server, и каждый раз, когда хост добавляется к системе или переподключается к ней, ему назначается лицензионный ключ. Назначенный через PowerCLI лицензионный ключ считается дефолтным, и когда нелицензированный до сих пор хост добавляется или переподключается, ему назначается именно дефолтный ключ. Если же хост лицензирован, он сохраняет собственный ключ.

Перед тем, как перейти непосредственно к процедуре пакетного лицензирования, нужно еще кое-что сделать:

В сессии PowerCLI подключаемся к системе vCenter Server и привязываем ассоциируемый менеджер лицензирования к переменной:

Connect-VIServer -Server 192.XXX.X.XX -User username -Password password

$licenseDataManager = Get-LicenseDataManager

Запускаем cmdlet, что получает дата-центр, в котором находятся хосты, к которым хотим применить функцию пакетного лицензирования:

$hostContainer = Get-Datacenter -Name Datacenter-X

Также можно запускать cmdlet, что получает кластер (для лицензирования всех хостов в кластере), или папку с аналогичной целью;

Создаем объект «LicenseData» и «LicenseKeyEntry», с ассоциированным ID типа и лицензионным ключом:

$licenseData = New-Object VMware.VimAutomation.License.Types.LicenseData

$licenseKeyEntry = New-Object Vmware.VimAutomation.License.Types.LicenseKeyEntry

$licenseKeyEntry.TypeId = «vmware-vsphere»

$licenseKeyEntry.LicenseKey = «XXXXX-XXXXX-XXXXX-XXXXX-XXXXX«

Ассоциируем атрибут «LicenseKeys» объекта «LicenseData» с объектом «LicenseKeyEntry»:

$licenseData.LicenseKeys += $licenseKeyEntry

Обновляем дату лицензии для дата-центра с объектом «LicenseData» и проверяем, ассоциирована ли лицензия с контейнером хоста:

$licenseDataManager.UpdateAssociatedLicenseData($hostContainer.Uid, $licenseData)

$licenseDataManager.QueryAssociatedLicenseData($hostContainer.Uid)

Готовим один или более хостов с vSphere Auto Deploy и назначаем им дата-центр или кластер, которым назначили дату лицензии.

С этого момента все хосты, ассоциированы с дата-центром, будут лицензироваться автоматически.

Использование vSphere Client в подготовительных к работе с vSphere Auto Deploy процессах

Пользоваться клиентом vSphere во всех предваряющих непосредственное развертывание хостов акциях при помощи vSphere Auto Deploy значительно проще, чем то, что мы только что делали с командлетами. И именно такой путь рекомендован тем, кто впервые сталкивается с такой необходимостью.

Создание правила развертывания и операции с ним с vSphere Client

В клиенте vSphere:

Проходим в Home > Auto Deploy;
На вкладке Deploy Rules кликаем New Deploy Rule – появится помощник New Deploy Rule;
На странице Name and hosts вводим имя нового правила;
Выбираем, хоти ли применить правило ко всем хостам в инвентаре, или только к тем, которые отвечают определенному шаблону (можно выбирать более одного шаблона);
На странице Configuration, опционально, включаем объекты в правило (каждый добавит новую страницу помощнику): Host Location (добавляет хосты, которые отвечают критерию правила к указанной локации), Image Profile (назначает профиль образа хостам, что отвечают критерию правила), Host Profile (назначают профиль хоста хостам, которые отвечают критерию правила), Script Bundle (назначают пакет скрипта хосту, что отвечает критерию правила). Если мы это сделали:

- На странице помощника Select host location выбираем дата-центр, папку или кластер как локацию хоста для хостов, что отвечают правилу;
- На странице Select image profile, воспользовавшись выпадающим меню, выбираем хранилище софта и профиль образа из списка. Если хотим пропустить верификацию уровня принятия профиля образа, ставим галочку в Skip image profile signature check;
- На странице Select host profile выбираем профиль хоста из списка;
- На странице Select script bundle выбираем пакет скрипта из списка;

На странице Ready to complete проверяем итоговую информацию нового правила.

Все новосозданные правила будут выведены списком на вкладке Deploy Rules. Их можно редактировать, клонировать, активировать/деактивировать, изменять порядок.

Если нам нужно создать еще несколько правил, легче всего будет склонировать уже существующее, сконфигурировав его, как нужно:

Проходим в Home > Auto Deploy;
На вкладке Deploy Rules выбираем правило из списка и кликаем Clone – появится помощник Clone Deploy Rule;
На странице Name and hosts вводим имя нового правила;
Выбираем, хотим ли, чтобы правило применялось ко всем хостам в инвентаре, или только к тем, которые отвечают определенному шаблону (можно выбирать более одного шаблона);
На странице Configuration, опционально, включаем объекты в правило (перечень см. выше в процедуре создания нового правила);
Если у нас есть страница Select host location, можем выбирать локацию хостов, которая отвечает правилу. Ставим галочку в Same Host location, если хотим сохранить текущую локацию хоста для склонированого правила. Либо ставим галочку в Browse for Host location, выбираем дата-центр, папку или кластер локации хоста и кликаем Next, если хотим выбрать новую;
Если у нас есть страница Select image profile, можем выбрать профиль образа. Ставим галочку в Same image profile, если не хотим менять профиль образа. Или ставим галочку в Browse for Image Profile, выбираем хранилище софта из выпадающего меню, выбираем профиль образа из списка (опционально, если хотим пропустить верификацию уровня принятия профиля образа, ставим галочку в Skip image profile signature check), если хотим назначить новый профиль образа выбранным хостам;
Если у нас есть страница Select host profile, можем выбрать профиль хоста. Ставим галочку в Same Host profile, если хотим сохранить профиль хоста в склонированном правиле. Либо ставим галочку в Browse for Host Profile и выбираем профиль хоста из списка, после чего кликаем Next, если хотим назначить новый профиль хоста выбранным хостам;
Если у нас есть страница Select script bundle, можем выбрать пакет скрипта из списка;
На странице Ready to complete просматриваем итоговую информацию для нового правила.

Отредактировать существующее правило можно следующим образом:

В Home > Auto Deploy на вкладке Deploy Rules выбираем правило, которое хотим изменить, и нажимаем Edit – появится диалоговое окно Edit Deploy Rule;
Все аналогично п. 3 – 10 процедуры клонирования (см. выше).

По операциям активации/деактивации правил, заметим, что новосозданное правило всегда поначалу будет в неактивном состоянии – чтобы оно начало действовать, его, естественно, необходимо активировать (по приведенной ниже процедуре делается также и деактивация или изменение порядка правил в списке):

Проходим в Home > Auto Deploy;
На вкладке Deploy Rules кликаем на Activate/Deactivate rules – появится помощник Activate and Reorder;
Из списка неактивных правил выбираем те, которые хотим активировать, и нажимаем кнопку Activate. Если какие-то правила нужно деактивировать – кнопку Deactivate;
Если нужно изменить порядок правил в списке активных (важно, с учетом приоритета их применения), выбираем правило, которое хотим переместить выше или ниже в списке и кликаемо на Move up или Move down вверху списка активных правил;
Нажимаем на ОК.

До того, как сделать правило активным, рекомендуется протестировать его, кликнув на Test rules before activation. Далее выбираем хост из списка и нажимаем на Check Compliance, чтобы просмотреть текущий статус хоста и изменения, которые ожидаются после активации правила. Если в результате хост показан как «compliant», восстанавливать его после активации правила нет нужды. В противном случае следует поставить галочку в Remediate all host associations after rule activation, или включить соответствующую кнопку – все хосты будут восстановлены.

Кстати, статус активации/деактивации правил показанный в специальной колонке прямо в списке правил на вкладке Deploy Rules.

Добавление хоста в инвентарь vSphere Auto Deploy с vSphere Client

Если хост не отвечает ни одному правилу vSphere Auto Deploy, его можно вручную добавить в инвентарь vSphere Auto Deploy (в случае, когда не хотим конкретно под него создавать новое правило, или редактировать старое):

Проходим в Home > Auto Deploy;
На вкладке Discovered Hosts выбираем один или более хостов, которые хотим добавить с соответствующей локацией, профилем образа и профилем хоста;
Выбираем Add to Inventory (если нажать Remove, можно убрать хост со вкладки Discovered Hosts) – появится помощник Add to Inventory;
На странице Select host location выбираем дата-центр, папку или кластер в качестве локации хоста;
На странице Select image profile из выпадающего меню выбираем хранилище ПО и выбираем профиль образа из списка;
На странице Select host profile используем Filter, чтобы отыскать профили хоста в списке, или можно поставить галочку в Do not include a host profile, чтобы не добавлять профиль хоста;
На странице Select script bundle выбираем пакет скрипта из списка;
На странице Ready to complete просматриваем выбранные ассоциации хоста.

Работа с пакетами скриптов с vSphere Client

Для дополнительной настройки после развертывания хостов можно добавлять пользовательский скрипт – он запустится сразу после окончания предоставления ESXi-хоста через Auto Deploy. Это помогает, когда необходимо, например, создать пользовательское правило файервола и другие настройки, недоступные с профилями хостов. В общем случае необходимо сделать следующее:

Проходим в Home > Auto Deploy;
Выбираем вкладку Script Bundles и нажимаем на Upload;
Находим пакет скрипта и выбираем Upload – скрипт появится в списке Script Bundles;

Если пакет нужно удалить из списка, кликаем на него и выбираем Remove с подтверждением нашего решения.

Подготовка к развертыванию vCenter Server

Выше, когда мы в общих указаниях в отношении подготовки говорили об этапе загрузки образов нашего гипервизора и vCenter, упоминалось, что образ appliance vCenter Server потребует подмонтирования. Немного поясним для тех, кто с таким еще не сталкивался, что имеется в виду.

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

Важно! ПО подмонтирования ISO, что разрешает не более 8 уровней каталога (например, MagicISO Maker на Windows) не поддерживается. Аналогично, для Linux OS и Mac OS не поддерживается Archive Manager.

Рекомендовано для подмонтирования использовать:

Mac OS: DiskImageMounter,
Ubuntu 14.04: Disk Image Mounter,
SUSE 12: терминал.

Следующим образом:

$ sudo mkdir mount_dir

$ sudo mount -o loop VMware-vCSA-all-version_number-build_number.iso mount_dir

Далее, перед тем, как непосредственно перейти к развертыванию vCenter Server, обязательно нужно добиться синхронизации времени между всеми уже проинсталлированными компонентами vSphere – тому, почему это важно, и как именно это сделать, мы уделили максимум внимания в отдельном подразделе «Начальных настроек», где можно найти все, что вас может заинтересовать в отношении синхронизации времени.

И, наконец, обязательно убеждаемся в том, что ESXi-хост, на котором планируем разворачивать appliance, не в lockdown-режиме или режиме техобслуживания, и не является частью полностью автоматизированного DRS-кластера. Если же мы хотим разворачивать наш appliance на DRS-кластере инвентаря инстанса vCenter Server (не первый vCenter Server в нашей системе), нужно убедиться, что в кластере содержится, минимум, один ESXi-хост, который не локдауне или maintenance-режиме.

Подготовка конфигурационного JSON-файла для CLI-метода развертывания appliance vCenter Server

В рамках подготовки конфигурационного JSON-шаблону можно редактировать пресетные значения, удалять параметры и добавлять их для создания собственного пользовательского видения, как именно должен быть настроен и как развернут наш vCenter Server. Но, заметьте, что для этого метода вы должны хорошо знать синтаксис JSON.

Помощь в работе с шаблоном можно получить в подкаталоге инсталлятора для конкретной ОС, запустив файл «vcsa-deploy install —template-help». А вообще подготовка этого файла выглядит так, пошагово:

В инсталляторе vCenter Server проходим в директорию «vcsa-cli-installer» и открываем подкаталог «templates»;
Копируем шаблон оттуда куда-то на свое рабочее место;
В текстовом редакторе открываем его (рекомендуется именно редактор JSON!);
Заполняем значение конфигурационных параметров, которые требуются, и, опционально, добавляем свои параметры со значениями. Например, если хотим использовать IPv4 DHCP назначение для сети appliance, в подсекции «network» меняем значение параметра «mode» на «dhcp» и удаляем дефолтные настройки для статики:

«network»: {

«ip_family»: «ipv4»,

«mode»: «dhcp»

Важно! Строки значений, з паролями, включительно, должны содержать только ASCII-символы (расширенные не поддерживаются!). Чтобы назначить значение, которое содержит «\» или «”», перед символом должен стоять символ бекслеша («\»). Например,

«password«:»my\»password«

Устанавливает пароль как «my«password», а вот

«image«:»G:\\vcsa\\VMwarevCenter-Server-Appliance-8.0.0.XXXX-YYYYYYY_OVF10.ova«

это путь «G:\vcsa\VMwarevCenter-Server-Appliance-8.0.0.XXXX-YYYYYYY_OVF10.ova».

Опционально, в самом редакторе JSON можно запустить валидацию отредактированного файла;
Сохраняем файл в формате UTF-8 и закрываем его.

Вообще, в инсталляторе vCenter Server вы найдете несколько шаблонов (в упомянутом выше подкаталоге) с минимумом конфигурационных параметров для всех видов развертываний:

embedded_vCSA_on_ESXi.json – для развертывания vCenter Server appliance на ESXi-хосте.

vCSA_with_cluster_on_ESXi.json – с одной нодой vSAN и кластером, который управляется vLCM на ESXi-хосте.

embedded_vCSA_on_VC.json – на инстансе vCenter Server.

embedded_vCSA_replication_on_ESXi.json – как репликационного партнера на другой встроенный vCenter Server на ESXi-хосте.

embedded_vCSA_replication_on_VC.json – как репликационного партнера для другого vCenter Server appliance на инстансе vCenter Server.

Список конфигурационных параметров, что встречаются в этих шаблонах:

Секция	Подсекция	Описание	Параметр	Тип	Описание
new_vcsa (описание appliance, которое развертывается, выбирается только одна из подсекций esxi или vc, и только один вариант по еsxi – или из vSAN и vLCM Managed Cluster, или без них)	еsxi (с vSAN и vLCM Managed Cluster)	При развертывании непосредственно на ESXi-хосте	hostname	string	IP-адрес или FQDN целевого ESXi-хоста
			username	string	Имя пользователя с привеиегиями администратора на целевом ESXi-хосте
			password	string	Его пароль
			deployment_network	string	Имя сети, к которой подключается appliance (доступной с ESXi-хоста). Если только одна сеть для целевого хоста, игнорируется
			datacenter	string	Указанный дата-центр, где создаемся
			cluster	string	Имя vSAN или vLCM управляемого кластера
			compression_only	Boolean	True, чтобы включить компрессию на кластере vSAN. Если true, то параметр deduplication_and_compression должен быть false
			deduplication_and_compression	Boolean	True, чтобы включить компрессию и дедупликацию на кластере vSAN. Если true, то параметр compression_only должен быть false
			cache_disk		Список UUID или канонических имен дисков, которые используются для кэша. Указываются только SSD
			capacity_disk		Список UUID или канонических имен дисков, которые используются для хранилища. Указываются или SSD, или HDD
			enable_vlcm	Boolean	Если true, будет создано управляемый vLCM кластер
			enable_vsan_esa	Boolean	Если true, будет создано vSAN-кластер с включенным vSAN ESA
			single_tier	Array	Список UUID или канонических имен дисков, которые хотим добавить к пулу хранилища vSAN. Используется только, если enable_vsan_esa установлено на true
			vsan_hcl_database_path	string	Локальный путь к БД vSAN HCL. Если имеющаяся база устарела, инсталлятор загрузит и заменит ее более новой. Требуется только тогда, когда enable_vsan_esa установлено на true
			datastore	string	Имя датастора, где будут храниться конфигурационные файлы и виртуальные диски appliance (должен быть доступен с ESXi-хоста)
			port	integer	Обратная прокси HTTPS целевого ESXi-хоста (дефолтный 443). Используется только, если у целевого хоста пользовательский HTTPS-порт обратной прокси
	еsxi (без vSAN и vLCM Managed Cluster)		hostname	string	IP-адрес или FQDN целевого ESXi-хоста
			username	string	Имя пользователя с привилегиями администратора на целевом ESXi-хосте
			password	string	Его пароль
			deployment_network	string	Имя сети, к которой подключается appliance (доступной с ESXi-хоста). Если только одна сеть для целевого хоста, игнорируется
			datastore	string	Имя датастора, где будут храниться конфигурационные файлы и виртуальные диски appliance (должно быть доступно с ESXi-хоста)
			port	integer	Обратная прокси HTTPS целевого ESXi-хоста (дефолтный 443). Используется только, если у целевого хоста пользовательский HTTPS-порт обратной прокси
	vc	При развертывании appliance в инвентаре инстанса vCenter Server	hostname	string	IP-адрес или FQDN целевого инстанса vCenter Server, на котором развертывается appliance
			username	string	Имя администратора vCenter Single Sign-On на целевом инстансе vCenter Server
			password	string	Его пароль
			deployment_network	string	Имя сети, к которой будет подключаться appliance (должна быть доступна с ESXi-хоста или DRS-кластера, на котором разворачивается appliance). Игнорируется, если целевой ESXi-хост или DRS-кластер обладают только одной сетью
			datacenter	array	Дата-центр vCenter Server, который содержит целевой ESXi-хост или DRS-кластер (значение чувствительно к регистру)
			datastore	string	Имя датастора, на котором хотим хранить конфигурационные файлы и виртуальные диски appliance (должно быть доступным с целевого ESXi-хоста или DRS-кластера)
			port	integer	Порт HTTPS обратной прокси целевого инстанса vCenter Server (дефолтный 443). Используется только, если целевой инстанс vCenter Server имеет пользовательский порт HTTPS обратной прокси
			target	array	Целевой ESXi-хост или DRS-кластер, на котором разворачивается appliance (имя, которое отображается в инвентаре vCenter Server). Значение чувствительно к регистру
			vm_folder	string	Опционально. Имя папки ВМ, где разворачивается appliance
	appliance	Описание appliance	thin_disk_mode	Boolean	Установить на true, чтобы развернуть appliance с тонкими виртуальными дисками
			deployment_option	string	Размер appliance (Значение: tiny / tiny-lstorage / tiny-xlstorage small / small-lstorage / small-xlstorage / medium / medium-lstorage / medium-xlstorage / large / large-lstorage / large-xlstorage / xlarge / xlarge-lstorage / xlarge-xlstorage – пояснения по размеру – выше в разделе «Подготовки…»)
			image	string	Опционально. Локальный путь к файлу или URL инсталляционного пакета vCenter Server appliance (по дефолту используется пакет, который включен в ISO-файл в папке «vcsa»)
			name	string	Имя ВМ для appliance
			ovftool_path	string	Опционально. Локальный путь к файлу OVF Tool (по дефолту, инсталлятор использует инстанс OVF Tool, что включено в ISO-файл в папке «vcsa/ovftool»)
	network	Описание конфигурации сети для appliance	ip_family	string	IP-версия сети для appliance (значение ipv4 или ipv6)
			mode	string	IP-назначение для сети appliance (значение static или dhcp)
			ip	string	IP-адрес appliance. Только если параметр mode установлено на static.
			dns_servers	string или array	IP-адрес одного, или нескольких DNS-серверов, отделенных запятыми
			prefix	string	Длина префикса сети. Только если параметр mode установлено на static. Если dhcp, параметр удалить
			gateway	string	IP-адрес дефолтного шлюза. Для IPv6 значение default
			ports	string	Опционально. Номера портов, которые vCenter Server appliance использует для прямых HTTP-подключений.
			system_name	string	Первичный идентификатор сети (IP-адреса или FQDN, желательно FQDN). После развертывания этот параметр изменить будет невозможно
	os	Описание операционной системы для appliance	password	string	Пароль пользователя root для ОС appliance
			ntp_servers	string или array	Опционально. Имена хостов или IP-адреса одного или нескольких NTP-серверов для синхронизации времени, разделенные запятыми
			ssh_enable	Boolean	Значение true, чтобы включить возможность администратору заходить в appliance по SSH. Если делаем НА – обязательно
			time_tools_sync	Boolean	Опционально. Значение на true, чтобы развернуть appliance с синхронизацией времени VMware Tools. Игнорировать, если задавали NTP-серверы (параметр ntp.servers)
	sso	Описание настроек vCenter Single SignOn для appliance	password	string	Пароль администратора vCenter Single Sign-On
			domain_name	string	Доменное имя vCenter Single Sign-On
			replication_partner_hostname	string	Системное имя партнера vCenter Server. Требуется, только если разворачивается репликационный партнер в уже существующем домене vCenter Single Sign-On
			sso_port	integer	HTTPS-порт обратной прокси партнера vCenter Server (дефолтный 443). Используется только, если партнер имеет пользовательский порт HTTPS обратной прокси
	ovftool_ arguments	Опциональная подсекция для добавления произвольных аргументов и их значений к OVF Tool command, которые генерируются инсталлятором. Не валидируется инсталлятором – если OVF Tool не сможет распознать, что вы задали, развертывание даст сбой
сeip	settings	Описание присоединения к VMware Customer Experience Improvement Program (CEIP)	ceip_enabled	Boolean	True, если хотим присоединиться к CEIP на этом appliance. Если значение «true», команда CLI-развертывания должна запускаться с аргументом «—acknowledge-ceip»

Список аргументов:

—accept-eula – принимает лицензионное соглашение конечного пользователя. Требуется для выполнения команди развертывания.

—acknowledge-ceip – подтверждает соглашение на присоединение к VMware Customer Experience Improvement Program (CEIP). Требуется, если параметр ceip.enabled установлено на true в шаблоне.

-v, —verbose – добавляет информацию про дебаг до вывода консоли.

-t, —terse – скрывает вывод консоли. Показывает лишь оповещение предупреждения и об ошибках.

—log-dir LOG_DIR – устанавливает локацию лога и других файлов вывода.

—skip-ovftool-verification – выполняет базовую верификацию конфигурационных параметров в JSON-файле и разворачивает appliance. Не выполняет верификацию параметров OVF Tool.

—no-esx-ssl-verify — пропускает SSL-верификацию подключений ESXi.

Важно! Избегайте использования этой опции, так как это может привести к проблемам в процессе развертывания или после него, так как идентификация целевого ESXi-хоста будет невалидированной.

—no-ssl-certificate-verification – пропускает верификацию сертификата безопасности для всех серверных подключений.

—operation-id OPERATION_ID – предоставляет операционный ID для отслеживания инсталляционных активностей.

—pause-on-warnings – ставит на паузу и ждет соглашения с предупреждениями.

—verify-template-only – выполняет базовую верификацию конфигурационных параметров шаблона в JSON-файле. Не разворачивает appliance.

—precheck-only – выполняет лишь базовую верификацию шаблона и параметра OVF Tool. Не разворачивает appliance.

—sso-ssl-thumbprint SSL-SHA1-THUMBPRINT – проверяет сертификат серевра на соответствие предоставленному отпечатку SHA1.

-h, —help – показывает подсказку помощи для инсталляционной команды vcsa-deploy.

—template-help – показывает подсказку помощи по использованию конфигурационных параметров в файле развертывания JSON.

После исполнения параметров команд можно получить код выходу из команды:

0 – команда отработала успешно

1 – ошибка в процессе работы

2 – ошибка проверки

3 – ошибка шаблону

Процедура инсталляции vSphere 8.0

В целом, в процессе инсталляции нам важно придерживаться следующего порядка действий:

Проинсталлировать и настроить ESXi-хосты;
Развернуть и настроить vCenter;
Сделать начальную настройку, которая выходит за пределы инсталляционных работ.

Соответственно, сначала проделаем все, что требует инсталляция ESXi-хостов, а потом то, что касается нашего vCenter:

Инсталляция ESXi

Установка ESXi может быть:

интерактивной (рекомендована для маленьких развертываний с пятью или менее хостами),
скриптованной,
при помощи vSphere Auto Deploy.

Важно! Способ vSphere Auto Deploy имеет в виду, что vSphere Auto Deploy инсталлируется вместе с vCenter Server. Следовательно, чтобы предоставить ESXi-хости, вы должны установить vCenter Server.

Все рассмотрим по очереди в свое время.

Интерактивный способ инсталляции ESXi

Самый простой и доступный способ. Всего лишь нужно загрузить ESXi-инсталлятор и следовать указаниям его помощника (установка пойдет на локальный диск хоста). Инсталлятор отформатирует и разобьет на необходимые партиции целевой диск и установит загрузочный образ ESXi (это если на диске ранее не было ESXi. Если же был, инсталлятор предложит провести апгрейд).

Замечание. Если ваша система поддерживает DPU, начиная с vSphere 8.0, вы можете одновременно установить, переставить или проапгрейдить ESXi-хост на DPU. Для этого нужно будет выбрать DPU, что подходит, нажать Enter – появится окно DPU Details, которое продемонстрирует свойства DPU-устройства.

Порядок действий:

Запускается приветственная страница:

Жмем на ней Enter, чтобы продолжить, и соглашаемся с EULA;

Дальше будет окошко, в котором нужно выбрать диск:

Если хотим просмотреть по нему информацию, жмем F1. Соглашаемся с выбором Enter. (Если на диске были данные, появится окно Confirm Disk Selection);

Выбираем тип клавиатуры для хоста (с консоли после инсталляции это можно будет изменить);
Вводим по запросу пароль root с подтверждением (пароль также можно будет заменить потом):
В дальнейшем жмем на F11, что запустит процесс инсталляции, по окончанию которого можно будет вынимать инсталляционное устройство;
Кликаем Enter, чтобы перезагрузить хост.

Описанный интерактивный способ работает с загрузчиком образа как с CD/DVD или USB-флешки, так и с сетевой загрузкой. На самом деле, в последнем случае со стороны пользователя происходит все точно так же, как описано выше, независимо от способу загрузки носителя. Теория по сетевой загрузке подробно описана ниже в разделе «Скриптованная инсталляция ESXi с сетевой загрузкой инсталлятора».

Первичная настройка ESXi-хоста при интерактивной инсталляции

При инсталляции ESXi хоста дается назначенный DHCP IP-адрес. И далее (обязательно до того, как хост начнет свою работу) нужно воспользовавшись DCUI (текстовым пользовательским интерфейсом с клавиатурным вводом) ESXi-хоста настроить некоторые параметры, например, такие как сетевые настройки хоста:

Таким образом задаются:

сетевой адаптер,
VLAN ID,
конфигурация IPv4/IPv6 (IP-адрес, маска подсети, дефолтный шлюз),
имя хоста,
DNS-серверы и суффиксы:

После этого выполняется перезагрузка управляющей сети (без перезагрузки системы), она тестируется (при помощи пингования и запросов DNS). Также будет возможность восстановить начальную конфигурацию сети (чтобы можно было все перезадать, если сделали ошибку).

Также этот интерфейс поможет администратору настроить параметры доступа:

Изменить пароль root;
Активировать/деактивировать режим lockdown (чтобы ограничить управление хостом vCenter):

Важно! Активация/деактивация режима lockdown возможна только для хостов, которые управляются инстансом vCenter.

Кроме того, в DCUI можно изменить раскладку клавиатуры, просмотреть информацию о поддержке (серийный номер лицензии хоста) и смотреть системные логи. По дефолту раскладка клавиатуры U.S. English. Также можно воспользоваться параметрами устранения неисправностей (по умолчанию выключено). Чтобы включить эту службу, нужно в Troubleshooting options выбрать Enable ESXi Shell для локального траблшутинга или Enable SSH – для удаленного исправления ошибок через SSH-клиент (например, PuTTY):

Далее обязательно нужно будет заняться синхронизацией времени для ESXi-хоста – о том, как это сделать, подробно поговорим ниже, в разделе «Начальная настройка» — «Синхронизация времени в сети vSphere».

Инсталляция ESXi при помощи скрипта

Инсталляционный скрипт – это текстовый файл (например, «ks.cfg»), который содержит поддерживаемые команды, что представляют собой инсталляционные опции ESXi в соответствующей секции. Эта секция обязательна и должна быть размещена первой в скрипте. Запуск скрипта эффективен в случае развертывания многих хостов без непосредственной необходимости администратору следить за процессом и направлять его, делая соответствующие вводы и выборы.

Инсталляционный скрипт должен храниться в локации, к которой у хоста есть доступ по HTTP, HTTPS, FTP, NFS, CDROM, или USB. Можно пользоваться PXE-загрузкой или загружать его с CD/DVD или USB-устройства:

Таким образом ESXi можно проинсталлировать на многих машинах, используя один скрипт для них всех, либо отдельные скрипты для каждой. Скрипт инсталляции можно запустить, введя параметры загрузки (нажав Shift+O в загрузчике) в командную строку загрузки инсталлятора ESXi. Во время загрузки может понадобиться указать параметры доступа к файлу «kickstart». Для PXE-загрузки параметры передаются через строку kernelopts файла «boot.cfg». Чтобы указать локацию инсталляционного скрипта установите параметр ks=filepath, где filepath указывает на расположение файла «kickstart». Без этого скриптованная инсталляция не стартует – запустится обычный текстовый инсталлятор.

На практике это выглядит следующим образом:

Запускаем хост;
Когда появится вот такое окно:

жмем Shift+O, чтобы отредактировать опции загрузки;

В командной строке runweasel вводим:

ks=location of installation script plus boot command-line options

Поддерживаемые параметры загрузки:

Опция загрузки	Описание
BOOTIF=hwtype-MAC address	То же самое, что и опция «netdevice» (см. ниже), за исключением формата PXELINUX (объяснение на syslinux.org в SYSLINUX, опция «IPAPPEND»)
gateway=ip address	Устанавливает сетевой шлюз в качестве дефолтного для загрузки инсталляционного скрипта с устройств
ip=ip address	Устанавливает статический IP-адрес для загрузки инсталляционного скрипта с устройств. Для этой опции формат PXELINUX поддерживается также
ks=cdrom:/path	Путь к скрипту с инсталляцией на CD в CD-ROM (подмонтируется и проверится в процессе поиска файла)
ks=file://path	Путь к скрипту
ks=protocol://serverpath	Путь к скрипту в сети на данном URL. «protocol» — это «http», «https», «ftp», «nfs»
ks=usb	Путь к скрипту на USB (будет искать скрипт с именем «ks.cfg», должен быть расположен обязательно в корневой директории диска). Если подсоединено много USB, поиск будет осуществляться до тех пор, пока не будет найден первый файл с таким именем. Поддерживаются только файловые системы FAT16/FAT32
ks=usb:/path	Путь к скрипту на USB в указанном местоположении
ksdevice=device	Попробует использовать сетевой адаптер «device» при поиске скрипта на устройстве. Указывается как МАС-адрес, или имя vmnicNN. Если ничего не указать, инсталлятор отыщет первый подсоединенный сетевой адаптер и выйдет в сеть через него
nameserver=ip address	Указывает доменное имя сервера, который используется для загрузки инсталляционного скрипта
netdevice=device	Попробует использовать сетевой адаптер «device» при поиске скрипта на устройстве. Указывается как МАС-адрес, или имя vmnicNN. Если ничего не указать, инсталлятор отыщет первый подсоединенный сетевой адаптер и выйдет в сеть через него
netmask=subnet mask	Указывает маску подсети для сетевого интерфейса, который будет загружать инсталлятор
vlanid=vlanid	Настраивает сетевую карту для представления в качестве указанного VLAN
systemMediaSize=small	Ограничивает размер партиций системного хранилища на загрузочном медиа. Возможные значения: · min (32 Гб, для единственного диска или встроенных серверов), · small (64 Гб, для серверов с, минимум, 512 Гб RAM), · default (128 Гб) · max (употребляет все доступное пространство, для мульти-терабайтных серверов)

Можно пользоваться дефолтным инсталляционным скриптом «ks.cfg» — он обязательно есть в самом инсталляторе ESXi, размещен на начальном RAM-диске в «/etc/vmware/weasel/ ks.cfg». Именно его расположение можно указать в загрузочной опции, о чем мы упоминали выше. Для этого скрипта дефолтным паролем для root является myp@ssw0rd. Смодифицировать его по собственному желанию, но не во время первой же инсталляции и не на инсталляционном медиа – когда она завершится, можно будет при помощи vSphere Client: зайти на vCenter Server, что управляет нашим хостом, и уже тогда редактировать. Как именно, об этом мы писали выше, в разделе «Подготовка к скриптованной инсталляции ESXi-хостов»

Важно! Если ваша система поддерживает DPU в vSphere 8.0, скрипт «ks.cfg» можно использовать для инсталляции ESXi на DPU.

Дефолтный скрипт «ks.cfg» содержит следующие команды:

# Sample scripted installation file

# Accept the VMware End User License Agreement

vmaccepteula

# Set the root password for the DCUI and Tech Support Mode

rootpw myp@ssw0rd

# Install on the first local disk available on machine

install —firstdisk —overwritevmfs

In case you system has DPUs, you also specify a PCI slot:

install —firstdisk —overwritevmfs —dpuPciSlots=

# Set the network to DHCP on the first network adapter

network —bootproto=dhcp —device=vmnic0

# A sample post-install script

%post —interpreter=python —ignorefailure=true

import time

stampFile = open(‘/finished.stamp’, mode=’w’)

stampFile.write( time.asctime() )

Несколько слов нужно сказать и о файле конфигурации загрузчика «boot.cfg». Он указывает ядро, параметры ядра и загрузочные модули, которые использует загрузчик «mboot.c32» или «mboot.efi». Файл «boot.cfg» предоставляется инсталлятором ESXi. Можно отредактировать строку kernelopt в нем, чтобы указать локацию инсталляционного скрипта или передать другие параметры загрузки. Этот файл использует такой синтаксис:

# boot.cfg — mboot configuration file

# Any line preceded with ‘#’ is a comment.

title=STRING

prefix=DIRPATH

kernel=FILEPATH

kernelopt=STRING

modules=FILEPATH1 — FILEPATH2… — FILEPATHn

# Any other line must remain unchanged.

Эти команды конфигурируют загрузчик, а именно:

Команда	Описание
title=STRING	Устанавливает название загрузчика как STRING
prefix=STRING	Опциональная. Добавляет DIRPATH/ впереди каждого FILEPATH в командах kernel= и modules=, которые, обычно, не стартуют с / или http://
kernel=FILEPATH	Устанавливает путь ядра как FILEPATH
kernelopt=STRING	Добавляет STRING к параметрам загрузки ядра
modules=FILEPATH1 — FILEPATH2… — FILEPATHn	Выводит перечень модулей, которые нужно загрузить (разделяются тремя дефисами)

Путь к инсталляционному скрипту ESXi указывается таким образом:

ks=http://XXX.XXX.XXX.XXX/kickstart/KS.CFG

где XXX.XXX.XXX.XXX – IP-адрес машины, где находится скрипт.

Как подготовить носитель с инсталлятором ESXi, мы рассматривали выше, в разделе о «Подготовке…» до установки. Когда он готов, в принципе, дальнейшие действия не зависят от того, выбрали ли CD/DVD, или USB-устройство в качестве носителя. Конкретно же, скриптованная инсталляция ESXi с CD/DVD или с USB флеш-устройства выглядит следующим образом:

Загружаем ESXi-инсталлятор с локального устройства CD-ROM/DVD-ROM, или вставляем флешку, и ждем, пока не появится окно вида:
Быстренько жмем Shift+O, чтобы отредактировать опции загрузки;
Вводим параметр загрузки, что вызывает дефолтный скрипт, или созданный вами собственноручно (рассматривали этот вариант выше, в разделе «Подготовка к скриптованной инсталляции ESXi-хостов»). Этот параметр имеет вид «ks=». После чего жмем Enter и процесс инсталляции запустится.

А все, что нужно проделать, чтобы подготовиться к скриптованной инсталляции с использованием загрузки через сеть мы рассматривали выше, в подразделе «Подготовка к скриптованной инсталляции ESXi с сетевой загрузкой инсталлятора». Сама же загрузка начинается автоматически, какого-то специфического вмешательства в процесс не требуется.

Инсталляция хостов через vSphere Auto Deploy

На самом деле, как и в случае со скриптованной инсталляцией, vSphere Auto Deploy полностью автоматизирует процесс инсталляции и настройки хостов за выбранными профилями. Да, ему предшествует очень масштабный, последовательный процесс подготовки, создания всех необходимых правил, профилей образов и хостов и другие действия, подробно описанные нами выше в подразделе «Подготовка к инсталляции ESXi через vSphere Auto Deploy», однако, когда все это есть, работа администратора сужается, в буквальном смысле, до нажатия нескольких кнопок:

Включаем хосты, которые планируем подготовить;
Они самостоятельно разворачиваются в автоматическом режиме согласно заданным правилам, используя референсный профиль, созданный по готовому профилю хоста;
Тестируем и восстанавливаем соответствие для исправления хостов (как расписано в выше упомянутом подразделе);
Окончательно проверяем, подключен ли каждый хост к системе vCenter Server, не в режиме ли они техобслуживания, и не имеют ли сбоев в соответствии, а также действительно ли они используют профили хоста с самой свежей, необходимой нам информацией.

Развертывание vCenter Server

По vCenter Server appliance, его можно разворачивать на ESXi-хосте или инстансе vCenter Server. Метод при этом можно выбрать интерактивный через GUI, или CLI (silent-режим) – оба соответствующие инсталляторы содержатся в ISO-образе нашего appliance. О них будет ниже отдельно. Доступна инсталляция или развертывание инстансов vCenter Server, соединенных в конфигурации Enhanced Linked Mode, путем их регистрации в общем домене Single Sign-On (об этом поговорим в отдельном подразделе «Начальных настроек» ниже).

Развертывание appliance vCenter Server при помощи GUI

Интерактивное развертывание appliance vCenter Server – невероятно удобный и доступный метод, родной для Windows, Linux и macOS, на протяжении которого загруженный инсталлятор на клиентскую машину запускает с нее помощник, который проходит два глобальных этапа: развертывание OVA и настройку appliance:

Все необходимые предварительные проверки и валидации он проходит самостоятельно, без нашего вмешательства. Альтернативно, если имеем доступ к vSphere Client, можем разворачивать OVA-файл через него. Но этот вариант остановится на первой стадии – для старта второго этапа нужно будет зайти в vCenter Server Management Interface нашего нового appliance (введя «https:// FQDN_or_IP_address:5480»), чтобы выполнить дальнейшие необходимые настройки.

На протяжении первичного развертывания OVA нам предложат выбрать тип развертывания и настройки appliance. Следующий этап состоит в задании синхронизации времени и vCenter Single Sign-On, после чего начальную базовую настройку можно будет считать завершенной, а все сервисы только что развернутого appliance запустятся.

Чтобы запустить инсталлятор, проходим в директорию «vcsa-ui-installer» и выбираем подкаталог, который соответствует нашей ОС:

Запускаем файл (для Windows подкаталог «win32», файл – «installer.exe»; для Linux подкаталог «lin64», файл – «installer»; для Mac подкаталог «mac», файл – «Installer.app») инсталлятора, после чего увидим следующее приветственное окно с выбором нескольких возможностей:

Нас интересует первая опция – Install. Три другие (Upgrade – для обновления существующего инстанса vCenter Server Appliance, Migrate – для миграции с существующего Windows-инстанса vCenter, а Restore – для восстановления с предыдущего бэкапа vCenter Server Appliance) будем рассматривать в запланированной другой статье об администрировании vSphere 8.0. Вот что предложит нам помощник и что нам необходимо будет в нем задать:

Приветственное окно познакомит с вехами развертывания, а боковое меню слева покажет пункты нашего помощника, по которым будем идти. Жмем Next:
Соглашаемся с лицензионным соглашением (EULA). Next;
В пункте «vCenter Server deployment target» подключаемся к целевому ESXi-хосту или системе vCenter. Для ESXi-хоста путем ввода его:

- FQDN или IP-адреса,
- HTTPS-порта,
- Имени пользователя с привилегиями администратора на ESXi-хосте и пароля.

После этого нужно кликнуть Next, продемонстрируется предупреждение о сертификатах, которое покажет SHA1 отпечаток SSL-сертификата, проинсталлированного на целевом ESXi-хосте – жмем там Yes, чтобы его принять.

В случае не первого развертывания vCenter Server, можно подключиться к инстансу vCenter Server и найти в инвентаре ESXi-хост или кластер DRS, где хотим развернуть appliance. Для этого случая вводим в помощнике данные по существующему инстансу vCenter Server:

- FQDN или IP-адрес,
- HTTPS-порт,
- Имя пользователя и пароль с привилегиями администратора vCenter Single Sign-On на инстансе vCenter Server.

После этого кликаем Next. Продемонстрируется предупреждение о сертификатах, которое покажет SHA1 отпечаток SSL-сертификата, проинсталлированного на целевом ESXi-хосте – жмем там Yes, чтобы его принять. Дальше будет выбор дата-центра или папки дата-центра, что содержат ESXi-хост или DRS-кластер, на котором развертываем appliance. Нажимаем Next, и после этого будет выбор самого ESXi-хоста или DRS-кластера. Опять Next;

«Set up vCenter Server VM». Вводим имя appliance vCenter Server (не должно содержать %,\,/, меньше 80 символов в длину), устанавливаем пароль для пользователя root (требования к паролям писали выше в «Подготовке…») и кликаем Next;
«Select deployment size». Рекомендации по выбору размера развертывания приводились выше, в разделе «Подготовка…»
«Select datastore». Выбираем размер хранилища для vCenter Server appliance и его местонахождение. Доступные варианты:

- Install on an existing datastore accessible from the target host – выбираем датастор из списка совместимых;
- Install on a new vSAN cluster containing the target host – указываем необходимую информацию для создания нового кластера vSAN или кластера vSAN Express Storage Architecture (vSAN ESA), который будет хранить vCenter Server appliance;
- Install on an existing vSAN datastore and claim additional disks – Указываем данные, чтобы создать кластер на датасторе vSAN. Эта опция доступна только в случае, если в среде есть хранилище vSAN;

Чтобы разрешить тонкое предоставление, выбираем Enable Thin Disk Mode. NFS-хранилища предоставляются в тонком формате, по дефолту. Кликаем Next;

«Configure network settings». Здесь задаем настройки сети:

- Network – выбираем сеть из выпадающего меню, к которой подключится appliance. Зависит от сетевых настроек целевого сервера. Если appliance разворачивается на ESXi-хосте, помните, что неэфемерные распределенные виртуальные порт-группы не поддерживаются и не отобразятся в выпадающем меню;
- IP version – выбираем версию IP-адреса appliance;
- IP assignment – выбираем, как именно выделить IP-адрес appliance (static – помощник предложит ввести IP-адрес и параметры сети, либо DHCP – если DHCP-сервер есть в среде, можно ввести желаемое FQDN для appliance);
- Common Ports – можно кастомизировать HTTP и HTTPS порты (опционально). Если указывается пользовательский номер порта, нужно убедиться, не используется ли уже употребленный vCenter Server номер порта, или дефолтные порты 80 и 443;

«Ready to complete stage 1». Пересматриваем все настройки развертывания для нашего appliance и кликаем Finish, после чего начнется сам процесс.

Дождавшись его окончания сможем кликнуть Continue, чтобы перейти ко второму этапу. Если на этом шагу нечаянно нажмете Close, ничего страшного – просто дальше зайдете в vCenter Server Management Interface, чтобы завершить все необходимые настройки.

На втором этапе наш помощник будет выглядеть вот так:

Сначала, традиционно, будет страница Introduction, на которой просто жмем Next. Далее:

«vCenter Server Configuration». Здесь настраиваем параметры времени для appliance (Synchronize time with the ESXi host – включает периодическую синхронизацию времени, VMware Tools установят время гостевой ОС таким же, как и время на ESXi-хосте; Synchronize time with NTP servers – использование NTP-серверов для синхронизации времени, нужно будет ввести их IP-адреса через запятую), опционально можем включить удаленный доступ по SSH. Кликаем Next;
«SSO Configuration». Создаем новый домен vCenter Single Sign-On, или присоединяемся к уже существующему. В первом случае выбираем опцию Create a new SSO domain:

- Вводим имя домена (например, vsphere.local), не должно содержать большие буквы!
- Устанавливаем пароль для аккаунта администратора;
- Подтверждаем пароль и кликаем Next.

Если присоединяемся к уже существующему домену (кстати, именно это нужно сделать, если хотим несколько наших vCenter развернуть в Enhanced Linked Mode):

- Вводим FQDN или IP-адрес сервера vCenter Single Sign-On;
- Вводим HTTPS-порт, который будет использоваться для коммуникации с сервером vCenter Single Sign-On;
- Вводим данные учетной записи для аккаунта администратора vCenter Single Sign-On;

Кликаем Next. Именно этот шаг продемонстрировано на приведенном выше скриншоте;

«Configure CEIP». Можем присоединиться к программе;
«Ready to complete». Пересматриваем параметры настройки и кликаем Finish, а затем – OK, чтобы закончить вторую стадию процесса развертывания. Выходим из помощника по Close.

Теперь нас направит на страницу Getting Started нашего appliance vCenter Server. Далее можем зайти через клиент vSphere, набрав в браузере «https://<vCenter_FQDN_or_IP_address>/ui», и управлять инвентарем vCenter:

Как это делать, настраивать vCenter, пользоваться vCenter Management Interface, работать с мульти-хоумингом и много чего другого рассмотрим в будущей статье по администрированию vSphere.

Развертывание appliance vCenter Server через CLI

CLI-инсталлятор производит «тихое» развертывание appliance vCenter Server на ESXi-хосте или инстансе vCenter Server. Оно состоит в запуске подготовленного нами ранее (подраздел «Подготовка конфигурационного JSON-файла для CLI-метода развертывания appliance vCenter Server» раздела «Подготовка…» выше) JSON-файла путем ввода нескольких команд у CLI. А именно:

Проходим в поддиректорию «vcsa-cli-installer», в зависимости от типа ОС («win32»/«lin64»/«mac»);
Опционально можем запустить проверку без непосредственного развертывания appliance, чтобы убедиться, что шаблон подготовлено правильно:

vcsa-deploy install —precheck-only path_to_the_json_file

Запускаем команду развертывания:

vcsa-deploy install —accept-eula —acknowledge-ceip optional_arguments path_to_the_json_file

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

vcsa-deploy install —accept-eula —acknowledge-ceip —log-dir=path_to_the_location path_to_the_json_file

Развертывание нескольких vCenter Server Appliance при помощи CLI

Можно разворачивать несколько инстансов vCenter Server appliance одновременно (в пакетном режиме) при помощи инсталлятора CLI. Для этого нужно подготовить JSON-шаблоны для всех инстансов vCenter Server в среде.

Важно! Инсталлятор CLI видит топологию развертывания и определяет порядок, в котором необходимо работать. Именно из-за этого обязательным условием является использование JSON-шаблонами статических IP-адресов для всех зависимых друг от друга инстансов vCenter Server в развертывании.

Все подготовленные шаблоны (об этом говорили выше в соответствующем подразделе «Подготовки…») следует поместить в одну директорию (желательно назвать ее как-то осмысленно, например, «MyWorkspace/BatchDeploy»). А далее:

Проходим в поддиректорию «vcsa-cli-installer», в зависимости от типа ОС («win32»/«lin64»/«mac»);
Опционально, можно запустить проверку перед развертыванием без развертывания самого appliance, чтобы убедиться, что шаблоны правильные:

vcsa-deploy install —precheck-only MyWorkspace/BatchDeploy

Запускаем команду развертывания:

vcsa-deploy install —accept-eula —acknowledge-ceip optional_arguments MyWorkspace/ BatchDeploy

vcsa-deploy install —accept-eula —acknowledge-ceip —log-dir=path_to_the_location MyWorkspace/BatchDeploy

Начальная настройка

Допустим, прогулка предыдущим разделом для нас завершилась полнейшим успехом – наша среда может похвастаться предоставленным некоторым количеством хостов ESXi, развернулся vCenter Server. Но время для отдыха еще не настало, ведь сейчас крайне важно как можно быстрее приступить к начальной настройке. Рассмотрим минимальный перечень необходимых акций в этой связи, а вот глубоких настроек и всех вопросов администрирования нашей vSphere 8.0 коснемся в будущем запланированном материале нашего блога.

Синхронизация времени в сети vSphere

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

Все компоненты сети vSphere должны быть синхронизированы по времени, иначе чувствительные к нему SSL-сертификаты и SAML-токены не будут распознаваться валидными в коммуникациях между машинами сети. Это приведет к проблемам с аутентификацией, фейлам инсталляций или запрету стартовать сервису vmware-vpxd vCenter Server, помешает аккуратному отображению графиков производительности, в логах не будет точной маркировки тайминга, что усложнит траблшутинг. Чтобы этого не случилось предварительно проверяем:

Синхронизирован ли с NTP или PTP целевой ESXi-хост, на котором должен развернуться vCenter Server?
Синхронизирован ли с NTP или PTP хост ESXi, что содержит источник vCenter Server?

Чтобы установить безопасное TLS-подключение к vCenter Server (серверу), система, где запускаем CLI-инсталлятор (клиент) должна быть засинхронизирована по часам с сервером в некотором, так называемом, промежутке толерантности (Clock Tolerance):

Сценарий развертывания	Толерантный временной промежуток
Связывание одного vCenter Server с другим	10 мин.
Инсталляция appliance vCenter Server при помощи контейнера vCenter Server через шаблон *._on_vc.json	8ч. 20 мин.

Синхронизацию можно настроить через VMware Host Client или vSphere Client. NTP (Network Time Protocol) дает точность времени в мили-секундах, а PTP (Precision Time Protocol) – в микросекундах. NTP или PTP можно настроить при помощи VMware Host Client или vSphere Client. Одновременно они работать не могут (как и с возможностью вручную выставить время):

ESXi-хост может быть настроен как NTP-клиент и синхронизировать время с NTP-сервером в интернете или с корпоративным NTP-сервером. NTP-клиент использует порт UDP 123:

Эта настройка выглядит довольно просто:

На домашней странице vSphere Client проходим в Home > Hosts and Clusters и выбираем хост;
На вкладке Configure выбираем System > Time Configuration;
Кликаем на Add Service и выбираем Network Time Protocol из выпадающего меню;
В диалоговом окне Network Time Protocol редактируем настройки протокола: если хотим видеть все события в среде vSphere, выбираем Enable monitoring events, а в текстовом поле NTP Servers вводим IP-адрес или имена хостов NTP-серверов, которые хотим использовать (по best practice их должно быть, минимум, три);
Нажимаем ОК.

РТР дает аппаратную метку времени для ВМ и хостов в сети. Клиент РТР использует порт UDP 319 и 320. Если служба РТР не работает, NTP может подключиться в качестве резервного варианта.

Процедура настройки РТР:

На домашней странице vSphere Client проходим в Home > Hosts and Clusters и выбираем хост;
На вкладке Configure выбираем System > Time Configuration;
Кликаем на Add Service и выбираем Precision Time Protocol из выпадающего меню;
В диалоговом окне Precision Time Protocol редактируем параметры: чтобы настроить метки времени, нужно выбрать из выпадающего меню тип сетевого адаптера как «PCI passthrough», или для метки времени ПО – «VMkernel Adapter» в качестве типа сетевого адаптера:
Опционально, создаем механизм отката в случае сбоя РТР-синхронизации, кликнув на Enable fallback, но это можно сделать, только если поставить галочку в Enable monitoring events, чтобы наблюдать за событиями в vSphere. В диалоговом окне NTP Servers вводим IP-адрес или имена хостов NTP-серверов, которые хотим использовать (по best practice их должно быть, минимум, три);
Нажимаем ОК.

Чтобы протестировать, правильно ли функционируют сервисы синхронизации, можно нажать Test Services – появится диалоговое окно Time Synchronization Services test, где будет нужная информация.

Если по какой-то причине не планируем, по крайней мере сейчас, работать с NTP или PTP синхронизацией времени, а расхождение между хостом и остальными компонентами vSphere присутствует, и значительная, можно вручную установить правильное время и дату на хосте. Для этого:

На домашней странице vSphere Client проходим в Home > Hosts and Clusters и выбираем хост;
На вкладке Configure выбираем System > Time Configuration;
Кликаем на Manual Set-Up – появится диалоговое окно, в котором вводим нужные дату и время, после чего подтверждаем все кнопкой ОК.

Важно! ESXi-хосты используют UTC (Coordinated Universal Time) и не поддерживают смену часовых поясов. В клиенте vSphere вы увидите локальное время как текущее для конкретного хоста.

Начальные настройки ESXi

Когда ESXi-хост загружается впервые или после сброса дефолтов, он вступает в фазу автоконфигурации, которая настраивает сеть системы и устройства хранилища с параметрами по умолчанию. По дефолту, DHCP настраивает IP, а все видимые пустые внутренние диски форматируются с VMFS, чтобы ВМ могли храниться на дисках.

Управлять ESXi-хостами можно при помощи VMware Host Client, vSphere Client и vCenter Server.

Также для траблшутинга, начального конфигурирования и установления административного доступа можно использовать прямой консольный интерфейс – он появится на экране, как только завершится фаза автоконфигурирования хоста. Горячие клавиши навигации прямой консоли:

F2 – просмотр и изменение конфигурации

F4 — переход пользовательского интерфейса на высококонтрастный режим

F12 – выключение или перезапуск хоста

Alt+F12 – просмотр логов VMkernel

Alt+F1 – переключиться на консоль оболочки

Alt+F2 – переключиться на интерфейс прямой пользовательской консоли

Arrow keys – перемещение выбора между полями

Enter – выбор объекта меню

Spacebar – переключение значения

F11 – подтверждение чувствительных команд, например, сброса конфигурации по умолчанию

Enter – сохранить и выйти

Esc – выйти без сохранения

q – выйти из системных логов

Чтобы настроить раскладку клавиатуры для прямой консоли:

С прямой консоли выбираем Configure Keyboard и нажимаем Enter;
Выбираем раскладку клавиатуры – жмем пробел, чтобы переключать выборы на on/off;
Кликаем Enter.

Чтобы установить баннер безопасности, который будет демонстрироваться на Welcome-экране прямой консоли, нужно:

С vSphere Client подключаемся к vCenter Server;
Выбираем хост в инвентаре;
Кликаем на вкладку Configure;
Под System выбираем Advanced System Settings;
Выбираем WelcomeMessage;
Кликаем иконку Edit;
Вводим оповещение по безопасности.

Чтобы перенаправить прямую консоль на последовательный порт (для удаленного управления консолью), можно воспользоваться настройкой вручную или интерфейсом vSphere Client.

Важно! Последовательный порт не должен использоваться для последовательного логгирования и дебаггинга.

В первом случае:

Запускаем хост;
Когда появится окно загрузки гипервизора, жмем на Shift+O, чтобы отредактировать опции загрузки;
Деактивируем logPort и gdbPort на com1, и устанавливаем tty2Port на com1, введя такое:

«gdbPort=none logPort=none tty2Port=com1»;

Чтобы вместо этого использовать com2, в выражении делаем соответствующие изменения.

А во втором:

С vSphere Client подключаемся к vCenter Server;
Выбираем хост в инвентаре;
Кликаем на вкладку Configure;
Под System выбираем Advanced System Settings;
Убеждаемся, что поля VMkernel.Boot.logPort и VMkernel.Boot.gdbPort не установлены на использование com-порта, на который хотим перенаправить прямую консоль;
Устанавливаем VMkernel.Boot.tty2Port на последовательный порт, чтобы перенаправить прямую консоль на com1 или com2;
Перезагружаем хост.

Включение ESXi Shell и SSH Access через пользовательский интерфейс прямой консоли

На прямой консоли жмем F2, чтобы зайти в меню System Customization;
Выбираем Troubleshooting Options и жмем Enter;
Из меню, что появилось, выбираем сервис, который необходимо включить — Enable ESXi Shell / Enable SSH и нажимаем Enter;
Опционально, можно установить тайм-аут для ESXi Shell (по дефолту — 0): из меню Troubleshooting Mode Options выбираем Modify ESXi Shell and SSH timeouts и жмем Enter, вводим значение в минутах, снова жмем Enter и вводим тайм-аут простоя;
Жмем Esc, пока не вернемся в главное меню.

Установка пароля для аккаунта администратора (имя пользователя — root)

По умолчанию, пароль администратора не установлен. Чтобы его настроить, нужно:

С прямой консоли выбираем Configure Password;
Опционально, если пароль уже есть, можно ввести новый в строку Old Password и нажать Enter;
В строке New Password вводим новый пароль и жмем Enter;
Снова вводим новый пароль и еще раз Enter.

Настройка параметров загрузки BIOS

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

Важно! Если вы используете ESXi Embedded, конфигурация загрузки BIOS определяет, загружается ли ваш сервер на загрузочное устройство ESXi или другое загрузочное устройство. Как правило, флеш-устройство USB отмечен первым в настройках загрузки BIOS на машине, на которой размещен ESXi. Когда вы устанавливаете или обновляете ESXi в режиме UEFI, инсталлятор создает параметр загрузки UEFI под названием VMware ESXi и делает его параметром загрузки по умолчанию, поэтому вам не нужно менять порядок загрузки.

Параметры загрузки можно менять, путем настройки ее порядка в BIOS во время первичного запуска или выбрав загрузочное устройство из меню выбора устройства. В первом случае после этих изменений новые настройки будут применяться ко всем последовательным перезагрузкам. Если же напрямую выбрать – примениться только к текущей загрузке. Для изменения этих параметров в BIOS для ESXi необходимо:

Хост ESXi должен быть включен, чтобы нажать клавишу, которая нужна для входу в настройки BIOS хоста (зависит от аппаратного обеспечения сервера, иногда это Delete);
Выбираем настройки загрузки BIOS:

- If you are using the installable version of ESXi – выбираем диск, на котором проинсталлировано ПО ESXi и перемещаем его на первую позицию в списке;
- If you are using ESXi Embedded – выбираем устройство USB и перемещаем его на первую позицию в списке.

Также можно настраивать параметры загрузки для виртуального медиа. Это полезно, когда используете ПО удаленного управления для установки ESXi. Виртуальное медиа помогает подключиться к удаленному медиа-хранилищу, например, CD-ROM, USB, ISO-образу, флоппи-диску на целевом сервере. Для этого:

Подключаем медиа к виртуальному устройству. Например, если у нас сервер Dell, заходим в Dell Remote Access Controller (DRAC) или другой подобный интерфейс и выбираем физический флоппи или устройство CD-ROM, либо предоставляем путь к образу флоппи / образу CD-ROM;
Перезагружаем сервер;
Когда сервер включится, заходим в меню выбора устройства (в зависимости от аппаратного обеспечения сервера это может быть функциональная клавиша или Delete);
Следуем указаниям и выбираем виртуальное устройство.

Настройка параметров сети и тестирование ее подключений

Чтобы выбрать сетевые адаптеры для management-сети:

С прямой консоли выбираем Configure Management Network и жмем Enter;
Выбираем Network Adapters и жмем Enter;
Выбираем сетевой адаптер и жмем Enter.

Чтобы установить VLAN ID ESXi-хоста:

С прямой консоли выбираем Configure Management Network и жмем Enter;
Выбираем VLAN и жмем Enter;
Вводим VLAN ID (число от 1 до 4094).

Чтобы настроить IP-параметры для ESXi:

Выбираем с прямой консоли Configure Management Network и жмем Enter;
Выбираем IP Configuration и жмем Enter;
Выбираем Set static IP address and network configuration;
Вводим IP-адрес, маску подсети и дефолтный шлюз, после чего жмем Enter.

Аналогичного результата можно достичь и из клиента vSphere (полезно, когда нет физического доступа к хосту):

Заходим на vCenter Server из vSphere Client;
Выбираем хост в инвентаре;
На вкладке Configure раскрываем Networking;
Выбираем VMkernel adapters;
Выбираем vmk0 Management Network и кликаем на иконку редактирования;
Выбираем IPv4 settings;
Выбираем Use static IPv4 settings;
Вводим или изменяем настройки статического IPv4-адреса (то же самое можно, если надо, сделать и для IPv6-адреса);
Кликаем на OK.

Чтобы настроить DNS для ESXi, можно, во-первых, выбрать вручную ли, или же автоматическим образом будет происходить конфигурация DNS хоста ESXi. По дефолту имеем автоматику (обязательно требует наличия DHCP и DNS серверов). Но иногда автоматический DNS не является доступным, или является нежелательным, и тогда можно настроить статическую DNS-информацию, включая имя хоста, имена первичного и вторичного серверов, DNS-суффиксами. Для этого с прямой консоли:

Выбираем Configure Management Network и жмем Enter;
Выбираем DNS Configuration и жмем Enter;
Выбираем Use the following DNS server addresses and hostname;
Вводим первичный сервер, альтернативный (опционально), и имя хоста;
Возвращаемся в Configure Management Network;
Выбираем Custom DNS Suffixes и жмем Enter;
Вводим новые DNS-суффиксы.

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

дефолтного шлюза,
первичного сервера DNS-имен;
вторичного сервера DNS-имен;
разрешения (Resolve) настроенного имени хоста.

Для этого выбираем Test Management Network и жмем Enter, и еще раз Enter, чтобы начать тест, после введения адресов, которые нужно пропинговать или другого DNS-имени хоста, которое нужно отрезолвить.

Также еще одной очень полезной и часто используемой операцией является перезагрузка management-сети (чтобы восстановить сетевое подключение или обновить аренду DHCP). Это тоже можно сделать из прямой консоли, выбрав Restart Management Network и нажав Enter, а затем — F11, чтобы подтвердить перезапуск.

И, наконец, завершая разговор о настройке подключений и сети, поговорим о восстановлении стандартного свитча (vSphere Distributed Switch в подробностях рассмотрим в статье об администрировании vSphere 8.0). Это может пригодиться:

Когда Distributed Switch не нужен, или по какой-то причине не работает;
Когда он ребует восстановления, но на это время хосты должны оставаться доступными;
Когда нам не нужно, чтобы хост управлялся vCenter Server (в последнем случае помните, что большинство функций vSphere Distributed Switch для хоста станут недоступными).

Чтобы переключиться таким образом, необходимо: выбрать Restore Standard Switch с прямой консоли и нажать Enter, а затем на F11 для подтверждения.

Начальные настройки vCenter Server

В принципе, большинство настроек только что развернутого нами vCenter Server можно спокойно осуществить впоследствии – с его управляющего интерфейса, или из клиента vSphere. И все эти операции, во всех подробностях, мы обязательно рассмотрим в будущей статье по администрированию нашей «сферы». Но, если наша задача в последовательном развертывании нескольких инстансов vCenter Server, обязательно следует рассмотреть возможность их организации в Enhanced Linked Mode – и вот в этом случае мешкать с настройками у нас не выйдет никоим образом.

Присоединение к домену vCenter в Enhanced Linked Mode

Appliance vCenter Server можно подсоединить к другой ноде во время ее развертывания (или позднее – путем перемещения, переназначения) в Enhanced Linked Mode группе. На практике в UI-инсталляторе это выглядит так:

Разворачиваем первый appliance vCenter Server как инстанс на первом хосте ESXi;
Разворачиваем второй appliance vCenter Server как инстанс на том же первом хосте. На втором этапе развертывания (stage 2) выбираем присоединение к серверу vCenter Single Sign-On развернутого первого appliance.

Важно! Синхронизацию времени, о которой говорилось выше в отдельном подразделе, для хоста ESXi, на котором развернуто наш первый vCenter Server appliance, с appliance vCenter Server нужно провести до того, как начнем работать со вторым appliance vCenter Server. Более того, для второго appliance синхронизация должна пройти с первым хостом первого appliance vCenter Server.

Если хотим сделать это через CLI:

Настраиваем конфигурационный JSON-шаблон «embedded_vCSA_on_VC.json» (или «embedded_vCSA_on_ESXi.json») для первого appliance как инстанса на первом хосте ESXi;
Разворачиваем первый appliance, запустив:

vcsa-cli-installer

Настраиваем конфигурационный JSON-шаблон «json» (или «embedded_vCSA_replication_on_ESXi.json») для второго appliance как инстанса на первом хосте ESXi. Вводим имя хоста первой встроенной ноды в поле «replication_partner_hostname» секции «sso»;
Разворачиваем второй appliance, запустив:

vcsa-cli-installer

что использует файл «embedded_vCSA_replication_on_VC.json» (или «embedded_vCSA_replication_on_ESXi.json»).

А о прочих операциях, включая настройку и работу с журналами логов, лицензирование, работу с инвентарем vCenter с помощью vSphere Client, назначение ролей пользователям, создание и настройку виртуальных сетей и хранилищ данных, а также виртуальных машин, кластеров, с управлением жизненным циклом нашей виртуальной среды, и много еще о чем другом поговорим в нашей следующей статье из цикла по vSphere 8.0, посвященной администрированию во всей его многогранности. Также выйдет и отдельный материал насчет обновления vSphere до 8-й мажорной версии – его, уверены, с нетерпением ждут все собственники «семерки» и еще более старых релизов.

Архитектура, компоненты и понятия

Глоссарий

Архитектура и компоненты

Сервисы аутентификации vCenter

Сервис лицензирования

VMware Certificate Authority

Сервис vSphere ESXi Dump Collector

Сервисы управления жизненным циклом

Виртуализация ресурсов

Требования и совместимость

Конфигурационные лимиты

Требования к уровню системного хранилища

Требования к «железу», сети и хранилищу

Требования к браузеру и ОС

Лицензирование

Подготовка к развертыванию vSphere 8.0

Порты и протоколы

Подготовка необходимой информации

Подготовка к инсталляции хостов ESXi

Кастомизация инсталляций при помощи vSphere ESXi Image Builder

Уровень принятия (acceptance level) и его изменение

Настройка vSphere ESXi Image Builder

Операции с профилем образа

Подготовка к скриптованной инсталляции ESXi-хостов

Подготовка к скриптованой инсталляции ESXi с сетевой загрузкой инсталлятора

Подготовка к инсталляции ESXi через vSphere Auto Deploy

Инсталляция и настройка vSphere Auto Deploy

Использование cmdlet vSphere Auto Deploy

Написание правила при помощи командлетов PowerCLI для vSphere Auto Deploy

Написание правила и назначение профиля образа хостам

Написание правила и назначение профиля хоста хостам

Написание правила и назначение хоста папке или кластеру

Тестирование и восстановление соответствия правила после его модификации

Пакетное лицензирование через vSphere Auto Deploy в PowerCLI

Использование vSphere Client в подготовительных к работе с vSphere Auto Deploy процессах

Создание правила развертывания и операции с ним с vSphere Client

Добавление хоста в инвентарь vSphere Auto Deploy с vSphere Client

Работа с пакетами скриптов с vSphere Client

Подготовка к развертыванию vCenter Server

Подготовка конфигурационного JSON-файла для CLI-метода развертывания appliance vCenter Server

Процедура инсталляции vSphere 8.0

Инсталляция ESXi

Интерактивный способ инсталляции ESXi

Первичная настройка ESXi-хоста при интерактивной инсталляции

Инсталляция ESXi при помощи скрипта

Инсталляция хостов через vSphere Auto Deploy

Развертывание vCenter Server

Развертывание appliance vCenter Server при помощи GUI

Развертывание appliance vCenter Server через CLI

Развертывание нескольких vCenter Server Appliance при помощи CLI

Начальная настройка

Синхронизация времени в сети vSphere

Начальные настройки ESXi

Включение ESXi Shell и SSH Access через пользовательский интерфейс прямой консоли

Установка пароля для аккаунта администратора (имя пользователя — root)

Настройка параметров загрузки BIOS

Настройка параметров сети и тестирование ее подключений

Начальные настройки vCenter Server

Присоединение к домену vCenter в Enhanced Linked Mode

Related posts: