Vmware 6 7 обновить до 7
You can upgrade vCenter Server appliance 6.5 or 6.7 to version 7.0 . All the installation files that are necessary for the upgrade are included in the vCenter Server installer, which you can download from the VMware website.
The upgrade of the vCenter Server appliance is a migration of the old version to the new version, which includes deploying a new vCenter Server appliance of version 7.0 . You can deploy the new appliance on an ESXi host 6.5 or later, or on the inventory of a vCenter Server instance 6.5 or later. You assign a temporary IP address to the new appliance to facilitate the configuration and services data migration from the old appliance to the newly deployed appliance. After the migration, the IP address and host name of the old appliance are applied to the new upgraded appliance of version 7.0 . At the end of the upgrade, the temporary IP address is released and the old appliance is powered off.
Version 7.0 of vCenter Server uses an embedded PostgreSQL database. During the upgrade, you must select a storage size for the new appliance that is suitable for the database size.
vCenter Server 7.0 uses an embedded vSphere Lifecycle Manager service that allows you to perform centralized and simplified lifecycle management of clusters with ESXi 7.0 hosts. vSphere Lifecycle Manager in vSphere 7.0 includes the functionality that Update Manager provided in earlier vSphere releases for host upgrade and patching operations, as well as upgrade of virtual machine hardware and VMware Tools .
If you are upgrading a vCenter Server appliance or migrating a vCenter Server that use an external Update Manager instance that runs on Windows, in vSphere 7.0 the external Update Manager instance is migrated to the embedded vSphere Lifecycle Manager extension service of the new, upgraded vCenter Server appliance.
If you are upgrading a vCenter Server appliance that uses an embedded VMware Update Manager instance, in vSphere 7.0 the embedded VMware Update Manager instance is upgraded to the embedded vSphere Lifecycle Manager extension service of the new upgraded vCenter Server appliance. The embedded VMware vSphere Update Manager Extension uses the embedded PostgreSQL database. Before the upgrade, you must run the Migration Assistant on the source Update Manager instance.
For information about the software included in the vCenter Server 7.0 , see vCenter Server Installation and Setup .
Note: For topologies with external Platform Services Controller instances, the Platform Services Controller will be converged during the upgrade process to vCenter Server 7.0 . After a successful upgrade, the external Platform Services Controller is powered off can be removed from your vSphere inventory. See Decommission the Platform Services Controller.
The vCenter Server installer contains executable files for both GUI and CLI upgrades which you can use alternatively.
Note: vCenter Server deployments using an external Platform Services Controller will not be supported in a future vSphere release. Deploy or upgrade to a vCenter Server deployment using an embedded Platform Services Controller . For more information, see Knowledge Base article KB 60229.
- The GUI upgrade is a two stage process. The first stage is a Deployment wizard that deploys the OVA file of the new appliance on the target ESXi host or vCenter Server instance. After the OVA deployment finishes, you are redirected to the second stage of the process that sets up and transfers the services and configuration data from the old appliance to the newly deployed appliance.
- The CLI upgrade method involves running a CLI command against a JSON file that you previously prepared. The CLI installer parses the configuration parameters and their values from the JSON file and generates an OVF Tool command that deploys the new appliance. The OVF Tool command also transfers services and configuration data and from the old appliance to the new appliance.
For information about the vCenter Server and Platform Services Controller appliance upgrade requirements, see System Requirements for the New vCenter Server Appliance.
Important: If the appliance that you are upgrading is configured in a mixed IPv4 and IPv6 environment, only the IPv4 settings are preserved. for information on the transfer of networking configuration settings for mixed mode IPv4 and IPv6 deployments, see Mixed IPv4 and IPv6 Upgrade and Migration.
If you are deploying the vCenter Server appliance directly on an ESXi host, non-ephemeral distributed virtual port groups are not supported and are not shown. After the upgrade, you can manually connect the appliance to the original non-ephemeral distributed virtual port group. This is not a limitation when deploying the appliance through a vCenter Server , and you can deploy to ephemeral or non-ephemeral distributed virtual port groups.
To upgrade vCenter Server appliance version 6.0 or earlier, you must first upgrade to version 6.5 or 6.7 and then upgrade to version 7.0 . For information about upgrading vCenter Server appliance 6.0 to version 6.5, see the VMware vSphere 6.5 documentation. For information about upgrading vCenter Server appliance 6.0 to version 6.7, see the VMware vSphere 6.7 documentation. For information on the upgrade compatibility of vCenter Server , see the VMware Compatibility Guide.
For information about deploying the vCenter Server , see vCenter Server Installation and Setup .
For information about configuring the vCenter Server , see vCenter Server Configuration .
Постоянный читатель прислал свои мысли о выборе гипервизоров и убедительной победе vSphere 7.0, несмотря на все грабли ;).
С чего все началось
Недавно у наших коллег появилось осознание, что:
- самым старым серверам в продуктивной среде уже 8 и больше лет,
- поддержки и запчастей на них нет,
- нагрузка по памяти под 90%, но ее там очень немного,
- установлена максимально возможная для этих серверов ESXi 6.5 , на тот момент 17477841 (сейчас 18071574).
Поэтому было решено:
- начать закупку новых серверов,
- обновить, где возможно, до ESXi 7.0 для единообразия.
Серверы, в основном, производства HPE и Huawei, на каких-то задачах используются серверы Supermicro. Предлагают закупать Dell, HPE, Lenovo. У Huawei сейчас все сложно, а присматриваться к линейке Kunpeng на Arm сейчас нет времени. Хотя под Arm есть и MS Server, и ESXi.
Почему ESXi, а не что-то еще
Все достаточно прозаично – сложившийся опыт эксплуатации и «люди со знанием в наличии». Мгновенно перейти «на что-то еще» нельзя, поддерживать две разные системы (например, ESXi и KVM) – потребует увеличить бюджет отдела на:
- Людей, которые могут, умеют и практикуют KVM – то есть утроить штат — оставить старые кадры, набрать (не мгновенно) новые кадры, и выделить людей со стороны сервисов / разработки, которые вместо текущей работы будут заниматься тестами «вообще». Автотестов у нас маловато и не все вылезает так быстро, как хотелось бы.
- Тестовые стенды сначала под «посмотреть», потом под пробную миграцию, замеры скорости и тому подобное(а на KVM может быть больно в дисковых операциях).
Затем – после решения вопроса денег и людей (новые люди – новое штатное расписание – новые начальники), придется:
- Долго и нудно искать подходящий оркестратор и разбираться в нем (Openstack, а еще? Если Openstack, то какой – ванильный или вендорский? Если вендорский, то чей? FusionSphere OpenStack, например – плюсы, минусы?
- Искать и пробовать – как работает бекап и восстановление?
- Поиметь проблемы со скоростью, как описанные, так и не очень.
- Я не перечисляю вопросы с импортозамещением у кого оно есть (в данном случае — нет), регуляторами (сертификацией средств защиты инофрмации) и прочей отраслевой спецификой. Граждане, попадающие под требования 187-2017-КИИ и ГОСТ Р 57580 знают, о чем речь.
Отдельно придется рассмотреть новые процедуры «поибэ», сбор и хранение логов и удаленный доступ для поддержки. В ESXi процесс понятен и передача support bundle «наружу» согласована с ИБ, а как быть с новыми системами?
Тоже самое придется тестировать и учить при выборе Hyper-V. Да, он надежен, совместим с массой программ резервного копирования, диски переедут без особых усилий, но все равно это требует времени и ресурсов, в том числе на изучение счётчиков производительности \Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time, Total Run Time, % Hypervisor Run Time, или же, если у вас некролаба — HKLM\SYSTEM\CurrentControlSet\Services\VMSMP\Parameters /v BelowTenGigVmqEnabled /t REG_DWORD /d 1 /f, сверху (если хорошая лаба) — все обмазать RoCEv2 в смеси с Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ or d.VMMQ) и заполировать Switch Embedded Teaming (SET) и так далее.
В остатке — переезд ради переезда ценой в удвоение бюджета ИТ ради снижения стоимости лицензий? На общем фоне даже временная аренда новых площадей для руководства и хотя бы трети нового штата (2/3 на удаленке) обойдется ООО «Скрудж и Марли» чуть дороже лицензий.
Отличия ESXi 7.0 от 6.7 и процедуры подготовки
Особое внимание надо уделить следующему:
Сети, которые Ethernet. В 7.0 и далее сменилась модель использования драйверов, и просто так поставить в дистрибутив старые линуксовые драйвера больше нельзя. Проверяйте HCL, проверяйте прошивки, смотрите в Community Networking Driver for ESXi.
Сети, которые storage area network (SAN). В связи с очень, очень странной политикой (почти монопольной) Brocade – оценивайте санкционные риски при использовании FC-Brocade (да и Cisco тоже). Возможно, со сменой серверов – можно рассмотреть и смену SAN с FC на Ethernet 10/25/100 G. Плюсы – меньшая привязка к вендору. Минусы – придется изучить массу нововведений для разгрузки центрального процессора и такую же массу дополнений к самому Ethernet. Тут и старые DCB, TSO-LRO, и lossless Ethernet, и RDMA м SR-IOV и RoCE (RDMA over Converged Ethernet) – много новых терминов, некоторые из них могут вызвать абсолютно неожиданные проблемы.
Сети вообще. Уже много лет идет переход на10/25 сети, а люди все равно умудряются собирать Etherchannel, совершенно не понимаю никак он работает, ни зачем он нужен, ни что такое beacon, ни его применимость. Потом получают проблемы в сети и страдают. Граждане, грамотно планируйте сеть, не усложняйте ее без существенных обоснований. Читайте официальную открытую бесплатную документацию.
Диски или новая боль. Много лет у ESXi был огромный плюс –гипервизор отлично работал с 4-8 Гб USB флешки или SD. USB/SD была нужна только на запуске, затем гипервизор жил в памяти – и настроить надо было только логирование, дампы, бекап и профили. Умерла флешка – не беда, поставили новую, обновили, восстановили из бекапа или из профиля. Но они особо и не умирали (кроме как в случае перегрева). В ESXi 7.0 ситуация изменилась – USB все еще можно, но лучше не надо: The recommended ESXi 7.0 install options are the following: A local disk of 138 GB or larger. The disk contains the boot partition, ESX-OSData volume and a VMFS datastore. A device that supports the minimum of 128 Terabytes Written (TBW) (ссылка).
Резервное копирование. При планировании перехода, проверяйте, что ваше ПО резервного копирования работает с новыми ESXi и vCenter до начала любых работ.
TLS. Тоже имейте в виду, что 1.0 и 1.1 уже не модно — You can use the TLS Configuration utility to enable or disable TLS versions on vCenter Server systems. As part of the process, you can disable TLS 1.0, and enable TLS 1.1 and TLS 1.2. Or, you can disable TLS 1.0 and TLS 1.1, and enable only TLS 1.2. (документация)
Ansible / Terraform / etc. Если вы работаете с этими инструментами, сразу смотрите «что изменилось».
Опыт коллег, или с чем столкнулись в тестах при обновлениях на vCenter 7.0
Сначала еще раз – почему нельзя обновить только хосты до ESXi 7 – и оставить старый вцентр 6.7? Потому! Смотрите VMware Product Interoperability Matrix.
Что нового, кроме отсутствия Flash? Вот обзорная статья, от себя добавлю , что не все функции 1:1 перенесли из Flash клиента. Я не записал, с чем коллеги столкнулись – то ли с монтированием FDD image, то ли с захватом сетевого трафика, какие-то не очень типичные операции. Проверять надо все ручные операции, надеюсь у вас есть их каталог.
vCenter 7 добавляет vSphere Cluster Services (vCLS). Это минимально возможные виртуальные машины «для служебных задач». Вот эта фраза в документации — ESXi host can be of any older version that is compatible with vCenter server 7.0 Update 1 – немного расходится с практикой, иногда эти VM отрабатывают нормально, иногда не могут запуститься. На этот счет есть заметка Demo Time: How to delete the vCLS VMs. Вопрос можно начать изучать отсюда — Workaround for ESXi-Arm in vSphere 7.0 Update 1.
В чистой установке vCenter 7.0 проблем вроде бы меньше, но это субъективное мнение – на vmware полно kb со словами “no workaround” и “will be fixed soon”.
Обновление – VUM / vLCM. Согласно сайту, все сделали только более лучше — We greatly improved lifecycle management in vSphere 7. The new innovations for lifecycle management in vSphere 7 make it easy for customers to have consistent and up-to-date systems. На практике в тестовом сегменте VUM вообще умер, и далее пришлось выполнять kb 2147284 Resetting VMware Update Manager Database on a vCenter Server Appliance 6.5/6.7/7.0 . Вместе с ним умерли задачи с проверкой Baseline хостов по расписанию, точнее задачи в расписании остались – а baseline уже нет. Пересоздали, конечно.
Бекап средствами vCenter. При последнем срочном обновлении до vCenter Server 7.0 U2b (17958471) умер встроенный бекап. Проблема «умирания» была связана с порядком запуска служб, состоянием VMware Directory Service (vmdir), проверкой «кто там запустился и в каком статусе», лечение связано с исправлениями в конфиге – куда не стоит заходить без наличия активной поддержки (потому что, бекапа, фактически, уже нет).
Проблемы могут быть и при самом апгрейде, например описанные в статье VCSA 7.0 Update 2 Upgrade Issue — Exception occurred in install precheck phase, с ручным НЕ РЕКОМЕНДОВАННЫМ исправлением через shell.
Дождавшись выхода VMware vSphere 7.0.0b, мы решились на обновление нашей инфраструктуры, построенной на платформе версии 6.7.
Для уменьшения количества граблей внимательно прочитали следующие документы:
Как это бывает, КБшка не помогла, как и не помог совет в форуме VMware.
Обратились в ТП VMware, получили волшебный скрипт и инструкцию: ls_ssltrust_fixer_p3.
- Проверить наличие актуальной резервной копии и сделать snapshot.
- Подключиться к vCenter по SSH.
- Скопировать «ls_ssltrust_fixer.py» в папку /usr/lib/vmidentity/tools/scripts (например, с помощью WinSCP).
- Перейти в папку:
После магических пасов руками vCenter обновился.
Проблема с vLCM
Зная рецепт, обновили несколько vCenter и получили разную функциональность в обновлении Update Manager — vSphere Lifecycle Manager (vLCM). Местами он категорически отказывался показывать Image Depot и видеть обновления для ESXi 7.0. Недолго думая, мы решили сделать сброс БД, чтобы заодно её почистить от компонентов для ESXi6.0 — Resetting VMware Update Manager Database on a vCenter Server Appliance 6.5/6.7/7.0 (2147284). Это исправило «видимость» семёрочных обновлений.
Проблема с безагентской антивирусной проверкой
Для безагентской антивирусной проверки требуются компоненты VMware NSX Data Center for vSphere, поддержка которого не была заявлена (вышел новый продукт) при релизе vSphere 7.0. Но, VMware одумалась и в этом месяце всё таки выпустила патч версии 6.4.7.
Проблема с плагином Veeam BR
Также отвалился плагин для Veeam BR — порешалось переустановкой.
P.S. В придачу слетел файловый бэкап vCenter ;). Требуется перенастройка.
Шаг 3. Сбор данных с имеющейся инфраструктуры
В первую очередь нам нужны данные по сетям с точки зрения VMware. Для этого у нас есть командлет Get-VirtualPortGroup:
(В следующей серии статей: злой брат близнец New-VirtualPortGroup и классы).
Затем стоит собрать данные по правам (хотя в таких запутанных инфраструктурах проще будет махнуть шашкой по заветам Александра Македонского — собрать права с нуля, учитывая классические ошибки – заведение прав «на пользователя», с его последующим увольнением, гранулярные кривые права на отдельные VM и так далее) и собрать информацию о системе резервного копирования (СРК), (которая, скорее, всего тоже будет модернизироваться). Смотрите лист совместимости для СРК, не все системы официально работают с vSphere 7.0.
Обновление VMware vCenter с версии 6.7 до 7.0: 5 комментариев
Про VUM очень помогло, спасибо за наводку.
Перед применением сделайте снапшот VC
Предварительно требуется переименовать скрипт из архива в ls_ssltrust_fixer.py
Fixing SSL trust mismatch in lookup service registration using ls_ssltrust_fixer.py
Symptoms
• Lookupservice registration has endpoint SSL trust certificate mismatch to actual node certificate.
Any situation leading to the procedure documented, see KB 2121701 or KB 78709 for 7.0Purpose
The automated way of performing procedure documented in KB 2121701 or KB 78709 for 7.0Resolution
****Please use the tool under the supervision of the PSC/SSL Team and/or Escalation Engineer****NOTE:
• The tool is applicable to only vSphere 6.x & 7.x. Partial upgrade state of 5.5 to 6.x is unsupported for this tool- 5.5 web client registration might change if fix used without validation.
• Port 443 is hardcoded to retrieve machine SSL certificate, validate third-party registrations thoroughly
• Current machine SSL certificate in use is collected using a live connection to the node, host not alive might impact the mismatch check.
1. Download the file attached to this article
Note:
• For vCenter 6.0 and vCenter 6.5, Download «ls_ssltrust_fixer_p2.py» file and rename to «ls_ssltrust_fixer.py»
• For vCenter 6.7, Download «ls_ssltrust_fixer_p3.py» file and rename to «ls_ssltrust_fixer.py»
• For vCenter 7.0, Download «ls_ssltrust_fixer_p3_70.py» file and rename to «ls_ssltrust_fixer.py»mr_orangeV прислал статью о своём опыте замены VMware vCenter. С небольшой редактурой публикую. Юмор автора местами сохранён.
В последнее время читаю много однотипных историй «у нас ESXi 5.1/5.5 /6 — как нам жить дальше или на что-то переехать?» Расскажу свою историю, может кому-то поможет.
Нам достался подряд на обследование и модернизацию инфрастуктуры одной организации. Беглый осмотр показал следующее:- десяток разных серверов (с разными процессорами) на ESXi 6.0/6.5/6.7;
- некая СХД, работающая по протоколам NFS/iSCSI;
- невнятная сеть почти без деления (лучше бы было совсем без деления, так как я такого ужаса еще не видел).
- VMware vCenter 6.5 на Windows, обновленный последний раз очень давно;
- полное отсутствие документации «что, где, куда и почему»;
- под сотню виртуальных машин, которые, конечно же, все очень важные и нужные. И тоже без обновлений! Настоящие админы до второго сервис пака не обновляют, но с Windows Server 2016/2019 есть проблема при таком подходе.
- cостояние резервного копирования неочевидно.
Для ликвидация хаоса были предприняты следующие шаги:
Шаг 7. Перенос VM
После того, как параллельная инфраструктура построена, проверена и работает, система резервного копирования (СРК) заведена и новый disaster recovery plan (DRP) в наличии — начинаем перенос хостов и виртуальных машин. Разумеется, перед переносом:
- Надо сделать (и проверить) хоть какой-то disaster recovery plan (DRP) — план восстановления, если что-то пойдет не так.
- Надо получить список виртуальных машин и как-то их отсортировать в порядке значимости. Можно (и нужно) сделать 1-2 тестовые виртуальные машины, только под проверку работы переноса.
Одновременно с переносом хостов желательно проводить и обновление самих хостов, хоть через VUM, хоть через ручное обновление путем закачки zip. Ничего сложного в процедуре нет, главное не забывать ОТКЛЮЧАТЬ LUN на время обновлений (если вы обновляете автоматически и между версиями).
При обновлении (U2-U3 например) надо обновляться до последней версии и все равно быть готовым к сюрпризам. Например, пару лет назад в свежем патче была проблема «-1», заканчивавшаяся остановкой vCenter. Читать: 503 Service Unavailable” error on the vSphere Web Client when logging in or accessing the vCenter Server (67818) — ESXi 6.7 Update 3 build 14320388–503 Service Unavailable и Excessive Hardware health alarms being triggered for “Sensor -1 type” on ESXi hosts running vSphere 6.7 U3 (74607)
До недавнего времени выбор метода переноса VM был не очень широк. Можно было переносить с перезагрузкой, а именно — выключаем VM, удаляем из инвентаря, добавляем на новом инвентаре, включаем. Перенос VM вместе с хостом — попробуйте, удивитесь, особенно при наличии EVC (примечание: читайте ссылки в рекомендованной литературе).
Относительно недавно появилась утилита Cross vCenter Workload Migration Utility, а теперь её добавили в сам vCenter — vSphere 7.0 U1c you can use The Advanced Cross vCenter Server vMotion (XVM) capability, в котором нас интересует раздел The Importing VMs Option. Дополнительные статьи тут и тут
Можно переносить и средствами резервного копирования — например, Veeam BR Quick Migration
В процессе переноса уточняете, что это за виртуальные машины, чьи они, нужны ли они, кто владелец.
Имеется сервер HPE ProLiant DL360 Gen10. На нём установлен гипервизор ESXi 6.7. Попробую обновить его до версии ESXi 7.0.2. Поехали.
Обновление ESXi 6.7 до ESXi 7.0
Выбираем вариант загрузки iLO Virtual USB 3 : iLO Virtual CD-ROM.
Загружается инсталлятор ESXi 7.0.
При загрузке инсталлятор определяется модель сервера, количество и тип процессоров, объём памяти. Видно версию ESXi 7.0.2 build 17867351.
Для продолжения установки нажимаем Enter.
Принимаем лицензионное соглашение: F11.
Найдено два диска. ESXi 6.7 у меня крутится на первом диске, проверим: F1.
Найден гипервизор ESXi 6.7.0. Установку будем производить на этот же диск. Enter. Enter.
Предлагают три опции установки:
- Upgrade ESXi, preserve VMFS datastore
- Install ESXi, preserve VMFS datastore
- Install ESXi, overwrite VMFS datastore
Для обновления выбираем Upgrade ESXi, preserve VMFS datastore. Enter.
Инсталлятор собирается обновить ESxi 6.7.0 до ESXi 7.0.2. Подтверждаем: F11.
Начинается обновление до ESXi 7.0.2.
Извлекаем установочный ISO образ и нажимаем Enter для перезагрузки.
Гипервизор обновлён до версии ESXi 7.0.2 build 17867351. Не забудьте обновить лицензионный ключ.
Подготовка сервера
На сервере установлен гипервизор ESXi 6.7.0 build 17700523. Скачиваем дистрибутив VMware vSphere Hypervisor ESXi 7.0 Update 2:
Монтируем установочный ISO образ. Перезагружаем сервер.
Для выбора вариантов загрузки нажимаем F11.
Шаг 2 Детализация и проверка совместимости
Идем на Intel ark и уточняем спецификации используемых процессоров. Записываем в нашу таблицу.
На VMware HCL ищем наши процессоры (точнее, выбираем CPU в выпадающем списке, а затем series), выписываем последний возможный уровень ESXi. В частности, для много лет любимого Intel Xeon 56xx Series Supported Releases — 6.5. Знающие люди говорят, что возможно и 6.7 (проверено сообществом), и 7.0 (не стоит оно того), но официально предел 6.5, дальше «не проверено производителем».
Если с процессором все хорошо, то аналогично проверяем сетевые карты, FC-, RAID-контроллеры и так далее.
Если железо от HPE, Lenovo, Dell или другой фирменной сборки, то проверяем сервер целиком.
Связана такая проверка с тем, что в ESXi 7.0 поменяли работу с драйверами:
Deprecation of VMKLinux
In vSphere 7.0, VMKLinux driver compatibility has been deprecated and removed. vSphere 7.0 will not contain support for VMKLinux APIs and associated VMKLinux drivers. Custom ISO will not be able to have any VMKLinux async drivers. All drivers contained in an ISO must be native drivers. All currently supported devices which are not supported by native drivers will not function and will not be recognized during installation or upgrade. VCG will not show any devices not supported by a native driver as supported in vSphere 7.0. VMware vSphere 7.0 Release Notes
Ещё недавно вышел пакет Community Networking Driver for ESXi (раз, два) — тоже проверяйте.
Совет: Крайне желательно выделить свободный сервер и пробовать новые версии ПО на нем, а не на боевой среде.
Совет: Для проверки можно воспользоваться автоматическим скриптом на Python — ESXi Compatibility Checker.
Шаг 4. Глубины понимания
Для проверки совместимости продуктов VMware между собой нам нужна LACP and vSphere (ESXi) hosts: not a very good marriage
Делать или не делать LACP – выбор исключительно ваш, особенно учитывая риски нахватать проблем со стороны сети. Например:
Для упрощения работы с сетями необходимо ознакомиться с простой и давно известной в PS вещи – классами.
Пример кода для понимания
Делаем табличку вида:
Добавление на хост:
New - VirtualPortGroup - Virtualswitch $ MySwitch - Name $ MyNewVlan . VlanName - Vlanid $ MyNewVlan . VlanId
Шаг 6. Обновление FW хостов в ходе миграции
Если вы внимательно делали шаг 2, то увидели прошивки (firmware) и версии драйверов.
Зачастую для ESXi 7 нужно обновить прошивки оборудования.
При обновлении старых хостов вы можете столкнуться с массой интересного. С чем довелось столкнуться мне опишу.
На относительно свежие сервера HPE уже не выпускается Service Pack for Proliant (SPP). Кроме того, лет 5 назад SPP был доступен бесплатно, сейчас – только по подписке.
У всех вендоров встречаются свои странности в работе IPMI – например, на HPE имеется HTML5 клиент, но он не работает с ISO, связь рвется через пару минут — используйте Java. Плюс для массового обновления HPE надо отдельно разворачивать OpenView или oneview (или вручную, привет SPP). У HPE есть Lights-Out Standalone Remote Console for Windows, который я пока так и не проверил. Dell/Lenovo идут со своими чудесами. На IBM (старых, еще IBM) – IPMI крайне чувствителен к версии Java, порой до того, что надо ставить точно такую и именно такую. Архивы Java тут.
У Supermicro обновления надо искать каким-то очень специфическим образом.
У Huawei отличная утилита Smartkit (SmartKit_V2R7C00RC6SPC300.zip) из состава Fusion tools , но путь до страницы Intelligent Servers неочевиден, как и недавнее обновление Enterprise сайта в попытке сделать лучше. Теперь надо не забывать нажимать справа Большую Красную Кнопку pre-version. Впрочем, кнопка есть.
Обязательное условие для любого вендора и любых обновлений: наличие действующей поддержки от вендора. Очень желательно проведение предварительной консультации и анализа сервера, особенно старого. Особенно необходима проверка Intel Fault Diagnosis and Management (FDM).
Обратите внимание, что у VMware есть ванильная версия ESXi и вендорские (от перечисленных выше производителей). HPE сделали умнее всех, и у них теперь две вендорские версии – для серверов поновее, и для серверов постарее. На версии постарее можно поймать фиолетовый экран просто так, от какого-то более нового драйвера, так что может оказаться, что надо ставить ванильную версию. У DELL свои веселые шутки за сто.
Шаг 1. Детальная инвентаризация железа
Проблема с инвентаризацией путем ручного прощелкивания хостов в vCenter –очевидна. Это долго, это неудобно. На помощь, как всегда, приходит VMware PowerCLI — это модуль для Powershell (PS) с готовым набором командлетов для продуктов VMware. Для понимания скриптов в статье необходимы базовые знания работы PS (способность сделать $a | Get-Member, $a[0] | Format-List и $a | ft, знакомство с циклами (foreeach) и фильтрами (Where-object)).
Сначала была проведена поверхностная инвентаризация. Это просто — берем в руки powershell, ставим PowerCLI:- Запускаем интегрированную среду сценариев PS через ярлык либо Пуск – Выполнить –powershell ise.
Совет: лучше использовать vscode, но powershell ise идет в комплекте с Windows. - Запускаем командлеты в PS:
Из названия командлета неочевидно, но Connect-VIServer работает как с отдельными хостами, так и с vCenter целиком, отличается только набор доступных команд для хоста, поэтому заводим сразу и vCenter, и какой-нибудь host:Как обычно, получаем ошибку:
Connect - VIServer Error : Invalid server certificate . Use Set - PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you ’ d like to connect once or to add a permanent exception for this server .
Выглядит это страшно и ужасно, картинки тут, поэтому добавляем в наш скрипт перед подключением:
Во всплывшем окне вбиваем имя пользователя и пароль и после успешного подключения подаем команду:
При необходимости добавляем нужные поля. Сразу же копируем данные в любую таблицу — хоть Excel, хоть Calc. Тут же можно сделать get-vm и посмотреть на список VM.
Читайте также:
- Перейти в папку: