Diagnostics for VMware Cloud Foundation — это централизованная платформа, которая отслеживает общее состояние работы программного стека VMware Cloud Foundation (VCF). Это платформа самообслуживания, помогающая анализировать и устранять неполадки компонентов VMware Cloud Foundation, включая vCenter, ESX, vSAN, а также возможностей, таких как vSphere vMotion, снапшоты, развертывание виртуальных машин (VM provisioning), и других аспектов, включая уведомления безопасности и сертификаты. Администратор инфраструктуры может использовать диагностические данные, чтобы контролировать текущее состояние своей среды.

Диагностические результаты (Findings)

Результаты диагностики, которые ранее предоставлялись через Skyline Advisor и Skyline Health Diagnostics, теперь доступны клиентам VCF и vSphere Foundation (VVF) в рамках продукта VCF Operations. Результаты приоритизируются по:

• Часто встречающимся проблемам, выявленным службой технической поддержки Broadcom.
• Вопросам, поднятым в рамках анализа эскалаций (post escalation review).
• Уязвимостям безопасности.
• Проблемам, выявленным инженерными командами Broadcom.
• Рекомендациям от клиентов.

В последнем релизе VCF Operations выпущено 114 новых диагностических результатов (Findings):

• 83 — основаны на часто встречающихся проблемах.
• 15 — по результатам анализа эскалаций.
• 14 — связаны с уязвимостями безопасности (VMSA).
• 2 — по запросам клиентов.

Из них:

• 62 результата состояния (Health Findings) — эквивалентны результатам Skyline Advisor и автоматически проверяются каждые 4 часа.
• 52 результата на основе логов (Log-based Findings) — эквивалентны Skyline Health Diagnostics и инициируются вручную через интерфейс конфигурации.

Эти новые находки включены в VCF Operations 9.0.1 (Release Notes). Давайте посмотрим на некоторые примеры этих результатов.

Уязвимости безопасности

В VMSA-2025-0010 описана уязвимость аутентифицированного выполнения команд в VMware vCenter Server (CVE-2025-41225) и уязвимость межсайтового скриптинга (XSS) в VMware ESXi и vCenter Server (CVE-2025-41228). Злоумышленник, обладающий привилегиями для создания или изменения тревог (alarms) и выполнения действий сценариев (script action), может воспользоваться данной уязвимостью для выполнения произвольных команд на сервере vCenter.

Злоумышленник, имеющий сетевой доступ к странице входа определённого хоста ESX или к путям URL сервера vCenter Server, может использовать эту уязвимость для кражи cookie-файлов или перенаправления пользователей на вредоносные веб-сайты. Эта уязвимость устранена в vCenter Server 8.0 Update 3e.

Анализ после эскалации (Post Escalation Review)

Техническая поддержка Broadcom внедрила процесс Post Escalation Review, в рамках которого критические обращения анализируются для предотвращения подобных инцидентов в будущем. Одним из результатов такого анализа является создание новых диагностических результатов.

Например, KB #370670:

Хосты ESX могут терять подключение к vCenter из-за чрезмерной скорости логирования, что приводит к потере сообщений syslog и невозможности записи сервисных логов. Часто проблема наблюдается при включении дополнительного логирования NSX, когда файл dfwpktlogs.log превышает допустимую скорость записи syslog. Однако причиной может быть и любая другая служба, создающая чрезмерный объём логов. Данный результат отображается при появлении соответствующих сообщений в vmkernel.log на хосте ESX.

Часто встречающиеся проблемы (Trending Issues)

KB 383273:

На хостах ESXi 8.0.2 и 8.0.3 фиксируются предупреждения “Miss counters detected” для драйверов Mellanox с ошибкой

nmlx5_QueryNicVportContext:188 command failed: IO was aborted.

Это известная ошибка в механизме проверки состояния драйвера, при которой NIC ошибочно определяется как неисправный. Исправлено в ESX 8.0 Update 3e (драйвер nmlx5 версии 4.23.6.5).

KB 318712:

Во время выполнения VCF Operations for Logs Query хост ESX сообщает о состоянии Permanent Device Loss (PDL). В Storage View хранилище отображается как недоступное, а адаптер сообщает об утере связи с устройством (Lost Communication). Все пути к устройству помечаются как «мертвые» (All Paths Down, APD). В результате невозможно подключиться к хосту через vSphere Client, и хост отображается как Disconnected в vCenter. Данный результат фиксируется при обнаружении соответствующих сообщений в vmkernel.log.

Находки, предложенные клиентами (Findings Nominated)

Главная цель команды Diagnostics — удовлетворённость клиентов. VMware стремится защитить их инфраструктуру, предоставляя результаты, основанные на опыте работы службы поддержки Broadcom, также принимаются предложения и от пользователей.

Так, например, появилась KB #385443:

На узлах vSAN происходит PSOD (Purple Screen of Death) из-за «зависших» операций ввода-вывода после сбоя диска. Команда ввода-вывода помечается как «застрявшая», а когда она завершается, соответствующие объекты уже освобождены, что вызывает сбой. Исправлено в ESX 8.0 Update 3e.

Чтобы ознакомиться со всеми диагностическими результатами в Diagnostics for VMware Cloud Foundation, откройте Findings Catalog в разделе Diagnostics Findings интерфейса VCF Operations. Для получения актуальных обновлений подпишитесь на Diagnostics for VMware Cloud Foundation Findings KB — он обновляется при каждом выпуске нового пакета или обновлении встроенных диагностических данных.

VMware представила унифицированный фреймворк разработки VCF SDK 9.0 для Python и Java.

Улучшение опыта разработчиков (Developer Experience) — один из главных приоритетов в дальнейшем развитии платформы VMware Cloud Foundation (VCF). Если рассматривать автоматизацию в целом, то можно выделить две чёткие категории пользователей: администраторы и разработчики.

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

Разработчики, напротив, ориентированы на интеграцию возможностей VCF в пользовательские приложения и решения. Им необходимы API и SDK, обеспечивающие программный доступ к сервисам и данным VCF, позволяя разрабатывать собственные инструменты, сервисы и расширения. Потребности в автоматизации у этих двух групп значительно различаются и соответствуют их уникальным ролям в экосистеме VCF. Понимая эти различия, Broadcom предлагает набор интерфейсов прикладного программирования (API), средств разработки (SDK) и разнообразных инструментов автоматизации, таких как PowerCLI, Terraform и Ansible.

Оглядываясь назад, можно сказать, что VMware хорошо обслуживала сообщество администраторов, предоставляя им различные инструменты. Однако API и SDK требовали улучшения в области документации, лучшей интеграции с VCF-стеком в целом и упрощения процесса для разработчиков. До выхода VCF 9.0 разработчики использовали отдельные SDK решений, сталкиваясь с трудностями, связанными с их интеграцией — такими как совместимость, аутентификация и сложность API. С выходом VCF 9.0 VMware рада объявить о доступности Unified VCF SDK 9.0. Давайте подробнее рассмотрим, что это такое.

Unified VCF SDK

Unified VCF SDK доступен с привязками к двум языкам — Java и Python. Это объединённый SDK, который включает в себя все основные SDK решений VCF в единый, упрощённый пакет. В своей первой версии Unified VCF SDK объединяет существующие SDK и добавляет новые библиотеки для установщика VCF и менеджера SDDC.

Список компонентов VCF, включённых в первую версию Unified VCF SDK:

• VMware vSphere
• VMware vSAN
• VMware Cloud Foundation SDDC Manager (новый)
• VMware Cloud Foundation Installer (новый)
• VMware vSAN Data Protection

Несмотря на то, что Unified VCF SDK поставляется как единый пакет, пользователи могут устанавливать и использовать только те библиотеки, которые необходимы для конкретных задач.

Для краткости в этом тексте Unified VCF SDK будет обозначаться как VCF SDK.

Преимущества

VCF SDK обеспечивает простой, расширяемый и единообразный опыт для разработчиков на протяжении всего жизненного цикла разработки.

Упрощённый жизненный цикл разработчика

С этим релизом были стандартизированы методы доставки и распространения, чтобы поддерживать различные сценарии развертывания:

• Онлайн-установка через PyPI (Python) и Maven (Java) — для прямого доступа и лёгкой установки/обновлений.
• Офлайн-установка через портал разработчиков Broadcom — идеально для сред с ограниченным доступом в интернет.
• Готовность к CI/CD — интеграции через пакеты и инструкции, размещённые на GitHub, для бесшовного включения в автоматизированные пайплайны при установке и обновлении.

Улучшенная документация и онбординг

VMware переработала документацию, чтобы упростить старт:

• Руководства по началу работы для Python и Java.
• Примеры кода для быстрого освоения.

OpenAPI-спецификация

OpenAPI-спецификация описывает API в стандартизированном машинно-читаемом формате (YAML/JSON). С выходом VCF SDK были также публикованы OpenAPI-спецификации для API-эндпоинтов. Это не просто документация — это шаг к философии API-first и ориентированности на разработчиков.

С помощью OpenAPI-спецификаций разработчики могут:

• Автоматически генерировать клиентские библиотеки на предпочитаемых языках с помощью инструментов вроде Swagger Codegen, Kiota или OpenAPI Generator.
• Загружать спецификации в такие инструменты, как Swagger UI, Redoc или Postman, чтобы визуально исследовать доступные эндпоинты, параметры, схемы ответов и сообщения об ошибках.
• Понимать структуру API и его поведение.

Скачать OpenAPI-спецификацию можно с портала разработчиков Broadcom или из репозитория GitHub.

VCF Python SDK

VCF Python SDK включает в себя следующие модули:

Каналы распространения

Unified VCF SDK доступен через различные каналы распространения. Это сделано для того, чтобы удовлетворить потребности разных типов сред и разработчиков — каждый может получить доступ к SDK в наиболее удобном для него месте. Ниже перечислены доступные каналы, откуда можно загрузить VCF SDK.

Портал разработчиков Broadcom

VCF Python SDK доступен для загрузки на портале разработчиков Broadcom. Вы можете распаковать содержимое ZIP-архива vcf-python-sdk-9.0.0.0-24798170.zip, чтобы ознакомиться с библиотеками SDK, утилитами и примерами. Однако сторонние зависимости не входят в состав архива — они перечислены в файле requirements-third-party.txt, находящемся внутри vcf-python-sdk-9.0.0.0-24798170.zip.

Файлы .whl компонентов VCF SDK находятся в папках ../pypi/*, а примеры кода для компонентов расположены в директориях вида /<имя_компонента>-samples/.

PyPI

VCF SDK доступен в PyPI, что позволяет разработчикам устанавливать и обновлять модуль онлайн. Это самый быстрый способ начать работу с VCF SDK.

Чтобы установить VCF SDK, выполните следующую команду:

Пакеты, установленные через pip, можно автоматически обновлять. Чтобы обновить VCF SDK, используйте команду:

Чтобы установить конкретную библиотеку из состава VCF SDK, выполните:

Примеры:

$ pip install pyvmomi
$ pip install vcf-installer

GitHub

Разработчики также могут скачать пакет VCF SDK из репозитория VMware на GitHub.

VCF Java SDK

VCF Java SDK включает в себя следующие артефакты:

Каналы распространения

Аналогично Python SDK, JAVA SDK также доступен через различные каналы распространения, что позволяет использовать его в самых разных средах.

Портал разработчиков Broadcom

VCF Java SDK доступен для загрузки на портале разработчиков Broadcom. Вы можете распаковать содержимое ZIP-архива vcf-java-sdk-9.0.0.0-24798170.zip, чтобы ознакомиться с библиотеками SDK, утилитами и примерами.

Файлы привязок SDK .jar, утилит .jar, а также BOM-файлы находятся в папке:

Maven

Артефакты VCF SDK доступны в Maven Central под groupId: com.vmware.sdk. В таблице ниже указаны данные об артефактах VCF SDK для версии 9.0.0.0.

Чтобы начать работу с VCF SDK, добавьте зависимость в файл pom.xml вашего проекта:

<dependencies>
<dependency>
<groupId>com.vmware.sdk</groupId>
<artifactId>vcf-sdk</artifactId>
<version>9.0.0.0</version>
</dependency>
</dependencies>

GitHub

Разработчики также могут скачать пакет VCF SDK из репозитория VMware на GitHub.

Журнал изменений API

С выходом VCF 9.0 VMware начала публиковать журнал изменений API. В нём отражаются все изменения: новые API, обновления существующих и уведомления об устаревании. Ознакомиться с журналом изменений можно здесь.

Ресурсы

• Release Notes
• API Change Log
• Broadcom Developer Portal
• VCF Python SDK on PyPI 
• VCF Java SDK on Maven 

Репозитории Github:

• VCF Python SDK 
• VCF JAVA SDK
• VCF OpenAPI Specifications

Страницы Getting Started:

• Getting Started with VCF Python SDK
• Getting Started with VCF JAVA SDK 
• Getting Started with VCF OpenAPI Specification

Заключение

С выпуском VMware Cloud Foundation 9.0 объединение различных библиотек в один SDK с улучшенной документацией, примерами кода и спецификацией OpenAPI — это важный шаг к простому, расширяемому и согласованному опыту для разработчиков.

Следующий шаг за вами — попробуйте Unified VCF SDK 9.0 и поделитесь с нами своими отзывами.

Интеграция VMware vCenter Server с Active Directory (AD) позволяет централизовать управление учетными записями и упростить администрирование доступа. Вместо локальной базы пользователей vCenter можно использовать доменную инфраструктуру AD или другой LDAP-сервис как единый источник аутентификации. Это означает, что администраторы vSphere смогут применять те же учетные записи и группы, что и для остальных ресурсов сети, для доступа к объектам vSphere.

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

$roles = Get-VIRole
$permissions = Get-VIPermission

$results = @{}
foreach ($permission in $permissions) {
    $role = $permission.Role
    if($results.ContainsKey($role)) {
        $results[$role]+=1
    } else {
        $results[$role]=1
    }
}

Write-Host "`nTotal Roles: $($roles.count)"
Write-Host "Total Roles Used: $($results.count)"
Write-Host "Role Usage:"

$results.GetEnumerator() | Sort-Object -Property Value -Descending

$outfile = "used-roles.txt"
foreach ($key in $results.keys) {
    $role = Get-VIRole $key
    if(!$role.IsSystem) {
        $key | Out-File -Append -LiteralPath $outfile
        "=========================================================" | Out-File -Append -FilePath $outfile
        $role.ExtensionData.Privilege | Out-File -Append -LiteralPath $outfile
        "" | Out-File -Append -LiteralPath $outfile
    }
}

Вот пример выполнения сценария:

А вот пример вывода из файла used-roles.txt, который генерируется и содержит список привилегий для каждой используемой роли:

Если вы пропустили новость о том, что вышло обновление платформы VMware vSphere 8 Update 3b, то сейчас самое время подумать об обновлении, так как сообщений о каких-то серьезных багах не поступало.

Итак, что нового в VMware ESXi 8.0 Update 3b:

• DPU/SmartNIC - появилась поддержка VMware vSphere Distributed Services Engine с DPU NVIDIA Bluefield-3. Устройства DPU NVIDIA Bluefield-3 поддерживаются как в режиме одиночного DPU, так и в dual-DPU конфигурациях.
• ESXi 8.0 Update 3b добавляет поддержку vSphere Quick Boot для нескольких серверов, включая:
  • HPE ProLiant DL145 Gen11
  • HPE ProLiant MicroServer Gen11
  • Cisco UCSC-C245-M8SX
  • Supermicro AS-2025HS-TNR

Для полного списка поддерживаемых серверов смотрите VMware Compatibility Guide.

• Улучшения в проектировании переменных cloud-init guestInfo: начиная с ESXi 8.0 Update 3b, попытка обычных пользователей задать переменные cloud-init guestInfo внутри гостевой ОС приводит к ошибке. Для получения дополнительной информации см. KB 377267.

Что нового в VMware vCenter 8.0 Update 3b:

• Этот выпуск устраняет уязвимости CVE-2024-38812 и CVE-2024-38813. Для получения дополнительной информации об этих уязвимостях и их влиянии на продукты VMware посмотрите статью VMSA-2024-0019.
• VMware vCenter Server 8.0 Update 3b предоставляет исправления ошибок, описанные в разделе Resolved Issues.
• Для информации об обновлениях VMware vSphere with Tanzu смотрите Release Notes для VMware vSphere IaaS Control Plane 8.0.
• Для информации об обновлениях Photon OS смотрите обновления безопасности VMware vCenter Server Appliance Photon OS.

Если вы не знаете, как скачать VMware vSphere 8 Update 3b, воспользуйтесь информацией по этой ссылке.

На днях компания VMware выпустила обновления для своей флагманской платформы VMware vSphere 8 Update 2 - ESXi 8.0 Update 2b и vCenter 8.0 Update 2b.

Что нового появилось VMware ESXi 8.0 Update 2b:

• 100 GiB пробной емкости хранения на каждое ядро vSAN - начиная с vSphere 8.0 Update 2b, в рамках предложения VMware vSphere Foundation, вы можете использовать до 100 гибибайт (GiB) хранилища vSAN на каждое лицензированное ядро хоста vSAN без применения лицензионного ключа vSAN. Для емкости, превышающей 100 GiB на каждое ядро vSAN, вы можете приобрести емкость vSAN на тебибайт (TiB) и применить ключ vSAN, отражающий общую сырую емкость хранилища кластера vSAN. Для получения дополнительной информации о отчетах по емкости и лицензировании vSAN смотрите "Разъяснение отчетности по емкости в vSAN" и "Подсчет ядер для VMware Cloud Foundation и vSphere Foundation и TiB для vSAN".
• Добавлена поддержка технологии vSphere Quick Boot для множества серверов: 
  • Dell - MX760c vSAN Ready Node, PowerEdge C6615, PowerEdge XR8610t, R7625 vSAN Ready Node, VxRail VP-760xa, VxRail VS-760
  • HPE - Alletra Storage Server 4110/4140, Cray XD670, ProLiant DL110 Gen11/DL20 Gen11/ProLiant ML30 Gen11
  • Lenovo DN8848 V2
• Исправлена ошибка с необнаружением Apple NVMe на Apple Mac Mini 2018. Об этом написал Вильям Лам.

Более подробно об обновлении VMware ESXi 8.0 Update 2b написано в Release Notes.

Что нового появилось VMware vCenter Server 8.0 Update 2b:

• Агрегация статистики по GPU на уровне хоста и кластера - в этом обновлении vCenter вы можете отслеживать агрегацию метрик GPU на уровне хоста и кластера, что полезно для нагрузок генеративного искусственного интеллекта, традиционных нагрузок AI и других, ускоренных с помощью GPU. В клиенте vSphere, в разделе Monitor > Performance, вы увидите:
  • на уровне хоста: обзорные диаграммы производительности и расширенные диаграммы производительности для использования вычислений на GPU, распределения памяти и температуры на хостах.
  • на уровне кластера: расширенные диаграммы производительности с агрегированной статистикой от хостов для памяти GPU и использования GPU.
• Для получения дополнительной информации смотрите "Работа с расширенными и пользовательскими диаграммами" и "Обзорные диаграммы производительности".
• Обновления vSphere with Tanzu (подробности тут) и Photon OS (подробности здесь).

Более подробно об обновлении vCenter Server 8.0 Update 2b написано в Release Notes.

Скачать VMware vSphere 8 Update 2, включая ESXi 8.0 Update 2b и vCenter Server 8.0 Update 2b можно по этой ссылке.

Конструктор лаборатории VMware Cloud Foundation Lab Constructor (VLC) Holodeck Toolkit предназначен для обеспечения масштабируемого, повторяемого способа развертывания вложенных сред VMware Cloud Foundation (VCF) непосредственно на хостах VMware ESXi. Эти среды идеально подходят для практических занятий нескольких команд, изучающих возможности VCF и реализации управляемого заказчиком облака VMware.

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

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

• Снижение требований к оборудованию - при работе в физической среде VCF требует четыре узла vSAN Ready Nodes для домена управления и дополнительные хосты для создания кластеров и доменов рабочих нагрузок. Во вложенной среде те же четыре-восемь хостов легко виртуализируются для работы на одном хосте ESXi.
• Самодостаточные сервисы - конфигурация Holodeck Toolkit предоставляет общие инфраструктурные сервисы, такие как NTP, DNS, AD, сервисы сертификатов и DHCP внутри среды, исключая необходимость полагаться на сервисы центра обработки данных во время тестирования. Каждой среде требуется один внешний IP.
• Изолированная сеть - конфигурация Holodeck Toolkit устраняет необходимость в соединениях VLAN и BGP в сети клиента на ранних этапах тестирования.
• Изоляция между средами - каждая развертываемая среда Holodeck полностью самодостаточна. Это избегает конфликтов с существующими сетевыми конфигурациями и позволяет развертывать множество вложенных сред без опасений насчет перекрытия.
• Множественные развертывания VCF на одном хосте VMware ESXi с достаточной мощностью - типичное развертывание стандартной архитектуры VCF с четырехузловым доменом управления и четырехузловым доменом рабочих нагрузок VI, а также дополнениями, такими как VMware vRealize Automation, требует примерно 20 ядер процессора, 512 ГБ памяти и 2.5 ТБ диска.
• Автоматизация и повторяемость - развертывание вложенных сред VCF почти полностью автоматизировано и легко повторяемо с использованием файлов конфигурации. Типичное развертывание занимает менее 3 часов, с менее чем 15 минутами активного времени использования клавиатуры.

Среда Holodeck Toolkit 2.0

Пакет Holodeck Toolkit 2.0 состоит из нескольких основных компонентов:

• Пакет VCF Lab Constructor (VLC) 5.0 для полной автоматизации развертывания повторяемых вложенных лабораторий Cloud Foundation на одном хосте ESXi. Этот релиз поддерживает VCF 4.5, 4.5.1 и 5.0.
• Пользовательские файлы конфигурации VLC-Holo-Site-1 и VLC-Holo-Site-2 для VLC, поддерживающие развертывания VMware Cloud Foundation с несколькими сайтами.
• Пользовательский Holo-Router на базе VMware Photon OS для поддержки коммуникаций внутри вложенной среды VCF и из этой среды во внешнюю сеть.
• Пользовательская Holo-Console на базе Microsoft Windows Server 2019.
• Полностью автоматизированный механизм создания ISO-образа Holo-Console.
• Полные руководства по развертыванию и эксплуатации одного или нескольких серверов Holodeck.
• Набор лабораторий Holodeck "Always succeed" для демонстрации модели облачной эксплуатации нескольким командам внутри центра обработки данных.
• Программно-определенные сети и безопасность с VMware NSX Data Center.
• Автоматизация частного облака на базе VMware Cloud Foundation.
• Масштабирование развертывания и мониторинга приложений с VMware vRealize Automation.
• Миграция рабочих нагрузок с VMware HCX.
• Модернизация приложений с VMware Tanzu.

Обзор VCF Lab Constructor (VLC)

VLC - это утилита PowerShell/PowerCLI, разработанная для автоматизации развертывания VMware Cloud Foundation во вложенной среде. VLC, используемый с конфигурацией Holodeck, автоматизирует предоставление стандартизированной среды Holodeck "Pod".

Каждый Pod Holodeck содержит:

• Четырехузловой домен управления VCF на вложенных узлах, готовых к использованию с vSAN.
• Опционально три дополнительных вложенных хоста в домене рабочих нагрузок - или второй кластер vSphere в домене управления, или просто дополнительные элементы первого.
• NSX полностью настроен.
• Развернутый AVN/NSX Edge (рекомендуется).
• Развернутый Tanzu (опционально).
  
• VM Cloud Foundation Cloud Builder, настроенный для предоставления DHCP, NTP, DNS, BGP peering и L3 маршрутизации внутри пода.

VLC также может автоматизировать развертывание второго экземпляра VCF на под для предоставления многосайтовой конфигурации VCF для продвинутых лабораторных занятий, таких как NSX Federation, VMware Site Recovery Manager и VCF с vSAN Stretched Cluster.

VLC предоставляет возможность развертывания вложенных сред с простым графическим интерфейсом или полностью автоматизированно с файлом конфигурации и командной строкой PowerShell. Масштабирование работающих вложенных сред (добавление дополнительных вложенных хостов ESXi) может быть выполнено с помощью опции пакета расширения в графическом интерфейсе VLC.

Примечание: VCF Lab Constructor не поддерживается VMware как официальный продукт, это что-то похожее на VMware Flings. Вы также можете присоединиться к каналу поддержки VLC в Slack.

Обзор вложенной среды

Конфигурация "VLC Holodeck Standard" является вложенной конфигурацией VMware Cloud Foundation, используемой в качестве базовой для нескольких лабораторных упражнений по эксплуатации частного облака, созданных командой технического маркетинга Cloud Foundation. Стандартный "VLC-Holo-Site-1" является основной развертываемой конфигурацией. Дополнительный VLC-Holo-Site-2 может быть развернут в любое время позже в рамках нового Pod. Конфигурация VLC-Holo-Site-1 соответствует лабораторной конфигурации в VCF Hands-On Lab HOL-2246 и вложенной конфигурации в программе VCF Experience, запущенной на платформе лабораторий VMware.

Каждый Pod в развертывании Holodeck работает с идентичной вложенной конфигурацией. Pod может быть развернут с автономной конфигурацией VLC-Holo-Site-1 или же с одновременно активными конфигурациями VLC-Holo-Site-1 и VLC-Holo-Site-2. Разделение подов, а также между сайтами внутри пода, обрабатывается на уровне виртуального коммутатора vSphere Standard Switch (VSS). Каждый Pod Holodeck настроен с уникальным VSS для сайта. Группа портов VMware vSphere настроена на каждом VSS и сконфигурирована как транк VLAN.

• Компоненты в группе портов используют тегирование VLAN для изоляции коммуникаций между вложенными VLAN. Это устраняет необходимость в физических VLAN, подключенных к хосту ESXi для поддержки вложенных лабораторий.
• Когда развертывается конфигурация Holo-Site-2, она использует второй VSS и группу портов для изоляции от Holo-Site-1.
• Конфигурация VLC Holodeck настраивает виртуальную машину VCF Cloud Builder для предоставления нескольких сервисов поддержки внутри пода, чтобы не требовать дополнительных сервисов со стороны клиента. VM Cloud Builder развертывается на сайт для предоставления следующих услуг внутри пода:
  • DNS (локально для Site1 и Site2 внутри пода, действует как промежуточный узел).
  • NTP (локально для Site1 и Site2 внутри пода).
  • DHCP (локально для Site1 и Site2 внутри пода).
  • L3 TOR для сетей vMotion, vSAN, управления, Host TEP и Edge TEP в каждом сайте.
  • BGP-пир с VLC Tier 0 NSX Application Virtual Network (AVN) Edge (обеспечивает подключение к оверлей-сетям NSX из лабораторной консоли).

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-1 внутри Pod Holodeck. Конфигурация Site-1 использует домен DNS vcf.sddc.lab и VLAN 10-15.

Пакет Holodeck также предоставляет предварительно настроенную виртуальную машину Photon OS, называемую "Holo-Router", которая функционирует как виртуализированный маршрутизатор для базовой среды. Эта ВМ позволяет соединять вложенную среду с внешним миром. Holo-Router настроен на перенаправление любого трафика Microsoft Remote Desktop (RDP) к вложенному jump-хосту, известному как Holo-Console, который развертывается внутри пода.

Интерфейс пользователя для вложенной среды VCF предоставляется через виртуальную машину Windows Server 2019 "Holo-Console". Holo-Console предоставляет место для управления внутренней вложенной средой, подобно рабочему столу системного администратора в центре обработки данных. Holo-Console используется для запуска пакета VLC для развертывания вложенного экземпляра VCF внутри пода. Виртуальные машины Holo-Console развертываются из специально созданного ISO, который настраивает следующее:

1. Microsoft Windows Server 2019 Desktop Experience, имеющий на борту:

• Домен Active directory "vcf.holo.lab"
• DNS-форвардер к Cloud Builder
• Сервер сертификатов, Web Enrollment и шаблон сертификата VMware
• Включенный RDP
• Настроенный IP, подсеть, шлюз, DNS и VLAN для развертывания как Holo-Console
• Отключенный брандмауэр и улучшенная безопасность IE
• Настроенное рабочее окружение SDDC Commander

2. Дополнительные программные пакеты, развернутые и настроенные:

• Google Chrome с закладками Holodeck
• VMware Tools
• VMware PowerCLI
• VMware PowerVCF
• VMware Power Validated Solutions
• Клиент PuTTY SSH
• VMware OVFtool

3. Дополнительные программные пакеты, скопированные в Holo-Console для последующего использования:

• VMware Cloud Foundation Cloud Builder OVA в C:\CloudBuilder.

4. VCF Lab Constructor 5.0 с двойной конфигурацией Holodeck:

• C:\VLC\VLC-Holo-Site-1
• C:\VLC\VLC-Holo-Site-2

5. VMware vRealize Automation 8.10 Easy Installer

На рисунке ниже показаны виртуальные машины, работающие на физическом хосте ESXi для предоставления пода Holodeck под названием "Holo-A". Обратите внимание на экземпляры Holo-Console, Holo-Router, Cloud Builder и четыре вложенных хоста ESXi. Они все общаются через группу портов VLC-A-PG.

Добавление второго сайта включает дополнительный экземпляр Cloud Builder и дополнительные вложенные хосты ESXi. VLC-Holo-Site-2 подключается ко второй внутренней линии Holo-Router на VLAN 20. Доступ в сеть из Holo-Console к VLC-Holo-Site-2 осуществляется через Holo-Router.

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-2 внутри пода Holodeck. Конфигурация Site-2 использует домен DNS vcf2.sddc.lab и VLAN 20-25.

Доступ к среде Holodeck

Доступ пользователей к поду Holodeck осуществляется через Holo-Console. Доступ к Holo-Console возможен двумя способами:

1. Подключение через Microsoft Remote Desktop Protocol (RDP) к внешнему IP Holo-Router. Holo-Router настроен на перенаправление всего RDP-трафика к экземпляру Holo-Console внутри пода:

• Клиент Microsoft Remote Desktop для Mac
• Клиент Remote Desktop для Windows (доступен в Microsoft Store)

2. Доступ к Holo-Console через хост ESXi:

• Консоль браузера (встроенная в клиент vSphere)
• VMware Remote Console (требуется вход в VMware Customer Connect)

Предварительные требования для развертывания VLC Holodeck

Размер хоста ESXi:

• Good (один под): Один хост ESXi с 16 ядрами, 384 ГБ памяти и 2 ТБ SSD/NVME
• Better (два пода): Один хост ESXi с 32 ядрами, 1024 ГБ памяти и 4 ТБ SSD/NVME
• Best (четыре или более подов): Один хост ESXi с 64+ ядрами, 2.0 ТБ памяти и 10 ТБ SSD/NVME

Конфигурация хоста ESXi:

• vSphere 7.0U3 или 8.0
• Виртуальный коммутатор и группа портов, настроенные с подключениями к сети клиента/интернету
• Поддерживается автономный хост, не управляемый сервером vCenter, и одноузловой кластер, управляемый экземпляром сервера vCenter
• Кластеры с несколькими хостами НЕ поддерживаются в этом выпуске из-за требования физической поддержки VLAN

Хост Holo-Build:

• Хост Windows 2019 или VM с локальным доступом к хостам ESXI, используемым для Holodeck + доступом в интернет для загрузки программного обеспечения. (Этот пакет был протестирован только на Microsoft Windows Server 2019)
• 200 ГБ свободного дискового пространства
• Действительный вход в CustomerConnect
• Лицензия на VCF 4.5 или 5.0 Enterprise для минимум 8 хостов (16 хостов, если планируется тестирование Cloud Foundation Multi region с NSX Federation)

Ключи лицензий для следующих компонентов VCF 4.5 или 5.0 (на данный момент Toolkit Holodeck не поддерживает подписочные лицензии):

• VMware Cloud Foundation
• VMware NSX-T Data Center Enterprise
• VMware vSAN Enterprise
• VMware vSphere Enterprise Plus
• VMware vCenter Server (одна лицензия)
• VMware vRealize Suite Advanced или Enterprise (теперь это VMware Aria Suite)

Требуемые внешние/клиентские сети:

• IP-адрес управления хоста ESXi (один на хост)
• Адрес Holo-Router на под

Требуемое программное обеспечение (ссылки и инструкции есть в модуле создания пользовательского ISO Holodeck):

• Microsoft Server 2019 Desktop Experience (Eval копия с истечением срока действия через 6 месяцев)
• Свежий пакет VMware VMTools
• Отдельная установка Google Chrome
• Последний архив VMware PowerCLI
• Свежий архив VMware PowerVCF
• Свежий модуль VMware Power Validated Solutions Module
• Свежий MSI клиента PuTTY SSH
• Свежий VMware OVFtool (требуется вход в CustomerConnect)
• VMware Cloud Foundation 4.5 или 5.0 Cloud Builder OVA (требуется вход в CustomerConnect)
• Архив VLC holodeck-standard-main zip - включает VCF Lab Constructor, Holo-Router.ova, скрипты автоматизации поддержки Holodeck и руководства по развертыванию в файле holodeck-standard-main.zip
• Notepad ++ 8.4.7
• VMware vRealize Automation 8.11.2 Easy Installer (требуется вход в CustomerConnect) - эта лаборатория разработана для работы только с VMware vRealize Automation 8.11.2.

Полезные ссылки

• Holodeck 2.0 Setup
• SDDC Manager Operations
• Software-Defined Networking
• Cloud Operations
• Tanzu Operations
• Exploring Holodeck

Давно мы не писали о сбросе паролей элементов виртуальной инфраструктуры VMware vSphere. Сегодня мы поговорим о том, как сделать это для основного компонента - виртуального модуля vCenter Server Appliance (vCSA), который построен на базе операционной системы Photon OS.

Об этой процедуре рассказали в блоге vTechSummary, приведем ее вкратце ниже.

Во время установки vCenter Server Appliance мы задаем пароль Root, с которым мы можем получать доступ в графическую консоль vCenter Management (VAMI) и командную строку.

По умолчанию задано устаревание пароля в 90 дней. Это можно изменить, выставив Password expires в значение No:

Если пройдет 90 дней, и вы не смените пароль, то при попытке логина в VAMI вы увидите вот такой экран:

Если вы просто забыли пароль Root, то будет вот так:

1. Вы помните пароль root, но он устарел

В этом случае мы сможем залогиниться в консоль VCSA и по SSH для смены пароля.

Открываем консоль VCSA, нажимаем F2, после чего мы можем ввести пароль. В этом случае устаревший пароль подойдет:

После этого переходим в раздел Configure Root Password, где можно поменять пароль:

Второй способ - это зайти в консоль сервера vCenter по SSH. Для смены пароля можно использовать следующую команду:

# passwd root

2. Вы не помните пароль root

Перезагрузите сервер vCenter Server Appliance и после того, как система Photon OS стартанет, нажмите клавишу <e>, чтобы зайти в редактор загрузчика GNU GRUB.

Найдите строчку, которая начинается словом linux, и добавьте в ее конец следующую строчку:

rw init=/bin/bash

После этого нажмите кнопку F10 для продолжения загрузки.

Затем вам нужно будет последовательно ввести две следующих команды:

mount -o remount,rw /

passwd

После этого вы сможете задать новый пароль пользователя root.

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

umount /

reboot -f

Затем вы можете логиниться пользователем root с новым паролем.

24 октября компания VMware выпустила критическое уведомление о безопасности VMSA-2023-0023 (уязвимости CVE-2023-34048 и CVE-2023-34056), в котором рассматриваются обнаруженные и устраненные уязвимости безопасности в vCenter Server, которые присутствуют в продуктах VMware vSphere и Cloud Foundation.

Эти уязвимости связаны с управлением памятью и ее повреждением (Out-of-Bounds Write Vulnerability), которые могут быть использованы для удаленного выполнения кода против служб VMware vCenter Server.

Матрица реагирования на обнаруженную уязвимость для разных версий vCenter выглядит следующим образом:

Более подробная версия о том, какие обновления следует поставить, приведена тут.

С выпуском обновления платформы виртуализации VMware vSphere 8 Update 2 компания VMware ввела еще один способ апгрейда сервисов управления виртуальной инфраструктурой vCenter Server Appliance 8.0 до Update 2, который теперь можно сделать методом Switchover. Это подразумевает развертывание нового экземпляра vCSA, на который по окончании апгрейда будет переключено управление виртуальной инфраструктурой vSphere.

Проапгрейдить на Update 2 вы можете vCenter 8 следующих версий (естественно, вы сможете апгрейдить и сам vCSA 8 U2 на последующие релизы в дальнейшем):

• 8.0 GA 8.0 U2
• 8.0 U1 8.0 U2
• 8.0 P02 8.0 U2

Суть нового метода описана в KB 92659, мы приведем здесь лишь основные шаги:

1. Монтируем ISO-образ c vCenter Server Appliance 8.0 до Update 2

2. Делаем бэкап vCenter на уровне файлов (это обязательно)

3. Обновляем плагин vCenter Server Lifecycle Manager в Upgrade Planner

4. Настраиваем новый модуль vCenter Server Appliance 8.0 Update 2 (это можно делать и для минорных апдейтов)

5. Запускаем предварительную фазу апгрейда (Prepare upgrade stage) с установкой временного IP

6. Запускаем процесс Switchover, во время которого произойдет остановка предыдущего виртуального модуля vCenter Server, перебивка IP-адресации и переключение на новый экземпляр vCSA

Florian Grehl на сайте virten.net опубликовал полезную статью о том, как включить аутентификацию Active Directory / LDAP / LDAPS в инфраструктуре VMware vSphere 8. Приводим ниже ее перевод.

Эта статья описывает, как интегрировать VMware vCenter Server в вашу инфраструктуру аутентификации. Источниками идентификации могут быть развертывания Microsoft Active Directory или протокола OpenLDAP.

В комплекте с управляющим сервером vCenter Server идет внутренняя база данных пользователей, которая позволяет добавлять и управлять пользователями из пользовательского интерфейса. Управление пользователями и единый вход предоставляются встроенным компонентом Platform Service Controller. В большой среде вы, возможно, захотите подключить вашу инфраструктуру виртуализации к централизованно управляемому провайдеру идентификации.

Обратите внимание, что VMware объявила о прекращении поддержки Integrated Windows Authentication (IWA). IWA был методом аутентификации, при котором вы присоединяли vCenter Server к вашему домену Active Directory. Несмотря на то, что Active Directory все еще поддерживается для аутентификации, рекомендуется использовать AD через LDAP или идентификацию с помощью ADFS. Для дополнительной информации см. KB78506.

1. Получение сертификата LDAPS

В связи с рисками безопасности, LDAPS заменяет LDAP как новый протокол каталога. Настоятельно рекомендуется использовать LDAPS, который использует SSL для установления безопасного соединения между клиентом и сервером перед обменом любыми данными. В настоящее время в пользовательском интерфейсе vCenter нет функции получения сертификата, поэтому сертификат нужно загрузить самостоятельно.

Подключитесь к vCenter Server Appliance (или любой системе с установленным OpenSSL CLI) с помощью SSH и войдите как root. Выполните следующую команду, чтобы показать сертификат LDAP:

# openssl s_client -showcerts -connect [LDAPS-Server]:636

Эта команда отображает цепочку сертификатов и информацию о сессии SSL. Вы можете использовать либо сертификат CA, либо сертификат сервера. Использование сертификата CA имеет преимущество в том, что вам не нужно перенастраивать провайдер идентификации, когда сертификат LDAPS заменяется.

Копируем содержимое между строчками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- в текстовый файл.

После этого сохраните полученный файл с расширением .crt.

2. Добавление провайдера идентификации

• Откройте vSphere Client.
• Войдите как Single Sign-On Administrator.
• Перейдите к Administration > Single Sign On > Configuration.
• На вкладке провайдера идентификации откройте Identity Sources.
• Нажмите ADD.

• Измените Identity Source Type на Active Directory over LDAP.

• Заполните остальные поля следующим образом:

Identity source name: Метка для идентификации (нужно указать имя домена)

Base distinguished name for users: Уникальное имя Distinguished Name (DN) начальной точки для поиска на сервере каталогов. Пример: Если ваше имя домена - virten.lab, то DN для всего каталога - "DC=virten,DC=lab".

Base distinguished name for groups: Уникальное имя (DN) начальной точки для поиска на сервере каталогов.

Domain name: Ваше имя домена. Пример: "virten.lab".

Domain alias: Ваше имя NetBIOS. Пример: "virten".

Username: Пользователь домена как минимум с правами просмотра.
Если вы получаете ошибку "Invalid DN syntax.", попробуйте ввести пользователя в формате DN: "uid=administrator,cn=users,dc=virten,dc=lab".

Password: Пароль пользователя домена.

Connect to: Выберите "Connect to any domain controller in the domain", если вы хотите использовать DNS для идентификации контроллеров домена или настроить статические основные и вторичные URL. При использовании статических записей вы можете либо запрашивать локальный каталог (порт 636), либо глобальный каталог (порт 3269). (Для устаревших незащищенных подключений используйте 389/3268). Пример: "ldap://dc.virten.lab:636".

• Нажмите "Browse" рядом с сертификатом (для LDAPS).
• Выберите файл .crt, полученный ранее от сервера LDAP.
• Нажмите "ADD" и завершите мастер настройки.
• В источниках идентификации ваш LDAP должен появиться в списке, и с этого момента вы можете назначать разрешения vCenter пользователям и группам из вашего каталога Active Directory.
• Выберите ваш AD и нажмите кнопку "SET AS DEFAULT", чтобы сделать его доменом по умолчанию для аутентификации в вашем vCenter, что означает, что каждый, кто не указывает имя домена для входа, автоматически аутентифицируется в этом домене.
• Для входа с пользователями AD вам нужно установить разрешения. Чтобы добавить пользователя/группу AD в качестве глобального администратора, перейдите к Administration > Access Control > Global Permissions.
• Нажмите "ADD".
• Выберите домен и начните вводить в поле поиска User/Group, чтобы выбрать Domain entity.

• Нажмите "OK".

Теперь вы должны иметь возможность входить с помощью учетной записи Active Directory. Чтобы решать проблемы, связанные с аутентификацией, проверьте файлы журнала на vCenter Server Appliance в папке /var/log/vmware/sso.

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

В июне компания VMware сделала анонс большого обновления своей архитектуры VMware Cloud Foundation версии 5.0. Этот крупный релиз платформы предлагает дополнительную масштабируемость, безопасность и несколько ключевых улучшений, которые направлены на соответствие требованиям для инфраструктур IaaS, упрощают развертывание облачных услуг на собственных площадках и обеспечивают дополнительную защиту от кибератак.

Компания VMware под конец года выпустила небольшие обновления двух продуктов - сервера управления vCenter Server 8.0a и средства мониторинга и управления виртуальной инфраструктурой vRealize Operations 8.10.1 (оно же Aria Operations).

Давайте посмотрим, что нового в VMware vCenter Server 8.0a:

• Новые возможности для VMware vSphere with Tanzu, список которых приведен в VMware vSphere with Tanzu Release Notes.
• Исправлены ошибки в vCenter Server, список которых приведен в разделе Resolved Issues заметок к релизу.
• Исправлена уязвимость CVE-2021-22048. Описание этого фикса приведено в статье VMSA-2021-0025.

Скачать VMware vCenter Server 8.0a можно по этой ссылке.

Для Aria Operations 8.10.1 это просто релиз с небольшими исправлениями ошибок. Cписок их довольно обширный, он приведен в KB 89886.

Скачать VMware Aria Operations 8.10.1 можно по этой ссылке. Ну а о том, что нового появилось в Aria Operations 8.10 мы писали вот тут.

Компания VMware на днях обновила свое главное программное комплексное инфраструктурное решение VMware Cloud Foundation до версии 4.4.1. Напомним, что это платформа, которая включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О версии платформы VCF 4.1 мы писали вот тут.

На днях VMware представила VCF 4.4.1, давайте посмотрим, что там нового (напомним, что релиз VCF 4.4 вышел в феврале):

• Новая версия VMware SDDC Manager 4.4.1
• Обновление средства управления VMware vCenter Server 7.0 Update 3d, в котором было исправлено множество ошибок (подробнее тут)
• Обновися VMware NSX-T до версии 3.1.3.7.4 (подробнее тут и тут).
• Добавлен VMware vRealize Suite Lifecycle Manager 8.6.2 PSPAK 3

Пользователи могут развернуть Cloud Foundation 4.4.1 как новый релиз, а также как последовательный или skip-level (через несколько версий) апгрейд с 4.4, 4.3.1, 4.3, 4.2.1, 4.2, 4.1.0.1 и 4.1.

Более подробно о решении VCF вы можете почитать тут. Совместимые с этой инфраструктурой решения приведены на специальном портале.

Компания VMware, вскоре после большого обновления vSphere 7 Update 3, выпустила небольшой апдейт vSphere 7 U3a. С момента прошлого релиза прошло около месяца, поэтому нововведений не так много. Напомним, что в Update 3 для администраторов и DevOps появилась возможность использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.

Теперь в Update 3a эта возможность позволяет вновь созданным виртуальным машинам стать частью кластера TKG (Tanzu Kubernetes Grid) с нативным исполнением команд. Это позволит:

• Компаниям использовать кластеры TKG как платформу Kubernetes с GPU-ускорением для нагрузок AI/ML.
• Администраторам получить инструмент быстрой и эффективной совместной работы над развертыванием и обслуживанием инфраструктуры контейнеров и уйти от рабочего процесса коммуникации на базе тикетов.

Инфраструктура Tanzu Kubernetes (TKr) теперь построена на Ubuntu 20.04 - сам образ был оптимизирован для использования с нагрузками AI/ML и тщательно оттестирован. Детальное руководство об использовании сервисов Tanzu для AI/ML находится в этой статье.

Также обновление содержит патч VMware vCenter Server Appliance 7.0 Update 3a, который включает в себя фиксы ошибок и исправления в подсистеме безопасности.

Скачать VMware vSphere 7 Update 3a можно по этим ссылкам:

• VMware vCenter 7 Update 3a
• VMware ESXi 7 Update 3a

Release Notes находятся тут.

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper

Некоторое время назад мы писали о новой версии решения VMware Cloud Foundation 4.2 (VCF), которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. 

На днях VMware сделала небольшое обновление этого пакета - VMware Cloud Foundation 4.2.1, давайте посмотрим, что там нового:

• Обновления безопасности для Photon OS в SDDC Manager 4.2.1 (пакет PHSA-2021-3.0-185 обновлен до PHSA-2021-3.0-209 - подробнее тут).
• Критические обновления безопасности для VMware vCenter Server Appliance (мы писали об уязвимости тут).
• Обновление некоторых версий продуктов в составе пакета.

Новый Bill of Materials включает в себя следующие версии решений VMware:

Для пользователей пакета версии 3.10.2 также есть обновление - VCF 3.10.2.1, о нем прдробно рассказано вот тут. Вот его Bill of Materials:

Об обновлении подсистемы безопасности VMware vCenter Server Appliance 6.7 Update 3n рассказано тут.

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a.

Многие пользователи жалуются, что консоль виртуальных машин, развернутых через VM Service в кластере vSphere with Tanzu, оказывается недоступна для логина, даже для администраторов. Над этой проблемой работают, но пока в интерфейсе это выглядит так:

Между тем, попасть в консоль иногда нужно (например, для отладки или траблшутинга) - и для этого есть воркэраунд.

Итак, заходим по SSH на VMware vCenter Server Appliance (vCSA) и выполняем следующие команды, которые получают root-пароль от Supervisor Cluster, выводят его в консоли и инициируют сессию к одному из узлов супервизор-кластера:

SV_DECRYPT_OUTPUT=$(/usr/lib/vmware-wcp/decryptK8Pwd.py)

SV_CLUSTER_IP=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'IP: ' '{print $2}' | awk '{print $1}')

SV_CLUSTER_ROOT_PASSWORD=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'PWD: ' '{print $2}' | awk '{print $1}')

echo -e "\n${SV_CLUSTER_ROOT_PASSWORD}\n"

ssh root@${SV_CLUSTER_IP}

Далее, после того, как мы залогинились в Supervisor Cluster, нужно получить креды от нужного нам узла. Делается это следующим набором команд:

VM_SERVICE_ACCOUNT_USERNAME=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.password}' | base64 -d)
VM_SERVICE_ACCOUNT_PASSWORD=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.username}' |base64 -d)
echo -e "\n${VM_SERVICE_ACCOUNT_PASSWORD}\n${VM_SERVICE_ACCOUNT_USERNAME}\n"

После этого заходим в vSphere Client под этими кредами и функция запуска консоли для данной ВМ вам будет доступна:

Источник.

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

Обновление: вышел патч с исправлением ошибки, доступен тут.

Те из вас, кто поставил обновление VMware vCenter Server 7.0.0c, могли столкнуться с проблемой высокой загрузки CPU в виртуальном модуле (почти до 100%). Данная проблема обсуждается вот в этой ветке форумов VMware.

Выглядит это примерно так при выполнении команды top в ОС модуля vCSA:

Также во время этого компонент vAPI Endpoint показывает следующее предупреждение:

Failed to connect to 1da6ff8a-0bfd-4605-b4cc-c18ba520e95b\com.vmware.vcenter.nsxd.vapi vAPI provider.

Пока VMware работает над решением данной проблемы, ну а в случае ее появления нужно пойти в vCenter Appliance Management (https://vcenter:5480) и там завершить службу Workload Control Plane. Эффект от этого сохранится только до перезагрузки.

Дункан Эппинг пишет, что сейчас идет работа над фиксом этого бага:

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

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

Все перечисленные ссылки агрегированы в KB 1014508.

Компания VMware выпустила небольшие обновления инфраструктуры виртуализации VMware vSphere 6.7 - на днях вышли апдейты vCenter Server 6.7 Update 3g и ESXi 6.7 Update 3 P02.

Более-менее заметные изменения появились только в vCenter 6.7 U3g:

• Появился аларм Replication State Change для виртуального модуля vCSA с Embedded Platform Services Controller, который возникает при переходе репликации между инстансами в статус READ_ONLY. При возвращении в статус Normal аларм исчезает.
• Теперь можно использовать утилиту sso-config для замены сертификата Security Token Service (STS).
• Несколько исправлений ошибок, приведенных в разделе Resolved Issues.
• Обновления Photon OS, о которых можно почитать вот тут.

Обновление ESXi 6.7 Update 3 P02 включает в себя только патчи подсистемы безопасности, а также апдейты драйверов устройств. Более подробно об этом написано вот тут. Скачать это обновление можно через Update Manager или вручную с этой страницы (а далее установить с помощью команды esxcli software vib).

Как вы все знаете, недавно компания VMware сделала доступной для загрузки платформу VMware vSphere 7, где службы управляющего сервера vCenter доступны уже только в формате виртуального модуля vCenter Server Appliance (vCSA).

Блоггер Ozan Orcunus написал интересную заметку о том, как можно отключить автозагрузку некоторых сервисов в vCenter 7. Не секрет, что с каждой новой версией vCenter становится все более и более прожорливым в отношении системных ресурсов. Например, для 10 хостов ESXi и 100 виртуальных машин теперь уже требуется сделать vCSA с двумя vCPU и 12 ГБ оперативной памяти, что слишком много для тестовых окружений, например, на ноутбуке.

Поэтому чтобы vCSA работал немного побыстрее в тестовых средах (и только там, в продакшене этого делать не рекомендуется) можно отключить некоторые его службы при загрузке. В KB 2109881 написано, как останавливать и запускать службы vCenter с помощью команды service-control, но нигде официально не написано о том, как отключать их при старте vCenter.

А делается это следующим образом:

1. Логинимся по SSH на сервер vCSA и переходим в каталог /etc/vmware/vmware-vmon/svcCfgfiles/.

2. Большинство сервисов vCenter - это не стандартные сервисы systemd, а службы спрятанные за за сервисом VMware Service Lifecycle Manager (vmware-vmon). Наберите "systemctl status vmware-vmon" и посмотрите на результат:

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

vi vdcs.json

И выставить в нем параметр StartupType как DISABLED.

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

4. После этого идем в раздел Services и видим, что автозапуск некоторых служб vCenter отключен:

Многие пользователи платформы VMware vSphere знают, что есть такой вариант развертывания и эксплуатации распределенной виртуальной инфраструктуры как ROBO (Remote or Brunch Offices). Она подразумевает наличие одного или нескольких главных датацентров, откуда производится управление небольшими удаленными офисами, где размещено несколько серверов VMware ESXi под управлением собственного vCenter или без него.

В конце прошлого года компания VMware выпустила интересный документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices" (мы уже немного рассказывали о нем тут), где рассматривается главный аспект применения такого сценария - производительность. Ведь удаленные офисы могут располагаться в других городах, странах и даже континентах, доступ к которым осуществляется по разным типам соединений (например, 4G или спутник), поэтому очень важно, сколько трафика потребляют различные операции, и как быстро они отрабатывают с точки зрения администратора.

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

Для тестирования использовалась удаленная конфигурация из 128 хостов ESXi, где было зарегистрировано 3840 виртуальных машин (960 ВМ на кластер, 30 на хост), из которых включалось до 3000 машин одновременно.

Сначала посмотрим на фоновый трафик для синхронизации хостов ESXi и vCenter, в зависимости от числа виртуальных машин на хосте (трафик в сторону vCenter):

Теперь посмотрим на трафик в обратную сторону (там просто передаются команды к хостам, ВМ не сильно затрагиваются, поэтому отличия небольшие):

Теперь посмотрим на то, как отличается объем передаваемого трафика от ESXi к vCenrer в зависимости от уровня собираемой статистики на сервере VMware vCenter:

Теперь давайте посмотрим, как отличается трафик к vCenter в зависимости от числа включенных виртуальных машин на хосте:

Посмотрим на трафик в обратную сторону (от vCenter к хостам ESXi) в зависимости от уровня статистики:

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

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

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

Теперь посмотрим на сетевой трафик от хоста ESXi к серверу vCenter, который включает в себя фоновый трафик, а также собираемую статистику Level-1:

Посмотрим на такой трафик в обратную сторону - от ESXi к vCenter:

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

И в заключение, посмотрим на трафик от хостов ESXi к серверу vCenter при выполнении операций с хостами:

В общем, очень интересный документ - будет не лишним прочитать его полностью.

Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.

Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.

Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:

ovftool --allowExtraConfig VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ova VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf

Сначала нам нужно добавить следующую конфигурацию в раздел Network конфигурации виртуального модуля OVF, содержащую нужный нам MAC-адрес:

<Item>

   <rasd:Address>00:50:56:ab:cd:ef</rasd:Address>

   <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>

   <rasd:Connection>Network 1</rasd:Connection>

   <rasd:ElementName xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">Ethernet adapter on &quot;Network 1&quot;</rasd:ElementName>
   <rasd:InstanceID xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">3</rasd:InstanceID>

   <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>

   <rasd:ResourceType>10</rasd:ResourceType>

</Item>

Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.

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

https://[адрес VCSA]:5480

В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:

Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:

https://[адрес VCSA]:5480

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

Осенью прошлого года компания VMware выпустила VMware Cloud Foundation 3.9. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

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

Главное обновление - это новый Bill of Materials (BoM) для последних версий продуктов (включая апдейты 2020 года):

Остальные новые возможности включают в себя:

• Функция Application Virtual Networks (AVN) - она позволяет решению vRealize Suite быть развернутым в сетях NSX overlay networks. AVN, которые являются стандартом по умолчанию, начиная с этой версии архитектуры VCF, предоставляют преимущества портируемости и быстрого восстановления после запланированного простоя или в случае аварии. Чтобы узнать больше об этих сетях и перевести компоненты vRealize Suite на эту технологию почитайте вот эту статью.
• Поддержка API для нескольких физических сетевых адаптеров и распределенных коммутаторов (vSphere Distributed switches). Теперь API поддерживает до трех vDS и до 6 физических NIC, что дает возможность применения API в высокопроизводительных средах с большим числом адаптеров и виртуальных коммутаторов (например, физическое разделение типов трафика).
• Улучшения Cloud Builder - обновленный графический интерфейс включает в себя несколько улучшений рабочих процессов, а также показывает в отчетах детали задач, которые были выполнены во время развертывания.
• Улучшения Developer Center - теперь можно получить доступ к Cloud Foundation API и примерам кода из дэшборда SDDC Manager.

Более подробная информация об улучшениях VMware Cloud Foundation 3.9.1 приведена в Release Notes.

На днях компания VMware выпустила документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices", в котором рассказывается о производительности сервера vCenter в инфраструктуре небольших офисов и филиалов, где развернуто всего несколько хостов VMware ESXi.

Инфраструктура remote offices and branch offices (ROBO), как правило, удалена от основного датацентра компании, что вызывает влияние на сетевые характеристики, такие как полоса пропускания, задержки в сети и ошибки в доставке пакетов. На эту тему в документе есть интересная табличка:

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

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

Год назад мы писали о средствах VMware vCenter Server Appliance для резервного копирования и восстановления на уровне файлов. Эти функции появились в VMware vCSA 6.5 и были существенно доработаны в версии vCSA 6.7 (отдельный раздел Backup, запланированные резервные копии, политика хранения бэкапов, браузер файлов и т.п.).

В то же время, у пользователей VMware vCSA есть запрос на автоматизацию процесса резервного копирования средствами PowerCLI через механизм vSphere RESTful API. На блогах VMware появилась интересная статья, описывающая данный процесс, приведем ниже основные его моменты.

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

Connect-CisServer -Server vcsa01.corp.local

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

Get-CisService -Name *backup*

Из вывода видно, что нам нужен сервис com.vmware.appliance.recovery.backup.job. Сохраняем его в переменую и передаем в Get-Member:

В выводе мы видим метод create, который позволяет создать задачу резервного копирования, а также свойство help, которое помогает сформировать входные параметры для задачи РК:

$backupJobSvc.Help.create.piece

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

$backupSpec.parts = @("common")

$backupSpec.location_type = "FTP"

$backupSpec.location = "ftp01.corp.local"

$backupSpec.location_user = "backup"

[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSpec.location_password = "VMware1!"

$backupSpec.comment = "PowerCLI Backup Job"

После этого можно уже создавать задачу РК:

$backupJob = $backupJobSvc.create($backupSpec)

Теперь объединяем это все в один скрипт:

# Login to the CIS Service of the desired VCSA

Connect-CisServer -Server vcsa01.corp.local
# Store the Backup Job Service into a variable

  $backupJobSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.job
# Create a specification based on the Help response

  $backupSpec = $backupJobSvc.Help.create.piece.CreateExample()
# Fill in each input parameter, as needed

  $backupSpec.parts = @("common")

  $backupSpec.location_type = "FTP"

  $backupSpec.location = "ftp01.corp.local"

  $backupSpec.location_user = "backup"

  [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSpec.location_password = "VMware1!"

  $backupSpec.comment = "PowerCLI Backup Job"
# Create the backup job 

  $backupJobSvc.create($backupSpec)

Чтобы создать запланированную задачу резервного копирования, надо использовать сервис com.vmware.appliance.recovery.backup.schedules. Тут нам надо задать schedule ID (это строковый параметр по вашему выбору, задается опционально) и заполнить спецификацию аналогично предыдущему сценарию.

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

Ну и, собственно сам сценарий запланированного бэкапа VMware vCSA на уровне файлов через PowerCLI:

# Store the Backup Job Service into a variable

$backupSchedSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.schedules
# Create a Schedule ID specification based on the Help response

  $schedSpec = $backupSchedSvc.Help.create.schedule.Create()

  $schedSpec = 'weekly'
# Create a specification based on the Help response

  $backupSchedSpec = $backupSchedSvc.Help.create.spec.Create()

  $backupSchedSpec.parts = @("common")

  $backupSchedSpec.location = "ftp://ftp01.corp.local"

  $backupSchedSpec.location_user = "backup"

  [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSchedSpec.location_password = "VMware1!"

  $backupSchedSpec.enable = $true

  $recurSpec = $backupSchedSvc.Help.create.spec.recurrence_info.Create()

  $recurSpec.days = @("Sunday")

  $recurSpec.minute = '59'

  $recurSpec.hour = '23'

  $backupSchedSpec.recurrence_info = $recurSpec

  $retentSpec = $backupschedsvc.help.create.spec.retention_info.Create()

  $retentSpec.max_count = '5'

  $backupSchedSpec.retention_info = $retentSpec
# Create the backup job 

  $backupSchedSvc.create($schedSpec, $backupSchedSpec)
 

Это все соответствует запланированной задаче РК со следующими параметрами:

В сентябре этого года мы писали о VMware Cloud Foundation 3.8.1 - комплексном программном решении, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

На днях компания VMware объявила о выходе обновленной архитектуры VMware Cloud Foundation 3.9.

Давайте посмотрим, что нового появилось в VCF 3.9:

• Поддержка апгрейдов на уровне кластера - теперь есть возможность выбрать отдельные кластеры в рамках домена рабочей нагрузки для обновления хостов ESXi.
• Возможность управления несколькими экземплярами Cloud Foundation из одной консоли.
• Домены рабочей нагрузки Virtual Infrastructure (VI) теперь поддерживают Fibre Channel (в дополнение к vSAN и NFS) как Principal Storage.
• Возможность пересборки конфигураций серверов Dell MX под нужды заказчиков.
• В SDDC Manager можно настроить бэкап NSX Managers на сервер SFTP таким образом, чтобы он находился в отдельной зоне отказа (fault zone). Рекомендуется зарегистрировать сервер SFTP на SDDC Manager после обновления и во время первоначальной настройки.
• Бета-возможность Developer Center - она позволяет получить доступ к Cloud Foundation API и примерам кода под SDDC Manager Dashboard.
• Поддержка Cloud Foundation API была существенно расширена, подробнее об этом рассказано тут.
• Bill of Materials (BoM) был обновлен до последних версий продуктов.

Вот список BoM для релиза VCF 3.9: