Zerologon check (проверка)

Как вы слышали,  в августе 2020 года была обнаружена критическая уязвимость CVE-2020-1472 в протоколе проверки пользователя контроллером домена.

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

Microsoft конечно же выпустил обновления, но кто ж их ставит, верно?

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

Поэтому я написал скрипт, который проверяет наличие требуемых обновлений на контроллерах домена Windows Server 2012 R2.

Список обновлений взят из статьи про уязвимость, а также Catalog MS, указывающего на более новые версии обновлений. В моем списке сентябрьское обновление, два августовских и перекрывающий их апдейт безопасности для Windows 2012 R2.

Обратите внимание, что для Windows 2016/2019 номера апдейтов другие!

Для запуска скрипта требуются права администратора домена, так как скрипт проходит по контроллерам и через WMI получает список установленных обновлений.

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

WARNING означает, что нужно срочно бежать и ставить обновления.

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

VCP:DCV2020 от Veeam

Наш спонсор, Veeam, выпустил обновленную версию неофициального гайда по подготовке к экзамену VMware Certified Professional on DataCenter Virtualization (VCP:DCV2020).

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

Руководство подготовлено Shane Williford и Paul Wilk, имеющими общую цифру 2x:

  • Шейн в ИТ более 20 лет;
  • Пол пока не разменял третий десяток 😉

P.S. А еще Пол похож на того мужика, что сует 1С в Кубернетис.

VMware vSphere Quick (Re)Boot

В платформе VMware vSphere 6.7 появилась технология vSphere(ESXi) Quick Boot, предназначенная для быстрой перезагрузки ESXi хостов во время обновлений с помощью vSphere Update Manager.

Технология требует соблюдения нескольких условий, описанных в БЗ Understanding ESXi Quick Boot Compatibility (52477):

  1. Модель сервера находится в VMware HCL (функция QuickBoot для ESXi 7.0+)  либо хранится локально в ESXi 6.7 в текстовых файлах.
  2. Выключена технология TPM.
  3. Нет passthru-устройств, подключенных к ВМ с хоста.
  4. Не загружены vmklinux-драйверы на хосте.

В vSphere 7.0 третье ограничение снято, а четвертое отсутствует архитектурно.

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

Пример вывода на стендовом хосте:

Для быстрого обновления хостов технология включается в vSphere 7+ Menu->Lifecycle Manager-> Images/Baselines Remediation Settings->Quick Boot. Сокращение времени установки равно времени проверок UEFI при полной перезагрузке хоста.

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

Вариант с Reddit:

Вариант от Jiří Viktorin:

Прошу проголосовать за добавление функционала в графический интерфейс на портале по сбору идей vSphere Ideas, авторизация стандартная от vmware.com.

Анонс VMware vSphere 7 Update 1, vSAN 7 Update 1 и Cloud Foundation 4.1

Компания VMware сегодня анонсирует обновления своих инфраструктурных продуктов VMware vSphere 7 Update 1, VMware vSAN 7 Update 1 и VMware Cloud Foundation 4.1:

  • МонстроВМ – vSphere 7 Update 1 поддерживает ВМ до 24 ТБ ОЗУ и до 768 вЦПУ для расширения поддержки база данных, работающих целиком в памяти.
  • Cluster Scale Enhancements – в vSphere 7 Update 1 расширена поддержка кластеров на 50% – до 96 узлов в кластере.
  • HCI Mesh – в vSAN 7 Update 1 представлен HCI Mesh,предназначен для разделения вычислительных мощностей и ресурсов хранения, что позволит планомерно масштабировать инфраструктуру в течение длительного периода. Теперь можно использовать хранилища с чужих VSAN-кластеров, при наличии лицензий.
  • Compression-Only Option – vSAN 7 Update 1 разрешает использовать компрессию без дедупликации, скорость должна вырасти ;).
  • Enterprise-Ready File Services – vSAN 7 Update 1 поддерживает протоколы SMB v3 и v2.1. vSAN File Services получил интеграцию с Active Directory и аутентификацию по Kerberos.
  • Remote Clusters – новая возможность для управления удаленными кластерами в  VMware Cloud Foundation 4.1 расширяет операционные возможности на периметральных локациях и в филиалах.
  • vVols Integration – новая интеграция vVols в VMware Cloud Foundation 4.1 с Tanzu предоставляет единый фреймворк для работы с внешними хранилищами.
  • VMware Skyline Support for VMware Cloud Foundation – проактивный анализ VMware Skyline теперь и в VMware Cloud Foundation.

Update 16092020

Запись вебинара на русском языке

https://cormachogan.com/2020/09/15/vsan-7-0u1-whats-new/

All About vSphere 7 U1 Features

Introducing VMware vSphere and vSAN 7 Update 1 and VCF 4.1

What’s new for vSAN 7.0 U1!?

vSphere 7 Update 1 – vSphere Lifecycle Manager Improvements

vSphere 7 Update 1 – AMD SEV-ES

What’s New with VMware vSphere 7 Update 1

Announcing vSAN Data Persistence Platform

What’s New in vSAN 7 Update 1

Хождение по граблям VMware vSphere 7.0

Цикл статей о борьбе с VMware vSphere 7.0 продолжается. Читайте содержимое предыдущих серий:

Обновление IBM/LENOVO System X M5 Embedded Hypervisor on SD-card до версии ESXi 7.0

Обновление VMware vCenter с версии 6.7 до 7.0

VMware ESXi 7.0 и неподдерживаемое оборудование

Снимки ВМ и NetApp FAS ONTAP

Самая жёсткая проблема, с которой столкнулись — это переход LUN’ов на системе хранения NetApp FAS в режим Offline при попытке сделать снимок из-под vSphere 7.0 с ошибкой “Out of space”.

Предположительно, проблема связана с All Flash LUN’ами, созданными в ONTAP версии 9.1 или 9.2. Проблема наблюдается в ONTAP 9.7P4, более поздние патчи не проверяли.

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

Решение проблемы:

  1. Вернуть LUN в Online.
  2. Если при Rescan Storage не вернулось DataStore на хостах, то перезагрузить хосты.
  3. Смигрировать ВМ на другой LUN.
  4. Пересоздать проблемный LUN (*либо устранить корневую причину).
  5. Смигрировать ВМ обратно.

vLCM Image и Intel VMD NVMe Driver

Самая весёлая проблема, которая убила кучу времени.

При переводе кластеров с модели обновления Baseline на модель обновления Image поймали отличный конфликт компонентов там, где не ожидали.

Про драйвер читать в статье:

VMware ESXi, VSAN и Intel VMD-Enabled NVMe Driver

На текущий момент в VSAN HCL рекомендуется версия драйвера intel-nvme-vmd-2.0.0.1146, в стандартном же образе зашит другой драйвер iavmd 2.0.0.1055-3vmw.700.1.0.15843807. При попытке собрать образ, совместимый с VSAN HCL получаем невозможность установить компоненты HA. Валят скопом такие ошибки:

  • vSphere HA host status/Cannot find HA master agent
  • vSphere HA agent for this host has an error: vSphere HA agent cannot be installed or configured
  • Component vsphere-fdm cannot be found in depot
  • ‘vxd’ service, runnig on ‘cluster’, reported issue: The HA constraints in the image spec have version whereas the expected version is 7.0.0.-16386338

Решение проблемы:

  1. Отключить HA.
  2. Добавить в image драйвер intel-nvme-vmd-2.0.0.1146.
  3. Накатить на  хост image.
  4. Убрать из image intel-nvme-vmd-2.0.0.1146.
  5. Включить HA.

В итоге, проходим проверку на VSAN HCL и получаем Warning при проверке Image Compliance.

Update 11092020. 10.09.2020 драйвер iavmd 2.0.0.1055-3vmw.700 добавлен в VSAN HCL.

Image не накатывается на хосты

Ещё одна весёлая проблема, при попытке пройти проверку или накатить Image получаем шедевральную ошибку:

Unknown error occurred when invoking host API.

Самое тупое решение:

  1. Cделать сброс БД менеджера обновлений —  Resetting VMware Update Manager Database on a vCenter Server Appliance 6.5/6.7/7.0 (2147284).
  2. Перезагрузить хост.
  3. Запустить обновление снова.

Не работает vLCM Image Export

Для переноса сборки Image между кластерами или vCenter разработчики предусмотрели вариант выгрузки собранной вами конструкции.

Существует три варианта экспорта:

А теперь о проблеме: если вы используете свои сертификаты, то ни одна опция не работает, происходит ошибка браузера “ERR_SSL_PROTOCOL_ERROR”.

Решение проблемы, конкурирующие с предыдущим по интеллектуальности и попахивает уязвимостью (неавторизованный доступ):

  1. Скопировать ссылку из адресной строки браузера.
  2. Открыть приватное окно.
  3. Вставить ссылку в адресную строку.
  4. Заменить протокол с https на http и получить ожидаемое.

Обновление IBM/LENOVO System X M5 Embedded Hypervisor on SD-card до версии ESXi 7.0

Семейство серверов IBM/LENOVO System X  серии M5 может иметь предустановленный Embedded Hypervisor на SD-карте с совместимой версией ESXi 6.x.

При попытке обновиться до версии ESXi 7.0 выходит ошибка:

Управление SD-картой осуществляется в интерфейсе IMM2. Анализ адаптера показывает, что в реальности используются 32 ГБ карты, но на заводе создан виртуальный диск на 1 ГБ. Расширение размеров не поддерживается.

Для установки ESXi 7.0 придётся прибегнуть к обходной схеме:

  1. Сделать резервную копию конфигурации ESXi – подробно описано в How to back up ESXi host configuration (2042141).
  2. Переформатировать SD-карту на 30 ГБ (максимально доступный размер).
  3. Установить чистый ESXi 6.x (версии, с которой снята резервная копия).
  4. Настроить сеть.
  5. Восстановить из резервной копии конфигурации по инструкции из пункта 1.
  6. Накатить обновление до ESXi 7.x.

P.S. Возможно, данная проблема встречается и на серверах других производителей с предустановленным гипервизором.

Много проблем с VMware Data Recovery

Много лет назад VMware решили, что неплохо было бы сделать свой бэкап-софт для виртуальной среды. Так и появился VMware Data Recovery.

Софт был несколько глючный, поэтому через несколько версий/лет (и объединение с EMC) VMware похоронило свою разработку и сделало vDP на базе EMC Avamar.

На этом глюки поуменьшились, но VMware и этого было мало, вследствие чего поддержка vDP была окончательно похоронена (в 2019 или 2020 году)…

  1. Как-то сдох у меня основной сторадж, на котором лежало все: виртуалки, контроллер домена, vcenter 6.0. Остался жить только vdp и еще один виндовый сервер, лежащие на локальных дисках ESXi. Стоит отметить, что места на локальных дисках ESXi под все виртуальные сервера из бэкапа не было. Но это не стало основной проблемой 😉
  2. Я зашел на веб-интерфейс vDP и запустил Emergency Restore трех продуктивных виртуальных машин (топ по критичности). Это была главная ошибка: надо было сначала восстанавливать DC/VC.
  3. Три критичных виртуалки восстановились, после чего веб-интерфейс vDP отмер – по таймауту. В течение суток и пары ребутов vDP восстановить его не удалось, пошли в саппорт.
  4. Ахмед сказал, что vDP окончательно слетел с саппорта и добавил: “я не гинеколог, но посмотреть могу”. Посмотрел на мое горе, посоветовал развернуть максимально свежую версию vDP и вставить диски туда/либо развернуть vDP 6.1.2 и подоткнуть диски туда.
  5. В штатном режиме vDP развертывается (ovf deploy) только через vCenter. 😉 (Ох щит) (это знак, что стоило сесть за чтение документации по развертыванию vDP)
  6. Я отредактировал вручную .OVF и успешно импортировал виртуальную машину;
  7. Затем я научился менять ip-настройки SLES11 из командной строки;
  8. После этого запустился инсталлятор vDP из веб-интерфейса и… напоролся на проблемы с отсутствием записей DNS.
  9. Ну вы помните, что у меня рабочих систем нет и я работаю в выжженом поле 😉 Ладно, побороли и DNS.
  10. На следующем шаге vDP сказал, что ему нужна для развертывания регистрация в vCenter. АААааааа 😊
  11. В силу ограниченных ресурсов я попытался развернуть vCSA 6.0. Ожидаемо встал на грабли плагина интеграции с браузером, который не захотел устанавливаться.
  12. Мыши плакали, кололись, но продолжали есть кактус.
  13. Я решил рискнуть костями и поставить vCSA 6.5. Да, по матрице он не совместим с vDP 6.1.2, но мало ли что. Впрочем, vCenter развернулся штатно (хоть что-то).
  14. Ожидаемо, регистрация vDP 6.1.2 на vCSA 6.5 не проходит. (непереводимая игра слов)
  15. Развернул через vCenter vDP 6.1.11 – он нормально прошел регистрацию на vCSA 6.5. С замиранием духа втыкаю в него VMDK от старого vDP и прожимаю импорт. Через полчаса…
  16. Через полчаса vDP 6.1.11 говорит, что пароль рута к дискам не подходит. Кстати говоря, эта же проблема имела место год назад. Тогда vDP 6.1.2 не стартовал, импорт дисков не помогал. Тогда vDP мне починил инженер из саппорта (фактически, специалист по Авамару и линуксу, судя по тому трешу, что он творил в консоли)
  17. Остается обратно лохматить старый и неподдерживаемый vDP.
  18. Обратно включаем с дисками старый vDP 6.1.2.
  19. Веб-интерфейс старого vDP открывается, но говорит “ждите до 25 минут, запускаемся”;
  20. В консоли старого vDP вижу, что не запускается служба MCS из-за проблем с чекпоинтами. К счастью есть статья в КБ (https://kb.vmware.com/s/article/2053986), служба запускается и…
  21. Еще минут через 5-10 запускается веб-интерфейс. И я могу продолжать emergency restore!!!11111

Выводы:

  1. Никогда. Не. Используйте. VMware Data Recovery!
  2. В DR-план восстановления инфраструктуры заложите восстановление самого сервера резервного копирования в случае какого-либо сбоя. Ну и тестируйте это (DR – Disaster Recovery, восстановление после катастрофы)!
  3. Я крайне не рекомендую использование в продуктиве софта, для DR-переустановки которого требуется куча “левых” компонент типа vCenter.

P.S. Впрочем, это одна из причин, по которой VMware “мигрировали” vDP на Avamar. До Avamar vDP метаданные держал в базе vCenter. Нет vCenter – ну вы поняли 😉

VMware ESXi 7.0 и неподдерживаемое оборудование

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки VMware. Любое использование оборудования вне VMware HCL может быть использовано только на свой страх и риск. В статье рассматривается только то оборудование, на котором возможен технический запуск ESXi 6.7U3.

В связи с выходом платформы VMware vSphere 7.0 виртуальные системные администраторы стали анализировать возможность обновления либо внедрения данного продукта.

Если проблемы с vCenter 7.0 вполне решаемы и описаны в нашей статье Обновление VMware vCenter с версии 6.7 до 7.0, то с ESXi 7.0 всё не так просто.

Для “упрощения” работы администраторов VMware расширила функциональность Update Manager (VUM) полуавтоматическим анализом оборудования: сверкой моделей серверов с HCL, проверкой версий прошивок и драйверов компонентов. Данная функциональность уже была частично представлена  в VSAN [Skyline] Health Hardware compatibility для дисковой подсистемы. Новая версия VUM стала называться vSphere Lifecycle Manager (vLCM). Для загрузки HCL следует в административном интерфейсе нажать ACTIONS->Sync HCL.

Мои ожидания от vLCM были примерно такие – запускаю на хосте Updates -> Hardware Compatibility и система пишет, что оборудование не в HCL, такие-то компоненты не имеют драйверов и не будут работать. В реальности, если сервер не в HCL, то на этом проверка останавливается:

Host model is not compatible with ESXi 7.0
Skipped checking host devices.

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

Поэтому с компонентами придётся разбираться самостоятельно. Continue reading “VMware ESXi 7.0 и неподдерживаемое оборудование”

Обновление VMware vCenter с версии 6.7 до 7.0

Дождавшись выхода VMware vSphere 7.0.0b, мы решились на обновление нашей инфраструктуры, построенной на платформе версии 6.7.

Для уменьшения количества граблей внимательно прочитали следующие документы:

Проблема с сертификатами

При попытке обновления вылезла ошибка с сертификатами:

Error: A vCenter Single Sign-On endpoint certificate validation error has occurred.
Resolution: Ensure that the endpoint service registrations in vmdir match their corrsponding machine SSL certificates in VECS. For more information, see Knowledge Base article KB 2121701

Как это бывает, КБшка не помогла, как и не помог совет в форуме VMware.

Обратились в ТП VMware, получили волшебный скрипт и инструкцию: ls_ssltrust_fixer_p3.

  1. Проверить наличие актуальной резервной копии и сделать snapshot.
  2. Подключиться к vCenter по SSH.
  3. Скопировать “ls_ssltrust_fixer.py” в папку /usr/lib/vmidentity/tools/scripts (например, с помощью WinSCP).
    1. Перейти в папку:
    2. Изменить права:
  4. Выполнить проверку ошибок “certificate thumbprint mismatch” с помощью команды:
  5. Выполнить исправление ошибок “certificate thumbprint mismatch” с помощью команды:

После магических пасов руками 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 ;). Требуется перенастройка.

VeeamOn Tour 2020

Всем доброго времени суток.

25 июня с 11:00 до 13:40 компания Veeam приглашает всех на конференцию VeeamOn Tour 2020. Из-за того, чье имя нельзя называть, встреча будет проходить в онлайн-режиме.

На выбор доступны 6 технических сессий:

  1. реализация Veeam NAS Backup в версии 10;
  2. практические рекомендации по защите данных от программ вымогателей;
  3. рекомендации по планированию инфраструктуры Veeam Backup & Replication v10;
  4. лучшие практики и рекомендации для успешной работы с Veeam Agents;
  5. все об интеграции с СХД и новые возможности Veeam v10;
  6. защита данных облачного Microsoft Office 365.

Будут сессии по облачной стратегии защиты данных.

Участие бесплатное, требуется регистрация.

P.S. Если желаете вспомнить, как это было в офлайн-эпоху, есть фотоотчет о посещении VeeamOn Tour 2016.

P.P.S. По данному тэгу вы можете просмотреть ссылки на конференции, проходившие в прошлых годах.