На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.

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

• Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
• Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
• Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):

• Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
• Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
• Улучшения Supervisor Cluster:
  • Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
  • Поддержка NSX-T 3.1 для Supervisor Clusters
  • Удалена поддержка Supervisor Cluster версий 1.16.x.
• Улучшения служб Tanzu Kubernetes Grid for vSphere:
  • Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
  • Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
  • Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.

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

Не так давно мы писали о технологии vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Делается это за счет того, что на хостах есть агентские виртуальные машины служб vCLS.

Дункан Эппинг описал ситуацию, когда эти виртуальные машины просто не включаются с ошибкой в консоли vSphere Cleint:

Insufficient resources

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

The target host does not support the virtual machine's current hardware requirements.

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

Feature 'MWAIT' was absent, but must be present.

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

Вариант 1:

Для устранения ошибки про Feature 'MWAIT' нужно убедиться, что опция Monitor/MWAIT включена в BIOS (Enabled). vCLS включает EVC на базе виртуальных машин для каждой ВМ. Если же это не помогло или вы не можете это сделать, то нужно использовать метод, описанный ниже.

Вариант 2:

1. Апгрейдим ВМ в плане "Compatibility" до последней версии виртуального железа “VM version 14” (меню апгрейда есть по правой кнопке в vSphere Client).
2. Выбираем нужную ВМ, переходим на вкладку Configure и идем в VMware EVC.
3. Нажимаем "Edit" и выбираем “Yes” для подтверждения изменения настроек
4. Выбираем Disable EVC.
5. Повторяем это для всех виртуальных машин.

На днях компания VMware выпустила обновление своего пакета vRealize Operations Management Pack for Kubernetes 1.5.1, которое позволяет отслеживать состояние контейнерных сред Kubernetes из консоли Operations. Напомним, что ранее оно называлось Management Pack for Container Monitoring.

Надо отметить, что vRealize Operations с помощью данного пакета может обеспечивать мониторинг как сред Tanzu Kubernetes в публичном или онпремизном облаке, так и инфраструктуры OpenStack с развернутыми кластерами Kubernetes.

Давайте посмотрим, что появилось нового в MP for Kubernetes 1.5.1:

1. Поддержка vRealize Operations Advanced

Теперь пользователи издания Advanced также могут использовать пакет управления, ранее эта возможность была доступна только владельцам лицензий Enterprise. Для vRealize Operations Cloud поддержка также сохранилась.

2. Улучшенный сбор метрик средствами Prometheus

Многие пользователи сред Kubernetes используют Prometheus для сбора метрик в кластерах. Теперь vRealize Operations за счет MP может запрашивать метрики с сервера Prometheus, а данные об инфраструктуре получать напрямую через Kubelet API.

Такая интеграция по-прежнему позволит вам использовать механизмы интеллектуального анализа данных, в том числе Troubleshooting Workbench и Metric Correlation.

Prometheus хранит данные в отличном от vRealize Operations формате. Чтобы преобразовать и получить данные для метрик Prometheus можно использовать следующих экспортеров (exporters):

• Telegraf Kubernetes Input Plugin
• cAdvisor Exporter
• cStats Exporter
• Kube-State-Metrics
• Windows-node-exporter
• Node Exporter

Если ваша команда разработки дорабатывает какие-то метрики в экспортерах, то они автоматически становятся доступны в vRealize Operations.

vRealize Operations также собирает метки (labels) с серверов Prometheus. Они могут включать важные данные, такие как IP-адреса узлов, имена приложений или процессов, номера версий или даже, например, какие метрики используются для конкретного ядра CPU:

Для игнорирования ненужных метрик (например, GUID) можно использовать фильтры:

3. Мониторинг приложений в Kubernetes

Теперь интеграция vRealize Operations и Prometheus позволяет более глубоко взглянуть на уровень приложений:

В данном примере показано приложение Redis, для которого используется экспортер Telegraf. Для него vRealize Operations может видеть такие метрики как: число клиентов, как много времени CPU требуется на выполнение вызовов, информацию о памяти и application backlogs.

4. Поддержка новых Tanzu Mission Control API

Теперь vRealize Operations и MP могут не только автоматически мониторить облачные среды Tanzu Mission Control на платформе AWS, но и полностью поддерживают обновленный API. Также недавно было анонсировано, что Tanzu Mission Control будет поддерживать Tanzu Kubernetes Grid on vSphere 7, и вскоре эта поддержка будет добавлена и в Management Pack.

Скачать VMware vRealize Operations Management Pack for Kubernetes 1.5.1 можно по этой ссылке. Документация находится здесь.

Компания Veeam, производитель лидирующих на рынке средств для обеспечения доступности виртуальных датацентров, в декабре объявила о доступности для скачивания новой версии Veeam Backup for Microsoft Office 365 v5. Напомним, что с помощью этого решения можно производить резервное копирование и восстановление данных Office 365 из облака, а также бэкапить локальные данные Microsoft Exchange, OneDrive и Sharepoint.

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

1. Поддержка Microsoft Teams

Многие Enterprise-администраторы используют Microsoft Teams для создания среды совместной работы для команд различного размера в рамках предприятия. Теперь Veeam Backup for Microsoft Office 365 v5 позволяет производить резервное копирование этих сред с использованием специального API от Microsoft.

Этот API позволяет узнать, с каким каналом ассоциирован каждый data point, что позволяет организовать бесшовное резервное копирование и восстановление сред Microsoft Teams для SharePoint Online, Exchange и OneDrive.

Veeam Explorer for Microsoft Teams включает в себя возможности восстановления для каналов, настроек, прав доступа, приложений и вкладок, включая данные и компоненты.

Также появилась возможность поиска по 17 полям:

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

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

Кроме того, теперь данные Office 365 в два раза быстрее перемещаются между локальной БД и объектным хранилищем репозиториев.

3. Обновление Restful API

Помимо поддержки Microsoft Teams, появились функции отчетности о ежемесячном использовании ресурсов, что позволяет гибко использовать эту информацию в целях биллинга (она поставляется в виде JSON). Через API теперь также можно управлять лицензиями пользователей.

Скачать можно по этой ссылке. Также Veeam выпустила целую книжку "Microsoft Teams Backup", в которой описаны лучшие практики по резервному копированию таких пользовательских сред.

Как многие администраторы уже знают, 31 декабря этого года прекращается официальная поддержка технологии Adobe Flash большинством браузеров. Это в первую очередь затрагивает VMware vSphere Web Client, использовавшийся для управления старыми версиями VMware vSphere, когда новая платформа vSphere Client на базе HTML5 еще только развивалась (сейчас это полнофункциональный клиент, а старого веб-клиента больше нет). Напомним, что ранее была прекращена поддержка Internet Explorer.

Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:

В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:

EOLUninstallDisable=1

EnabledAllowList=1

AllowListPreview=1

AllowListUrlPattern=https://FQDN/

Вместо FQDN нужно указать адрес вашего сервера vCenter, vCloud Director или веб-консоли другого продукта.

Вот где находится файл mms.cfg в зависимости от браузера и операционной системы:

Более подробно об этом рассказано в KB 78589.

На сайте проекта VMware Labs появилось обновление утилиты VMware Event Broker Appliance (VEBA) v0.5. Напомним, что это решение, которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That". О версии VEBA 0.3, вышедшей весной этого года, мы писали вот тут.

Давайте посмотрим, что нового появилось в продукте, начиная с версии 0.3 и вплоть до вышедшей на днях версии 0.5:

• Новый интерфейс VEBA Direct Console UI (DCUI)

• Новые примеры функций Incident Management
• Новый пример функции на Golang
• Возможность развертывания VEBA в существующем кластере Kubernetes (см. тут)
• Обновление базовой ОС на последний релиз Photon OS 3.0 Rev2
• Сетевой провайдер (CNI) контейнеров Weave заменен на Antrea
• Поддержка кастомизации Docker bridge network (default: 172.17.0.1/16) через свойство OVF-шаблона
• Возможность мониторинга виртуального модуля VEBA через vRealize Operations (см. тут)
• Обновлены: Helm chart, BOM, ресурсы (документация и посты блогов), K8s, Contour, OpenFaaS
• Возможность фильтрации по всем полям данных
• В Readme добавили информацию по всем событиям vCenter
• Конфигурация виртуального модуля теперь происходит через YAML
• Обновлен create-docker-dev-image.yml
• Поддержка бэкап-функций для виртуальных машин Veeam Backup and Replication
• Функции VMware Cloud Notification Slack и поддержка Microsoft Teams
• Нотификация по email о машинах, перезапущенных со стороны VMware HA
• В документации появились функции поиска
• Много небольших нововведений, доработок и фиксов багов

Полный список улучшений последней версии VEBA v0.5 приведен вот тут. Скачать VMware Event Broker Appliance можно по этой ссылке. Также у VEBA появился отдельный сайт, где есть большой раздел с документацией:

Какое-то время назад мы писали о полезном документе "Product Lifecycle Matrix", в котором приведены основные моменты касающиеся жизненного цикла продуктов VMware: дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровождения и дата снятия с продаж.

Наш читатель Ser указал на интересный ресурс - это онлайн-тул Product Lifecycle Matrix, который выводит актуальную информацию из указанного документа в возможностью сортировки и фильтрации по нужным колонкам:

Удобно, что в таблице можно не только искать нужный продукт (кстати, не ищите vSphere, потому что там продукты разделяются на ESXi и vCenter), но и экспортировать полученный табличный вид в PDF или CSV, а также вывести его на печать.

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

В общем, нужная штука - пользуйтесь.

На сайте компании Veeam появился кумулятивный Patch 3, который вы можете накатить на релиз продукта для резервного копирования и репликации виртуальных машин Veeam Backup and Replication 10a. Главная новая фича данного патча - это официальная поддержка новой версии платформы виртуализации VMware vSphere 7 Update 1.

Это уже третий кумулятивный патч после релиза версии 10а в июле этого года.

Давайте посмотрим на новые возможности, появившиеся в третьем патче к Veeam B&R v10a:

• Полная поддержка VMware vSphere 7.0 U1, включая обновленный vSphere API, а также виртуальных машин с Virtual Hardware 18.
• Автоматическое исключение из бэкапа системных ВМ, используемых службой vSphere Clustering Service (vCLS).
• Поддержка Microsoft Windows 10 20H2 и Microsoft Windows Server 20H2 как гостевых ОС, защищенных методом host-based backups и agent-based backups. Также туда можно поставить компоненты Veeam Backup & Replication.
• Поддержка дистрибутивов RHEL 8.3 и SLES 15 SP2 со стороны Veeam Agent for Linux 4.0.1.2372 - как в плане функций агента, так и в плане установки компонентов Veeam B&R.
• Добавлена поддержка S3-совместимого объектного хранилища со включенным версионированием и отключенным object lock (например, Backblaze B2).

Перед обновлением убедитесь, что номер билда вашей версии - это 10a (build 10.0.1.4854) в разделе Help -> About консоли Veeam Backup & Replication. После апгрейда номер билда должен измениться на 10.0.1.4854 P20201202.

Скачать Veeam Backup and Replication 10a Patch 3 можно по этой ссылке.

Компания VMware запустила новый ресурс core.vmware.com, посвященный технической информации для администраторов инфраструктуры VMware vSphere, решений vSAN, Horizon, vRealize и других платформ.

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

Например, из интересного:

• VMware vSphere Security Configuration Guide 7 (а также секция Security)
• vMotion Enhancements in vSphere 7 (а также секция vSphere)
• vSphere with Tanzu Proof of Concept и Quick Start Guides

Документов будет много, но основной упор будет делаться на продукты vSphere, vSAN и Cloud Foundation.

Кстати, раз уж речь зашла о документации, расскажем, что VMware потихоньку начинает добавлять техническую документацию по продуктам на русском языке на сайт VMware Docs (мы писали об этом тут). Смотрите, например, что уже есть по vRealize Automation:

В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.

Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:

Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).

Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.

После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:

Для конкретного продукта можно вывести список его версий/релизов:

Также для конкретной версии можно вывести список категорий максимумов:

С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:

Можно вывести все конфигурации в рамках заданной категории:

Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:

Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.

С помощью параметра New можно, например, вывести все новые настройки:

Параметр Modified выведет только отличающиеся максимумы конфигураций:

Ну а параметр Deleted выведет устаревшие настройки:

Ну и все вместе, без неизмененных значений:

Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:

PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation

Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.

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

Переход на новую subscription-based схему начался уже сейчас и завершится к 6 мая 2021 года, когда обычные лицензии Horizon перестанут существовать.

По заверениям VMware это даст пользователям следующие преимущества:

• Единую среду для управления лицензиями онпремизных инсталляций и облачных пользовательских сред - все это будет делаться через Horizon Control Plane.
• Облачные сервисы могут применяться к онпремизным десктопам, расширяя их функциональность. Если же пользователям нужны только онпремизные инфраструктуры - то и там можно будет использовать десктопы на базе подписки.
• Администраторы смогут разворачивать новые десктопы в облаке без капитальных затрат, а также создавать их в целях HA/DR. Это позволит гибко подходить к вопросу отказо- и катастрофоустойчивости, добавляя или удаляя резервные системы по мере надобности.
• Возможность перехода между тарифами. Теперь пользователи смогут использовать гибкую систему ценообразования и апгрейдов, чтобы постепенно стремиться к получению оптимальной конфигурации.
• Инструменты для получения единой среды EUC (End User Computing) для всех пользователей на любых устройствах с помощью облачного решения Workspace ONE, интегрированного с VMware Horizon.

В ближайшее время ожидаем документ с подробным описанием новой схемы лицензирования VMware Horizon на базе подписки.

Компания VMware на днях выпустила обновление продукта Cloud Director Availability 4.1, предназначенного для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).

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

Давайте посмотрим на основные новые возможности Cloud Director Availability 4.1:

1. Новые e-mail оповещения для клиентов

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

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

2. Поддержка шифрования Cloud-to-Cloud

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

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

Теперь клиенты могут использовать единую аутентификацию с использованием собственного провайдера identity provider (SSO/LDAP/SAML), что позволяет не вводить логин-пароль при соединении с разными площадками.

4. Упрощенный мастер начальной конфигурации

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

5. Улучшенные нотификации для провайдеров

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

6. Разделение операций Migrations и Protections

Теперь управление для Migrations и Protections полностью разделено и доступно на базе независимых контролов:

7. Резервное копирование и восстановление виртуальных модулей Cloud Director Availability 4.1

Теперь Virtual Appliances, входящие в состав Cloud Director Availability 4.1, можно бэкапить, а также восстанавливать с случае сбоев производственных систем. Важно, что восстановление, как и бэкап, делается в несколько кликов.

Если у вас версия Cloud Director Availability 4.0 то до 4.1 можно обновиться сразу, а вот с версии 3.5 придется обновляться через 4.0. Более подробная информация о продукте приведена здесь.

Недавно компания VMware залила на GitHub актуальную версию графики для составления схем и диаграмм в Microsoft Visio и OmniGraffle - VMware Stencils. Иконки и графика доступны еще и в формате Microsoft PowerPoint, а также в векторном формате SVG.

Напомним, что в прошлый раз о стенсилах VMware Stencils мы писали год назад вот тут, а в то время не было версии для OmniGraffl под Mac OS.

Собственно сами ссылки:

• Версия для Microsoft Visio
• Версия для OmniGraffle
• Версия для Microsoft PowerPoint
• Версия в формате SVG

Рекомендации по использованию графических ресурсов:

• Используйте шрифт Metropolis.
• Сначала создавайте текстовые блоки, чтобы понять, что дизайн вписывается в максимальный размер элементов по ширине.
• Не используйте шрифт менее 11 пунктов.
• Не масштабируйте фигуры и иконки - это может привести к их искажениям.
• Не используйте другой формат страницы, это тоже может вызвать сбой в визуализации.

Скачать иконки, графику и диаграммы можно из папок по основной ссылке на GitHub.

На днях на сайте проекта VMware Labs появилось очередное интересное обновление - новая версия гипервизора VMware ESXi Arm Edition 1.2 для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства).

Напомним, что о версии ESXi Arm Edition 1.1 мы писали вот тут, а здесь также рассказывали об установке этого гипервизора на платформу Raspberry Pi.

Давайте посмотрим, что нового в VMware ESXi Arm Edition 1.2:

• Если у хоста нет датасторов, то datastore browsing отключен
• Пофикшен отсутствующий параметр context_id для вызовов CPU_ON
• Исправлена проблема с контроллером GICv2 (теперь SGI всегда включены и работают как устройства GIC-500)
• Поддержка гостевых ОС на базе big-endian
• Убраны требования/ограничения на initrd для ВМ без UEFI

В целом, все это технические фиксы - но обновить вашу тестовую лабу не помешает. Новая версия ESXi Arm встает только как свежая установка, обновление прошлых версий не поддерживается. Можно сохранить прошлые тома VMFS, выбрав опцию "Preserve VMFS", но машины надо будет перерегистрировать заново.

Скачать ESXi Arm Edition 1.2 можно по этой ссылке.

Недавно у компании VMware появился интересный документ "Performance Characterization of NVMe-oF in vSphere 7.0 U1", в котором рассказывается о производительности протокола NVMe-oF (NVMe over Fibre Channel).

Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.

Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.

Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).

Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:

Задержка (Latency) также снизилась практически в два раза:

На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:

Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!

Остальные интересные детали тестирования - в документе.

На днях один из сотрудников компании VMware сделал аддон Helm Chart под решение vRealize LogInsight Cloud, который позволяет обрабатывать логи кластеров Kubernetes в среде VMware vSphere и TKG (Tanzu Kubernetes Grid).

Работает это решение в двух средах:

• Интегрированные кластеры Tanzu Kubernetes Grid (TKG) K8
• Отдельные инсталляции кластеров K8 на платформах vSphere/AWS

После установки аддона вы можете начать собирать метрики с кластеров TKG и K8 в вашем окружении, а также визуализовывать их на дашбордах наподобие вот такого:

Вообще Helm - это менеджер пакетов для Kubernetes. Это один из лучших путей поиска, шаринга и использования программного обеспечения в кластерах K8. Helm Charts это YAML-манифесты Kubernetes, объединенные в один пакет, который можно развернуть в среде K8. После запаковки установка Helm Chart в кластере производится одной командой helm, которая позволяет просто указать параметры развертывания и апгрейда.

Перед использованием данного средства вам понадобятся:

• Токен для vRealize LogInsight Cloud API
• Helm версии 3.x
• Административный доступ к кластеру Kubernetes

Итак, процедура по шагам:

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Получаем файл с переменными из рабочей директории:

helm show values loginsight-cloud/loginsight-cloud-helm > values.yaml

3. Обновляем параметры API Token и другие настройки, специфичные для вашей среды. Начинаем с команды:

cat values.yaml

4. Устанавливаем компонент Chart:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm -f values.yaml

5. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

6. Верифицируем релиз Helm:

helm list

Второй рабочий процесс установки (интерактивный режим):

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Устанавливаем Chart в интерактивном режиме:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm --set vrlic.apikey=SETME --set tag.environment=DEMO

3. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

4. Верифицируем релиз Helm:

helm list

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

Чтобы начать пользоваться пробной бесплатной версией облака vRealize LogInsight Cloud, можно запросить триальную версию тут.

Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:

1. Расширение томов PersistentVolumeClaim

В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.

2. Статический провижининг в Supervisor Cluster

Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).

3. Поддержка vVols для vSphere K8s и TKG Service

Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.

4. Функции Data Protection for Modern Applications

В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.

5. Функции vSAN Direct

Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.

Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.

Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.

1. Функции Network QoS для трафика резервного копирования

Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:

Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.

2. Улучшенная обработка задач резервного копирования

Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.

3.Улучшенное масштабирование для одновременно запущенных задач РК

Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.

4. Улучшения vSphere APIs for I/O Filtering (VAIO)

Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.

Теперь здесь появились следующие улучшения:

• CIM provider теперь стал 64-битным
• Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты

Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.

На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.

Симптомы переполнения кучи, как правило, следующие:

• Датасторы на хостах показывают статус "Not consumed"
• Виртуальные машины не могут выполнить vMotion
• Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
• При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."

В логе vmkernel.log могут появляться следующие сообщения об ошибках:

• Heap vmfs3 already at its maximum size. Cannot expand
• Heap vmfs3: Maximum allowed growth (#) too small for size (#)
• Failed to initialize VMFS distributed locking on volume #: Out of memory
• Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory

Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:

# vmkfstools -c 10M -d eagerzeroedthick /vmfs/volumes/datastore/eztDisk

Удалить этот диск можно командой:

# vmkfstools -U /vmfs/volumes/datastore/eztDisk

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

# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done

Результат будет примерно таким:

Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:

Maximum allowed growth * too small for size

Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.

На сайте проекта core.vmware.com появился интересный документ из будущего, описывающий особенности проектирования и сайзинга кластеров хранилищ vSAN, актуализированный 4 декабря этого года - VMware vSAN 7 Update 1 Design Guide:

На самом деле, документ этот очень полезен для администраторов VMware vSAN, планирующих развертывание корпоративной инфраструктуры хранилищ на базе серверов ESXi. В нем рассматриваются все новые возможности версии vSAN 7 Update 1, включая технологию HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):

Основные разделы документа:

• vSAN Design Overview
• vSAN Limits
• Network Design Considerations
• Storage Design Considerations
• VM Storage Policy Design Considerations
• Host Design Considerations
• Cluster Design Considerations
• Determining if a Workload is Suitable for vSAN
• Sizing Examples
• vSAN Sizing Tool
• VMware vSAN GSS Support

Очень полезная вещь - это наличие рекомендаций и лучших практик по различным аспектам проектирования кластров:

Интересная табличка по рекомендациям выставления опций по реакции на событие изоляции (Isolation Responce / Isolation Policy):

Интересны также указания на часто встречающиеся ошибки проектирования:

В общем, документ мегаполезный. Скачать VMware vSAN 7 Update 1 Design Guide можно вот тут.

На днях на сайте проекта VMware Labs появилась новая версия средства VMware OS Optimization Tool (билд b2000), предназначенного для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач. Напомним, что о прошлом релизе (b1171) мы писали вот тут.

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

• Новая опция, позволяющая отложить обновления фич или сразу накатить их (или пропустить)
• Такая же опция, касающаяся quality updates
• Возможность пропустить обновления Office Click-to-Run
• Добавлены команды по остановке и отключению служб App Volumes при повторном включении Windows Update
• После этого они будут установлены в значение automatic, если Windows Update будет снова отключен

Также в новом билде было поправлено много ошибок:

• Исправлена проблема, из которой останавливался автоматический логин в издания Server и WVD после применения Sysprep
• Исправлено подтверждение перезагрузки в процессе генерализации Win10 1607 LTSB
• Исправлена проблема с невозможностью включения антивируса в Windows 10 2004
• Исправлена проблема со скачиванием обновлений фичей при повторном включении Windows Update
• Выбор Common options теперь сохраняется при следующих запусках OS Optimization Tool
• Для всех вкладок пользователи могут применять разные настройки Common Options на оптимизируемой системе
• На вкладке Update есть опция включения/выключения обновлений Office 365, 2016, 2019
• На вкладке Store Apps есть чекбокс для отключения удаленных встроенных приложений.

Скачать VMware OS Optimization Tool b2000 можно по этой ссылке.

Многие администраторы платформы VMware vSphere задаются вопросом - что произойдет, если изменить политику хранилищ (Storage Policy) в кластере vSAN для виртуальной машины? Будет ли после этого выполнена операция по перестроению дисковых объектов (Rebuild), что повлечет дополнительную нагрузку на хранилища и займет время?

Также в некоторых условиях операция Rebuild может не выполняться, но выполняется Resync - добавление новых копий данных, при котором исходные копии данных не изменяются (например, вы увеличиваете значение политики FTT, что влечет создание новых дисковых объектов).

Ответ на этот вопрос зависит от того, какую политику и на что вы меняете. Дункан Эппинг провел полезные тесты в своей лабе, чтобы выяснить, в каких случаях происходит Rebuild/Resync. После каждой операции он через интерфейс командной строки проверял, происходила ли операция ресинхронизации. Далее он свел полученные результаты в таблицу ниже, чтобы при изменении политики администраторы vSAN представляли, что произойдет дальше.

Собственно, таблица:

Компания VMware пару недель назад объявила о выпуске бета-версии операционной системы Photon OS 4.0 Beta. Напомним, что эта ОС используется сейчас уже во всех виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. Напомним, что о прошлой версии Photon OS 3.0 мы писали весной прошлого года вот тут.

Давайте посмотрим, что нового появилось среди возможностей обновленной ОС:

1. Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)

Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов.

2. Безопасность

Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.

Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.

3. Оптимизации производительности для решения vSphere with Tanzu

Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.

4. Улучшения компонентов ОС

В Photon 4.0 были обновлены более 700 пакетов, включая ключевые компоненты, такие как tdnf, pmd, network config manager и многие другие. Также в релиз включены превью-фичи для, которые ожидаются в финальной версии ОС. Поэтому рекомендуется не использовать бету Photon 4.0 для производственных сред.

Разработка Photon OS очень сильно опирается на участие комьюнити. Поэтому ваши комментарии, предложения и отчеты об ошибках можно добавлять вот тут.

В этом релизе, как в прошлом, ОС распространяется в бинарном предзапакованном формате - загрузочный ISO, предустановленный минимальный OVA-пакет, кастомизированный под VMware, образ Amazon AMI, образ Google GCE, образ Azure VHD, а также образ Raspberry Pi (протестированный для архитектуры ARM64).

Образы Photon OS 4.0 Beta можно скачать по этой ссылке. Публичный репозиторий доступен вот тут.

Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.

Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027 Version 8 (build 13861).

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

Общие улучшения и багофиксы

• Обновлено ядро модуля Linux Kernel.
• Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
• Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
• Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
• Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.

Улучшения синхронной репликации

• Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
• Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
• Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.

Управляющая консоль (Management Console)

• Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
• Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).

Модуль StarWindX PowerShell

• Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.

• Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.

Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.

На сайте проекта VMware Labs появилась очень замороченная, но интересная штука для гиков - симулятор Storage Simulator Using Cellular Automata.

Это такая утилита, построенная на принципах клеточного автомата (cellular automata, CA), которая позволяет смоделировать характеристики производительности для путей данных в кластере vSAN. Сам методика клеточных автоматов позволяет смоделировать и исследовать комплексную систему со множеством элементов, работающих параллельно и имеющих короткие соединения между собой, при этом создающих эмерждентную сущность.

При симуляции стека хранилищ данная утилита моделирует передачу блоков данных по сети через аппаратные ресурсы по различным коротким соединениям, таким как CPU->кэш->DRAM->SSD/HDD, соединения PCIe, Ethernet и т.п. Вот небольшое видео о том, как это работает:

Основная цель такой симуляции - получить идеальные показатели пиковой пропускной способности к хранилищам - так называемая speed-of-light (SOL) throughput.

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

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

Вот пример такого моделирования:

В общем, если у вас есть время на подобные игры - скачивайте Storage Simulator Using Cellular Automata по этой ссылке. Инструкции по использованию доступны там же на вкладке "Instructions".

Пару недель назад на сайте проекта VMware Labs вышли обновления сразу нескольких утилит, поэтому вы, возможно, пропустили апдейты HCIBench 2.5 и 2.5.1. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.

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

• Добавлена возможность тестирования в рамках топологии vSAN HCI Mesh, теперь можно добавлять локальные и удаленные датасторы vSAN одновременно.
• Добавлена поддержка локальных хранилищ, включая VMFS и тестирование vSAN-Direct.
• Новый режим vSAN Debug Mode, который позволяет автоматически собрать бандлы vm-support и vmkstats при тестировании vSAN.
• Изменена конвенция имен виртуальных машин на {vm_prefix}-{datastore_id}-batch_num-sequence_num.
• Улучшенный формат отчета о тестировании.
• Возможность указывать кастомные IP для тестовых машин.
• Возможность выставлять CPU и память для тестовых машин.
• Добавлено руководство по сетевому траблшутингу как раздел пользовательской документации.
• Возможность обновления на текущую и последующие версии одной командой:
  tdnf install -y git && git clone https://github.com/cwei44/HCIBench.git && sh HCIBench/upgrade.sh
MD5 Checksum: 1d14426f92b353e90469a8623ade2bc1 HCIBench_2.5.1.ova
• Исправлены ошибки с тестированием не-vSAN кластера, а также с превалидацией политики хранилищ.
• Прочие исправления ошибок.

Скачать VMware HCIBench 2.5.1 можно по этой ссылке.

Некоторое время назад мы писали о версии пакета VMware Tools 11, который теперь доступен и для Mac OS. На днях компания VMware сделала еще одно важное изменение в линейке VMware Tools - теперь это отдельный и самостоятельный продукт, а не часть платформы vSphere.

На практике это означает, что теперь тулзы имеют собственную политику жизненного цикла (Lifecycle policy), а также собственную матрицу поддержки, позволяющую пользователям понять, какой жизнью живут VMware Tools, и когда их нужно апгрейдить:

Также загружать VMware Tools стало более удобно. Раньше они были доступны на вкладке "Drivers and Tools" раздела загрузки vSphere, а теперь это отдельный продукт и находится он в "Product Downloads".

Скачать VMware Tools теперь можно по этой ссылке. Основная статья базы знаний на эту тему - KB 78528.

Многие администраторы VMware vSphere знают, что у этой платформы есть режим совместимости Enhanced vMotion Compatibility (EVC), который позволяет привести хосты с процессорами (CPU) разных моделей к единому базовому уровню по набору возможностей CPU Feature Set, чтобы обеспечить свободную миграцию vMotion между хостами ESXi. Делается это за счет маскирования некоторых наборов инструкций процессора через CPUID.

Сейчас многие приложения (например, реализующие техники Machine Learning / Deep Learning) используют ресурсы графического адаптера (GPU), поскольку их многоядерная архитектура отлично подходит для такого рода задач.

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

Поэтому в VMware vSphere 7 Update 1 сделали еще одно полезное улучшение по этой теме - режим Enhanced vMotion Capabilities для графических процессоров GPU, который является частью EVC, настраиваемого в vSphere Client:

Графический режим VMFeatures включает в себя поддерживаемые возможности для 3D-приложений, включая библиотеки D3D 10.0/ Open Gl 3.3, D3D 10.1 / Open GL 3.3 и D3D 11.0 / Open GL 4.1. Пока приведение к базовому уровню доступно только до D3D 10.1 / OpenGL 3.3 (версии 11.0 и 4.1, соответственно, будут поддерживаться в следующих релизах).

Когда хост ESXi включается в кластер, где включена EVC for Graphics, сервер vCenter проверяет, что он поддерживает соответствующие версии библиотек. При этом можно добавлять хосты разных версий - ESXi 6.5, 6.7 и 7.0, благодаря поддержке D3D 10.0 и OpenGL 3.3.

Как и для обычного EVC, пользователи могут включить EVC for Graphics на уровне отдельных ВМ. В этом случае перед тем, как включить виртуальную машину на хосте ESXi, сервер vCenter убеждается, что он поддерживает соответствующие библиотеки. Такая настройка полезна при возможной миграции виртуальной машины между датацентрами или в публичное облако.

Если у вас включена EVC for Graphics, то перед миграциями vMotion также будут проводиться нужные предпроверки по поддержке графических функций GPU со стороны видеоадаптера целевого хоста.

Это крупнейшая БЕСПЛАТНАЯ онлайн-конференция в этом году, организованная Veeam. Вас ждет не просто очередной скучный вебинар, а яркое мероприятие: интересные интерактивные сессии и рассказы о возможностях использования продуктов Veeam, которые помогут вам подготовиться к решению любых задач по защите данных.

Мероприятие пройдет онлайн в этот четверг, 12 ноября.

Региональная команда Veeam проведет сессии на русском по следующим темам:

• Управление данными в облаке
• Кибербезопасность
• Возможности предстоящей Veeam v11

Запланирована дискуссия с русскими заказчиками: SberCloud, MTC, Мегафон и DataLine, для обмена опытом. Сессии, на которые рекомендуем обратить внимание:

• Управление данными в гибридных мультиоблачных средах. Круглый стол с ведущими поставщиками услуг - Владимир Клявин
• Безграничные возможности масштабирования в облаке с Veeam Scale-out Backup Repository - Виталий Савченко
• Сессии для партнеров - Елена Карина

Регистрируйтесь прямо сейчас и участвуйте бесплатно!

VMware на днях выпустила патч VMSA-2020-0023, который окончательно закрывает уязвимость CVE-2020-3992, имевшуюся в сервисе OpenSLP хоста ESXi. Эта уязвимость типа Use-After-Free позволяла злоумышленнику, имевшему доступ к 427 порту, получить возможность удаленного исполнения кода (эта уязвимость имела критический статус и CVS score 9.8 из 10).

VMware заявляет, что данные патчи, выпущенные 20 октября, не закрывают уязвимость полностью, поэтому нужно скачивать самые последние версии патчей:

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

• ESXi 7.0 - ESXi70U1a-17119627. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi_7.0.1-0.0.16850804
• ESXi 6.7 - ESXi670-202011301-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi670-202010401-SG
• ESXi 6.5 - ESXi650-202011401-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi650-202010401-SG

Воркэраунд, описанный в статье базы знаний KB 76372, все еще актуален. Его суть заключается в полном отключении сервиса SLP с помощью следующих команд:

/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off

Обновляйтесь обязательно!