Конфликт VIB при обновлении ESXi

Дошли и у меня руки до обновления на vSphere 6.5.

Первым делом был обновлен vCenter. В силу определенных причин миграция была осуществлена на 6.5U1, поэтому в дальнейшем этот vCenter был обновлен до 6.5U2c через VAMI (https://vcsa:5480).

Ранее мы уже писали о подобных граблях при обновлении сервера IBM образом от Lenovo.

Continue reading “Конфликт VIB при обновлении ESXi”

Миграция с vCenter 5.5 на vCSA 6.5

Сначала определимся с терминами:

– vCenter – это vCenter Server, установленный на Windows Server;

– vCSA – vCenter Server Appliance – линукс с vCenter Server.

Так случилось, что апгрейд инфраструктуры до 6.5 откладывался очень долго, практически, до окончания сроков основной поддержки vSphere 5.5.

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

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

  • 6.0;
  • 6.5;
  • 6.7.

vCenter 6.7 отпал сразу, так как у нас есть хосты v5.5, а их напрямую туда не подключишь.

Так как было желание собрать vCenter на базе Appliance, то выбор очевиден в пользу 6.5.

Это встроенный Update Manager и более простой процесс миграции в дальнейшем.

Continue reading “Миграция с vCenter 5.5 на vCSA 6.5”

Ошибка при обновлении Custom Image VMware ESXi “The upgrade has VIBs that are missing dependencies”

Для большей совместимости со своим оборудованием производители серверов выпускают преднастроенные образы ESXi.

Проблемы возникают при попытке перейти с версии на версию ESXi с помощью Update Manager – вылазят ошибки с таким текстом:

При попытке заменить образ ESXi 6.0 от IBM на образ ESXi 6.7 от Lenovo получил охапку конфликтов с различными утилитами для железяк: Continue reading “Ошибка при обновлении Custom Image VMware ESXi “The upgrade has VIBs that are missing dependencies””

Обновление VMware vCenter Server с 5.5 до 6.0

Никогда такого не было, и вот опять…

Внезапно мы узнали, что vSphere 5.5 не поддерживается на новых серверах HPE BL460c Gen10, и приняли принципиальное решение двигаться дальше :).

Так как основная масса хостов – это vSphere 5.5 с одиноким 5.1, то максимально допустимая для нас версия vCenter – это 6.0. Текущий vCenter установлен на MS Windows Server, так что было принято решение там и оставаться.

Я прочитал гайд по обновлению, посмотрел пару видео, и заверте…

Continue reading “Обновление VMware vCenter Server с 5.5 до 6.0”

vSphere Spectre and Meltdown fix

Добрый вечер, коллеги.

Как вы слышали, в процессорах Intel обнаружены уязвимости «Spectre and Meltdown».

VMware не рекомендует к установке патчи, выпущенные в 2018 году для закрытия этой уязвимости.

https://kb.vmware.com/s/article/52345

«For ESXi hosts that have not yet applied one of the following patches ESXi650-201801402-BG, ESXi600-201801402-BG, or ESXi550-201801401-BG, VMware recommends not doing so at this time. It is recommended to apply the patches listed in VMSA-2018-0002 instead.» Continue reading “vSphere Spectre and Meltdown fix”

Просмотр логов на ESXi

Мы уже писали о расположении журналов событий в гипервизоре VMware ESXi –Расположение журналов в разных версиях VMware vSphere.

Вот только смотреть их было раньше неудобно: подключение к хосту по SSH или заблокированные журналы – всё это тратило время системных администраторов.

Сейчас смотреть ESXi логи очень просто – достаточно зайти в интерфейс ESXi Embedded Host Client по адресу https://hostname/ui.

Например, просмотр журнала hostd.log:

host_logsПросмотр заблокированного журнала виртуальной машины vmware.log:
vm_log

P.S. У меня поиск не работает – только подсвечивает, может так задумано или у кого-то другое поведение?

UPD: Еще есть ссылка https://hostname/host, содержащая виртуальный каталог со всеми журналами хоста. Правда, журнала ВМ (vmware.log) там нет.

Отключение VAAI ATS сердцебиений для хранилища

Иногда при обновлении прошивки на массиве производитель (HP 3PAR) рекомендует временно отключить сердцебиение VAAI для VMFS-хранилищ (точнее, вернуться к до-VAAI методу). Есть целая статья, которая описывает, как это сделать через командную строку esxcli или PowerCLI – для одного хоста.

Поделюсь тем, как это делать на нескольких хостах через PowerCLI:

Name                 Value                Type                 Description
—-                 —–                —-                 ———–
VMFS3.UseATSForHB… 1                    VMHost
VMFS3.UseATSForHB… 1                    VMHost
VMFS3.UseATSForHB… 1                    VMHost
VMFS3.UseATSForHB… 1                    VMHost
VMFS3.UseATSForHB… 1                    VMHost

Name                 Value                Type                 Description
—-                 —–                —-                 ———–
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost

Name                 Value                Type                 Description
—-                 —–                —-                 ———–
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost
VMFS3.UseATSForHB… 0                    VMHost

После окончания работ обратно включаете этот механизм, передавая значение 1.

UPD: Обратите внимание, что в примере меняется параметр для VMFS5. Если есть VMFS3 – хранилища, то надо выполнять изменение двух параметров в теле скрипта.

Релиз RVTools 3.9.2

Rob de Veij выпустил обновление своей отличной утилиты инвентаризации VMware vSphere – RVTools версии 3.9.2.

В этой версии появилась поддержка vSphere 6.5 и новые функции:

  • Используется  .NET Framework 4.
  • Используется NPOI 2.1.3.1.
  • Вход происходит быстрее.
  • RVTools больше не пишет в лог событий Windows.
  • Все закладки, относящиеся к ВМ, содержат колонку OS в соответствии VMware Tools.
  • Все закладки содержат колонку VI SDK Server.
  • Колонка vCenter UUID переименована в VI SDK UUID.
  • Закладка vInfo содержит новую колонку VI SDK API version.
  • Экпорт в Excel использует формат xlsx, все колонки имеют авторазмер.
  • Названия листов Excel соответствуют названиям закладок.
  • Аннотации можно исключить через настройки.
  • Закладка vPartition содержит новую колонку Consumed MB.
  • Папки vHealth _replica исключены из проверок на зомби-объекты.
  • Файлы *_sesparse.vmdk исключены из проверок на зомби-объекты .
  • Новая закладка с информацией о лицензиях.
  • Возможность шифровать пароль с помощью приложения PasswordEncryption.
  • Командная строка RVTools принимает зашифрованные пароли.

Metadata.pyc – update manager

Одновременно в двух ЦОДах стала наблюдаться странная фигня: обновление ESXi-хостов на базе блейдов HP стало сваливаться с ошибкой. Причем проблема была как при операции Remediate, так и при Stage.

В логах Update Manager ничего не было, в журнале esxupdage.log – странный набор предупреждений вида:

2016-12-05T11:46:20Z esxupdate: downloader: DEBUG: Downloading http://VUM:9084/vum/repository/hostupdate/HPQ/metadata-hp-esxi5.5uX-bundle-2.4-16.zip to /tmp/tmp3WpTDj…
2016-12-05T11:46:20Z esxupdate: Metadata.pyc: INFO: Unrecognized file vendor-index.xml in Metadata file

Попытки гуглить ни к чему не привели, поэтому я стал решать проблему творчески.

Была обнаружена следующая закономерность: если убрать из обновления все HP’шные апдейты, то операция Remediate успешно проходила.

В ходе решения проблемы я победил обновление vCenter&VUM с 5.5U3b до 5.5U3e. Попутно узнал, что если у вас на vCenter ОЗУ меньше 16ГБ, то будут проблемы с апгрейдом служб SSO и Inventory.

Увы – не помогло.

Заколотил в обратную зону DNS адреса всех хостов – не помогло.

И тут я вспомнил, что компания HP решила развалиться на две, вследствие чего весь серверный сегмент сидит теперь на hpe.com. А я накануне проверял, что у меня HP’шный депот в Update Manager не подключается.

hpe

Исправил в URL на HPE.COM, скачал апдейты, просканировал на совместимость и снова запустил Remediate.

Работает, ура 🙂

VMware vSphere – очередной старый баг

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

Чтение Tasks показало, что ВМ никто не выключал. Events показали, что произошла какая-то ошибка после консолидации дисков, после чего виртуальная машина была просто выключена.

Continue reading “VMware vSphere – очередной старый баг”