Переход на VMware Cloud Foundation (VCF) 9 — это не просто обновление версии платформы. Он включает ребрендинг ключевых сервисов, перенос функций между компонентами, а также существенные улучшения управления жизненным циклом (Lifecycle Management). Для команд, планирующих миграцию с VCF 5.x, важно понимать, что именно изменилось: какие элементы остались прежними, какие переименованы, а какие были полностью заменены.

Об этом в общих чертах мы писали в прошлой статье, а сегодня разберём переход с VCF 5.x серии на версию VCF 9 через призму:

• Сравнения ключевых компонентов
• Архитектурных изменений
• Обновлений управления жизненным циклом
• Замены компонентов и блоков функционала

Обо всем этом рассказывается в видео ниже:

Базовая архитектура управления: что осталось неизменным

SDDC Manager — ядро VCF остаётся тем же

Один из наиболее важных выводов: SDDC Manager по-прежнему остаётся центральным движком управления VCF, и он:

• Присутствует как в VCF 5, так и в VCF 9
• Не меняет название (нет ребрендинга)
• Остаётся основным интерфейсом управления инфраструктурой

Однако отмечается, что в VCF 9 функциональность SDDC Manager расширена и улучшена по сравнению с 5-й серией.
Это важно, потому что SDDC Manager — "точка сборки" всей архитектуры VCF: он стабильный и развивается, миграции проще планировать и стандартизировать.

Изменения бренда и унификация: Aria -> VCF Operations

Одно из наиболее заметных изменений VCF 9 — это масштабный ребрендинг линейки VMware Aria в сторону единого зонтичного бренда VCF Operations.

VMware Aria Operations -> VCF Operations

Ранее компонент VMware Aria Operations выполнял роль:

• Централизованных дашбордов
• Мониторинга инфраструктуры
• Уведомлений и alerting
• SNMP-настроек
• Кастомной отчётности (например, oversizing виртуальных машин)
• Capacity planning

В VCF 9 этот же компонент переименован как часть стратегии VMware по движению к унифицированной "operations-платформе" в рамках VCF. Функционально компонент выполняет те же задачи, но позиционирование стало единым для всей платформы.

Operations-экосистема: логирование и сетевые инсайты

Aria Operations for Logs -> VCF Operations for Logs

Компонент логирования в VCF 5 назывался по-разному в средах заказчиков: Aria Operations for Logs и Log Insight. По сути — это централизованный syslog-агрегатор и анализатор, собирающий логи от всех компонентов VCF. В VCF 9 Aria Operations for Logs переименован VCF Operations for Logs. Функционально это тот же концепт, сбор логов остаётся централизованным и управляется как часть единого "Operations-стека".

Aria Operations for Network Insights -> VCF Operations for Network

Сетевой компонент прошёл длинный путь переименований: vRealize Network Insight, затем Aria Operations for Networks и, наконец, в VCF 9 он называется VCF Operations for Network.

Он обеспечивает:

• Централизованный мониторинг сети
• Диагностику
• Анализ сетевого трафика
• Возможности packet capture от источника до назначения

Главное архитектурное изменение: Lifecycle Management -> Fleet Management

VMware Aria Lifecycle Management (Aria LCM) -> VCF Operations Fleet Management

В VCF 5 жизненным циклом (апдейты/апгрейды) занимался компонент Aria Lifecycle Management (LCM), В VCF 9 сделан важный шаг - появился компонент VCF Operations Fleet Management. Это не просто переименование - продукт получил улучшенную функциональность, управление обновлениями и версиями стало более "streamlined", то есть рациональным и оптимизированным, а также появился акцент на fleet-подход: управление инфраструктурой как "парком платформ".

Fleet Management способен управлять несколькими инстансами VCF, что становится особенно важным для крупных организаций и распределённых инфраструктур. Именно тут виден "архитектурный сдвиг": VCF 9 проектируется не только как платформа для одного частного облака, а как унифицированная экосистема для гибридных и мультиинстанс-сценариев.

Feature transition: замена Workspace ONE Access

Workspace ONE Access удалён -> VCF Identity Broker

Одно из самых "жёстких" изменений — это не ребрендинг, а полная замена компонента. Workspace ONE Access полностью удалён (removed), вместо него введён новый компонент VCF Identity Broker. Это новый компонент для управления идентификацией (identity management), интеграции доступа, IAM-сценариев (identity access management), интеграции авторизации/аутентификации для экосистемы VCF.

Миграция и перемещение рабочих нагрузок: HCX теперь - часть Operations

VMware HCX -> VCF Operations HCX

HCX остаётся инструментом для пакетной миграции виртуальных машин (bulk migration) и миграций из одной локации в другую (в т.ч. удалённые площадки). Но в VCF 9 меняется позиционирование продукта: он теперь полностью интегрирован в VCF Operations и называется VCF Operations HCX. То есть HCX становится частью единого "операционного" контура VCF 9.

Автоматизация: упрощение названий и интеграция компонентов

Aria Automation -> VCF Automation

Это компонент автоматизации, отвечающий за сценарии и рабочие процессы частного облака, развертывание рабочих нагрузок и ежедневные операции. В VCF 9 это просто VCF Automation.

Aria Automation Orchestrator -> VCF Operations Orchestrator

Orchestrator используется для end-to-end рабочих процессов и автоматизации процессов создания ВМ и операций. В VCF 9 это теперь просто VCF Operations Orchestrator. Это важно: Orchestrator закрепляется как часть "operations-логики", а не просто автономный компонент автоматизации.

VMware Cloud Director: интеграция/поглощение в VCF Automation

Теперь VMware Cloud Director имеет новое позиционирование: продукт полностью интегрирован в VCF Automation. То есть Cloud Director как самостоятельное наименование уходит на второй план, а функции “переезжают” или связываются с модулем VCF Automation.

Слой Kubernetes: vSphere with Tanzu -> vSphere Supervisor

vSphere with Tanzu переименован в vSphere Supervisor

Это важное изменение, отражающее стратегию VCF по треку modern apps. Supervisor рассматривается как компонент для приложений новой волны, перехода monolith > microservices, контейнерного слоя и инфраструктуры enterprise-grade Kubernetes.

Платформа VCF при этом описывается как:

• Unified Cloud Platform
• Подходит для частного облака
• Интегрируется с hyperscalers (AWS, Azure, Google Cloud и т.д.)
• Поддерживает enterprise Kubernetes services

Итоги: что означает переход VCF 5 -> VCF 9 для архитектуры и миграции

Переход от VCF 5.x к VCF 9 — это комбинация трёх больших тенденций:

1) Унификация бренда и операционной модели

Aria-компоненты массово становятся частью семейства VCF Operations.

2) Улучшение управления жизненным циклом

LCM эволюционирует в Fleet Management, что отражает переход к управлению группами платформ и множественными VCF-инстансами.

Самое заметное — удаление Workspace ONE Access и введение VCF Identity Broker.

Cоответствие компонентов VCF 5.x и VCF 9

• SDDC Manager -> SDDC Manager (улучшен)
• Aria Operations -> VCF Operations
• Aria Operations for Logs -> VCF Operations for Logs
• Aria Operations for Network Insights -> VCF Operations for Network
• Aria LCM -> VCF Operations Fleet Management
• Workspace ONE Access -> VCF Identity Broker (замена продукта)
• HCX -> VCF Operations HCX
• Aria Automation -> VCF Automation
• Aria Automation Orchestrator -> VCF Operations Orchestrator
• Cloud Director -> интеграция в VCF Automation
• vSphere with Tanzu -> vSphere Supervisor

В новом видео на канале Gnan Cloud Garage подробно разобраны ключевые отличия между VMware Cloud Foundation (VCF) версии 5.2 и VCF 9.0, причем автор подчеркивает: речь идёт не о простом обновлении, а о кардинальной архитектурной переработке платформы.

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

Основные отличия VCF 5.2 и VCF 9.0

1. Модель развертывания

• VCF 5.2: установка строилась вокруг SDDC Manager и требовала загрузки Cloud Builder размером около 20 ГБ. Развёртывание компонентов происходило последовательно.
• VCF 9.0: представлен новый VCF Installer (~2 ГБ) и fleet-based модель. Это обеспечивает более быстрое развертывание, модульную архитектуру и гибкость с первого дня.

Результат: ускорение внедрения и переход от монолитного подхода к модульному.

2. Управление жизненным циклом (LCM)

• VCF 5.2: весь LCM был сосредоточен в SDDC Manager.
• VCF 9.0: управление разделено между Fleet Management Appliance и SDDC Manager.
  
  
• Fleet Management отвечает за операции, автоматизацию и управление идентификацией.
• SDDC Manager фокусируется на базовой инфраструктуре.

Результат: параллельные обновления, меньшее время простоя и более точный контроль.

3. Управление идентификацией

• VCF 5.2: использовались Enhanced Linked Mode и vCenter Identity.
• VCF 9.0: внедрены VCF Single Sign-On и VCF Identity Broker, обеспечивающие единую систему идентификации для всех компонентов.

Результат: действительно унифицированная и современная модель identity management.

4. Лицензирование

• VCF 5.2: традиционные лицензии — по продуктам и ключам (vSphere, NSX, vSAN, Aria).
• VCF 9.0: keyless subscription model — без ключей, с подпиской.

Результат: упрощённое соответствие требованиям, обновления и соответствие современным облачным моделям потребления.

5. Операции и мониторинг

• VCF 5.2: VMware Aria Operations — опциональный компонент.
• VCF 9.0: операции встроены по умолчанию, обеспечивая fleet-wide мониторинг и compliance «из коробки».

6. Автоматизация

• VCF 5.2: автоматизация была дополнительной опцией.
• VCF 9.0: решение VCF Automation встроено и оптимизировано для:

• AI-нагрузок
• Kubernetes
• виртуальных машин

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

• VCF 5.2: NSX — опциональный компонент.
• VCF 9.0: NSX становится обязательным для management и workload-доменов.

Результат: единая программно-определяемая сетевая архитектура во всей среде VCF.

8. Хранилище

• VCF 5.2: поддержка vSAN, NFS и Fibre Channel SAN.
• VCF 9.0: акцент на vSAN ESA (Express Storage Architecture) и Original Storage Architecture, с планами по расширению поддержки внешних хранилищ.

Результат: фундамент для более современной и производительной storage-архитектуры.

9. Безопасность и соответствие требованиям

• VCF 5.2: ручное управление сертификатами и патчами.
• VCF 9.0: встроенные средства управления:
  
  
  • унифицированное управление ключами
  • live patching
  • secure-by-default подход

Результат: серьёзная модернизация безопасности и Zero Trust по умолчанию.

10. Модель обновлений

• VCF 5.2: последовательные апгрейды.
• VCF 9.0: параллельные обновления с учётом fleet-aware LCM.

Результат: меньше простоев и лучшая предсказуемость обслуживания.

11. Kubernetes и контейнеры

• VCF 5.2: ограниченная поддержка Tanzu.
• VCF 9.0: нативный Kubernetes через VCF Automation.

Результат: единая платформа для VM и Kubernetes — полноценная application platform.

12. Импорт существующих сред

• VCF 5.2: импорт существующих vSphere/vCenter не поддерживался.
• VCF 9.0: можно импортировать существующие окружения как management или workload-домены.

Результат: упрощённая миграция legacy-нагрузок в современное частное облако.

Итог

VCF 5.2 — это классическая платформа частного облака с опциональными возможностями, ну а VCF 9.0 — это современное, cloud-like частное и гибридное облако, ориентированное на масштабирование, автоматизацию и управление флотом инфраструктуры.

Как подчёркивает автор видео, VCF 9.0 — это не апгрейд, а полноценный редизайн, нацеленный на лучший пользовательский опыт и соответствие требованиям современных enterprise и облачных сред.

VMware Cloud Foundation (VCF) 9.0 предоставляет быстрый и простой способ развертывания частного облака. Хотя обновление с VCF 5.x спроектировано как максимально упрощённое, оно вносит обязательные изменения в методы управления и требует аккуратного, поэтапного выполнения.

Недавно Джонатан Макдональд провёл насыщенный вебинар вместе с Брентом Дугласом, где они подробно разобрали процесс обновления с VCF 5.2 до VCF 9.0. Сотни участников и шквал вопросов ясно показали, что этот переход сейчас волнует многих клиентов VMware.

Джонатан отфильтровал повторяющиеся вопросы, объединив похожие в единые, комплексные темы. Ниже представлены 10 ключевых вопросов («must-know»), заданных аудиторией, вместе с подробными ответами, которые помогут вам уверенно пройти путь к VCF 9.0.

Вопрос 1: Как VMware SDDC Manager выполняет обновления? Есть ли значительные изменения в обновлениях версии 9.0?

Было много вопросов, связанных с SDDC Manager и процессом обновлений. Существенных изменений в том, как выполняются обновления, нет. Если вы знакомы с VCF 5.2, то асинхронный механизм патчинга встроен в консоль точно так же и в версии 9.0. Это позволяет планировать обновления и патчи по необходимости. Главное отличие заключается в том, что интерфейс SDDC Manager был интегрирован в консоль VCF Operations и теперь находится в разделе управления парком (Fleet Management). Многие рабочие процессы также были перенесены, что позволило консолидировать интерфейсы.

Вопрос 2: Есть ли особенности обновления кластеров VMware vSAN Original Storage Architecture (OSA)?

vSAN OSA не «уходит» и не объявлен устаревшим в VCF 9.0. Аппаратные требования для vSAN Express Storage Architecture (ESA) существенно отличаются и могут быть несовместимы с существующим оборудованием. vSAN OSA — отличный способ продолжать эффективно использовать имеющееся оборудование без необходимости покупать новое. Для самого обновления важно проверить совместимость аппаратного обеспечения и прошивок с версией 9.0. Если они поддерживаются, обновление пройдёт так же, как и в предыдущих релизах.

Вопрос 3: Как выполняется обновление VMware NSX?

При обновлении VCF все компоненты, включая NSX, обновляются последовательно. Обычно процесс начинается с компонентов VCF Operations. После этого управление передаётся рабочим процессам SDDC Manager: сначала обновляется сам SDDC Manager, затем NSX, потом VMware vCenter и в конце — хосты VMware ESX.

Вопрос 4: Если VMware Aria Suite развернут в режиме VCF-aware в версии 5.2, нужно ли отвязывать Aria Suite перед обновлением?

Нет. Вы можете сначала обновить компоненты Aria Suite до версии, совместимой с VCF 9, а затем продолжить обновление остальных компонентов.

Вопрос 5: Можно ли обновиться с VCF 5.2 без настроенных LCM и Aria Suite?

Да. Наличие компонентов Aria Suite до обновления на VCF 9.0 не требуется. Однако в рамках обновления будут развернуты Aria Lifecycle (в версии 9.0 — VCF Fleet Management) и VCF Operations, так как они являются обязательными компонентами в 9.0.

Вопрос 6: Сколько хостов допускается в консолидированном дизайне VCF 9.0?

Для нового консолидированного дизайна рекомендуется минимум четыре хоста. При конвергенции инфраструктуры с использованием vSAN требуется минимум три ESX-хоста (четыре рекомендуются для отказоустойчивости). При использовании внешних систем хранения достаточно минимум двух хостов. Что касается максимальных значений, документированных ограничений нет, кроме ограничений VMware vSphere: 96 хостов на кластер и 2500 хостов на один vCenter. В целом рекомендуется по мере роста добавлять дополнительные домены рабочих нагрузок или кластеры для логического разделения среды с точки зрения производительности, доступности и восстановления.

Вопрос 7: Как перейти с VMware Identity Manager (vIDM) на VCF Identity Broker (VIDB) в VCF 9?

Прямого пути обновления или миграции с vIDM на VIDB не существует. Требуется «чистое» (greenfield) развертывание VIDB. Это особенно актуально, если используется VCF Automation, так как в этом случае новое развертывание VIDB является обязательным.

Вопрос 8: Нужно ли загружать дистрибутивы для VCF Operations и куда их помещать?

Это зависит от используемого сценария. В общем случае, если вы выполняете обновление и компоненты Aria ещё не установлены, потребуется загрузить и развернуть виртуальные машины VCF Operations и VCF Operations Fleet Management. После их развертывания бинарные файлы загружаются в репозиторий (depot) VCF Operations Fleet Management для установки дополнительных компонентов. Если вы конвергируете vSphere в VCF, все недостающие компоненты будут развернуты установщиком VCF, и, соответственно, должны быть загружены в него заранее.

Вопрос 9: Существует ли путь отката (rollback), если во время обновления возникла ошибка?

В целом не существует «кнопки отката» для всего VCF сразу. Лучше рассматривать каждое последовательное обновление как контрольную точку. Например, перед обновлением SDDC Manager с 5.2 до 9.0 нужно всегда делать резервную копию. Если во время обновления возникает сбой, можно откатиться к состоянию до ошибки и продолжить диагностику. То же самое относится к другим компонентам. При сбоях в обновлении NSX, vCenter или ESX-хостов нужно оценить ситуацию и либо выполнить откат, либо обратиться в поддержку, если время окна обслуживания истекает и необходимо срочно восстановить работоспособность среды. Именно поэтому тщательное планирование имеет решающее значение при любом обновлении VCF.

Вопрос 10: Существует ли путь миграции с VMware Cloud Director (VCD) на VCF Automation?

На данный момент VCD не поддерживается в VCF 9.0, и официальных путей миграции не существует. Если у вас есть вопросы по этому поводу, обратитесь к вашему Account Director.

В примере показано, как среда, использующая Aria Suite Lifecycle Manager и Aria Operations, переходит на новую версию платформы. Процесс начинается с обновления Aria Lifecycle Manager до версии 8.18 Patch 2 или выше. Затем с его помощью выполняется апгрейд Aria Operations до VCF Operations 9.0, что автоматически разворачивает новый компонент — VCF 9 Fleet Management Appliance.

После обновления сервисов Aria обновляется сама инфраструктура vSphere: выполняется переход на VLCM images, обновляются vCenter Server и хосты ESX до версии 9.0.

На следующем этапе используется установщик VMware Cloud Foundation, который скачивает необходимые бинарные файлы и проводит обновление среды до VCF 9.0. В ходе этого процесса выполняется консолидация существующих компонентов vCenter Server и VCF Operations в единый VCF Management Domain. Установщик также автоматически разворачивает Operations Collector, VMware NSX, настраивает SDDC Manager и при необходимости устанавливает модуль VCF Automation (его можно добавить позже через Fleet Management Appliance).

После завершения обновления выполняется повторное лицензирование среды под VCF 9.0, а также ряд действий после обновления: развёртывание VCF Logs, настройка внешнего vCenter Identity Broker, включение VCF SSO, связывание нескольких серверов vCenter и установка дополнительных модулей, включая Operations for Networks и HCX.

Видео демонстрирует комплексный процесс перехода на новую версию VMware Cloud Foundation и подчёркивает преимущества глубокой интеграции и автоматизации в экосистеме VMware.

Команда поддержки VMware в Broadcom полностью привержена тому, чтобы помочь клиентам в процессе обновлений. Поскольку дата окончания общего срока поддержки VMware vSphere 7 наступила 2 октября 2025 года, многие пользователи обращаются к вендору в поисках лучших практик и пошаговых руководств по обновлению. И на этот раз речь идет не только об обновлениях с VMware vSphere 7 до VMware vSphere 8. Наблюдается активный рост подготовки клиентов к миграции с vSphere 7 на VMware Cloud Foundation (VCF) 9.0.

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

Чтобы помочь в этом процессе, каким бы он ни был, были подготовлены руководства в формате статей базы знаний (KB), которые проведут вас через весь процесс от начала до конца. Этот широкий набор статей базы знаний по обновлениям продуктов предоставляет простые, пошаговые инструкции по процессу обновления, выделяя области, требующие особого внимания, на каждом из следующих этапов:

• Подготовка к обновлению
• Последовательность и порядок выполнения апгрейда
• Необходимые действия после переезда и миграции

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

• Обновление VMware Cloud Foundation (VCF) 4.x и 5.x
• Обновление ESXi 7.x до 8.x или установка ESXi
• Обновление vCenter Server 7.0 до 8.0
• Обновление до VMware vSAN 8
• Обновление до VMware Live Site Recovery 9.0
• Обновление до vSphere Replication 9.0
• Обновление до Aria Automation 8.18.x
• Обновление до Aria Suite Lifecycle 8.18
• Обновление до Aria Operations for Logs 8.18.x
• Обновление до Aria Operations 8.18.x
• Обновление Aria Operations for Network через графический интерфейс
• Обновление до VMware Cloud Director 10.6
• Обновление HCX
• Обновление NSX

VMware vSphere 7 достигнет конца основного срока поддержки (End of General Support) 2 октября 2025 года. Если вы в настоящее время используете vSphere 7, вам необходимо перейти на vSphere 8, чтобы продолжать получать поддержку продукта, обновления безопасности и патчи. Это также подготовит вас к переходу на VCF 9, когда вы будете к этому готовы.

Существует два варианта обновления:

1. Вы можете напрямую обновить vSphere 7 до vSphere 8

2. Либо можно импортировать vSphere 7 в VMware Cloud Foundation (VCF) версии 5.2 и выполнить обновление домена рабочих нагрузок до версии 8 через VMware SDDC Manager.

Выбор подходящего пути зависит от ряда факторов, таких как готовность бизнеса, поддержка сторонних продуктов и конфигурация среды. Ниже описано, как команда VCF Professional Services подходит к каждому из этих вариантов.

Вариант 1: Обновление с использованием vSphere Lifecycle Manager

Этот вариант представляет собой традиционный способ обновления vSphere. Вы можете использовать vSphere Lifecycle Manager Images или vSphere Lifecycle Manager Baselines для выполнения задачи обновления.

Преимущества этого подхода:

• Используются уже существующие операционные процессы обновления.
• В большинстве случаев требуется минимальное изменение текущей среды.
• Нет необходимости в дополнительных виртуальных модулях (appliances).

Недостатки этого подхода:

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

Шаги по обновлению с использованием vSphere Lifecycle Manager

Многие организации сначала выполняют обновление на тестовой (staging) среде перед тем, как переходить к рабочей (production). Шаги, как правило, одинаковы для любых сред.

Шаг 1: Планирование, предварительная проверка и подготовка среды к обновлению.

На этом этапе необходимо вручную подтвердить, что ваша среда поддерживает новые версии. Начните с изучения Release Notes для vSphere 8 и проверьте, поддерживают ли ваши интеграции с другими продуктами VMware или сторонними приложениями vSphere 8. Также потребуется подготовка к обновлению vCenter и понимание изменений, связанных с обновлением хостов VMware ESX.

Шаг 2: Загрузка бинарных файлов (если необходимо).

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

Шаг 3: Обновление vCenter.

Обновление vCenter можно выполнить несколькими способами, в зависимости от требований пользователя. Существует три основных метода:

• Обновление с сокращённым временем простоя (Reduced Downtime Upgrade) - при этом способе разворачивается вторичный виртуальный модуль, и конфигурационные данные переносятся на него. Это наиболее предпочтительный метод, поскольку он обеспечивает минимальные простои по сравнению с другими способами обновления.

• Установщик vCenter (vCenter Installer) – установщик vCenter включает опцию обновления, которая позволяет обновить существующий виртуальный модуль. Этот метод может быть использован в случае, если недостаточно ресурсов для развертывания второго модуля.

• Обновление через интерфейс управления виртуальным модулем (Virtual Appliance Management Interface Upgrade) – этот метод позволяет автоматически загрузить и установить бинарные файлы напрямую из интерфейса управления виртуальным модулем vCenter. Мы также можем использовать этот способ, если недостаточно ресурсов для развертывания второго модуля.

Шаг 4: Обновление хостов ESX.

После обновления vCenter можно переходить к обновлению хостов ESX. Существует несколько способов обновления хостов ESX. VMware использует два основных подхода:

• vSphere Lifecycle Manager - это предпочтительный метод, так как он позволяет обновлять целые кластеры одновременно, вместо обновления каждого хоста по отдельности. Это самый простой способ выполнения обновлений.

• Сценарные обновления (Scripted Upgrades) – этот метод рекомендуется, когда необходимо обновить большое количество хостов. Существует несколько способов автоматизации обновления с помощью сценариев, что позволяет адаптировать процесс под конкретные операционные процедуры и используемые языки скриптов.

Шаг 5: Обновление VMware vSAN.

После обновления хостов следующим шагом является обновление формата дисков vSAN. Этот шаг рекомендуется, но не является обязательным. Обновление vSAN позволяет воспользоваться новыми функциями.

Шаг 6: Обновление версии vSphere Distributed Switch.

Версию vSphere Distributed Switch также можно обновить. Этот шаг также является необязательным, однако рекомендуется его выполнить, чтобы получить доступ к новым возможностям.

Шаг 7: Проверка после обновления (Post-Upgrade Validation).

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

На этом процесс обновления среды vSphere с использованием vSphere Lifecycle Manager завершается.

Вариант 2: Импорт vSphere в экземпляр VCF и обновление через SDDC Manager

Второй вариант — это импорт среды vSphere в VCF 5.2 с последующим обновлением через консоль SDDC Manager. Для этого у вас уже должен быть развернут экземпляр VCF.

Преимущества импорта vSphere в VCF и обновления через SDDC Manager:

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

Недостатки:

• Требуются дополнительные виртуальные модули. VCF представляет собой полноценный программно-определяемый датацентр, и такие компоненты, как VMware NSX, являются обязательными. Это требует выделения дополнительных ресурсов.
• Как упомянуто в разделе с преимуществами, приведение среды к стандарту VCF может потребовать выполнения определённых исправлений.

Шаги по импорту vSphere в VCF и обновлению через SDDC Manager

Шаг 1: Импорт существующей среды vSphere в конфигурацию VCF.

Используйте VCF Import Tool для проверки предварительных условий и выполнения импорта в уже существующий экземпляр VCF.

Шаг 2: Обновление vSphere через SDDC Manager.

После того как в среде доступен SDDC Manager, вы можете использовать его для выполнения следующих задач:

• Загрузка пакетов обновлений (Download Update Bundles) – скачайте необходимые пакеты, чтобы иметь возможность выполнить обновление.

• Выполнение предварительных проверок (prechecks) – выполните проверку предварительных условий, чтобы выявить проблемы, которые могут привести к сбою обновления. Если будут обнаружены какие-либо ошибки или проблемы, их необходимо устранить перед продолжением процесса.

• Обновление компонентов (Upgrade Components) – обновите все компоненты vSphere (vCenter и ESX). SDDC Manager выполнит обновление в правильной последовательности, чтобы обеспечить совместимость с перечнем компонентов (Bill of Materials) VCF 5.2.

Шаг 3: Проверка после обновления (Post-Upgrade Validation).

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

Как уже упоминалось, данный вариант требует наличия развернутого экземпляра VCF. Если его нет, вы можете сначала обновить хотя бы один экземпляр vCenter 7 до vSphere 8, используя Вариант 1, а затем преобразовать этот экземпляр vSphere в VCF.

Недавно компания VMware выпустила полезный документ "VMware Cloud Foundation 9.0 and VMware vSphere Foundation 9.0 Feature Comparison & Upgrade Paths", в котором приводится сравнении функциональности VMware Cloud Foundation и vSphere Foundation, а также рассказывается о существующих вариантах апгрейда.

Издания платформы: Cloud Foundation vs vSphere Foundation

VMware Cloud Foundation (VCF) 9.0

Полноценная IaaS-платформа, предоставляющая Enterprise-возможности:

• vSphere (ESX и vCenter), vSAN, NSX и HCX
• Автоматизация управления жизненным циклом с помощью SDDC Manager, операции Fleet Management и VCF Operations
• Aria Automation в рамках портала самообслуживания, Terraform, GitOps, blueprints
• Оперативный мониторинг, комплаенс, chargeback через Aria Operations Enterprise
• Kubernetes как сервис, включая Supervisor Services, ArgoCD, Data / AI Services
• Поддержка больших объемов хранения (до 1 TiB/core), глобальной дедупликации, растянутых кластеров, QoS, снапшотов и многого другого

VMware vSphere Foundation (VVF) 9.0

Базовая, но мощная платформа виртуализации:

• Включает vSphere Kubernetes Service, vSAN, vCenter Standard, VCF Operations (включая базовый мониторинг и жизненный цикл)
• Не включает NSX, HCX, Aria Automation или Aria Operations Enterprise
• Поддерживает основное управление платформой виртуализации и контейнерами, но не полноценную автоматизацию и изоляцию тенантов

Сравнение ключевых возможностей

Пути обновления (Upgrade Paths)

В документе VMware четко описывает возможности перехода с предыдущих продуктов:

• Старые версии: vSphere Enterprise Plus, vSphere Standard, vCloud Suite, Aria Suite и другие можно мигрировать либо в vSphere Foundation 9.0 (если нужны базовые функции), либо сразу в VCF 9.0 для полной автоматизации и сетевых возможностей.

• Лицензирование:

  • Подписка VCF 9 или VVF 9 включает лицензию версии 9.0, а также ключи для версий 8.x, которые можно использовать или понижать (downgrade) при необходимости.

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

Последовательность обновления при переходе на VCF 9.0

Broadcom рекомендует следующую схему для обновления компонентов в среде с несколькими доменами нагрузки (workload domains):

1. Aria Suite Lifecycle (до версии 8.18 Patch 2)
2. VCF Operations и Fleet Management
3. VCF Automation, VCF Operations – Networks, Logs (новый лог-менеджмент вместо Aria Logs)
4. SDDC Manager
5. HCX, NSX, затем vCenter
6. Identity Broker / VIDB
7. Supervisor, vSAN Witness, хосты ESX
8. vSAN, файловый сервис, VMware Tools, Virtual Hardware.

Важно: компонент Aria Operations for Logs 8.x не обновляется напрямую — миграция исторических данных происходит через Day-N операции в новом VCF Operations Logs.

Что выбрать?

• vSphere Foundation 9.0 — если нужна стабильная виртуализация с контейнерами и vSAN, но без сложной сетевой и автоматизационной логики.

• Cloud Foundation 9.0 — если требуется:

  • Автоматическая настройка облака (IaaS) под клиентов
  • Полнофункциональные сети и безопасность
  • Глобальное управление через единую платформу
  • Поддержка Kubernetes, AI, Data services
  • Полная интеграция Operations / Automation

Выводы

• VMware предложила две SKU-конфигурации, одна — мощная, полностью автоматизированная платформа IaaS (VCF), другая — компактная и эффективная инфраструктурная база ( vSphere Foundation).
• Лицензирование и upgrade гибкие — подписка VCF/VVF 9 позволяет использовать версию 9.0 или откатиться на 8.x в рамках лицензии.
• Обновление требует чёткого порядка, особенно при переходе с существующих систем – важна последовательность компонентов, миграция логов и identity.
• Выбор зависит от ваших нужд: простота и контейнеризация или полный спектр управления частным облаком с IaaS, безопасностью и DevOps-интерфейсами.

Недавно мы писали о программном доступе к спискам совместимости Broadcom Compatibility Guide (BCG), а на днях стало известно, что ключевой компонент платформы VMware Cloud Foundation 9 - платформа VMware vSphere 9 - уже присутствует в BCG, так что можно проверять свои серверы и хранилища на предмет совместимости с VMware ESXi 9.0 и VMware vSAN 9.0:

Кстати в списках совместимости с vVols не указан VMware ESXi 9, так как эта технология будет признана deprecated в следующей версии платформы (и окончательно перестанет поддерживаться в vSphere 9.1).

Имейте в виду, что список совместимости еще может поменяться к моменту финального релиза VMware vSphere 9, но ориентироваться на это для планирования закупок можно уже сейчас.

С выходом TKG Service 3.2.0 в октябре 2024 года VMware объявила об устаревании API Tanzu Kubernetes Cluster (TKC), направляя клиентов на использование Cluster API в качестве поддерживаемого метода для инициализации, настройки и управления кластерами Kubernetes. Ниже описан процесс отказа от использования API TKC в пользу более современной методологии на основе Cluster API.

Далее термины "TKG Service", "TKGS" и "vSphere Kubernetes Service" (VKS) используются взаимозаменяемо. VMware проводит небольшую ребрендинг-кампанию, и в будущих выпусках вы начнете замечать обновленный брендинг.

API TanzuKubernetesCluster долгое время был полезным инструментом для управления кластерами Kubernetes, но по мере развития экосистемы Cluster API стал предлагать более зрелый, функциональный и управляемый по версиям подход к управлению жизненным циклом кластеров. Этот переход гарантирует клиентам стандартизацию, большую гибкость и долгосрочную поддержку. Однако в VMware понимают, что у многих пользователей уже развернуты кластеры, созданные с помощью API Tanzu Kubernetes Cluster. Это создает определенные сложности: необходимо обеспечить возможность корректного отказа от TKC-ресурсов без нарушения существующих рабочих процессов. Общий план по обновлению включает три ключевых этапа:

Начиная с TKG Service 3.2.0, пользователи, работающие с ресурсами TKC, получают предупреждения об устаревании и рекомендации по переходу на Cluster API.

С выпуском TKG Service 3.3.0 был представлен упрощенный процесс вывода ресурсов TKC для существующих кластеров, при этом управление ими продолжается через Cluster API. Подробное описание этого процесса приведено ниже.

В одном из будущих выпусков поддержка API TKC будет полностью прекращена. К этому моменту пользователи должны будут вывести из эксплуатации все ресурсы TKC перед обновлением до новых версий TKG Service/VKS.

Обзор процесса вывода из эксплуатации

Этот процесс позволяет корректно удалить ресурсы TKC, при этом кластеры остаются полностью работоспособными и управляемыми через ресурс Cluster в Cluster API.

При применении метки kubernetes.vmware.com/retire-tkc к кластеру TKC:

• Если кластер соответствует предварительным условиям вывода из эксплуатации, ресурс TKC удаляется, а управление кластером полностью переходит на его ресурс Cluster.
• Если условия не выполнены, валидация заблокирует процесс вывода, и вам будут предоставлены подробные сведения об ошибках, которые помогут устранить проблемы.

Примечание: вывод ресурса TKC из эксплуатации не влияет на сам кластер или его узлы и не вызывает поэтапного обновления (rolling update).

Начало работы

Перед началом убедитесь, что ваш кластер не работает на устаревшей версии Kubernetes. Устаревшие версии совместимы только с vSphere 7.x (и 8.x для обновления) и должны быть обновлены до поддерживаемой версии Kubernetes перед выводом из эксплуатации. Используйте шаги проверки совместимости кластера, чтобы определить и обновить устаревшие версии.

Также убедитесь, что в кластере нет активных обновлений, и что он находится в стабильном состоянии. Важно об управлении через TMC: на данный момент кластеры, управляемые Tanzu Mission Control (TMC), не могут быть выведены из эксплуатации. Эта функциональность пока не поддерживается.

Шаги

Подробное руководство по процессу вывода из эксплуатации можно найти в официальной документации в разделе Retiring Tanzu Kubernetes Cluster resources.

Добавьте метку к ресурсу TKC для кластера, который вы хотите вывести из эксплуатации:

kubectl label tanzukubernetescluster/<cluster-name> kubernetes.vmware.com/retire-tkc="" 

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

• Неустаревшая версия Kubernetes: кластер должен работать на поддерживаемой версии Kubernetes (не может быть переопределено).
• Существующий ресурс Cluster: должен существовать соответствующий ресурс Cluster, находящийся в состоянии Ready (можно переопределить — см. документацию).
• Нет активных обновлений: в кластере не должно выполняться обновление (можно переопределить, если версии Kubernetes совпадают).
• Нет других миграций: кластеры, находящиеся в процессе миграции, не могут быть выведены из эксплуатации (не может быть переопределено).
• Кластер не управляется TMC: кластеры, управляемые Tanzu Mission Control, не могут быть выведены из эксплуатации (не может быть переопределено).

Если все проверки пройдены, процесс вывода продолжается. Если какая-либо из проверок не проходит, процесс приостанавливается, и в статусе TKCRetired указывается причина отказа. После устранения проблем процесс можно перезапустить.

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

После запуска процесса вывода вы увидите обновления через события:

• RetirementTriggered – событие публикуется при запуске процесса.
• RetirementDone – событие публикуется при удалении ресурса TKC.

Остановка процесса при необходимости

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

Результат

При успешном завершении процесса:

• Старый ресурс API TKC будет удален.
• Кластер продолжит работать без перебоев и будет полностью управляться через ресурс Cluster.
• Все операции жизненного цикла, включая обновления и масштабирование, будут выполняться через Cluster API.

Этот процесс обеспечивает чистый и безопасный переход от управления кластерами через TKC к полному управлению с помощью Cluster API.

Недавно мы писали о выходе большого обновления VMware vSphere 8 Update 3, а несколько дней назад пользователи стали сталкиваться с ошибкой при попытке наката обновления. Текст ошибки выглядит так:

Pre-install failed for vmidentity:Expand

Выглядит это как-то так (только вместо vpxd написано vmidentity):

При этом некоторые пользователи могут откатиться (Rollback) к исходному дистрибутиву, а у кого-то этот селектор неактивен (загреен). При обращении в техподдержку VMware пользователям было сказано, что на эту тему готовится KB, а пока можно воспользоваться приведенным ниже воркэраундом.

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

1. Подключитесь по SSH к серверу vCenter

2. Выведите список сертификатов и определите псевдоним некорневого (Non-CA) сертификата с CN=ssoserver

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

3. Сделайте резервную копию сертификата, который показывает CN=ssoserver
Примечание: замените <Alias> на идентификатор псевдонима, определенный на предыдущем шаге.

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store TRUSTED_ROOTS --alias <Alias> --output /var/tmp/non_ca_ssoserver.crt

4. Удалите сертификат из хранилища VECS.
Примечание: замените <Alias> на идентификатор псевдонима, определенный на шаге 2

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <Alias> -y

5. Повторно выведите список сертификатов и убедитесь, что сертификат удален

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

Теперь можно продолжить обновление vCenter.

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

На днях компания VMware в составе Broadcom выпустила очередной пакет обновлений своей флагманской платформы виртуализации - VMware vSphere 8.0 Update 3. vSphere 8 Update 3 улучшает управление жизненным циклом, безопасность и производительность, включая поддержку двойных DPU и улучшенную настройку виртуального оборудования.

Как вы знаете, недавно платформа VMware Fusion стала бесплатной для некоммерческого использования. В том числе, теперь пользоваели Macbook и компьютеров на базе macOS с процессорами архитектуры ARM (Apple Silicon - M1/M2 и другие) могут устанавливать в виртуальной машине релизы Microsoft Windows 11 for ARM (пока в статусе Insider Preview).

Вильям Лам рассказал о том, что у некоторых пользователей при попытке апгрейда их гостевой ОС возникала следующая ошибка:

This PC doesn't currently meet Windows 11 system requirements

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

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

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability : BranchName -> CanaryChannel
• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\UI\Selection : UIBranch -> CanaryChannel

После этого обновление пройдет успешно:

Mateusz Romaniuk написал отличный пост о том, что делать, когда вы провели апгрейд решения для создания отказоуйстойчивых хранилищ с версии VMware vSAN 8 Update 1 на Update 2.

VMware vSphere 8.0 U2 вносит множество улучшений, исправляет несколько проблем и повышает стабильность. После обновления с vSphere 8.0 U1 на U2 происходят также некоторые изменения в vSAN. Если кластер vSAN работает в производственной инфраструктуре, вам необходимо проапгрейдить версию диска, когда вы используете самую новую версию vSphere.

В итоге у вас должна быть версия 19 для формата дисков кластера vSAN (Disk format version):

Итак, сам процесс обновления:

1. В клиенте vSphere выберите ваш кластер vSAN. Перейдите на вкладку Configure и в разделе vSAN выберите Disk Management. Если вы проверите один из хостов ESXi, работающих на vSAN, вы увидите, что текущая версия диска - 18.0.

2. Запустите процедуру предварительной проверки Pre-Check Upgrade, чтобы убедиться, что формат дисков может быть обновлен:

3. Если все в порядке, то нажимайте кнопку Upgrade:

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

5. После апгрейда вы получите уведомление об успешном завершении, а в разделе Disk Management вы можете выбрать хост ESXi и нажать View Disks:

6. Там в разделе Disk group вы и увидите нужную вам информацию - Disk format version: 19

Ну а вот и сами диски дисковой группы:

Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...

С выпуском обновления платформы виртуализации 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

На днях компания VMware объявила о доступности обновленной версии решения Cloud Provider Lifecycle Manager 1.4 (VCPLCM). Напомним, что этот продукт предназначен для автоматизации рутинных операций жизненного цикла продуктов, для которых можно разрабатывать свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров (VCPP) сосредоточиться на более высокоуровневых операциях. В прошлой версии этого средства появился графический интерфейс, о чем мы писали вот тут.

Основные нововведения Cloud Provider Lifecycle Manager 1.4 сосредоточены в трех областях:

1. Упрощенные операции

Теперь в разделе Environments есть кнопка Register Environment, с помощью которой можно просто импортировать продукт и окружение, после чего он добавится в управляемые системы.

Также в графическом интерфейсе доступны новые Day-2 операции, чтобы выровнять функции API и GUI. Теперь вы можете управлять следующими вещами:

• Апгрейд продуктов
• Управление сертификатами
• Управление узлами

Функция Discover была добавлена для отслеживания изменений и модификаций, которые были сделаны в развернутом продукте, и синхронизации их с репозиторием Lifecycle Manager Repository.

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

2. Уменьшенное время исполнения задач

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

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

3. Улучшенный траблшутинг

В VCPLCM 1.4 вы можете получать логи и сообщения об ошибках через GUI или API, просто залогинясь на хост VCPLCM по SSH. Теперь отдельные лог-файлы создаются для каждой задачи с уникальным ID, чтобы упростить решение проблем.

Также появилась опция генерации бандла поддержки (support bundle), чтобы получить все необходимые конфигурационные файлы в архиве через API или GUI.

Кроме того, был упрощен процесс проверки и развертывания пакетов Interop Bundles. Теперь вы можете проверить доступность последнего interop bundle и обновить его через GUI. В разделе Administration доступны опции Check for Interop Bundle Update и Update Interop Bundle:

Также теперь при логине в GUI появляется баннер, который периодически проверяет доступность версий interop bundle и предлагает обновиться, чтобы ваш хост VCPLCM был всегда последней версии. Помните, что для работы функций VCPLCM нужен доступ к VMware Customer Connect.

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

Загрузить VMware Cloud Provider Lifecycle Manager 1.4 можно по этой ссылке. Документация доступна тут.

Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.

Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.

Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.

Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).

Итак для этого вам понадобятся:

• Действующий vCenter Server не ниже седьмой версии
• Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
• Виртуальный модуль vCenter Server Appliance 8.0 Build 20519528 OVA
• Виртуальный модуль Nested ESXi 8.0 IA OVA

Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.

Пример исполнения сценария показан ниже:

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

Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:

Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.

На днях компания VMware обновила свое решение vRealize Suite Lifecycle Manager до версии 8.8, входящее в пакет решений vRealize Suite. Напомним, что оно предназначено для развертывания установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Он пришел на смену решению VMware Update Manager (VUM), расширив его возможности. О версии 8.6 vRLCM мы писали вот тут.

Давайте посмотрим, что нового в vRLCM 8.8:

1. Управление жизненным циклом vRealize Orchestrator

Теперь Lifecycle Manager поддерживает решение по автоматизации операций vRealize Orchestrator, которое есть в составе пакета vRealize Automation (базовая версия), так и существует в виде отдельного продукта (полнофункциональная версия для производственной среды).

Теперь можно добавить существующий сервер vRealize Orchestrator, развернуть новый в составе vRealize Automation, либо создать отдельный инстанс vRO в рамках установки инфраструктуры vRA:

Помните, что vRealize Orchestrator нельзя установить без наличия в инфраструктуре сервисов vRealize Automation. Импорт существующего инстанса выглядит очень просто:

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

После импорта иконка vRealize Orchestrator будет отображаться на карточке виртуального окружения:

Так как vRO ассоциирован с установленным vRA, то действия Day 2 для vRO появятся как подвкладка для продукта vRealize Automation:

Действия Day 2 для управления жизненным циклом доступны из меню в правом верхнем углу:

2. Улучшения для vRealize Automation

Раньше при снятии снапшота инфраструктуры vRealize Automation перед апгрейдом кластера требовалось около 10 минут на правильное выключение всех систем. Теперь это время было уменьшено в рамках улучшений рабочих процессов при создании онлайн-снапшота и откате к нему. Перед апгрейдом vRLCM проверяет нормальное функционирование vRealize Automation.

Второе улучшение в vRealize Automation Cloud - это поддержка развертывания Cloud Extensibility Proxy. Раньше карточка для прокси была, но доступна она была только для стандартных прокси. Теперь при создании нового прокси он будет развернут как extensibility service. На картинке ниже показано отличие от предыдущей версии:

3. Кластеры VMware Identity Manager

При развертывании или масштабировании трехузлового кластера VMware Identity Manager теперь можно развертывать новые узлы в разных датацентрах и кластерах. Это позволяет обеспечить высокую доступность на уровне разных кластеров и площадок.

В прошлых релизах расширенные настройки не позволяли менять инфраструктурные опции. Теперь же можно менять все поля настроек для каждого узла:

Обратите внимание, что все узлы должны использовать одну сеть в рамках серверов vCenter Server.

4. Улучшенные нотификации

Теперь появились нотификации для состояния лицензий и их устаревания:

Это позволяет заранее позаботиться о лицензиях и сертификатах, которые актуальны в вашем окружении и выполнить соответствующее действие в службе Lifecycle Operations перед тем, как ваши лицензии/сертификаты устареют.

Еще одно улучшение - это дополнительный шаг валидации при добавлении webhook URL для Slack и Teams, чтобы сразу убедиться в том, что параметры указаны верно (отсылается тестовое сообщение).

5. Улучшения VMware Cloud Foundation

В этом релизе появилась автоматическая установка менеджмент паков VMware Identity Manager и SDDC Health как части развертывания vRealize Operations. Это нужные паки для мониторинга окружения VMware Cloud Foundation, которые раньше устанавливались вручную.

Начиная с VMware Cloud Foundation 4.4 и vRealize Suite Lifecycle Manager 8.6.2, развертывание продуктов семейства vRealize контролируется vRLCM. Это позволяет пользователям делать апгрейд продуктов, как только выходят их новые версии, без необходимости ждать, пока обновится список поддерживаемых систем VMware Cloud Foundation BOM.

Теперь пользователи могут проводить апгрейды продуктов vRealize в режиме поддержки VMware Cloud Foundation, что сокращает время самого апгрейда. Это поддерживается для продуктов vRealize, начиная с версии 8.1.

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

Еще одно улучшение тут - это обработка изменений пароля vCenter. Теперь SDDC Manager может регулярно менять пароли vCenter Server, которые автоматически обновляются в хранилище Realize Suite Lifecycle Manager.

6. Улучшения Content Management

В этом релизе исправлена ошибка, когда контент не удалялся из источника (например, GitHub) при обновлении.

Подробнее о VMware vRealize Suite Lifecycle Manager 8.8 можно узнать по этой ссылке. Release Notes на русском языке доступны тут.

Многие из вас заметили, что на сайте VMware обновление vSphere 7 Update 3 пока не скачать. При входе на страницу загрузки VMware vSphere показывают красное предупреждение, которое говорит о том, что проблема нового апдейта весьма серьезная:

Скачать VMware vSphere 7 Update 3 и ее компоненты сейчас нельзя.

Ситуация продолжается уже 5 дней, а VMware не дает конкретных сроков устранения проблемы. При этом пользователям, которые уже провели апгрейд до vSphere 7 Update 3, 3a или 3b - неясно пока, что делать. Нам в комментариях уже писали о том, что сталкиваются с серьезными проблемами при апгрейде на U3 и после этого.

Основная информация о возникшей проблеме приведена в KB 86398. Там можно узнать, что вся линейка Update 3 была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Прямо скажем - проблем этих много, и просто удивительно, как все это прошло выходной контроль при выпуске релизов третьего пакета обновлений. Это и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и другое:

Следим за развитием событий, FAQ в KB 86398 не дает никакой ясности по планируемому времени исправления проблемы. Пользователям, обновившимся до vSphere 7 Update 3, не рекомендуют откатываться до предыдущей версии, если они не сталкиваются с серьезными проблемами в функционировании инфраструктуры.

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

Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.

Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:

iqn.1998-01.com.vmware:labesx06-4ff17c83

То для Update 2 уже так:

iqn.1998-01.com.vmware:labesx07:38717532:64

Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.

Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.

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

$ esxcli iscsi adapter get -A vmhba67

Вывод будет, например, таким:

vmhba67
Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

И потом вот эту команду, чтобы задать новое имя:

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

Также можно это сделать и с помощью PowerCLI-сценария (подробнее тут):

Get-VMHost |
ForEach-Object -Process {
    $HostHBA = $_ | Get-VMHostHba -Type iScsi | Select-Object Name,IScsiName
    $esxcli = get-esxcli -v2 -vmhost $_
    $CLIARG =  @{
        adapter = $HostHBA.Name
        name = $HostHBA.IScsiName
        skipifsessionactive = $false
        }
    $esxcli.iscsi.adapter.set.Invoke($CLIARG)
write-host "Setting host " $H  "adapter"  $HostHBA.Name "with IQN" $HostHBA.IScsiName
    }

Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.

Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):

Failed to load crypto64.efi

Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.

Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:

• Supervisor Cluster
  • Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
  • Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
• Tanzu Kubernetes Grid Service for vSphere
  • Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
  • Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
  • Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.

Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-7.0U2a-17867351-standard \

-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Скачать VMware vSphere 7 Update 2a можно по этой ссылке. Release notes доступны тут.

Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.

Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).

Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

• Quick boot on Dell EMC
• Quick Boot on HPE
• Quick Boot on Cisco
• Quick Boot on Fujitsu
• Quick Boot on Lenovo

По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.

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

Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.

Ну и вот небольшое демо того, как это работает:

Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.

Давайте посмотрим, на какие вопросы там можно найти ответы:

• Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
• Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:

• Какое хранилище рекомендуется в качестве системного для ESXi?
• Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
• Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
• Что вообще означает Degraded Mode?
• Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
• Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
• Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут

Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

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

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:

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

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

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.

Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...

Для платформы VMware vSphere 7 вышло первое обновление - стал доступен для скачивания апдейт управляющего сервера VMware vCenter 7.0 Update 0a.

Цифра 0 в номере апдейта намекает на то, что ничего особо нового в обновлении нет, что соответствует действительности - было исправлено лишь несколько мелких ошибок и одна важная.

Она заключалась в том, что vSphere Lifecycle Manager и службы vSAN File Services не могли быть одновременно включены в кластере. Если вы включали что-то из этого первым, то второй компонент не мог быть включен после этого (они не были совместимы между собой). Теперь это поправили - и они вполне работают вместе.

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

Помимо этого, были обновлены и службы VMware vSphere with Kubernetes, включающие в себя виртуальный модуль Tanzu Kubernetes clusters OVA. Из нового там появилось:

• Службы Tanzu Kubernetes Grid Service for vSphere:
  • Пользователи могут накатывать последовательные обновления rolling upgrades на узлы worker nodes и control plane nodes для Kubernetes Grid Service for vSphere и апгрейдить службы pvCSI, Calico и authsvc. Также для этих компонентов предусмотрены процедуры пре-чеков перед апгрейдом.
  • Последовательные обновления rolling upgrades могут быть использованы для одновременного с апгрейдом изменения класса ваших узлов на больший или меньший по размеру.
• Для Supervisor cluster поддерживаются новые версии Kubernetes с возможностью апгрейда:
  • Kubernetes 1.17.4
  • С версии Kubernetes 1.16.x можно обновиться на 1.17.x

Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.

Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.

Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:

Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:

После этого данный образ появится в списке:

Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:

Выбираем образ, который мы хотим привязать к бейслайну:

После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:

После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):

Перед запуском апгрейда нужно выполнить Remediation Pre-Check, чтобы проверить, что в кластере нет препятствий для апгрейда хостов на седьмую версию.

Если ничего критичного не нашлось, жмем на кнопку Remediate:

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

В консоли вы увидите, что ESXi 7.0 установлен:

То же самое будет и в vSphere Client:

Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.

При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:

CPU_SUPPORT ERROR

Такая ситуация, например, произошла у Rajesh Radhakrishnan на сервере HP 380 G7, где он развертывал виртуальный ESXi 7.0 на платформе vSphere 6.0 Update 3:

В этом случае вы все равно можете установить гипервизор ESXi седьмой версии. Для этого вам надо открыть настройки виртуальной машины:

В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:

• Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
• Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000

После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:

После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:

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