Рубрики
VMware: Инсталляции обновлений

Обновление VMware vSphere до версии 8.0

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

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

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

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

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

Важно! Процесс обновления ESXi блокирует VIB, которые не имеют контрольной суммы SHA256 в своих метаданных (VIB для ESXi, выпущенных ранее, чем 6.7). Такие VIB предварительно должны заместить теми, что касаются более свежих версий.

vSphere 8.0 уже окончательно не совместима с VMware NSX for vSphere (NSX-V). Если у вас именно такой вариант сетевой виртуализации, стоит рассмотреть вариант миграции на NSX-Т, либо придется оставаться на старой версии vSphere.

Таблицу совместимости с другими продуктами VMware мы приводили в подразделе «Требования и совместимость» материала «Инсталляция vSphere 8.0 с нуля». А вот с какой на какую версию можно апгрейдить, собственно, компоненты платформы приведем в следующем подразделе. В разрезе всех прочих вопросов совместимости (аппаратная часть, драйверы, ОС, KMS, валидированные решения партнеров и много чего еще) можно обращаться к такому полезному инструменту, как VMware Compatibility Guide.

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

Чтобы узнать, с каких версий ESXi и vCenter можно добраться к самой свежей в один шаг, стоит воспользоваться вкладкой «Upgrade Path» в очень удобном инструменте VMware Interoperability Matrix. По vCenter Server эта матрица выглядит следующим образом (специально привели только с 6-й мажорной, ведь все, что является более древним, сейчас в обиходе встретить довольно сложно):

А по ESXi так:

То есть, как мы видим, обновляться напрямую до «восьмерки» можно только с 6.7 или 7-х версий. При этом обновленный vCenter Server 8.0 сможет управлять хостами ESXi версий 6.7+.

Замечание. Прямой апгрейд с 6.5 на 8.0 хостов ESXi не поддерживается, по причине наличия у первых VMKAPI версии 2.4, а в «восьмерке» это было убрано вообще. Вначале придется обновить хосты до 6.7 таким образом, чтобы у них не было VIB, которые зависят от VMKAPI 2.4. Подробнее в КБ.

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

Замечание. Начиная с 8-й версии, vSphere перестала поддерживать CPU з маркировкой «End of Support» и «End of Life», чьи модели приведены в этом КБ.

Важно! Если хост имеет устройство, поддерживаемое драйвером nmlx4_en, либо устройство было удалено в драйвере lpfc, при попытке обновиться можно утратить доступ к хранилищу или датасторам, к сети или предыдущие конфигурации на хосте. Это невосстановимые проблемы. Чтобы их избежать, до апгрейда следует заместить соответствующие устройства. См. КБ с полным перечнем более не поддерживаемых устройств.

Максимальный ресурсный охват ВМ, а также работа с некоторыми технологиями (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.

В целом, все требования к аппаратной части, хранилищу, сети, уровню системного хранилища, ОС и бразуера изложены в недавней нашей статье «Инсталляция vSphere 8.0 с нуля», поэтому сейчас повторяться, считаем, неуместно. Все это пока еще актуально, а если нас постигнут какие-то изменения в будущем, обязательно выпустим новость с подробностями при необходимости. Единственное что, напомним, что обязательно нужно убедиться в наличии открытого порта 22 на vCenter Server appliance, который и должны обновлять, а на хосте-источнике ESXi, который содержит наш appliance старой версии, открыт порт 443.

Подготовка к обновлению vSphere

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

Подготовка к обновлению vCenter Server

Важно! Перед обновлением нескольких vCenter в Enhanced Link Mode (ELM) по best practice считается сделать параллельные снэпшоты всех выключенных vCenter Server и Platform Services Controller в домене Single Sign-On, чтобы предотвратить проблемы с синхронизацией репликации.

Первое, что мы должны сделать, это загрузить новый образ vCenter Server Appliance. Сейчас актуальной является версия 8.0.0В – билд 21216066:

И подмонтировать его к физическому серверу, с которого выполняется апгрейд, или к ВМ в сети. (Как это сделать подробно описывалось в подразделе «Подготовка к развертыванию vCenter Server» материала «Инсталляция vSphere 8.0 с нуля»).

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

Вообще, существует всего два метода апгрейда нашего vCenter Server:

  • Через GUI-инсталлятор,
  • CLI-метод.

Подготовка к обоим имеет свои особенности. Рассмотрим их по очереди. Но сперва подготовим целевой хост ESXi, если его версия древнее 6.7.

Подготовка хостов к апгрейду vCenter Server

Если ваши целевые хосты древнее версии 6.7, в случае обновления именно на них, а не на инстансе vCenter Server, прежде всего необходимо проапгрейдить их, минимум, до версии 6.7. Как это сделать для «семерки», можно почитать в этом нашем материале.

Если ваши целевые хосты не старше 6.7 версии, перед тем, как приступить к обновлению нашего vCenter Server, обязательно следует убедиться, что они не в режиме техобслуживания или в локдауне, и к тому же что они не являются частью автоматизированных DRS-кластеров (в последнем случае следует зайти в настройки этих хостов и поменять их Automation Level на Manual или Partially Automated, иначе прямо в процессе обновления они могут внезапно перезагрузиться).

Подготовка к обновлению vCenter Server через GUI

Этапы подготовки через GUI включают в себя и подготовку хостов, являющуюся общей и для этого метода, и для CLI. Насчет остального обязательно нужно приступить к бэкапированию силами графического интерфейса и также очень желательно заранее выписать всю необходимую в процессе информацию.

Бэкапирование vCenter Server

В отношении vCenter Server известно несколько методов бэкапирования и восстановления ради защиты данных, в том числе и при операциях обновления версии аppliance, с возможностью безопасного шифрования:

  • Бэкап на основе файлов (по расписанию – его мы, вероятно, рассмотрим в будущей статье об администрировании vSphere0; через vCenter Server Appliance Management Interface; через GUI-инсталлятор appliance – как неотъемлемая часть процесса апгрейда и будущая возможность восстановления с бэкапа);
  • Бэкап на основе образов (с помощью vSphere Storage API — Data Protection с использованием стороннего продукта бэкапирования, процесс зависит от вендора продукта, поэтому описывать его здесь нет смысла).

В GUI управления нашим appliance vCenter Server (vCenter Server Appliance Management Interface) в боковом меню есть специальный пункт Backup, зайдя в который увидим посредине экрана кнопку BACKUP NOW, после нажатия которой попадаем в окошко, где нужно будет указать локацию сохранения бэкапа (используем синтаксис «protocol:<server-address<:port-number>/folder/subfolder»), ввести данные учетной записи для root, и поставить галочку в блоке, который указывает, какие именно данные хотим сохранить: статистику, события и задачи, или инвентарь и конфигурацию:

Когда нажмем START, процесс начнется. Заметьте, что бэкап не сохраняется на vCenter Server Appliance.

Если в процессе обновления у нас что-то пойдет не так, мы всегда сможем вернуться к отправной точке, воспользовавшись опцией приветственного окна инсталлятора нашего appliance vCenter Server – его четвертым блоком – Restore:

Сразу, забегая наперед, скажем, что если у нас уже есть сохраненный при помощи vCenter Server Appliance Management Interface бэкап, опция Restore дарит нам своеобразное комбо: развернется новый appliance и при этом он сразу заполнится данными, которые сохранились в созданном нами ранее бэкапе.

Подготовка необходимой информации для обновления vCenter Server через GUI

В процессе апгрейда vCenter Server до версии 8.0 администратору, идя по пунктам наших стадий инсталлятора GUI, нужно будет делать множество выборов и вводов, следовательно, разумно будет заранее выписать себе все необходимые данные. А именно:

  • FQDN или IP-адрес appliance-источника, который обновляем;
  • HTTPS-порт appliance-источника (дефолтный — 443);
  • Данные учетной записи администратора vCenter Single Sign-On appliance-источника (дефолтный логин — administrator@vsphere.local);
  • пароль пользователя root для appliance-источника;
  • FQDN или IP-адрес сервера-источника, на котором размещен обновляемый appliance;
  • HTTPS-порт сервера-источника (дефолтный — 443);
  • Данные учетной записи (если сервер-источник является ESXi-хостом, пользуемся root, если сервер-источник – это инстанс vCenter Server: «user_name@your_domain_name»);
  • FQDN или IP-адрес целевого сервера, на котором будем развертывать новый appliance (может быть ESXi-хостом или инстансом vCenter Server);
  • HTTPS-порт целевого сервера (дефолтный — 443);
  • данные учетной записи пользователя с привилегиями администратора (если целевой сервер является ESXi-хостом, пользуемся root, если целевой сервер – это инстанс vCenter Server: «user_name@your_domain_name»);
  • дата-центр из инвентаря vCenter Server, на котором хотим развернуть новый appliance, если развертываемся на инстансе vCenter Server (опционально можно предоставить папку);
  • ESXi-хост или DRS-кластер из инвентаря дата-центра, на котором хотим развернуть новый appliance, если развертываемся на инстансе vCenter Server;
  • имя ВМ для нового appliance (не должно содержать «%», «\», «/», менее 80 знаков в длину, дефолтное – «VMware vCenter Server Appliance»);
  • пароль root для ОС appliance (только ASCII-символы без пробелов, минимум 8 знаков, максимум – 20, как минимум одну большую, одну маленькую буквы, одну цифру, один спецсимвол (например, $#@.!));
  • выбрать размер развертывания нового appliance (Tiny/Small/Medium/Large/X-Large – соображения насчет выбора приведены в подразделе «Требования к «железу, сети и хранилищу» статьи «Инсталляция vSphere 0 с нуля»);
  • выбрать размер хранилища для нового appliance (Default/Large/X-Large, соображения насчет выбора см. В вышеупомянутом подразделе, дефолтный — Default);
  • имя датастора, на котором хотим хранить конфигурационный файлы и виртуальные диски нового appliance;
  • имя сети, к которой должен подсоединиться новый appliance (должно быть доступно с сервера-источника и с физической клиентской машины, на которой выполняется развертывание);
  • выбрать ІР-версию временного адреса appliance (IPv4/IPv6, по дефолту — IPv4);
  • выбрать ІР-назначение для временного адреса appliance (static/DHCP, по дефолтом — static);
  • FQDN или IP-адрес временного имени системы (если static) или FQDN (если DHCP);
  • временный IP-адрес (если static);
  • маска подсети (для IPv4, если static) или префикс сети (для IPv6, число от 0 до 128);
  • дефолтный шлюз (если static);
  • DNS-серверы через запятую.

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

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

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

В статье «Инсталляция vSphere 8.0 с нуля» мы подробно касались в подразделе «Подготовка конфигурационного JSON-файла для CLI-методу развертывания appliance vCenter Server» правил синтаксиса (все замечания актуальны!), команд помощи, расшифровки конфигурационных параметров и аргументов (не все – про отличия далее), а также приводили перечень предоставленных вендором шаблонов для различных сценариев развертывания/обновления под CLI-методику. Но между greenfield-инсталляцией и апгрейдом, конечно же, есть некоторые отличия в конфигурировании соответствующего JSON-файла, которые сейчас и разберем.

Во-первых, в подкаталоге «templates» директории «vcsa-cli-installer» для обновления есть специальные шаблоны в папке «upgrade» — именно с ними будем работать, а не с «install», как в прошлый раз. Путь к ним будет иметь вид «vcsa-cli-installer\templates\upgrade\vcsa\6.7» для версии 6.7 источника или «vcsa-cli-installer\templates\upgrade\vcsa\7.0» для «семерки».

Замечание. Если речь о 6.7, то в папке будет четыре файла («embedded_vCSA_on_ESXi.json», «embedded_vCSA_on_VC.json», «vCSA_on_ESXi.json» и «vCSA_on_VC.json»), а о 7.0 – только два («embedded_vCSA_on_ESXi.json» и «embedded_vCSA_on_VC.json»).

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

Секция Подсекция Описание Параметр Тип Описание
source_vc (описание существующего appliance, который хотим обновлять) managing_esxi_or_vc Описание источника (ESXi-хост/инстанс vCenter Server appliance) hostname string IP-адрес или FQDN источника ESXi или vCenter Server, где размещен обновляемый appliance
username string Имя пользователя с привилегиями администратора на источнике ESXi-хосте (root)
password string Его пароль
port integer HTTPS-порт обратной прокси источника ESXi-хоста (дефолтный — 443). Используется только, когда источник ESXi-хост имеет пользовательский HTTPS-порт обратной прокси 
vc_vcsa Описание appliance источника hostname string IP-адрес или FQDN appliance-источника
username string Имя пользователя-администратора vCenter Single Sign-On на appliance-источнике (administrator@ your_domain_name)
password string Его пароль
root_password string Пароль пользователя root для ОС на appliance-источнике
export_dir string Директория для экспорта конфигурации источника и  данных
source_vum run_migration_assistant Опционально, если источник vCenter Server appliance подключен к інстансу VMware Update Manager, который запущен на Windows ВМ. Используется только,. Если хотим, чтобы Migration Assistant на источнике инстанса VMware Update Manager запускался автоматически esxi_hostname string IP-адрес или FQDN ESXi-хоста, что содержит инстанс VMware Update Manager источника
esxi_username string Имя пользователя с привилегиями администратора на ESXi-хосте (root)
esxi_password string Его пароль
esxi_port string HTTPS-порт обратной прокси ESXi-хоста (дефолтный — 443). Используется только, когда ESXi-хост имеет пользовательский HTTPS-порт обратной прокси 
vum_hostname string IP-адрес или FQDN Windows ВМ, где запущен инстанс источника VMware Update Manager
vum_os_username string Имя администратора Windows ВМ, где запущен инстанс источника VMware Update Manager
vum_os_password string Его пароль
export_dir string Директория для экспорта конфигурации источника и данных

Подготовка к апгрейду vCenter Server в НА-средах

Как мы знаем, реализация концепции НА (High Availability) имеет в виду, что у нас есть три appliance vCenter Server (Active, Passive и Witness ноды, где Active-нода сконфигурирована как нода vCenter HA, и принадлежит кластеру vCenter HA, а все диски vCenter HA в одном и том же самом датасторе). Чтобы подготовиться к обновлению в этом случае, необходимо:

  • Убедиться, что vCenter HA-кластер в дееспособном состоянии (healthy state) и во включенном режиме (enabled mode);
  • Размещение целевого vCenter Server совпадает с размещением источника vCenter Server.

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

Подготовка к обновлению ESXi-хостов

С учетом того, что одной из главных «фишек» современной vSphere стала поддержка Data Processing Unit (DPU), сразу заметим, что на DPU ESXi можно обновляться только vSphere Lifecycle Manager или ESXCLI. Интерактивный метод и скриптованный не поддерживаются. Но сегодня мы все равно рассмотрим все, ведь не все готовы начать работать с DPU.

Первое, что мы должны сделать, это загрузить новый образ ESXi. Сейчас актуальной является версия 8.0В – билд 21203435:

В принципе, для ESXi-хостов VMware предлагает широкий спектр вариантов апгрейда:

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

Замечание. По best practice, первые три метода (DCUI, скриптованный и ESXCLI) лучше всего применять к standalone-хостам, в миниатюрных демонстративных средах – просто чтобы посмотреть на новый функционал свежей версии, для апгрейда первого(ых) хостов, на которых должен обновляться наш vCenter Server, в случае, когда целью являются именно они, а не другой инстанс vCenter Server. Метод через встроенный в vCenter Server сервис vSphere Lifecycle Manager, по сравнению с ними, считается, самым безопасным и самым совершенным с точки зрения выполнения им всех необходимых пречеков в отношении конфигурации, совместимости, соблюдения всех нужных требований.

Замечание. Метод vSphere Auto Deploy применяется к хостам ESXi, развернутых тоже через vSphere Auto Deploy, — это, так называемый, процесс перепредоставления хостов. Безусловно, уже с новой версией ESXi в профиле образа. Но сегодня об этом методе говорить не видим смысла, ведь он, включительно с кастомизацией образов с помощью vSphere ESXi Image Builder, работой с профилями образов и правилами, самым подробным образом рассматривался в подразделах «Кастомизация инсталляций при помощи vSphere ESXi Image Builder», «Подготовка к инсталляции ESXi  через vSphere Auto Deploy» и «Инсталляция хостов через vSphere Auto Deploy» статьи «Инсталляция vSphere 8.0 с нуля».

Подготовка к каждому из них имеет свои особенности – немного погодя рассмотрим их все, по очереди. За исключением интерактивного метода обновления ESXi-хостов – она полностью идентична тому, что мы писали в разделе «Подготовка к развертыванию vSphere 8.0» статьи «Инсталляция vSphere 8.0 с нуля». Но перед этим поговорим обо всех общих для всех методов этапах подготовки, которые состоят в бэкапировании хоста – если обновление даст сбой, можно будет его восстановить, — а также в проверке, на всех ли  хостах, которые готовятся к апгрейду, синхронизированы часы, и в миграции или выключении всех ВМ хоста.

Замечание. В отношении вариативности опций загрузки инсталлятора ESXi-хостов, как их выбирать, менять и настраивать мы в подробностях писали в подразделе «Подготовка к инсталляции хостов ESXi» и «Начальные настройки ESXi» статьи «Инсталляция vSphere 8.0 с нуля».

Важно! Если хост имеет поддерживаемые новой версией ESXi пользовательские проинсталлированные vSphere Installation Bundles (VIB), например, сторонние драйверы или management-агенты, они мигрируются, за исключением случаев, когда они включены в ISO инсталлятора. Если при этом возникнет конфликт, апгрейд прервется соответствующим сообщением об ошибке, и тогда можно:

  • Либо удалить конфликтный VIB с хоста при помощи esxcli-команд и перезапустить обновление;
  • Либо использовать vSphere ESXi Image Builder CLI, чтобы создать пользовательский образ ISO-инсталлятора, который разрешит этот конфликт приемлемым для вас образом (ссылка на раздел с vSphere ESXi Image Builder приводилась немного выше).

Бэкапирование хостов ESXi

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

  • Номер билда назначения хоста отвечает билду, с которого было взято резервную копию;
  • UUID хоста остался тем же самым.

Бэкап хоста можно создать тремя способами:

  • через командную строку ESXi,
  • vSphere CLI,
  • vSphere PowerCLI.
Создание резервной копии конфигурации хоста при помощи командной строки ESXi

Для создания бэкапа ESXi-хоста:

  1. Синхронизируем измененную конфигурацию с постоянным хранилищем:

# vim-cmd hostsvc/firmware/sync_config

  1. Бэкапируем конфигурационные данные:

# vim-cmd hostsvc/firmware/backup_config

Команда вернет URL («http://<host_fqdn_orIP>/downloads/123456/configBundle-xx.xx.xx.xx.tgz»), с которого можно загрузить файл бэкапа;

  1. Из веб-браузера проходим на этот URL:

Файл бэкапа будет в директории «/downloads» (дефолтной для браузера или указанной другой) и называться «configBundle-HostFQDN.tgz».

Чтобы восстановиться с этой копии, во-первых, нужно ее переименовать в «configBundle.tgz», а, во-вторых:

  1. Погрузить хост в режим техобслуживания командой:cmd hostsvc/maintenance_mode_enter
  2. Скопировать полученный нами файл на ESXi-хост или доступный датастор;
  3. Перезагрузить хост;
  4. Переместить наш файл в «/tmp/configBundle.tgz»;
  5. Запустить команду:

cmd hostsvc/firmware/restore_config 0

Важно! Если есть нужда силовым методом перезаписать расхождение UUID, в конце команды ставим «1».

Создание резервной копии конфигурации хоста при помощи vSphere CLI

Для создания бекапа конфигурационных данных хоста ESXi введите команду:

# vicfg-cfgbackup —server=ESXi_host_IP_address —username=root -s output_file_name

Чтобы восстановиться с этой резервной копии:

  1. Погружаем наш хост в режим maintenance;
  2. Перезагружаем хост;
  3. Заходим на сервер, где проинсталлировано vCLI;
  4. Запускаем скрипт «vicfg-cfgbackup» с отметкой «-1», чтобы загрузить конфигурацию хоста с указанного файла бекапа:

# vicfg-cfgbackup —server=ESXi_host_IP_address —username=root -l backup_file

Создание резервной копии конфигурации хоста при помощи vSphere PowerCLI

Чтобы сделать бэкап хоста, вводим команду:

# Get-VMHostFirmware -VMHost ESXi_host_IP_address -BackupConfiguration -DestinationPath output_directory

где «-DestinationPath» — это директория, где должен сохраниться наш файл.

Она может выглядеть, например, вот так:

# Get-VMHostFirmware -VMHost 10.0.0.1 -BackupConfiguration -DestinationPath C:\Downloads

Чтобы восстановить хост из этой резервной копии:

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

# Set-VMHost -VMHost ESXi_host_IP_address -State ‘Maintenance’

  1. Перезагружаем хост:

# Restart-VMHost -VMHost ESXi_host_IP_address -Confirm:$false

  1. Восстанавливаем конфигурацию командой:

# Set-VMHostFirmware -VMHost ESXi_host_IP_address -Restore -SourcePath backup_file -HostUser username -HostPassword password

Например, последняя команда может выглядеть так:

# Set-VMHostFirmware -VMHost 10.0.0.1 -Restore -SourcePath c:\bundleToRestore.tgz -HostUser root -HostPassword exampleRootPassword

Миграция или выключение машин хоста

Миграция ВМ – тема довольно масштабная и разнообразная, поэтому во всех нюансах, включительно с vSphere vMotion,  коснемся ее в запланированной статье об администрировании vSphere 8.0. Сейчас же лишь кратко вспомним один наипростейший и самый распространенный способ – через клиент vSphere. С его помощью можно делать как холодную миграцию (для выключенных машин или переведенных в статус suspend), так и горячую (для включенных). Для этого встав на нужную машину в инвентаре просто выбираем требуемое действие:

Специальный визард нам предложит ряд миграционных опций, в частности, по перемещению чего-то одного:

  • вычислительных ресурсов,
  • хранилища,
  • вычислительных ресурсов и хранилища,
  • перемещение между инстансами vCenter Server, не из одного SSO-домена.

Далее просто движемся показанным на скриншоте помощником и проделываем все необходимые вводы и выборы.

Выключение ВМ производится в тех же самых Actions: кликаем на действие Power, и если машина имеет статус Power On, выбираем Power Off (если она и так выключена, конечно же, ничего не трогаем).

Важно! В некоторых случаях предпочтительней, чем полностью выключить машину, оставить ее подсоединенной к сети (как бы поставить на паузу). Этот статус называется «Suspend» в секции действий Power.

Для удобства, все статусы (там еще есть такие действия, как перезапустить и жестко выключить – полезно, когда кнопка Power Off не отвечает) обозначены пиктограммками:

Подготовка к скриптованному методу обновления ESXi-хостов

Этот метод полезен лишь в случае, когда нам необходимо обновить много хостов с одинаковой конфигурацией. Так же, как и по процедуре инсталляции, описанной в много раз уже упомянутом нашем предыдущем материале «Подготовка к скриптованной инсталляции ESXi-хостов», нам придется сделать определенные изменения в инсталляционном скрипте «ks.cfg» — все приведенные там команды и рекомендации актуальны и для нашего случая. Единственное что, команду «install» везде заменяем на «upgrade».

Подготовка к обновлению ESXi-хостов при помощи ESXCLI

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

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

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

  • Вывести списком информацию по всем VIB:

esxcli —server=<server_name> software sources vib list —depot=<depot_URL>

  • Вывести информацию по конкретному VIB:

esxcli —server=<server_name> software sources vib list —viburl=<vib_URL>

  • Вывести списком информацию по всем профилям образов:

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

Изменение уровня принятия VIB (если он ниже уровня принятия хоста):

esxcli —server=<server_name> software acceptance set —level=<acceptance_level>

Замечание. Уровень принятия может приобретать значения: «VMwareCertified», «VMwareAccepted», «PartnerSupported» или «CommunitySupported».

Замечание. Можно применять опцию «—force» для команд «esxcli software vib» или «esxcli software profile», чтобы силовым методом добавить VIB или профиль образа с более низким уровнем принятия, чем у хоста. Продемонстрируется предупреждение, и далее, в таком случае, они будут появляться все время в процессе любых операций на хосте, так как он утратит свое соответствие.

Далее должны отметить, что VIB, которые имеют способность инсталлироваться на живую, не нуждаются в перезагрузке хоста – лишь его погружения в режим техобслуживания. Другие же в процессе обновления хоста обязательно прибегнут к перезагрузке. Когда мы выше запрашивали информацию по VIB, в выводе там, обычно, присутствует параметр «Live-Install-Allowed», значение которого указано как «true» или «false». Вот если первый вариант, в рамках подготовки нам понадобится умение погружать хост в режим maintenance.

Замечание. Невозможно обновлять хосты без перезагрузки, если хост принадлежит vSphere HA кластеру. Сначала следует деактивировать НА на кластере или же вывести нуждающийся в апгрейде хост из него.

Выведение хоста в режим maintenance при помощи ESXCLI

Сначала проверяем, не в режиме ли техобслуживания хост уже:

esxcli —server=<server_name> system maintenanceMode get

Далее:

  1. Получаем список всех запущенных на хосте ВМ, чтобы узнать их World ID:

esxcli —server=<server_name> vm process list

  1. Выключаем каждую ВМ, запущенную на этом хосте. Возможны несколько вариантов:
    • Выключить гостевую ОС, после чего выключить ВМ:

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>

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

  1. Помещаем хост в режим техобслуживания:

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

  1. Проверяем, действительно ли он ушел в режим maintenance:

esxcli —server=<server_name> system maintenanceMode get

Подготовка к обновлению ESXi-хостов через vSphere Lifecycle Manager

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

Преимущества использования именно vSphere Lifecycle Manager:

  • Перед попыткой vSphere Lifecycle Manager погрузить хосты в режим maintenance им проводятся некоторые проверки, чтобы убедиться, что они способны это сделать, и клиент vSphere сообщит о любых конфигурационных проблемах, которые могут тому помешать;
  • Если кластер настроен для vSphere DRS, vSphere Lifecycle Manager с последним интегрируется автоматически. Когда vSphere Lifecycle Manager помещает хосты в режим техобслуживания, vSphere DRS эвакуирует каждый хост до момента патчирования;
  • После обновления и перезагрузки хоста vSphere Lifecycle Manager выведет его из режима техобслуживания, а vSphere DRS смигрирует некоторые ВМ назад на хост.

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

Настройка хранилища образов и загрузка новых версий в vSphere Lifecycle Manager

Если мы зайдем в vSphere Lifecycle Manager, увидим несколько вкладок, первая из которых — Image Depot – покажет весь доступный софт, которым может пользоваться vSphere Lifecycle Manager:

Это хранилище образов ESXi размещено в системе vCenter, а также аддонов вендора и сторонних компонентов. Как показано на скриншоте, там приведена версия ESXi с датой релиза для облегчения ориентации. Чтобы образы появились в этом хранилище, их нужно импортировать из онлайн-источников, причем, vSphere Lifecycle Manager это делает регулярно сам, если настроить импорт контента по расписанию, либо при необходимости процедуру можно инициировать и вручную, выбрав вверху в выпадающем меню ACTIONS под UpdatesSync Updates:

Но до этого, чтобы наш vSphere Lifecycle Manager знал, откуда тащить версии образов и прочие вещи, следует настроить источники загрузок. С этой целью на вкладке Settings выбираем из бокового меню Patch Setup и выбираем, добавляем или меняем URL – для этого вверху таблички есть NEW, EDIT, DELETE, ENABLE и DISABLE:

Также можно импортировать контент и из оффлайн-источников: из выпадающего меню Actions сверху выбираем Import Updates – появится окошко, куда можно либо ввести URL, либо нажать BROWSE, чтобы найти нужный ZIP-файл с обновлением:

Управление обновлением хостов кластера при помощи vSphere Lifecycle Manager

Чтобы воспользоваться vSphere Lifecycle Manager в жизненном цикле наших хостов, нам нужно добавить их в кластер vSphere Lifecycle Manager – тогда они смогут управляться единым образом. При создании этого кластера опция использования единственного образа выбрана по умолчанию (галочка в Manage all hosts in the cluster with a single image), также можно или установить этот образ самостоятельно, либо указать, что нужно воспользоваться образом хоста в или вне текущего инстанса vCenter Server. В этом поможет встроенный помощник New Cluster:

Для этого:

  1. В клиенте vSphere проходим в инвентарь Hosts and Clusters;
  2. ПКМ на дата-центр и выбираем New Cluster – появится упомянутый визард;
  3. На странице Basics вводим имя кластера и включаем vSphere DRS, vSphere HA или vSAN;
  4. Оставляем галочку в Manage all hosts in the cluster with a single imageи флажок в Compose a new image (выбраны по дефолту);
  5. Опционально, чтобы включить vSphere Configuration Profiles на кластере, выбираем Manage configuration at a cluster level. Жмем Next;
  6. На странице Image устанавливаем желаемый образ (выбираем версию ESXi и, опционально, аддон вендора и его версию) и кликаем Next;
  7. Если выбрали vSphere Configuration Profiles, просматриваем информацию на Configuration и жмем Next;
  8. На странице Review проверяем сделанные настройки и кликаем Finish, чтобы начать создание кластера.

Если хотим, чтобы к нашему кластеру применялся образ определенного хоста, делаем то же самое до п. 3 включительно, галочку в Manage all hosts in the cluster with a single image оставляем, а вот с Compose a new image флажок снимаем и выбираем метод создания образа для кластеру:

  • Чтобы импортировать образ из хоста в том же инвентаре vCenter Server, выбираем Import image from an existing host in vCenter inventory;
  • Чтобы импортировать образ из другого инстанса vCenter Server или standalone-хоста не из vCenter Server, выбираем Import image from a new host.

П. 5 без изменений, а далее, в первом случае: на странице Image выбираем референсный хост и жмем Next – далее все точно так же до завершения работы помощника, как и с созданием нового образа. А во втором: на странице Image вводим данные хоста и кликаем кнопку Find Host, появится диалоговое окно Security Alert, где нужно нажать Yes, чтобы согласиться с подключением к хосту, а чтобы переместить этот хост в наш кластер, ставим галочку в Also move selected host to cluster и жмем Next, и далее снова все так же точно, как в п.7-8.

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

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

vSphere Lifecycle Manager сделает проверку по компонентам образа, нет ли в нем пропущенных зависимостей и конфликтующий компонентов, и покажет именно тот образ, который является самым новым и тем, что наиболее подходит вашей среде. Чтобы просмотреть рекомендованные образы, можно кликнуть на Recommendations около надписи Image вверху, или выбрать в упомянутом меню под «тремя точечками» View recommended images:

Редактирование образов кластера в vSphere Lifecycle Manager

Образ, согласно которому исправляются хосты кластера, после его добавления в хранилище vSphere Lifecycle Manager можно редактировать, путем изменения самого базового образа или изменения, добавления или удаления компонентов (версии образа ESXi, аддонов вендора, firmware, аддонов драйверов и других):

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

Параллельное исправление хостов в кластере при помощи vSphere Lifecycle Manager

Ниже в подразделе о процедуре «Обновления ESXi-хостів с vSphere Lifecycle Manager» мы покажем, как восстанавливать несоответствующие заданному образу хосты в кластере. Интересно, что для экономии времени мы можем это делать не последовательно, а параллельно, осуществив некоторые настройки  на вкладке Settings под Cluster lifecycle бокового меню в Images:

Там же можно указать максимальное количество параллельных исправлений.

Замечание. Операция параллельного исправления в кластере доступна лишь для хостов в режиме maintenance.

Процедура апгрейда vSphere

Важно! Вначале обновляется всегда vCenter Server, а уже после него – ESXi.

Вообще, вся процедура обновления vSphere должна идти по такому плану, схематически:

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

Процедура обновления vCenter Server

Задачи апгрейда vCenter Server, схематически:

Важно! В средах с несколькими инстансами vCenter Server appliance нельзя прибегать к параллельным апгрейдам. Каждый инстанс vCenter Server должен обновляться отдельно, так как VMware Directory Services (vmdird) сталкивается с проблемами репликации с информацией о single-sign on и сертификате.

Как мы уже писали раньше, существует два метода обновления appliance vCenter Server. Рассмотрим их по очереди.

Апгрейд vCenter Server через GUI-инсталлятор

GUI-инсталлятор проведет нас через две глобальные стадии, первая из которых состоит в развертывании нового виртуального аppliance уже 8-й версии, а вторая – в миграции существующих данных и настройке всех его сервисов. Пройдемся по ним.

Как только запустим инсталлятор, что подходит нашей операционной системе:

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

Нас интересует, соответственно, «Upgrade». Нажав на нее попадем в приветственное окно «Іntroduction», которое познакомит с упомянутыми двумя стадиями:

Далее идем по пунктам бокового меню, после нажатия на этой странице Next:

  1. «End user license agreement». Ставим галочку, что соглашаемся с лицензионным соглашением. Жмем Next:
  2. «Connect to source appliance». Вписываем данные об источнике – FQDN, порт, данные учетной записи аккаунта администратора и пароль root, а также FQDN хоста или инстанса vCenter Server, где развернут старый аppliance, и данные учетной записи пользователя этого хоста или инстанса. Жмем Next:

Покажет предупреждение о сертификате – нужно подтвердить отпечаток (кнопка YES):

  1. «vCenter Server deployment target». Вводим данные по цели vCenter Server (хост или инстанс vCenter Server) – FQDN, порт и данные учетной записи пользователя. Жмем Next:

Снова предупреждение сертификата – соглашаемся кнопкой YES.

  1. «Select folder». Выбираем дата-центр и папку, где должна создаться ВМ vCenter Server. Жмем Next:
  2. «Select compute resource». Выбираем вычислительные ресурсы, кликаем Next:
  3. «Set up target vCenter Server VM». Задаем данные нашей новой ВМ (имя, логин/пароль root). Жмем Next:
  4. «Select deployment size». Выбираем размер развертывания (об этом подробно говорилось в статье «Инсталляция vSphere 0 с нуля», подраздел «Требования к «железу», сети и хранилищу»). Жмем Next:
  5. «Select datastore». Выбираем хранилище, кликаем Next:
  6. «Configure network settings». Задаем настройки сети для нового vCenter Server (название сети, ІР-версию – IPv4/IPv6, тип IP-назначения – static/DHCP, IP-адрес, маску подсети или длину префикса, дефолтный шлюз, DNS-серверы). Жмем Next:
  7. «Ready to complete stage 1». Пересматриваем сделанные настройки, если все хорошо, кликаем на FINISH:

Начнется процесс развертывания нового appliance, по завершению которого продемонстрируется сообщение, что мы успешно прошли первую стадию. Здесь, если нажмем CLOSE, настройки включительно с переносом данных придется делать отдельно, через клиент vCenter Server Management Interface. Но мы нажмем CONTINUE, чтобы сразу перейти ко второй стадии.

Помощник второй стадии также сначала поздоровается с нами страницей «Іntroduction», где расскажет, что будем делать дальше:

После того, как нажмем Next:

  1. «Connect to source vCenter Server». На этом шаге помощник проверит, имеет ли доступ к источнику vCenter Server appliance, используя настройки, которые мы сделали на первой стадии:

Результат пречека будет иметь вид с неким перечнем предупреждений и предложений по их устранению (если таковые будут). Закрываем это окно CLOSE:

Жмем Next;

  1. «Select upgrade data». Выбираем тип данных, которые хотим, чтобы были смигрированы из источника vCenter Server (ставим флажок – одно из трех, от наименьшего по содержанию и объему до самого полного). Жмем Next:
  2. «Configure CEIP». Ставим галочку, если хотим присоединиться к программе улучшения опыта клиентов. Жмем Next:
  3. «Ready to complete». Пересматриваем итог сделанных нами настроек, ставим галочку, что сделали бэкап (как именно – писали выше, в соответствующем подразделе раздела «Подготовки…»), и жмем FINISH:

Выскочит предупреждение, что источник vCenter Server appliance выключится, как только перенесутся сетевые настройки новую версию appliance:

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

CLI-метод обновления vCenter Server

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

vcsa-deploy upgrade path_to_the_json_file list_of_arguments

куда обязательно нужно вставить через пробел аргумент «—accept-eula» и вдобавок можно внести другие необходимые аргументы, коих мы подробно касались в подразделе «Подготовка конфигурационного JSON-файлу для CLI-метода развертывания appliance vCenter Server» материала «Инсталляция vSphere 8.0 с нуля».

Процедура обновления ESXi-хостов

Схематически, процесс апгрейда ESXi-хостов выглядит так:

Рассмотрим каждый из возможных методов.

Интерактивное обновления хостов ESXi

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

  1. После запуска инсталлятора увидим традиционное приветственное окно, на котором нужно нажать Enter:
  2. Принимаем End User License Agreement (EULA) кнопкой F11:
  3. Выбираем диск, на котором нужно выполнить инсталляцию/апгрейд, Enter:
  4. Инсталлятор поймет, что у нас уже есть предварительно установленная версия ESXi и предложит либо обновить ее, либо установить чистую – выбираем Upgrade и жмем Enter:

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

  1. И еще раз F11 в следующем окне для подтверждения:
  2. Некоторое время будем наблюдать прогресс процесса, и если все хорошо, увидим сообщение о его окончании, где нужно будет нажать Enter, чтобы вынуть инсталляционный медиа и перезагрузить хост:

После этого уже загрузится обновленный хост, в котором, если хотим, можно будет перенастроить некоторые параметры, как рассказывалось в статье «Инсталляция vSphere 8.0 с нуля», подраздел «Начальные настройки ESXi».

Апгрейд ESXi-хостов при помощи скриптов

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

Об этом и о том, что нужно сделать для искомого результата подробно описано в подразделе «Инсталляция ESXi при помощи скрипта» упомянутой статьи. Собственно, это и все, что нам следует сделать, чтобы процесс апгрейда начался.

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

Используя командную строку, обновить ESXi-хост можно, буквально, парой команд в удобном SSH-клиенте, например, PuTTY:

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-8.0.0-20513097-standard

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

Через несколько минут командная строка отрапортует, что обновление произошло успешно, и продемонстрируется замечание «Reboot Required: true»:

Но, это далеко не все, ведь можно также обновлять хосты индивидуальными VIB, доступными по URL или в оффлайн ZIP-хранилище. А также VIB или профилями образов из ZIP-файла в хранилище.

Обновления хоста с индивидуальными VIB через ESXCLI и инсталляция отдельного ZIP-файла на хосте

ZIP-пакетом для апдейта можно пользоваться напрямую с сайта VMware, либо разместить его в поддерживаемом вендором хранилище, или вообще загрузить локально.

Важно! Команды «esxcli software vib update» и «esxcli software vib install» не поддерживаются в операциях обновления.

При этом порядок действий будет следующим:

  1. Определяем, какие VIB проинсталлированы на хосте:

esxcli —server=<server_name> software vib list

  1. Находим, какие VIB доступны в хранилище. Если у нас хранилище доступно по URL:

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

Если в локальном хранилище:

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

  1. Обновляем существующие VIB, чтобы включить VIB, имеющиеся в хранилище, или чтобы проинсталлировать новые. Для VIB, доступных по URL:

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

Для VIB из локального хранилища:

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

Проинсталлировать отдельный ZIP-файл можно командой:

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

Опция Dry Run в обновлении через ESXCLI

Опция Dry Run очень полезна в работе с обновлениями при помощи ESXCLI, ведь она не делает никаких изменений в процедуре, но позволяет предварительно просматривать результаты апгрейда. Добавление «—dry-run» к командам дает отчет об операциях на уровне VIB.

Важно! Обновляться до ESXi 8.0 и более новых версий с использованием опции «—dry-run» можно только с 7.0U3i версии.

Команда в этом случае может выглядеть, например, так:

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

или так:

esxcli —server=<server_name> software profile update —dry-run

Обновление ESXi-хостов с vSphere Lifecycle Manager

Рассмотрим более общий случай обновления хостов, что управляются vCenter Server и собраны в кластер. Для этого в клиенте vSphere:

  1. В свойствах нашего кластера кликаемо на вкладку Updates, а потом в боковом ее меню под Hosts на Image и внизу на кнопкуSetup Image:
  2. Появится окно настроек образа, где мы должны, прежде всего, выбрать версию из выпадающего меню:

И нажать на кнопку Save, после чего выскочит предупреждение, что завершение настройки  образа заместит все baseline, которые были прикреплены к кластеру и его хостам, и этот процесс необратим, но полученный образ сможем отредактировать в любое время в будущем. Здесь надо согласиться кнопкой YES, FINISH IMAGE UP;

  1. Проверяем соответствие на уровне кластера, нажав кнопку Check Compliance:

Важно! Перед тем, как приступить к исправлению хостов, если они не соответствуют, рекомендуется запустить проверку, не случится ли каких-то проблем в процессе исправления, кнопкой RUN PRE-CHECK.

  1. Как видим, хосты не соответствуют, значит, их нужно исправить кнопкой Remediate All:
  2. Появится окошко Review Remediation impact, что продемонстрирует, какой именно будет иметь эффект исправление – ставим галочку внизу, соглашаясь с EULA и нажимаем кнопку Start Remediation:

Прогресс процесса сможем видеть в задачах vCenter Server:

и хосты начнут исправляться:

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

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

Когда главные компоненты vSphere успешно обновились до 8-й версии, необходимо предпринять некоторые операции пост-апгрейда, чтобы среда начала работать без замечаний. А именно:

  • Завершить любую реконфигурацию компонентов, которая не вошла непосредственно в процедуру апгрейда. В том числе, по желанию, довести все хосты среды до самых свежих версий;
  • Попробовать зайти через vSphere Client на vCenter Server (введя в браузере «https://vcenter_server_ip_address_or_fqdn/ui») и проверить:
    • корректен ли IP-адрес,
    • не изменилась ли регистрация Active Directory,
    • правильна ли регистрация сети,
    • валидны ли сертификаты,
    • корректно ли смигрировали данные инвентаря (история событий, графики производительности, пользователи, разрешения и роли);
  • Если используете аутентификацию смарт-картами, убедитесь, что их порт открыт в клиентской среде (на vCenter Server, по дефолту);
  • Если имели зарегистрированные с vCenter Server до апгрейда плагины и сторонние клиентские пакеты плагинов, после обновления SSL-сертификата, можно, при необходимости, их перерегистрировать. Заметьте, что подобные расширения и клиентские плагины могут иметь свои особенности после перерегистрации, поэтому обязательно проконсультируйтесь с их вендором. В общем случае для этого нужно: пройти в браузере на Managed Object Browser нашего vCenter Server

https://vcenter_server_ip_address_or_fqdn/mob/?moid=ExtensionManager

ввести данные своей учетной записи, на странице ManagedObjectReference:ExtensionManager под Methods кликнуть на UnregisterExtension, на странице void UnregisterExtension в текстовом поле внутри колонки Value ввести значение свойства «key» объекта данных «Extension» соответствующего расширения vSphere Client. А чтобы снять регистрацию с расширения нажимаем на Invoke Method.

  • Проверить лицензии хостов;
  • Перенастроить систему журналов логов по желанию.

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