Категорії
VMware: Інсталяції оновлень

Обновляем ESXi до версии 7.0U2

Начиная с 09.03.21 г. доступен второй апдейт vSphere 7.0, и многие, наверняка, захотят протестировать ее обновленный интерфейс и множество новых функций, которые мы перечисляли в недавно опубликованных нами релизах «VMware ESXi 7.0 Update 2 Release Notes» и «VMware vCenter Server 7.0 Update 2 Release Notes». Бесспорно, весьма разумной тактикой будет не апгрейдить продакшен, пока не выйдет хотя бы первый патч к ESXi 7.0U2 (кстати, он вышел 29 апреля, об этом мы писали вот здесь), ведь ошибок и проблем с ним имеется еще масса (см. наш материал «Возможные ошибки в VMware ESXi 7.0 Update 2»), однако для тестовой среды, а также в качестве рекомендации для будущего обновления эта статья будет более чем полезной.

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

Что ж, давайте оставим предисловия позади и перейдем непосредственно к делу.

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

Апгрейд ESXi можно осуществлять с версий 6.5/6.7 на 7.0.х напрямую. Но, перед тем, как приступать к подготовке к нему и самому непосредственному процессу, стоит самым внимательным образом изучить требования к среде и ее компонентам, а также получить все сведения о совместимости того, что у нас уже есть в системе (либо точно планируется заполучить в ближайшем будущем – до смены версии гипервизора), чтобы обновление не дало сбой, либо же после него не оказалось, что обстоятельства вынуждают откатываться назад.

Совместимость с платформами, ОС, версионностью «железа» и прочим проверяем, как обычно, здесь, в VCG. С другими решениями и продуктами VMware (а без гипервизора у нас, как известно, очень многое, попросту не существует) – здесь.

Поддерживаемые пути апгрейда

Учтите, что хосты, версии 6.5U1 и древнее, на «семерку» сходу обновить не получится – сначала доводим их до 6.5U2, а еще лучше – сразу до 6.7.х, и только потом – до самой свежей. Вообще же совместимость версий гипервизора проверяется в этой таблице, а для ESXi 6.5U2 и новее она сейчас выглядит, например, вот так:

Важно! Если что, откатиться на 6.х-версии ESXi не получится (причины раскрываются ниже в подразделе «Требования к уровню системного хранилища»). Рекомендуется сделать бэкап загрузочного устройства до обновления и, при необходимости, восстановиться с него.

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

Уровень системного хранилища ESXi в 7.х-семействе – это гибкое управление партициями для больших модулей, агрегация со сторонними компонентами и чрезвычайно упрощенная отладка. Если у вас версия 6.5/6.7, вы, конечно же, в курсе, что она декларирует фиксированный размер партиций, за исключением партиции «/scratch» и опционального VMFS-датастора, а также статичное их кол-во наряду с ограниченными возможностями управления. В «семерке» все консолидировалось в меньшее по количеству партиций, но больших размеров хозяйство, причем, все это интересно масштабируемо.

Уровень системного хранилища сейчас раздроблен всего на четыре партиции:

  • System Boot (хранит загрузчик и модули EFI, 100 МБ),
  • Boot-bank 0 и Boot-bank 1 (системные пространства для модулей загрузки ESXi, 500 МБ – 4 ГБ каждая),
  • ESX-OSData (консолидированная локация для хранения дополнительных модулей, не используемая в загрузке и для ВМ, содержит старую «/scratch», партицию локера для VMware Tools и назначения дампа ядра, до 138 ГБ).

Первые три относятся к типу FAT16, а ESX-OSData – к VMFS-L. Последний том поделен на постоянные (образа VMware Tools, конфигурации и дампы ядра) и непостоянные (логи, глобальные трассировки VMFS, данные vSAN Entry Persistence Daemon (EPD), трассировки vSAN и БД в реальном времени) данные.

Также к этому всему прилагается традиционный датастор VMFS, объем которого – это все, что осталось. Для высоконадежных носителей, к примеру, это 142+ ГБ, и в этом случае хранилище VMFS создается автоматически с целью хранения данных ВМ.

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

  • «min» (33 ГБ – одиночный диск или встроенные сервера),
  • «small» (69 ГБ – сервера с, минимум, 512 ГБ оперативной памяти),
  • «default» (138 ГБ),
  • «max» (все доступное пространство – для мульти-терабайтных серверов).

Учтите, что процесс апгрейда ESXi со старых версий на любую из «семерок» повлечет за собой перераспределение партиций на загрузочном диске. При этом, если пользователем место назначения дампа ядра не настроено, система водрузит его, по умолчанию, в том ESX-OSData. VMware Tools будут смигрированы из партиции локера и этот раздел очистится. Партиция дампа ядра очистится тоже, а если syslog-служба настроена на хранение файлов логов на 4 ГБ VFAT scratch-партиции, их переместят из «var/run/log» в том ESX-OSData.

Требования к «железу»

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

  • 2 CPU (широкий диапазон 64-битных х86 процессоров – проверять в VCG, со включенным битом NX/XD в BIOS),
  • 4 ГБ RAM (от 8 ГБ для запуска ВМ в типичных продакшен-средах),
  • Gigabit или более быстрые Ethernet-контроллеры (совместимость смотрим там же),
  • загрузочный диск с 8 ГБ для USB/SD и 32ГБ для HDD/SSD/NVMe,
  • SCSI-диск или локальный, несетевой RAID LUN с неразделенным пространством для ВМ,
Важно! Загрузочный диск не должен использоваться совместно несколькими ESXi-хостами.
  • удаленный (не локальный) SATA-диск, подключенный через поддерживаемые SAS-контроллеры или встроенные SATA-контроллеры. Такие диски не могут использоваться как scratch-партиция по дефолту.

По best practice максимальных показателей производительности можно достичь при обновлении ESXi в надежной системе с хорошим запасом оперативной памяти и несколькими физическими дисками.

Важно! ESXi-хосты всегда требуют больше RAM, чем типичные серверы.
Важно! Чем быстрее процессоры – тем лучше производительность ESXi. Учтите, что некоторые рабочие процессы весьма требовательны к производительности и для них хорошо бы предусмотреть больший кэш.

Требования к хранилищу

По размеру хранилища для ESXi 7.0.х рекомендовано следующее:

  • 8 ГБ USB/SD + 32 ГБ локального диска (загрузочные партиции будут на USB/SD, а том ESX-OSData – на локальном диске);
  • локальный диск на 32 ГБ (загрузочные партиции вместе с томом ESX-OSData);
  • локальный диск на 142 ГБ или больше (там все – и загрузочные партиции, и том ESX-OSData, и VMFS-датастор).
Важно! Рекомендуется размещать все данные, используемые ВМ на специально выделенных для них физических дисках. Для повышения производительности стоит не размещать ВМ там, где содержится загрузочный образ ESXi.

Если используется 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

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

Важно! Рекомендуется размещать управляющую сеть и сети ВМ на разных физических сетевых картах.

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

По поводу открытия портов, следует свериться с этой таблицей. Если устанавливаются другие VIB на хосте, должны быть доступны дополнительные сервисы и порты файерволлинга – здесь все индивидуально.

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

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

Браузер, версия Mac OS Windows Linux
Google Chrome 75+ 75+ 75+
Mozilla Firefox 60+ 60+ 60+
Microsoft Edge 79+
Safari 9.0+

Подготовка к обновлению гипервизора

Важно! Гипервизор всегда обновляется после vCenter Server. Как его апгрейдить до последней версии мы учились в статье «Обновляем vCenter Server до версии 7.0U2».

Обновление ESXi VMware рекомендует делать, согласно следующей схеме:

Вот по ней, собственно, и начнем свое продвижение.

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

  • интерактивный с подмонтированного носителя (CD, DVD или USB) через GUI,
  • скриптованный,
  • ESXCLI,
  • Auto Deploy,
  • через vSphere Lifecycle Manager.

Каждый имеет свои преимущества и недостатки, а также идеальную сферу применения. Так, первый метод весьма нагляден для начинающих виртуализаторов и удобен, если всего несколько хостов нуждаются в обновлении. Скрипты – прекрасный вариант, если хостов множество. vLCM – замечательный комплексный инструмент по обслуживанию всего жизненного цикла компонентов vSphere, включая апгрейд, исправление и прочие касающиеся предмета нашего сегодняшнего разговора вещи. Его оркестровка существенно упрощает жизнь, проверено на практике.

Если же мы говорим о vSphere Auto Deploy, он подходит только в варианте, когда и предыдущая версия разворачивалась тоже с ним – метод повторной подготовки хоста и перезагрузки его уже с новым профилем образа. В таком профиле будет обновление или исправление ESXi, профайл конфигурации хоста и, при необходимости, сторонние драйверы или агенты управления, предоставляемые партнерами VMware. Можно готовить кастомные образа, используя vSphere ESXi Image Builder CLI.

И, наконец, классика ESXCLI – для любителей работы с командной строкой, находящихся на короткой ноге с синтаксисом JSON, опытных виртуализаторов, тех, кто предпочитает автоматизировать свою работу, особенно в случае управления сотнями хостов с отличными конфигурациями.

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

  • Если к хосту подключен vSAN, нужно отключить систему Fibre Channel. Не отключать карты HBA в BIOS;
  • Сделать бэкап хоста;
  • Смигрировать или выключить ВМ на хосте (см. ниже по каждому методу апгрейда), погрузить хост в режим техобслуживания (требуется в ряде случаев).

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

Важно! Требования к паролям: должны содержать, минимум, одну большую букву, одну маленькую, одну цифру и спецсимвол, быть длиной от 7 до 40 знаков, не совпадать со словами из словаря или их частью. Если начинается с большой буквы, все равно далее должна встречаться еще одна большая буква. Если заканчивается на цифру, еще одна цифра должна присутствовать в теле пароля. По дефолту, аккаунт блокируется после 5 попыток ввода неправильного пароля. Разблокировка происходит, обычно, через 15 минут.

Подготовка к апгрейду через vLCM

vLCM способен управлять обновлением хостов с помощью baseline или образов. У вторых, на данный момент, функционал масштабнее и ярче, но image работают только с «семерки», чего не скажешь о baseline, хоть под ними недоступны ROBO-поддержка, REST API и ограничена поддержка рекомендаций софта – только для кластеров vSAN в формате рекомендаций baseline.

Важно! Если перешли на апгрейд через vLCM с образами, вернуться к старой стратегии (с baseline), если таковая применялась, не получится. Разве что перенести хосты в кластер, использующий baseline.

Образа vLCM представляют собой желаемую спецификацию софта, предназначенную для применения ко всем хостам в кластере (версию ESXi, дополнительное ПО VMware, вендорское и стороннее ПО, в т. ч. драйвера и firmware). По итогу, нам нужен будет только один образ, который и станет управлять всеми хостами в кластере, благодаря чему достигается желаемая гомогенность. Сейчас в деталях изучать vLCM мы не будем – уж больно масштабная тема, действительно, с тоннами теории и возможностей, поэтому расскажем о его применении к процессу апгрейда хостов.

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

  • Оффлайн-пакет в zip-формате. Используется в ручной загрузке апдейтов: опцией импорта после выкачки они заходят в хранилище vLCM. Начиная с 7.0-версии vSphere, оффлайн-пакеты содержат не только патчи и расширения, но и базовый образ ESXi, вендорские аддоны или стороннее ПО, те же асинхронизированные драйвера, специфичные для требований OEM hardware и пр. Скачивается zip-пакет отсюда. Нужны будут привилегии VMware vSphere Lifecycle Manager.Upload File.Upload File;
  • ISO-образ для импортирования в локальное хранилище vLCM. Применяется для апгрейда ESXi с 6.5.х/6.7.х до 7.0. Выбрав нужный тип лицензии, скачиваем ISO отсюда:

Процедуру подгрузки апдейтов в клиенте vSphere и работу с импортированными образами рассмотрим в деталях со скриншотами ниже в подразделе «Обновление с помощью vLCM» главы «Процедура апгрейда ESXi до версии 7.0U2».

Кстати, можно настроить связь vLCM с центром обновлений для автоматического получения апдейтов по расписанию, либо же, когда необходимо, вручную загружать их. Во втором случае нам нужно пройти на домашнюю страницу vLCM (в клиенте vSphere выбрать в «Menu» – «Lifecycle Manager» и в выпадающем меню «Lifecycle Manager» отыскать нужный нам vCenter Server). Далее в «Actions» выбираем «Sync Updates» вверху, после чего стартует синхронизация. Загруженные патчи и расширения теперь появятся на вкладке «Updates».

Синхронизация автоматического типа изначально включена по дефолту и ее работа начинается, как только будет развернут vCenter Server. Расписание предписанного обновления включает в себя частые проверки, но, его можно изменить, по желанию. Чтобы поменять эти настройки, в клиенте vSphere заходим через «Menu» в «Lifecycle Manager» и из выпадающего меню выбираем нужный нам vCenter Server. Затем проходим на вкладку «Settings», где в «Administration» выбираем «Patch Downloads», и на панели «Automatic Download Settings» кликаем на кнопку «Edit». Откроется соответствующее диалоговое окно, где ставим галочку на «Download patches» и задаем настройки нашего расписания, после чего сохраняем все по «Save».

Подготовка к интерактивному обновлению через CD/DVD/USB

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

Далее помещаем ISO инсталлятора на CD/DVD или на USB-флешку. Также можно использовать PXE для загрузки. И проверяем, установлены ли часы «железа» сервера на UTC (в BIOS).

Важно! Если поддерживаемые пользовательские VIB не включены в ISO инсталлятора ESXi, они будут смигрированы.

И, напоследок, следует сделать резервную копию существующего хранилища VMFS и внимательно ознакомиться с документацией вендора по hardware на предмет изменения порядка загрузки.

Подготовка к обновлению через скрипт

Размещать скрипт обновления следует на чем-то одном из следующего: FTP-сервере, HTTP/HTTPS-сервере, NFS-сервере, USB-устройстве, приводе CD-ROM. Сам скрипт представляет собой текстовый файл («ks.cfg» или пользовательский, но с именем такого вида «ks_*.cfg») с поддерживаемыми командами, командная секция которых содержит опции инсталляции ESXi – она всегда должна стоять первой.

Для определения, который диск включен для инсталляции или апгрейда ESXi, в скрипте должны быть команды: «install»/«upgrade»/«installorupgrade». Команда «install» генерирует дефолтную партицию, включая датастор VMFS, занимающую все доступное пространство после создания всех остальных партиций. Список остальных команд и упомянутых, с расшифровкой:

  • аccepteula/vmaccepteula (требуется);
  • clearpart (опционально) – очищает все существующие партиции на диске (только с «install»). Аргументы:
    • –drives= (удаляет партиции на указанных дисках),
    • –alldrives (удаляет партиции на каждом диске),
    • –ignoredrives= (удаляет партиции на всех дисках, кроме указанных – работает только, если первые две не указывались),
    • –overwritevmfs (позволяет перезаписывать партиции VMFS на указанных дисках, по дефолту не разрешено),
    • –firstdisk= («disk-type1»/«[disk-type2,…]», производится разбитие на партиции по первому доступному диску. Порядок, по умолчанию: локальный, удаленный, USB. Можно изменить, добавив список в аргумент, разделив запятыми его участников),
  • dryrun (опционально) – парсит и проверяет инсталляционный скрипт, саму установку не инициирует;
  • install – указывает на свежую инсталляцию. Аргументы: «-disk=»/«–drive=» (с командами «–disk=diskname», где «diskname» – имя диска или полный путь к нему в файловой системе),

«–firstdisk=

disk-type1,

[ disk-type2,…]» (партиции разбиваются на первом доступном диске – порядок см. выше), «–ignoressd» (исключает твердотельные диски из создания партиций, используется только с «install» и «–firstdisk»), «–overwritevsan» (если ESXi устанавливается на диск из дисковой группы vSAN, диск очищается), «–overwritevmfs» (нуждается в уже существующем VMFS, перезаписывает поверх), «–preservevmfs» (сохраняет существующий VMFS), «–novmfsondisk» (запрещает создавать партиции VMFS на диске, используется только с «–overwritevmfs», и если партиции VMFS уже есть на диске);

  • installorupgrade – аргументы: «–disk=»/«–drive=»,

«–firstdisk=

disk-type1,

[ disk-type2,…]»

«–overwritevsan», «–overwritevmfs» – описания см. выше;

  • keyboard (опционально) – устанавливает тип клавиатуры для системы. Аргумент «keyboardType», доступны следующие типы: Belgian, Brazilian, Croatian, Czechoslovakian, Danish, Estonian, Finnish, French, German, Greek, Icelandic, Italian, Japanese, Latin American, Norwegian, Polish, Portuguese, Russian, Slovenian, Spanish, Swedish, Swiss French, Swiss German, Turkish, Ukrainian, United Kingdom, US Default, US Dvorak;
  • network (опционально) – указывает сетевой адрес для системы. Аргументы: «bootproto=[dhcp|static]» (указывает откуда получать сетевые настройки – из DHCP или устанавливать их вручную), «–device=» (указывает либо МАС сетевой карты, либо имя устройства в формате «vmnicNN», относится к аплинку виртуального свитча), «–ip=» (IP-адрес машины в формате «xxx.xxx.xxx.xxx», нуждается в опции «–bootproto=static»), «–gateway=» (обозначает дефолтный шлюз как IP-адрес, в формате «xxx.xxx.xxx.xxx», используется с опцией «–bootproto=static»), «–nameserver=» (обозначает имя первичного сервера как IP-адрес, используется с опцией «–bootproto=static», пропускаем, если не используем DNS, может принимать два айпишника, например, «–nameserver=”10.126.87.104[,10.126.87.120]”»), «–netmask=» (указывает маску подсети для инсталлируемой системы в формате «xxx.xxx.xxx», используется с опцией «–bootproto=static»), «–hostname=» (указывает имя хоста), «–vlanid=vlanid» (указывает какая система VLAN доступна, значение от 1 до 4096), «–addvmportgroup=(0|1)» (указывает, надо ли добавлять VM Network порт-группу, используемую для ВМ, по дефолту значение «1»);
  • paranoid (опционально) – выводит предупреждающие сообщения, прерывая инсталляцию, если пропустить, сообщения будут сохраняться в логи;
  • part/partition (опционально) – создает дополнительный VMFS-датастор в системе (можно только один на диск, только одна партиция указывается для одного диска и она может быть только партицией VMFS). Аргументы: «datastore name» (указывает, где партиция будет подмонтирована), «-ondisk=»/«–ondrive=» (указывает диск или привод, где будет создана партиция),

«–firstdisk=

disk-type1,

[ disk-type2,…]» (разбивает первый найденный диск);

  • reboot (опционально) – перезагружает машину по окончанию скриптованной инсталляции. Аргумент: «<–noeject>» (CD не вынимается после);
  • rootpw (требуется) – устанавливает пароль рута для системы. Аргументы: «–iscrypted» (зашифрованный), «password» (тело пароля);
  • upgrade – аргументы: «–disk=»/«–drive=» (см. выше),

«–firstdisk=

disk-type1,

[ disk-type2,…]» (см. выше);

  • %include/include (опционально) – указывает другой инсталляционный скрипт для анализа. Аргумент: «filename» (пример – «%include part.cfg»);
  • %pre (опционально) – указывает на скрипт, который должен быть запущен до того, как оценится конфигурация kickstart (можно использовать, чтобы генерировать файлы для включения в kickstart). Аргумент:

«–interpreter

=[python|busybox]» (задает другой скрипт инсталляции для parseSpecifies интерпретатора, по дефолту «busybox»);

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

«–interpreter

=[python|busybox]» (задает интерпретера), «–timeout=secs» (указывает таймаут для работы скрипта, скрипт может не закончить свою работу по его истечению и тогда он остановится силовым методом),

«–ignorefailure

=[true|false]» (если значение «true», инсталляция будет считаться успешной, даже если скрипт «%post» остановится с ошибкой);

  • %firstboot – создает скрипт «init», который запускается только при первой загрузке. На другие последующие скрипты влияния не оказывает. Если таких секций много, они будут запускаться в порядке, в котором расположены в файле kickstart.
Важно! Этот скрипт не запустится, если на ESXi-хосте разрешена безопасная загрузка.

Аргументы:

«–interpreter

=[python|busybox]» (задает интерпретатора, по дефолту – «busybox»).

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

Формат Описание Пример
NAA Идентификатор SCSI INQUIRY naa.6d09466044143600247aee55ca2a6405
EUI Идентификатор SCSI INQUIRY eui.3966623838646463
T10 Идентификатор SCSI INQUIRY t10.SanDisk00Cruzer_Blade000000004C530001171118101244
VML Устаревший идентификатор VMkernel vml.00025261
MPX Идентификатор на основе пути mpx.vmhba0:C0:T0:L0

А также идентификаторам и именам устройств хранилища. Идентификаторы могут быть даны самим хранилищем в формате «naa.xxx»/«eui.xxx»/«t10.xxx», либо же опираться в своем отображении на путь, например, выглядеть так: «mpx.vmhba1:C0:T1:L3». Чтобы вывести имена всех девайсов в vSphere CLI, нужно ввести команду:

esxcli storage core device list

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

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

Теперь рассмотрим подготовку к инсталляции через сетевую загрузку. Если хотим грузиться с сети (PXE-загрузка хоста ESXi с сетевого устройства), хост будет использовать старый BIOS или UEFI, либо же, если поддерживается нативный UEFI HTTP, можно использовать HTTP для загрузки. PXE-загрузка нуждается в специфической сетевой инфраструктуре и машине с PXE-совместимым сетевым адаптером, однако в большинстве случаев все это доступно по умолчанию. Нативный UEFI HTTP использует DHCP и HTTP в процессе загрузки, и здесь нужно, чтобы версия firmware UEFI на хосте включала функцию HTTP-загрузки, а сетевой адаптер поддерживал UEFI-сеть. Этот тип загрузки более быстр и доступен, чем использование TFTP. Если же ESXi-хосты не поддерживают нативный UEFI HTTP, можно использовать iPXE HTTP.

Важно! Сетевая загрузка со старым firmware BIOS возможна исключительно по IPv4. Если же есть возможность работать с UEFI BIOS, без разницы, у нас IPv4 или IPv6. Однако, и это важно, микс этих протоколов не поддерживается.

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

  • С нативным UEFI HTTP. Firmware UEFI должен поддерживать функцию загрузки HTTP, а конфигурация «железа» целевого хоста – поддерживаться версией ESXi, и на нем должен быть сетевой адаптер с UEFI-сетью. Также следует настроить DHCP-сервер с загрузкой UEFI HTTP и использовать родной VLAN, причем NIC должна поддерживать спецификацию VLAN ID; 
  • С iPXE и HTTP. Конфигурация «железа» целевого хоста должна поддерживаться версией ESXi, как и сетевой адаптер с PXE. Также необходим DHCP-сервер, настроенный под загрузку PXE, TFTP-сервер, причем, политики сетевой безопасности должны разрешать трафик TFTP (UDP-порт 69), и нужно использовать родной VLAN, причем NIC поддерживает спецификацию VLAN ID. Если у нас старый BIOS, важно получить версию 3.86 пакета SYSLINUX;
  • С PXE и TFTP. Конфигурация «железа» целевого хоста должна поддерживаться версией ESXi, как и сетевой адаптер с PXE. DHCP-сервер должен быть в состоянии настаивать PXE-загрузку, также имеется в наличии TFTP-сервер, и его трафик разрешают политики безопасности сети (UDP-порт 69). Также нужно использовать родной VLAN, причем NIC поддерживает спецификацию VLAN ID. Если у нас старый BIOS, важно получить версию 3.86 пакета SYSLINUX.

Еще один немаловажный момент, о котором хотелось бы сказать, завершая разговор о подготовке к скриптованной инсталляции обновления ESXi через сетевую загрузку, это настройка DHCP-сервера – мы постоянно упоминали ее, когда говорили о требуемых шагах при разных сценариях исходных данных. По итогу мы должны добиться того, чтобы DHCP-сервер посылал адрес TFTP/HTTP-сервера и имя файла стартового загрузчика на ESXi-хост. Когда целевая машина загружается впервые, она рассылает пакет по сети, запрашивая информацию для своей загрузки, и DHCP-сервер ей отвечает. Он должен распознавать, позволено ли целевой машине загружаться, и расположение двоичного файла начального загрузчика. Для PXE это файл на сервере TFTP, а для UEFI HTTP-загрузки локация – это URL.

Важно! Если в сети уже есть один DHCP-сервер, второй делать нельзя. Иначе будет конфликт получения IP-адресов машинами, либо же произойдет сбой получения правильной загрузочной информации.

Приведем несколько примеров настройки DHCP. Если загрузка использует PXE и TFTP с IPv4:

#

# ISC DHCP server configuration file snippet.  This is not a complete

# configuration file; see the ISC server documentation for details on

# how to configure the DHCP server.

#

allow booting;

allow bootp;

option client-system-arch code 93 = unsigned integer 16;

class “pxeclients” {

   match if substring(option vendor-class-identifier, 0, 9) = “PXEClient”;

   next-server xxx.xxx.xxx.xxx;

   if option client-system-arch = 00:07 or option client-system-arch = 00:09 {

      filename = “mboot.efi”;

   } else {

      filename = “pxelinux.0”;

   }

}

Если загрузка использует PXE и TFTP с IPv6:

#

# ISC DHCPv6 server configuration file snippet.  This is not a complete

# configuration file; see the ISC server documentation for details on

# how to configure the DHCP server.

#

allow booting;

allow bootp;

option dhcp6.bootfile-url code 59 = string;

option dhcp6.bootfile-url “tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/mboot.efi”;

Если загрузка использует iPXE и HTTP с IPv4:

#

# ISC DHCP server configuration file snippet.  This is not a complete

# configuration file; see the ISC server documentation for details on

# how to configure the DHCP server.

#

allow booting;

allow bootp;

option client-system-arch code 93 = unsigned integer 16;

class “pxeclients” {

   match if substring(option vendor-class-identifier, 0, 9) = “PXEClient”;

   next-server xxx.xxx.xxx.xxx;

   if option client-system-arch = 00:07 or option client-system-arch = 00:09 {

      if exists user-class and option user-class = “iPXE” {

         # Instruct iPXE to load mboot.efi as secondary bootloader

         filename = “mboot.efi”;

      } else {

         # Load the snponly.efi configuration of iPXE as initial bootloader

         filename = “snponly.efi”;

      }

   } else {

      if exists user-class and option user-class = “iPXE” {

         # Instruct iPXE to load pxelinux as secondary bootloader

         filename = “pxelinux.0”;

      } else {

         # Load the undionly configuration of iPXE as initial bootloader

         filename = “undionly.kpxe”;

   }

}

Если загрузка использует iPXE и HTTP с IPv6:

#

# ISC DHCPv6 server configuration file snippet.  This is not a complete

# configuration file; see the ISC server documentation for details on

# how to configure the DHCP server.

#

allow booting;

allow bootp;

 

option dhcp6.bootfile-url code 59 = string;

if exists user-class and option user-class = “iPXE” {

   # Instruct iPXE to load mboot.efi as secondary bootloader

   option dhcp6.bootfile-url “tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/mboot.efi”;

} else {

   # Load the snponly.efi configuration of iPXE as initial bootloader

   option dhcp6.bootfile-url “tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/snponly.efi”;

}

Если загрузка использует UEFI HTTP с IPv4:

#

# ISC DHCP server configuration file snippet.  This is not a complete

# configuration file; see the ISC server documentation for details on

# how to configure the DHCP server.

#

allow booting;

allow bootp;

option client-system-arch code 93 = unsigned integer 16;

class “httpclients” {

   match if substring(option vendor-class-identifier, 0, 10) = “HTTPClient”;

   option vendor-class-identifier “HTTPClient”;

 

   if option client-system-arch = 00:10 {

      # x86_64 UEFI HTTP client

      filename = http://www.example.com/esxi/mboot.efi;

   }

}

И если загрузка использует UEFI HTTP с IPv6:

#

# ISC DHCPv6 server configuration file snippet.  This is not a complete

# configuration file; see the ISC server documentation for details on

# how to configure the DHCP server.

#

allow booting;

allow bootp;

 

option dhcp6.bootfile-url code 59 = string;

option dhcp6.user-class code 15 = { integer 16, string };

option dhcp6.vendor-class code 16 = { integer 32, integer 16, string };

 

if option dhcp6.client-arch-type = 00:10 {

      # x86_64 HTTP clients

      option dhcp6.vendor-class 0 10 “HTTPClient”;

      option dhcp6.bootfile-url “http://www.example.com/esxi/mboot.efi”;

}

Подготовка к обновлению с использованием ESXCLI

Выбор этого метода обновления требует понимания VIB (пакетов ПО ESXi от VMware и партнеров с решениями, драйверами, CIM-провайдерами и приложениями, расширяющими платформу – доступных в хранилищах софта, используются для создания и кастомизации образов, апгрейда хостов), профилей образов (определяющих образ ESXi и состоящих из VIB, включающих базовый VIB и, часто, другие VIB, проверяется и определяется с помощью vSphere ESXi Image Builder) и хранилищ софта (коллекций VIB и профилей образов, имеющих иерархическую структуру файлов и папок и доступных через HTTP URL или ZIP-файл).

Важно! Если далее по тексту какие-то команды будут непонятны, либо захочется отступить от предложенной схемы в каких-то целях, следует вбить в командную строку «esxcli –help», чтобы увидеть список поддерживаемых опций.

Каждый VIB характеризуется неизменяемым уровнем приемлемости, определяющим, какие VIB могут быть установлены на хост. Этот уровень применяется индивидуально по каждому VIB использованием команд «esxcli software vib install» и «esxcli software vib update», а также по проинсталлированным с помощью vLCM VIB и к VIB в профилях образов. Уровень приемлемости должен быть настолько высоким, насколько это возможно, например, если уровень хоста – VmwareAccepted, на него можно ставить только VIB VMwareCertified /VMwareAccepted, но не PartnerSupported/CommunitySupported. В принципе, эту политику, при желании, можно изменить, если поменять в клиенте vSphere параметры приемлемости хоста командами «esxcli software acceptance». Уровни приемлемости VIB, требуемые для установки на хостах:

Уровень приемлемости хоста VMwareCertified VIB VMwareAccepted VIB PartnerSupported VIB CommunitySupported VIB
VMwareCertified Х
VMwareAccepted Х Х
PartnerSupported Х Х Х
CommunitySupported Х Х Х Х

Инсталляция VIB наживую не требует перезагрузки хоста, однако может нуждаться в его погружении в режим maintenance. Чего не скажешь о прочих видах инсталляции.

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

Подготовка к обновлению через Auto Deploy

Сервер vSphere Auto Deploy автоматически обновляется при апгрейде соответствующего vCenter Server (начиная с 6.0 он всегда находится на той же управляющей ноде, что и система vCenter Server):

Среди компонентов этой схемы:

  • vSphere Auto Deploy server – сервер vSphere Auto Deploy (предоставляет образа и профили хостов ESXi-хостам),
  • vSphere Auto Deploy rules engine – механизм правил vSphere Auto Deploy (посылает информацию на сервер vSphere Auto Deploy о том, какой профиль образа и какой профиль хоста должен быть предоставлен тому или иному хосту. Эти правила можно настраивать),
  • Image profiles – профили образов (определяют набор VIB для загрузки с ними ESXi-хостов. VMware вместе с партнерами выкладывают профили образов и VIB в публичных хранилищах, которые исследуются vSphere ESXi Image Builder, опираясь на механизм правил, чтобы понять, какой образ следует применить к тому или иному хосту. Кроме того, пользователи могут создавать свои собственные образы, исходя из тех, что в этом хранилище, с целью последующего применения),
  • Host profiles – профили хостов (определяют специфичную для машин конфигурацию, например, сетевые настройки или настройки хранилища. Их можно создавать с помощью специального UI),
  • Host customization – настройка хоста (хранит информацию, предоставляемую пользователем при применении профилей хоста к хосту. Должна содержать IP-адрес или другие соответствующие данные).

Информация о хосте – это выполняемое ПО для запуска на хосте ESXi (профиль образа, созданный vSphere ESXi Image Builder), настраиваемые параметры, определяющие, как хост был сконфигурирован (виртуальные свитчи, настройки драйвера, сгенерированные приватные ключи, параметры загрузки и т.д. – профиль хоста, созданный соответствующим UI), динамическое состояние (состояние в реальном времени, генерируемое запущенным софтом – работающими БД, сгенерированными приватными ключами и пр., например, память хоста, теряемая в процессе перезагрузки), состояние ВМ (тех, что хранятся на хосте и данные по автозапуску машин – только последовательный запуск), пользовательские данные (состояние, опирающееся на пользовательский ввод – IP-адрес, предоставляемый пользователем, когда запускается система, к примеру, словом, все то, что автоматически не включается в профиль хоста, и хранится vCenter Server при первой загрузке).

Подготовка к Auto Deploy заключается в следующем:

  1. Проверяем, подключены ли по сети ESXi-хосты к vCenter Server, и открыты ли все порты (см. раздел «Требования и совместимость» выше);
  2. Убеждаемся, что в среде есть TFTP и DHCP сервера, чтобы была доступна посылка файлов и назначение сетевых адресов хостам, к ним было подключение ESXi-хостов, как и к серверам vSphere Auto Deploy;
  3. Учитываем, что для репозитория vSphere Auto Deploy есть, минимум, 2 ГБ свободного места (четыре профиля образов и немного сверх того – а вообще, рассчитывается, исходя из того, сколько профилей планируется к использованию);
  4. Если хочется использовать VLAN в среде, устанавливаем правильно связь и вручную вносим изменения в интерфейс UEFI/BIOS так, чтобы драйвер firmware при PXE-загрузке хоста помечал фреймы правильными идентификаторами VLAN. Также важно корректно настроить порт-группы ESXi с VLAN ID;
  5. Меняем имя файла «gpxelinux.0» на «snponly64.efi.vmw-hardwired», если у нас UEFI, либо же на «undionly.kpxe.vmw-hardwired» – если BIOS;
  6. Защищаем сеть от любого другого метода PXE-разворота. Несмотря на то, что Auto Deploy передает данные по SSL, аутентификация клиента или сервера Auto Deploy не проверяется при загрузке;
  7. Если хотим управлять vSphere Auto Deploy при помощи PowerCLI cmdlet, следует убедиться, что на Windows-машине проинсталлированы Microsoft .NET Framework 4.5/4.5.x и Windows PowerShell 3.0/4.0;
  8. Устанавливаем удаленный сервер Syslog, настраиваем первый загружаемый хост для его использования и применяем такой профиль хоста ко всем другим целевым хостам. Опционально можно поставить и использовать vSphere Syslog Collector – инструмент vCenter Server, предлагающий унифицированную архитектуру для системного логгирования, разрешающий сохранение логов сети и комбинирующий информацию со множества хостов;
  9. Инсталлируем ESXi Dump Collector, настраиваем первый хост так, чтобы все дампы ядра направлялись на него, и применяем этот профиль ко всем остальным хостам;
  10. Если хосты с BIOS, следует проверить, есть ли у сервера vSphere Auto Deploy IPv4-адрес.

Учтите, что нам еще понадобятся права администратора на сервере DHCP, управляющем сегментом, откуда хотим совершать загрузку.

Также очень полезно будет заранее научиться, как написать правило и назначить его одному или большему кол-ву хостов с vSphere Auto Deploy. Для этого нам понадобятся PowerCLI и все перечисленное выше ПО, а также придется экспортировать профиль хоста, который хотим использовать. Далее в сеансе PowerCLI запускаем «Connect-VIServer», чтобы подключиться к системе vCenter Server, с которой был зарегистрирован и vSphere Auto Deploy:

Connect-VIServer ipv4_or_ipv6_address

Может вернуть предупреждение о сертификации (если речь о продакшене, проблему нужно исправить). Далее через клиент vSphere задаем хост с настройками, которые хотим использовать и с него создаем профиль хоста, а после ищем имя профиля хоста командой «Get-VMhostProfile», передавая хост с которого создавался профиль. Теперь в командной строке определяем правило с конкретными параметрами, например, с диапазоном IP-адресов:

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

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

Add-DeployRule testrule2

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

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

Процедура апгрейда ESXi до версии 7.0U2

В качестве исходных данных будем рассматривать 6.7 версию ESXi (пускай, это будет три хоста с тремя ВМ, с vCenter Server и организованным в нем дата-центром и кластером vSAN). О стартовом обновлении vCenter Server мы рассказывали в статье «Обновляем vCenter Server до версии 7.0U2» – именно с него мы всегда начинаем обновление нашей среды. Предположим, что все требования по совместимости и другим важным вещам, описанные выше в разделе «Требования и совместимость», нами соблюдены, все этапы подготовки к апгрейду также пройдены, значит, настало время непосредственно перейти к процессу приведения хостов к новой версии.

Обновление с помощью vLCM

Итак, как мы уже говорили, у нас на данный момент vSAN-кластер с хостами 6.7-версии:

А обновление vCSA уже успешно завершилось (см. выше ссылку на соответствующий мануал). Грейдить будем сразу кластер, поэтому выделяем его в боковом меню инвентаря клиента vSphere и в верхней панели ищем выпадающий список действий «Menu», где нас интересует пункт «Lifecycle Manager»:

Если на него нажать и в верхнем меню правой рабочей области выбрать «Baselines», мы увидим список предустановленных путей апдейта:

Перед тем, как начать в нем работать, нам нужно загрузить скаченный предварительно образ новой версии гипервизора в секцию «Imported ISOs». Для этого кликаем на «Import ISO» ниже, и в появившемся окне нажимаем на кнопку «Browse», выбираем нужный образ и затем запускаем его загрузку по кнопке «IMPORT»:

Теперь нам нужно создать новый baseline с этим образом. Для этого в «Imported ISOs» ставим на нем флажок и нажимаем на «New Baseline» нашего меню действий:

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

  • «Name and Description». Задаем имя нашего нового baseline и, опционально, его описание, флажок на «Upgrade», после чего жмем на «Next»;
  • «Select ISO». Здесь автоматически подгрузится список с нашим предварительно импортированным образом, ставим на нем флажочек. «Next»:

  • «Summary». Проверяем, все ли верно, и запускаем процесс создания нового baseline кнопкой «Finish»:

Теперь нам нужно прикрепить его к нашему кластеру, для чего возвращаемся в инвентарь и становимся на кластер, затем в верхнем меню жмем на «Updates», в боковом списке рабочей области ищем под «Hosts» «Baselines», а под информационными плитками – нужный блок действий и выпадающее меню «Attach», в котором нужно выбрать пункт «Attach Baseline or Baseline Group»:

В появившемся окошке ищем только что нами созданный baseline, отмечаем его галочкой и нажимаем кнопку «Attach»:

Теперь он появится в списке «Baselines». Здесь же, выбрав его галочкой в списке, жмем в плитке с «Check Compliance» на одноименное действие, чтобы проверить соответствие по всем нашим хостам кластера:

Далее, в плитке правее ищем действие «Pre-check Remediation» и жмем уже на него, чтобы проверить готовность к выполнению:

Появится окно с соответствующей информацией:

Далее, оставив свой выбор на нашем baseline, нажимаем кнопку действий «Remediate»:

Появится окно с лицензионным соглашением, где ставим галочку и кликаем на «OK»:

Затем в непосредственном окне настроек выполнения, проверяем, все ли подлежащие обновлению хосты отмечены галочкой в блоке «n hosts will remediate»:

Здесь ниже есть еще пара очень полезных и интересных блоков (раскрыть их содержимое можно, если нажать по ним на значок «>»). Например, можно задать выполнение не немедленно, а по расписанию, если поставить галочку в «Schedule this remediation to run later» и выбрать дату и время, назвать как-то нашу будущую задачу и опционально – привести ее описание. А еще ниже можно, при желании, поставить галочку в «Quick Boot», выключить «Check host health after update» (не рекомендовано, однако иногда полезно, если знаете, что хелс-чек не пройдет, а обновиться все равно надо, но потом все равно займетесь выявленными проблемами), выбрать «Ignore warnings about hardware errors» (снова-таки, не рекомендовано, но, если предполагаете, что с железом также все не идеально, можно поставить, а затем обязательно решить вопрос). И, наконец, можно запустить параллельное выполнение, если оно необходимо:

Запуск процесса идет по кнопке «Remediate»:

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

Со временем хост, над которым сейчас трудится vLCM, временно перестанет отвечать:

Это нормальный ход вещей, не надо пугаться, процесс все равно завершится.

Когда все хосты вернутся в свое обычное состояние, если по кластеру выберем наш baseline и запустим «Check Compliance», увидим вот такую картину:

Все хосты прошли успешно проверку на соответствие, и в «Summary» по каждому из них мы уже будем наблюдать новую, самую последнюю из доступных версий:

Интерактивное обновление хостов ESXi через внешний носитель

Если все этапы подготовки к интерактивному апгрейду через CD/DVD/USB пройдены успешно, проделываем следующее:

  1. Вставляем внешний носитель и перезагружаем машину;
  2. Устанавливаем в BIOS загружаться с внешнего устройства;
  3. В панели «Select a Disk» выбираем нужный привод (по отмеченному диску можно нажать F1 для получения информации);
  4. Запускаем процесс обновления, если инсталлятор нашел соответствующий файл и VMFS-датастор. Если существующее хранилище VMFS не может быть сохранено, выбирается установка с перезаписью существующего хранилища VMFS, либо же она отменяется, в принципе. Все произойдет, если нажать F11;
  5. По окончанию процесса, вынимаем инсталляционное внешнее устройство и нажимаем Enter для перезагрузки хоста;
  6. Меняем в настройках обратно загрузочное устройство на то, которое использовалось до установки внешнего носителя.

Обновление через скрипт

Запуск скрипта апгрейда производится вводом параметров загрузки в командной строке загрузки инсталлятора ESXi. При этом может потребоваться указать опции для доступа к файлу «kickstart», и с такой целью нужно нажать в загрузчике на Shift+O:

Если используется вариант с загрузкой PXE, параметры можно передать через строку «kernelopts» файла «boot.cfg» (о его синтаксисе и командах мы писали в разделе «Подготовка…» выше). Для указания местоположения скрипта служит параметр «ks=filepath», где «filepath» – это локация файла «kickstart». Поддерживаемые опции загрузки для инсталляции ESXi:

Опция загрузки Описание
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

Теперь в командной строке нужно задать:

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

Примером ввода может служить такое:

ks=http://00.00.00.00/kickstart/ks-osdc-pdp101.cfg nameserver=00.00.0.0 ip=00.00.00.000 netmask=255.255.255.0 gateway=00.00.00.000

С помощью скриптов апгрейд ESXi можно осуществлять как через CD/DVD, так и через USB-привод или же через сетевую загрузку инсталлятора. В первом и втором случае нам нужно просто загрузить инсталлятор через привод и когда появится его окно, нужно тоже просто нажать на Shift+O (как это выглядит – см. предыдущий скриншот), чтобы отредактировать параметры загрузки, как было описано выше (параметр загрузки имеет формат «ks=»). И после всего нажать на Enter.

Альтернативно, рассмотрим процедуру сетевой загрузки инсталлятора для всех трех возможных вариантов:

  • Нативный UEFI HTTP. Копируем файл «efi/boot/bootx64.efi» из образа инсталлятора в директорию на HTTP-сервере и переименовываем файл на «mboot.efi». Далее создаем директорию на HTTP-сервере с именем, повторяющим версию ESXi, содержащегося на нем, например: «http://www.example.com/esxi/ESXi-7.x.x-XXXXXX», и копируем содержимое образа инсталлятора в нее. Изменяем файл «boot.cfg», добавив строку с URL новосозданной директории: «prefix=http://www.example.com/esxi/ESXi-7.x.x-XXXXXX». Если в этом файле строки «kernel=» и «modules=» начинаются с «/», удаляем этот символ, а если в строке «kernelopt=» есть «cdromBoot», удаляем «cdromBoot». Добавляем опцию «kernelopt» в строку после команд ядра в файл «boot.cfg», чтобы указать локацию инсталляционного скрипта (пример – «kernelopt=ks=http://www.example.com/esxi_ksFiles/ks.cfg») и указываем, хотим ли, чтобы все хосты UEFI загружались с одного и того же инсталлятора (опции «Same installer» или «Different installers»).
  • iPXE и HTTP. Для начала нам нужно получить и настроить iPXE, на его загрузочной странице слушаясь инструкций и запустив одну из команд:
    • «make bin/undionly.kpxe» для ESXi-хостов со старым BIOS;
    • «make bin-x86_64-efi/snponly.efi» для ESXi-хостов с UEFI;

И копируем файл «undionly.kpxe» или «snponly.efi» в директорию «/tftpboot» на TFTP-сервер. Если на хосте старый BIOS, достаем и настраиваем PXELINUX (получаем SYSLINUX 3.86, распаковываем и копируем файл «pxelinux.0» в директорию «/tftpboot» TFTP-сервера, создаем конфигурационный файл PXELINUX по такой модели кода:

DEFAULT install

NOHALT 1

LABEL install

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

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

  IPAPPEND 2

Важно! С синтаксисом конфигурационного файла PXELINUX поможет ресурс. В нем обязательно должны быть прописаны пути к файлам «mboot.c32» и «boot.cfg», а его имя может строиться по одной из трех схем: «01-mac_address_of_target_ESXi_host», «default» или IP-адрес целевого хоста в шестнадцатеричной системе исчисления. Сохранять его следует только на TFTP-сервере в «/tftpboot/pxelinux.cfg/».

Сохраняем его в директорию «/tftpboot/pxelinux.cfg» на TFTP-сервере). Если же UEFI, копируем файл «efi/boot/bootx64.efi» из образа инсталлятора в папку «/tftpboot» на TFTP-сервере и переименовываем файл на «mboot.efi». Создаем директорию на HTTP-сервере с таким же именем, что и содержащаяся на нем версия ESXi (например, «/var/www/html/ESXi-7.x.x-XXXXXX»), копируем контент образа инсталлятора в нее и редактируем файл «boot.cfg», добавив строку «prefix=http://XXX.XXX.XXX.XXX/ESXi-7.x.x-XXXXXX». Если в этом файле строки «kernel=» и «modules=» начинаются с «/», удаляем этот символ, а если в строке «kernelopt=» есть «cdromBoot», удаляем «cdromBoot». Добавляем опцию «kernelopt» в строку после команд ядра в файл «boot.cfg», чтобы указать локацию инсталляционного скрипта, используя модель кода: «kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg», где «XXX.XXX.XXX.XXX» – IP-адрес сервера, где находится инсталляционный скрипт, а «esxi_ksFiles» – директория, содержащая файл «ks.cfg», а также указываем, хотим ли, чтобы все UEFI-хосты грузились с одного и того же инсталлятора, или нет;

  • PXE и TFTP. При старом BIOS повторяем сему получения и настройки PXELINUX (см. выше) и сохраняем его в директорию «/tftpboot/pxelinux.cfg» на TFTP-сервере. Если у нас UEFI, копируем файл «efi/boot/bootx64.efi» с образа инсталлятора ESXi в папку «/tftpboot» на TFTP-сервере и переименовываем его на «mboot.efi». Далее создаем поддиректорию на верхнем уровне директории «/tftpboot» (например, «/tftpboot/ESXi-7.x.x-xxxxx») и копируем контент образа инсталлятора ESXi в эту новую директорию. Модифицируем файл «boot.cfg», добавив строку «prefix=ESXi-7.x.x-xxxxxx». Если в этом файле строки «kernel=» и «modules=» начинаются с «/», удаляем этот символ, а если в строке «kernelopt=» есть «cdromBoot», удаляем «cdromBoot». Добавляем опцию «kernelopt» в строку после команд ядра в файл «boot.cfg», чтобы указать локацию инсталляционного скрипта, используя модель кода: «kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg», где «XXX.XXX.XXX» – IP-адрес сервера, где находится инсталляционный скрипт, а «esxi_ksFiles» – директория, содержащая файл «ks.cfg», а также указываем, хотим ли, чтобы все UEFI-хосты грузились с одного и того же инсталлятора, или нет.

Обновление ESXi-хостов через ESXCLI

Перед тем, как приступать непосредственно к процедуре апгрейда по этому методу, осуществляем необходимую подготовку согласно рекомендациям подраздела «Подготовка к обновлению с использованием ESXCLI» выше.

Если запустить команду «esxcli», и после этого сразу нажать на Ctrl+C, появится интерфейс командной строки. Далее следуем следующей процедуре:

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

esxcli –server=<server_name> software sources vib get -v <absolute_path_to_vib>

другая – для проверки VIB на хранилище:

esxcli –server=<server_name> software sources vib get –depot=<depot_name>

и, наконец, третья – для проверки профиля образа в хранилище:

esxcli –server=<server_name> software sources profile get –depot=<depot_name>

Возврат будет представлен значениями параметров «Live-Install-Allowed» и «Live-Remove-Allowed», «false» по первому проинструктирует систему о том, что нужна перезагрузка после инсталляции, а «false» по второму – что нужна перезагрузка после удаления VIB;

  1. vLCM автоматически погружает хосты в режим maintenance, а вот при использовании команд esxcli это придется делать вручную. И вначале нам нужно проверить, не находится ли хост уже в этом режиме командой:

esxcli –server=<server_name> system maintenanceMode get

Если еще нет, выключаем ВМ, работающую на ESXi-хосте (список всех запущенных машин, если не знаете их ID, можно получить командой «esxcli –server=<server_name> vm process list»), одной из следующих команд. Если хотим выключить гостевую операционку, а затем выключить ВМ:

esxcli –server=<server_name> vm process kill –type soft –world-id <vm_ID>

Если хотим просто сразу выключить машину:

esxcli –server=<server_name> vm process kill –type hard –world-id <vm_ID>

Выключить силовым методом, не взирая ни на что:

esxcli –server=<server_name> vm process kill –type force –world-id <vm_ID>

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

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

esxcli –server=<server_name> system maintenanceMode set –enable true

И проверяем, нормально ли он туда ушел:

esxcli –server=<server_name> system maintenanceMode get

  1. Апдейтим хост с помощью VIB из хранилища софта, доступного по URL или из оффлайнового ZIP-хранилища, либо с помощью профилей образов, либо просто загрузкой zip-файла на хранилище.
Важно! Если апдейт ESXi-хоста производится zip bundle из хранилища, поддерживаемого VMware (доступ через сайт или загруженные локально – не важно), работать можно только через профили образов командой «esxcli software profile update –depot=<depot_location> –profile=<profile_name>».
    • В первом случае вначале указываем целевой сервер (с помощью «–server=<server_name>»), после чего нас запросят ввести имя пользователя и пароль. Затем определяем, какие VIB уже проинсталлированы на хосте:

esxcli –server=<server_name> software vib list

Находим VIB, доступные в хранилище, если пользуемся URL, то командой:

esxcli –server=<server_name> software sources vib list –depot=http://<web_server>/<depot_name>

а если из локального хранилища zip-файлов:

esxcli –server=<server_name> software sources vib list –depot=<absolute_path_to_depot_zip_file>

Если нужно указать прокси-сервер, используем опцию «–proxy».

И устанавливаем новые VIB, либо же апдейтим уже установленные. Для апдейта из доступного по URL хранилища командой:

esxcli –server=<server_name> software vib update –depot=http://<web_server>/<depot_name>

для апдейта из локального хранилища zip-файлов:

esxcli –server=<server_name> software vib update –depot=<absolute_path_to_depot_ZIP_file>

и для инсталляции всех VIB из zip-файла на указанном оффлайн-хранилище (включая партнерские):

esxcli –server=<server_name> software vib install –depot <path_to_VMware_vib_ZIP_file>\<VMware_vib_ZIP_file> –depot <path_to_partner_vib_ZIP_file>\<partner_vib_ZIP_file>

Убеждаемся, что VIB успешно проинсталлировались на ESXi-хосте командой:

esxcli –server=<server_name> software vib list

    • Если нужно поработать с профилями образов (результат команд приведет весь контент образа хоста в соответствие с результатом комплексного метода ISO-инсталлятора), указываем целевой сервер командой «–server=<server_name>», после чего на попросят ввести имя пользователя и пароль. Далее определяем, какие VIB уже проинсталлированы на хосте:

esxcli –server=<server_name> software vib list

и какие профили образов доступны на хранилище:

esxcli –server=<server_name> software sources profile list –depot=http://<web_server>/<depot_name>

Можно указать прокси-сервер, используя опцию «–proxy». Затем обновляем существующий профиль образа, чтобы включить VIB или проинсталлировать новые. Если нужно проапдейтить профиль образа из поддерживаемого VMware zip-пакета в хранилище, доступном через сайт или загруженном локально:

esxcli software profile update –depot=<depot_location> –profile=<profile_name>

(такие пакеты называются по типу «VMware-ESXi-<version_number>-<build_number>-depot.zip», а сам профиль может называться либо «ESXi-<version_number>-<build_number>-standard», либо «ESXi-<version_number>-<build_number>-notools», если без VMware Tools).

Если же это обновление профиля образа из доступно по URL хранилища:

esxcli –server=<server_name> software profile update –depot=http://<web_server>/<depot_name> –profile=<profile_name>

а из zip-файла на локальном хранилище целевого сервера:

esxcli –server=<server_name> software profile update –depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>

скопированного на датастор:

esxcli –server=<server_name> software profile update –depot=<datastore_name>/<profile_ZIP_file> –profile=<profile_name>

скопированного локально и примененного к целевому серверу:

esxcli –server=<server_name> software profile update –depot=/<root_dir>/<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>

А если нужно проинсталлировать все новые VIB в указанном профиле, доступном по URL:

esxcli –server=<server_name> software profile install –depot=http://<web_server>/<depot_name> –profile=<profile_name>

То же самое, но из zip-файла, хранимого локально на целевом сервере:

esxcli –server=<server_name> software profile install –depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>

Из zip-файла на целевом сервере, скопированного на датастор:

esxcli –server=<server_name> software profile install –depot=<datastore_name>/<profile_ZIP_file> –profile=<profile_name>

Все новые VIB из zip-файла, скопированного локально и примененного к целевому серверу:

esxcli –server=<server_name> software profile install –depot=/<root_dir>/<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>

И окончательно убедиться, что все нужные VIB установились на хосте:

esxcli –server=<server_name> software vib list

    • При простой загрузке zip-файла на хранилище, инсталлируется он одной командой:

esxcli –server=<server_name> software vib update –depot=/<path_to_vib_ZIP>/<ZIP_file_name>.zip

Важно! Метод ESXCLI осуществляет предпроверку на наличие потенциальных проблем (недостаток памяти, неподдерживаемые устройства и т.д.) только для ESXi 6.7U1 и новее. Тогда как ISO-инсталлятор пре-чек делает всегда и по всему.
Важно! Если хост принадлежит к НА-кластеру и апдейт требует перезагрузки, вначале нужно удалить этот хост из кластера, либо же отключить на время НА, а потом только приступать к любому методу обновления.

Если профиль образа нужно подчистить от уже не актуальных VIB, проделываем вышеуказанные п. 1-2 и удаляем VIB командой: «esxcli –server=<server_name> software vib remove –vibname=<name>». Кстати, их можно удалять сразу комплексом, если в конце написать не просто имя, а «<vendor>:<name>» или «<vendor>:<name>:<version>» (с уточнением по версии), а также только определенные версии одного VIB: «<name>:<version>». Например, вот так:

esxcli –-server myEsxiHost software vib remove –vibname=PatchVendor:patch42:version3

По best practice, перед тем, как накатывать обновления на рабочие хосты, рекомендуется запускать, т. н. Dry Run. Это продемонстрирует, каковы будут результаты апгрейда, однако никаких изменений пока не произведется. Для этого существует опция «–dry-run» – ее просто нужно добавить в конце строки вводимой для инсталляции или апдейта команды, к примеру:

esxcli –server=<server_name> software vib update –dry-run

После этого просто оценивается вывод и, если все хорошо, хосты обновляются уже как положено.

Обновление через Auto Deploy

Чтобы перепредоставить хосты ESXi с помощью Auto Deploy нам нужно:

  1. Заходим в «Home» – «Auto Deploy» под правами администратора и на странице «Auto Deploy» выбираем из выпадающего меню вверху соответствующий vCenter Server;
  2. Кликаем на «Enable Auto Deploy and Image Builder». Если сервис уже активен, проходим на вкладку «Configure» и нажимаем на «Enable Auto Deploy Service»;
  3. На странице «Software Depot» настраиваем TFTP-сервер: заходим на вкладку «Configure» и нажимаем на «Download TFTP Boot Zip», чтобы загрузить конфигурационный файл TFTP, и распаковываем его в директорию, где хранятся файлы этого сервера. Опционально, если нужно использовать прокси-сервер, кликаем на «Add» в панели «Auto Deploy Runtime Summary» и вводим URL прокси-сервера в текстовом поле;
  4. Настраиваем DHCP-сервер, чтобы указывал на наш TFTP-сервер, вначале вписав IP-адрес TFTP-сервера в параметре 66 DHCP («next-server»), а затем имя файла загрузчика «efi.vmw-hardwired» (если UEFI) или «undionly.kpxe.vmw-hardwired» (если BIOS) в параметре 67 DHCP («boot-filename»);
  5. Указываем каждый хост, который хотим предоставить с помощью vSphere Auto Deploy, для сетевой загрузки или PXE-загрузки (опираясь на инструкции производителя);
  6. Опционально, если хотим настроить среду для использования режима Thumbprint, можно применять собственный СА, заместив OpenSSL-сертификат «rbd-ca.crt» и приватный ключ OpenSSL «rbd-ca.key» пользовательскими. Для справки, файлы находятся в «/etc/vmware-rbd/ssl/», и по дефолту vCenter Server использует VMCA.

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

После всех соответствующих настроек перепредоставление хостов осуществляется: простой перезагрузкой/перезагрузкой отдельных хостов, в процессе которой пользователю задаются определенные вопросы/перепредоставлением с другим профилем образа/перепредоставлением с другим профилем хоста. В первом случае нужно просто погрузить хост в режим техобслуживания и перезагрузить его (если он – часть DRS-кластера, машины сами смигрируют на соответствующие хосты при погружении в maintenance, а если нет – придется самостоятельно мигрировать все ВМ на другие хосты и потом каждый хост погружать в режим техобслуживания).

Если же хочется перепредоставить хост с новым профилем образа, можно использовать сеанс PowerCLI, изменив правило для хоста и выполнив тест, после которого нужно будет предпринять операцию по исправлению соответствия. В случае, когда нужные VIB поддерживают live-апдейт, можно применить команду «esxcli software vib», но, до этого обязательно нужно обновить правило, установленное для этого профиля образа, чтобы оно включало новые VIB. Также при тестировании стоит помнить, что профиль образа можно применить к отдельному хосту, используя cmdlet «Apply-EsxImageProfile» и перезагрузив хост, чтобы изменения вступили в силу. Правда, при этом лишь проапдейтятся ассоциации между хостов и профилем образа, однако сами VIB не установятся. Если все это неинтересно, можно просто сделать следующее:

  1. В командной строке PowerShell запускаем cmdlet «Connect-VIServer» для подключения к системе vCenter Server, с которой зарегистрирован vSphere Auto Deploy:

Connect-VIServer ipv4_или_ipv6_адрес

Вернется предупреждение о сертификате. В производственной среде, важно сделать все, чтобы больше оно не возникало;

  1. Определяем местонахождение публичного хранилища софта с нужным нам профилем образа, либо же задаем пользовательский профиль образа с помощью «vSphere ESXi Image Builder»;
  2. Запускаем «Add-EsxSoftwareDepot», чтобы добавить это хранилище к сеансу PowerCLI. Если это удаленное хранилище, команда выглядит так:

Аdd-EsxSoftwareDepot depot_url

А если zip-файл (предварительно нужно загрузить или создать подмонтированную локальную точку к машине PowerCLI), то так:

Add-EsxSoftwareDepot C:\file_path\my_offline_depot.zip

  1. Запускаем «Get-EsxImageProfile», чтобы вывести список профилей образов и решить, который будем использовать;
  2. Запускаем «Copy-DeployRule» и указываем параметр «ReplaceItem», чтобы изменить правило. В результате текущий профиль образа сменится новым:

Copy-DeployRule myrule -ReplaceItem my_new_imageprofile

где «my_new_imageprofile» – новый профиль, а «myrule» – правило, которое будет применять новый профиль образа к хостам (старая версия правила будет переименована и скрыта);

  1. Тестируем соответствие правила для каждого хоста, вначале проверив доступ к самому хосту:

Get-VMHost -Name ESXi_hostname

а затем запустив и сам тест:

$tr = Test-DeployRuleSetCompliance ESXi_hostname

Проверить разницу между содержимым набора правил и конфигурацией хоста можно командой «$tr.itemlist». Система вернет таблицу текущих и ожидаемых объектов, после чего нужно запустить исправление хоста, чтобы в следующий раз при первой загрузке хоста к нему применились эти правила:

Repair-DeployRuleSetCompliance $tr

  1. Окончательно перезагружаем хост с новым профилем образа.

Операции пост-апгрейда

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

  1. Тестируем систему любым предпочитаемым методом (в первую очередь, правильное переподключение к управляющему vCenter Server – выбираем наш хост в инвентаре vCenter Server, кликаем по нему правой кнопкой мыши и в выпадающем меню выбираем «Connect»);
  2. Применяем лицензии хоста;
  3. При необходимости настраиваем сервер syslog для удаленного сбора логов, чтобы их файлам хватало места. Этот шаг просто жизненно необходим, если у вас весьма ограниченное пространство локального хранилища для хоста. Кстати, инструмент vSphere Syslog Collector включен как одна из служб, еще начиная с версии 6.0 vCenter Server.

Если обновление происходит в рамках одной мажорной версии (с 7.0, к примеру, на 7.0U2), замещать существующую лицензию не требуется. Однако, если ситуация, как в нашем примере – с версией 6.7, сделать это придется. В принципе, срочности в этой операции никакой нет – автоматически включается 60-дневный триал, на протяжении которого у нас явно появится время заполучить и применить новую лицензию под «семерку». Делается это элементарно: получаем лицензию от My VMware и используем функционал управления лицензиями в клиенте vSphere, либо же, в случае предпочтения методов скриптования апгрейда, ключ просто вписывается в файл «kickstart (ks)». Кстати, забыть о необходимости что-то сделать с лицензией vSphere Client нам попросту не даст – постоянно будет висеть весьма настойчивое предупреждение, в котором просто стоит нажать на кнопку «Manage your Licenses», чтобы инициировать процедуру замены:

После описанных обязательных акций пост-инсталляции, если нужно, можно проверить, как перенеслись все используемые сторонние пользовательские VIB (драйвера, агенты управления и т. д.), а также как произошла перенумерация устройств хоста sdX (при необходимости, обновляем все скрипты, ссылающиеся на устройства sdX). И, наконец, если есть необходимость, апгрейдим все ВМ на хосте, используя пошаговый визард клиента vSphere, либо же vLCM, а также с помощью последнего – версию VMware Tools.

В принципе, это все, о чем хотелось поговорить в отношении обновления гипервизора ESXi до версии 7.0U2. Если в процессе возникнут какие-то проблемы, изучайте логи апдейта, обращайтесь к нашему материалу по траблшутингу этого продукта «Возможные ошибки в VMware ESXi 7.0 Update 2», или же напрямую адресуйте свои вопросы в саппорт вендора, а также сертифицированным консультантам области. Последние два совета актуальны и в том случае, если хотите освоить какой-то экзотический функционал.