За релизами платформы VMware vSphere 8, у которой недавно состоялся выпуск General Availability, многие забыли о том, что большинство пользователей в производственной среде используют еще VMware vSphere 7. Недавно компания VMware выпустила обновления компонентов этой версии платформы - ESXi 7.0 Update 3i (на 13 декабря почему-то недоступен для скачивания) и vCenter 7.0 Update 3i. Напомним, что об обновлении VMware vSphere 7 Update 3f мы писали вот тут (а здесь - о возможностях Update 3), с тех пор вышел еще апдейт 3g, а сегодня мы расскажем об очередном пакете - 3i.
Давайте посмотрим, что нового в ESXi 7.0 Update 3i:
Поддержка функций vSphere Quick Boot для сервера HPE ProLiant MicroServer Gen10 Plus v2
Исправления для уязвимостей CVE-2022-31696 и CVE-2022-31699, описанных в статье VMSA-2022-0030
В VMware vCenter 7.0 Update 3i появились следующие улучшения:
Исправления для уязвимостей CVE-2022-31697 и CVE-2022-31698, описанных в статье VMSA-2022-0030
Исправление для уязвимости CVE-2021-22048, описанное в статье VMSA-2021-0025
Обновление решения VMware vSphere with Tanzu (подробнее - в Release Notes)
Обновление Photon OS (подробнее тут, в основном патчи безопасности)
Как мы видим, обновления чисто косметические, но исправлены некоторые актуальные проблемы безопасности, поэтому обновиться стоит. Очевидно, что новый функционал в vSphere 7 добавляться уже не будет, так как идет работа над обновлением vSphere 8.
Скачать VMware ESXi 7.0 Update 3i и VMware vCenter 7.0 Update 3i можно по этой ссылке.
На сайте проекта VMware Labs появился новый интересный продукт - Cluster Rules Manager (CRM). С помощью данной утилиты можно провести обследование виртуальной инфраструктуры на предмет правил DRS affinity и anti-affinity rules. Первые определяют обязательное сосуществование ВМ на одном хосте ESXi (например, критичный сервис с высокой интенсивностью сетевого и дискового взаимодействия), а вторые - наоборот, невозможность существования ВМ на одном хосте (например, для целей отказоустойчивости и независимости от единой точки отказа оборудования).
По итогам использования этого средства через веб-консоль администраторы могут провести аудит текущих правил DRS, а также делать их импорт и экспорт в рамках инфраструктуры VMware vSphere.
Давайте посмотрим на возможности VMware Cluster Rules Manager:
Аудит правил anti-affinity для всех виртуальных машин в рамках сервера vCenter.
Импорт правил DRS affinity rules из разных серверов vCenter.
Экспорт правил DRS affinity rules в новый vCenter с сервера vCenter, гле они уже настроены.
Отчет о правилах, содержащий различные умные метрики - пользователь может выбрать, на каком уровне он будет сгенерирован (vCenter, датацентр или кластер). Отчет можно экспортировать в HTML-формат.
Отчет в реальном времени по ассоциациям VM-Rule. Можно выбрать виртуальную машину, и отчет будет содержать информацию обо всех правилах DRS, которые затрагивают данную ВМ. Этот отчет также можно генерировать на разных уровнях - ВМ, хост ESXi, кластер, датацентр и сервер vCenter. Его также можно экспортировать.
Возможность соединяться с разными vCenter в интерфейсе продукта.
Скачать VMware Cluster Rules Manager (CRM) можно по этой ссылке. Такую утилиту мы давно ждали, правда пока интерфейс оставляет желать лучшего. Ждем следующих версий!
На сайте проекта VMware Labs вышло еще одно полезное обновление - комплект драйверов USB Network Native Driver for ESXi версии 1.11. USB-драйвер для ESXi может понадобиться для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этого комплекта драйверов мы рассказывали тут.
Основным и единственным нововведением данного комплекта стала поддержка гипервизора VMware ESXi 8.0 в составе VMware vSphere 8.0 (пакет SXi800-VMKUSB-NIC-FLING-61054763-component-20826251.zip).
Актуальная таблица поддерживаемых сетевых адаптеров на сегодня выглядит так:
Установка драйвера для vSphere версии 7.0 и выше выполняется командой:
По итогам конференции Explore 2022 компания VMware представила линейку продуктов Aria, пришедшую на смену семейству vRealize. В нее вошло онпремизное решение Aria Operations 8.10, а также облачное Aria Operations Cloud. Оба они предназначены для комплексного управления и мониторинга виртуальной облачной инфраструктуры в различных аспектах.
Одной из главных возможностей Aria Operations являются дэшборды, которые показывают различные метрики виртуальной инфраструктуры, собираемые как напрямую, так и с помощью менеджмент-паков. Сегодня мы посмотрим на интересный дэшборд CPU Core, который предоставляет информацию об используемых ядрах CPU на уровне разных объектов - от датацентров до хостов VMware ESXi.
В рамках анонсированной недавно подписки vSphere+ и решения vRealize Cloud Subscription Manager появилась возможность лицензировать компоненты виртуальной инфраструктуры vSphere и Aria на базе ядер процессоров (CPU Cores). Ниже мы посмотрим, как можно с помощью Aria Operations визуализовать распределение процессоров, чтобы оптимизировать потребление лицензий. Об этом рассказал Karthic Kumar в блоге VMware.
Дэшборд - это мощный функционал Aria Operations, который дает администратору коллекцию виджетов и связанную информацию об объектах датацентра. Мы создадим суперметрики (super metrics) и представления (Views), которые предоставляют данные для дэшборда Core distribution. Чтобы упростить процесс, используем шаблон, в котором есть следующие файлы:
Super Metrics (supermetrics.json)
Views (views.zip)
Dashboard(dashboard.zip)
Итак, скачиваем файл шаблона и заходим в консоль Aria / vRealize Operations под аккаунтом администратора. Нам надо импортировать суперметрики из JSON-файла, для этого идем в Configure –> Super Metrics –> Import и выбираем Supermetric.json:
После импорта у нас в списке появится суперметрика CorePerSocket. Выбираем для нее пункт Edit и включаем ее в политике по умолчанию, чтобы она применилась:
Далее нужно импортировать представления (Views), которые забирают данные суперметрик. Идем в Visualize –> Views –> Manage–> Import и выбираем файл views.zip:
После этого мы увидим импортированные представления в списке:
Теперь пришло время импортировать сам дэшборд. Идем в Visualize –> Dashboards –> Manage–> Import и выбираем файл Dashboard.zip:
Теперь можно кликнуть на Core Distribution в списке дэшбордов. Чтобы данные актуализировались может пройти до 15 минут (если вы видите надпись "No data available"):
В отображаемых данных вы увидите распределение ядре по датацентрам и хостам. Эти виджеты позволят вам получить информацию о соответствии использования лицензий по разным объектам вашей гибридной инфраструктуры. Ну а вы всегда сможете кастомизировать этот дэшборд, чтобы он соответствовал вашим требованиям.
Все из вас, я думаю, знают о продукте Veeam Backup and Replication, ставшем уже стандартом де-факто для резервного копирования виртуальной инфраструктуры VMware vSphere и обеспечения доступности виртуальных датацентров.
Вы также, конечно же, в курсе, что недавно компания VMware объявила о финальной доступности (General Availability) своей обновленной платформы виртуализации VMware vSphere 8. Очевидно, сразу же встал вопрос резервного копирования виртуальных машин на этой платформе.
Компания Veeam недавно выпустила статью KB 2443 о поддержке резервного копирования ВМ на VMware vSphere 8 продуктом Veeam Backup and Replication 11a (билд 11.0.1.1261 P20220302). Суть ее в том, что в целом сейчас обеспечивается работоспособность процесса бэкапа для серверов VMware ESXi 8.0 (это протестировали инженеры Veeam), но с некоторыми ограничениями:
Как вы знаете, недавно компания VMware сделала публично доступной для всех обновленную версию платформу виртуализации VMware vSphere 8 в рамках релиза General Availability (ранее состоялся выпуск продукта на этапе Initial Availability).
Администраторы, которые давно следят за выпусками платформы vSphere, знают, что при первоначальном выпуске гипервизора в официальном списке совместимости HCL (Hardware Compatibility List) не все серверные системы приводятся как сертифицированные для последнего релиза vSphere. Например, некоторые могут заметить, что многие серверы различных производителей, которые поддерживались в vSphere 7 Update 3, пока отсутствуют в HCL.
На это обратил внимание Florian Grehl, автор сайта virten.net. Причина такого факта проста - при первоначальном выпуске новой версии ESXi не все серверные системы успевают должным образом протестировать и сертифицировать.
Именно такой список и приводит Флориан, он довольно большой, поэтому лучше всего посмотреть его тут. Список официально несертифицированного оборудования становится все короче, поэтому на virten.net публикуются его обновления (последнее доступное - от 14 ноября). В списке пока представлены только серверы от Cisco, DELL, Fujitsu, Hewlett Packard Enterprise, Hitachi, IBM, Lenovo, Inspur, Huawei и Supermicro.
При клике на выбранный сервер откроется его карточка в VMware HCL:
Надо понимать, что тот факт, что система не сертифицирована, не означает, что VMware vSphere / ESXi на ней работать не будет. Просто вендоры самостоятельно занимаются сертификацией, а значит делают это каждый в своем темпе. Поэтому, если ваш сервер есть в списке, то лучше всего спросить о его сертификации у вендора напрямую.
На сайте проекта VMware Labs вышло обновление платформы VMware ESXi Arm Edition 1.11. Напомним, что этот продукт представляет собой гипервизор для архитектуры ARM на базе кода ESXi. В будущем он найдет свое применение в таких решениях, как Project Monterey. О прошлой версии ESXi для ARM 1.10 мы писали в июле этого года.
Давайте посмотрим, что нового появилось в ESXi Arm Edition 1.11:
Поддержка CPU accelerated crypto (например, NEON и Armv8 Cryptographic Extensions) для встроенных служб ESXi
Исправлена проблема с xterm-256color terminfo. Программа Terminal в macOS (или любой другой современный терминал) теперь корректно отображает данные команды esxtop
Поддержка виртуального модуля vTPM с функциями Secure Boot и шифрования ВМ
Поддержка аппаратного обеспечения GICv4
Добавлены VMware Tools для Windows
Решена проблема с драйвером ixgben
Обратите внимание, что начиная с версии 1.10, поддерживается апгрейд с ESXi Arm Edition 1.x. Чтобы сделать апгрейд вам понадобится создать загрузочное USB-устройство из ISO-образа и инициировать апгрейд в интерактивном режиме через ESXi Console. Использование VUM/vSphere Lifecycle Manager пока не поддерживается.
Известные на данный момент проблемы:
Системы Ampere Altra могут вывалиться в розовый экран (PSOD) при использовании AHCI-дисков
Графический инсталлятор Ubuntu 22.04 LTS не работает, используйте Ubuntu 22.10
Загрузить VMware ESXi ARM Edition 1.11 можно по этой ссылке.
Как вы знаете, на прошедшей конференции 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
Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.
Пример исполнения сценария показан ниже:
В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:
Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:
Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.
Вчера мы писали о том, что решение VMware vSphere 8 стало доступным для загрузки (Initial Availability). Анонсированная на конференции Explore 2022 платформа приобрела не только новые функции клиента vSphere Client, предназначенного для управления инфраструктурой на базе vCenter, но и получила новую версию хостового клиента для отдельных серверов ESXi Host Client 2, который удобно использовать, когда vCenter недоступен.
Напомним, что в прошлый раз о этом клиенте мы писали вот тут, тогда VMware планировала выпустить его второе поколение в конце 2021 года. Теперь Host Client 2 поддерживает не только управление инфраструктурой vSphere 8, но и серверы виртуализации vSphere 7.0 Update 6 (обновление пока не вышло).
Итак, что же нового в VMware ESXi Host Client 2:
1. Обновленная иконка приложения
Самое главное:)
2. Новый дизайн интерфейса на базе фреймворка Clarity
Многие из вас в курсе, что VMware перевела почти все свои интерфейсы на собственный open source фреймворк Clarity, и хостовый клиент стал очередным продуктом, который также был на него переведен. Рабочие процессы теперь выглядят более опрятно, а шаги мастеров - более организованно:
Браузер датасторов теперь дает больше информативности, а сами надписи и информационные лейблы стали более читаемыми. Файлы теперь можно загружать в параллельном режиме в фоне, а колонки позволяют обеспечивать видимость глубокой структуры каталогов:
3. Улучшенные иконки
Теперь в качестве визуальных элементов используется более 100 иконок, которые соответствуют таковым из конвенционального vSphere Client. Все иконки стали монохромными, чтобы не нагружать интерфейс и глаза.
Вот так выглядят портлеты свойств:
А вот так - действий:
4. Специальные возможности
Теперь для слабовидящих людей есть приятные улучшения. Элементы попадают в обводку:
Для полей ввода есть выделение (можно переключаться между ними по Tab или Shift+Tab), а на вкладках четко видны активные элементы:
5. Выбор светлой или темной темы
Тему можно выбрать в разделе Help > About > UI Preferences Theme:
На выбор есть 3 темы. Стандартная - это светлые цвета и мягкий контраст:
Классическая - для привыкших к стандартному белому фону:
И темная - для чувствительных к свету и любителей работать по ночам:
Но вообще по кнопке Customize можно настроить различные цвета для визуальных групп:
6. Кастомизабельный стартовый экран
В файле /etc/vmware/welcome можно редактировать иконку и приветственное сообщение, которые могут быть индивидуальными для каждой компании:
Таблица поддерживаемых браузеров сейчас выглядит так:
Клиент ESXi Host Client 2 в обновленной платформе VMware vSphere 8 доступен администраторам по ссылке в браузере:
Недавно мы писали о новой схеме релизов платформы VMware vSphere. Согласно ей, вводится два типа выпусков - IA (Initial Availability) и GA (General Availability), которые позволяет выровнять схему релизов с продуктами облачной линейки Cloud Services в рамках доступной пользователям подписки vSphere+.
Вчера VMware объявила о доступности vSphere 8 Initial Availability - продукт можно скачать по этой ссылке. О возможностях новой версии платформы мы писали вот тут.
IA-релиз - это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он, как правило, на 4-6 недель раньше, чтобы собрать условия его применения от клиентов (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени будут публиковаться все найденные важные проблемы.
Ставить этот релиз в производственной среде вы можете, но это не рекомендуется. Пока его лучше обкатывать на тестовых серверах и смотреть, как все работает (особенно новый функционал платформы). После выхода vSphere 8 General Availability можно смело устанавливать продукт на свои производственные серверы, так как все критичные проблемы первоначального релиза будут уже решены.
Вчера мы писали о важном нововведении технологии горячей миграции виртуальных машин vMotion Notifications, появившемся в обновленной версии VMware vSphere 8, представленной на конференции Explore 2022. Она позволяет оповещать приложение гостевой ОС о скором начале миграции, чтобы оно могло подготовиться к ней и выполнить процедуры по приостановке сервисов или переключению на резервную систему для кластеризованных приложений.
Второе важное нововведение vMotion в ESXi 8 - это технология Unified Data Transport.
Для миграции включенных виртуальных машин используется протокол vMotion, который оптимизируют уже много лет - он многопоточный и асинхронный, что позволяет минимизировать время перемещения виртуальной машины между хостами ESXi. Этот же протокол использует и технология миграции хранилищ Storage vMotion. В то же время, если вам нужно переместить выключенную виртуальную машину (холодная миграция), то это может занять значительное время, так как в этом случае используется протокол Network File Copy (NFC).
Приведем ниже сравнительные характеристики обоих протоколов (реальная скорость миграции будет зависеть от параметров вашего окружения):
Network File Copy (NFC)
vSphere vMotion
Процесс в один поток
Глубоко оптимизированный многопоточный процесс
Синхронный ввод-вывод
Асинхронный ввод-вывод
Пиковая производительность 1.3 Gbps
Пиковая производительность 80 Gbps
Чтобы привести все к единому уровню производительности, VMware представила технологию Unified Data Transport (UDT) в платформе vSphere 8, которая комбинирует лучшие моменты обеих технологий NFC и vMotion.
Unified Data Transport (UDT) использует NFC как протокол для управления миграцией, а вот сама передача данных идет через протокол vSphere vMotion. Для того, чтобы эта технология работала, вам нужно активировать сервис "Provisioning" для интерфейса VMkernel (это может быть как новый, так и уже существующий интерфейс):
Если вы используете выделенный стек TCP/IP для vMotion, вы не сможете активировать службу "Provisioning" на этом же интерфейсе, в этом случае можно просто создать еще один интерфейс.
Посмотреть вживую, насколько хорошо работает технология Unified Data Transport для холодной миграции виртуальных машин, вы можете в видео ниже:
По итогам прошедшей конференции Explore 2022 компания VMware анонсировала платформу виртуализации vSphere 8. В прошлой версии платформы в технологии горячей миграции vMotion появилось очень много всего нового (например, вот, тут, тут, тут и тут). В этой версии также были сделаны некоторые улучшения vMotion, давайте на них посмотрим.
vSphere vMotion Notifications
Как вы знаете, переключение с одного процесса ВМ на другой целевого хоста ESXi занимает очень мало времени, и для большинства приложений это незаметно. Однако есть очень небольшое количество приложений, которые не могут пережить малые задержки (latency), поскольку очень интенсивно используют ресурсы CPU и хранилищ. Таких случаев буквально единицы, но VMware решила позаботиться и о них.
Теперь приложения могут быть написаны таким образом, чтобы они могли получить оповещение о предстоящей миграции vMotion и подготовиться к ней. Такие действия могут включать в себя остановку сервисов, заморозку приложения (quiescing), переключение на резервный инстанс в случае кластеризованного приложения, а также выполнение других операций.
Приложение может отложить миграцию vMotion на заданный таймаут, но не может отклонить и остановить ее. Вот как это работает (кликните на картинку для открытия анимации):
Приложение, через механизм VMware Tools, может быть оповещено о начале задачи vMotion. На полученную нотификацию оно реагирует согласно своей логике, после чего отсылает подтверждение платформе ESXi о том, что миграцию можно начинать. Виртуальная машина затем перемещается с помощью vMotion, после чего приложение получает оповещение о завершении миграции, чтобы оно могло также выполнить необходимые шаги, учитывая действия, совершенные на этапе подготовки.
Механизм vMotion Notifications не включен по умолчанию. Чтобы это работало, надо в расширенных настройках виртуальной машины установить параметр vmOpNotificationToAppEnabled:
После этого нужно установить host-level timeout, который будет определять максимальное время, которое есть у виртуальной машины для завершения подготовки к миграции. Для этого нужно через vSphere API установить параметр vmOpNotificationToApp.Timeout со значением большим 0. Значение устанавливается в секундах (то есть, чтобы дать приложению 5 минут, нужно установить значение 300).
Для установки данного параметра используйте ConfigManager API (см. документацию).
Приложение должно использовать утилиту командной строки vmtoolsd пакета VMware Tools для регистрации оповещений. Вот какие команды ему доступны:
На конференции Explore 2022 компания VMware объявила о выпуске новой версии платформы VMware vSphere 8, о возможностях которой мы уже писали. Сегодня мы посмотрим, что нового появилось в механизме работы томов vVols, которые позволяют более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.
Сегодня мы поговорим о нововведениях, которые появились в технологии vVols для восьмой версии платформы.
1. Поддержка технологии NVMe-oF
Это большое нововведение означает поддержку томами vVols на платформе vSphere 8 технологии NVMe-oF. В новой спецификации vVols появились определения vSphere API для механики работы с хранилищами VASA (vSphere Storage APIs for Storage Awareness) 4.0.
Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.
NVMe-oF имеет преимущество в виде меньших задержек (latency) над традиционным интерфейсом SCSI. Эта технология изначально предназначена для флэш-памяти и позволяет подключать all-flash NVMe дисковые массивы с очень высокой производительностью.
В рамках технологии NVMe-oF vVols каждый объект vVol становится пространством имен NVMe Namespace. Эти пространства имен группируются в ANA group (Asymmetrical Namespace Access). Многие команды проходят как In-Band для более эффективной коммуникации между хостами ESXi и дисковыми массивами.
Также упростилась настройка томов, в том числе NVMe с технологией vVols. При развертывании NVMe в vCenter, когда зарегистрирован VASA-провайдер, оставшаяся установка происходит в фоновом режиме, а обнаружение NVMe-контроллеров происходит автоматически. Как только создается датастор, объекты vPE (virtual Protocol Endpoints) и само соединение подхватываются и обрабатываются автоматически.
2. Дополнительные улучшения vVols NVMe-oF
Они включают в себя следующее:
Поддержка до 256 пространств имен и 2000 путей
Расширенная поддержка механизма резерваций для устройств NVMe - это позволит поддерживать функцию Clustered VMDK для кластеризованных приложений, таких как Microsoft WSFC на базе хранилищ NVMe-oF
Функции автообнаружения в механизме NVMe Discovery Services для ESXi при использовании NVMe-TCP для обнаружения контроллеров NVMe
3. Прочие улучшения
Улучшение VM swap - уменьшенное время при включении и выключении для обеспечения лучшего быстродействия vMotion
Улучшенная производительность компонента config-vVol - убраны задержки при обращения виртуальных машин к платформе ESXi
В рамках событий первого дня проходящей сейчас конференции VMware Explore 2022 была анонсировала платформа виртуализации VMware vSphere 8. Это событие очень ждали многие администраторы и менеджеры датацентров, так как с момента релиза прошлой мажорной версии платформы VMware vSphere 7 прошло уже два с половиной года. Давайте посмотрим, что нового в VMware vSphere 8...
Компания VMware обновила свой гипервизор для архитектуры ARM на сайте проекта Labs - ESXi ARM Edition 1.10. В будущем этот гипервизор найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM 1.9 мы писали в апреле этого года.
Давайте посмотрим, что нового в ESXi ARM Edition 1.10:
Теперь поддерживается апгрейд с прошлых версий ESXi-Arm 1.x
Поддержка Arm DEN0115 (доступ к конфигурации PCIe через интерфейс firmware, протестировано на Raspberry Pi)
Поддержка L3 cache info для Ampere eMAG
Небольшие улучшения для non-cache coherent DMA
Статистики для Raspberry Pi NIC (genet)
GOS: возможность использования VNXNET3 и PVSCSI как драйверов по умолчанию в freebsd12
Поддержка чипов RK3566 SBC (например, Quartz64) - как PCIe, так и EQOS onboard NIC
Исправлены ошибки для драйвера Intel igbn NIC (повышена стабильность работы)
Возвращается нулевой код ошибки для unknown sys_reg(3, 0, 0, x, y) для виртуальных машин
Данные телеметрии - собирается статистика о системе, на которой запущен гипервизор
Вот какие данные собираются в рамках телеметрии в целях улучшения продукта:
CPU info: число ядер, NUMA, производитель и т.п.
Firmware info: вендор и версия
Platform info: вендор, продукт, UUID, список устройств
ESXi-Arm info: версия, уровень патчей, билд продукта
Скрипт /bin/telemetry выполняется при каждой загрузке и в 00:00 каждую субботу
Скачать VMware ESXi ARM Edition 1.10 можно по этой ссылке.
Компания VMware на днях выпустила два обновления своей платформы виртуализации vSphere 7 - ESXi 7 Update 3f и vCenter 7 Update 3f. Напомним, что об обновлении vSphere 7 Update 3d мы писали вот тут.
Давайте посмотрим, что в них появилось нового.
VMware ESXi 7 Update 3f:
Данный релиз исправляет уязвимости, описанные в бюллетенях CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 и CVE-2022-29901. Для подробной информации об этих проблемах вы можете обратиться к статье VMSA-2022-0020.
Добавлена поддержка vSphere Quick Boot для следующих серверов:
Исправления уязвимостей CVE-2022-22982 (подробнее тут) и CVE-2021-22048 (подробнее тут)
Улучшения масштабируемости архитектуры VMware HCI Mesh - теперь один кластер vSAN может обслуживать локальные датасторы до 10 клиентских кластеров vSAN
Улучшения компонентов vSphere Client - исправлены некоторые проблемы с дата-гридами, инвентарем (более компактное представление), Related Objects и Global Inventory Lists. Ну и в целом улучшено юзабилити клиента.
Обновление инфраструктуры VMware vSphere with Tanzu (подробнее тут)
Как вы знаете, через интерфейс esxcli на сервере VMware ESXi можно устанавливать расширенные настройки (Advanced Settings). Список таких доступных настроек можно вывести командой:
esxcli system settings advanced list
При этом не все пространства имен (namespaces) доступны через этот интерфейс командной строки. Эти настройки, в таком случае, как правило, доступны через интерфейс vSphere Client, но вам может понадобиться заскриптовать их. Об этом рассказал Дункан Эппинг.
Некоторые администраторы vSphere знают, что есть также такой интерфейс vim-cmd, который уже не рекомендуется использовать, но, тем не менее, его еще можно применять для установки некоторых настроек. Среди них, например, есть настройка Config.HostAgent.ssl.keyStore.allowSelfSigned для разрешения самоподписанных сертификатов на хостах ESXi.
В этом случае вы можете использовать команды в следующем формате:
vim-cmd hostsvc/advopt/update name.option type value
Для самоподписанных сертификатов нужная команда выглядит так:
Мы довольно часто пишем о максимальных параметрах виртуальной инфраструктуры VMware vSphere и ее компонентов, в частности VMware vCenter (например, тут и тут). Сегодня мы немного освежим эти данные на примере последней версии сервера управления vCenter и приведем несколько примеров. Для начала напомним, что актуальные данные по максимальным конфигурациям продуктов VMware можно найти по адресу: https://configmax.vmware.com, а также в официальной документации.
Кроме того, у VMware есть отличное видео, посвященное лимитам vCenter и правилам выполнения одновременных операций в виртуальной среде:
Итак, лимиты можно разделить на 2 категории:
Глобальные лимиты для инфраструктуры (виртуальный датацентр).
Лимиты на уровне хоста и его компонентов (например, сетевые адаптеры).
Если говорить о глобальных параметрах, то значения тут следующие:
Вы можете запустить до 640 одновременных операций в vCenter, пока они не начнут становиться в очередь.
Всего можно запустить до 2000 одновременных операций на один сервер vCenter.
На уровне хостов ESXi есть следующие механизмы работы и ограничения:
Хосты ESXi 6 и 7 версий имеют 16 слотов для выполнения операций в единицу времени:
Любая операция с виртуальными машинами потребляет какое-то количество слотов на источнике и целевом хосте.
Операция Storage vMotion стоит 8 слотов на хост. Если вы меняете только датастор у виртуальной машины, оставляя тот же хост, то потребляются эти 8 слотов, то вы можете сделать 2 одновременных миграции. Ранее это работало несколько иначе - смотрите наш пост вот тут.
Операция Linked clone потребляет 1 слот, но для этого у вас уже должен быть создан снапшот. Если у вас его нет, то он сначала создается - это может замедлить создание первого связанного клона. Также снапшот требуется и при клонировании включенной ВМ, где требуется уже 2 слота (то есть одновременно можно делать 8 таких операций для данной пары хостов).
Операции Clone, Relocate и vMotion стоят 2 слота каждая на каждом хосте - то есть и на источнике, и на целевом (суммарно получается потребляется 4 слота на двух хостах). Это же работает и при клонировании ВМ на том же самом хосте - на нем в этот момент потребляется 4 слота (то есть одновременно на хосте можно делать 4 таких операции).
Для датасторов также есть слоты и ограничения на одновременные операции:
У одного датастора есть 128 слотов.
Операция vMotion стоит 1 слот, то есть на одном датасторе может проходить до 128 одновременных миграций vMotion.
Операция Storage vMotion стоит 16 слотов, то есть на одном датасторе может проходить до 8 одновременных миграций vMotion.
Это же работает и для датасторов vSAN, где часто встречаются конфигурации с одним датастором - это надо иметь в виду.
Лимиты для сетевых адаптеров сейчас следующие (помните, что для vMotion лучше иметь отдельный адаптер или выделенную пару портов на нем):
У 1Gb NIC есть 4 слота, то есть можно делать до 4 одновременных миграций vMotion через этот адаптер.
У 10Gb и 25Gb NIC есть 8 слотов, то есть можно делать до 8 одновременных миграций vMotion через такие адаптеры.
Более подробно об организации адаптеров для vMotion вы можете прочитать в KB 2108824.
На сайте проекта VMware Labs вышло обновление USB Network Native Driver for ESXi 1.10. Напомним, что это средство представляет собой нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этих драйверов мы писали вот тут.
Давайте посмотрим, что нового в версии пакета 1.10:
Добавлена поддержка VMware ESXi 7.0 Update 3c и 3d
Исправлена проблема с выпадением ESXi в BSOD при использовании драйвера с последними версиями ESXi
Драйверы версии 1.10 подходят только для ESXi 7.0 Update 3c и Update 3d, вот их дистрибутив:
Таблица поддерживаемых устройств теперь выглядит так:
Для других версий ESXi нужно использовать одну из предыдущих версий драйвера. Вот, например, обновилась также и версия 1.9, куда были добавлены следующие возможности:
Добавлена поддержка ESXi 7.0 Update 3, 3a и 3b.
Добавлена поддержка идентификаторов VID: 0x0b05/PID: 0x1976 и VID: 0x1A56/PID: 0x3100.
Исправлена проблема в механизме управления питанием в xHCI.
Сканирование шины USB (usbBusFullScanOnBootEnabled=0) отключено по умолчанию, что позволяет предотвратить выпадение в PSOD для пользователей, у которых есть несколько сетевых карточек USB.
Этот релиз предназначен только для ESXi 7.0 Update 3, Update 3a и Update 3b:
В ESXi 7 Update 3d появилась поддержка технологии vSphere Quick Boot для следующих платформ:
Dell Inc. C6420 vSAN Ready Node
Dell Inc. MX740C vSAN Ready Node
Dell Inc. MX750C vSAN Ready Node
Dell Inc. PowerEdge R750xa
Dell Inc. PowerEdge R750xs
Dell Inc. PowerEdge T550
Dell Inc. R650 vSAN Ready Node
Dell Inc. R6515 vSAN Ready Node
Dell Inc. R740 vSAN Ready Node
Dell Inc. R750 vSAN Ready Node
Dell Inc. R7515 vSAN Ready Node
Dell Inc. R840 vSAN Ready Node
Dell Inc. VxRail E660
Dell Inc. VxRail E660F
Dell Inc. VxRail E660N
Dell Inc. VxRail E665
Dell Inc. VxRail E665F
Dell Inc. VxRail E665N
Dell Inc. VxRail G560
Dell Inc. VxRail G560F
Dell Inc. VxRail P580N
Dell Inc. VxRail P670F
Dell Inc. VxRail P670N
Dell Inc. VxRail P675F
Dell Inc. VxRail P675N
Dell Inc. VxRail S670
Dell Inc. VxRail V670F
В VMware vCenter 7.0 Update 3d появились следующие улучшения:
Исправление проблемы безопасности CVE-2022-22948. Более подробно об этом рассказано тут.
Множество исправлений ошибок, полный список которых приведен тут. Решены проблемы с развертыванием ВМ из OVF-шаблонов, исправлены ошибки с накатыванием инкрементальных патчей vCenter, а также проблема с сообщением о невозможности подключения к серверу Single Sign-On.
Обновлены компоненты VMware vSphere with Tanzu, подробнее об этом рассказано тут.
Обновлены компоненты Photon OS, подробнее об этом рассказано тут.
Скачать компоненты VMware vSphere 7.0 Update 3d можно по этой ссылке. Release Notes доступны тут:
На сайте проекта Labs стала доступна новая версия гипервизора VMware под аппаратную архитектуру ARM - VMware ESXi Arm Edition 1.9. В будущем этот гипервизор найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали в декабре прошлого года.
Экспериментальная поддержка платформ Marvell Octeon TX2 CN92xx/CN93xx/CN95xx/CN96xx/CN98xx
Улучшенная поддержка оборудования PL011 UART
Поддержка VMM для ID_AA64ISAR2_EL, а также исправления ошибок для новых ядер Linux (>= 5.17-rc2)
Поддержка PCIe Enhanced Allocation
Улучшения логирования для шины PCIe
Улучшения в механизме виртуализации MSI
Исправления ошибок
Скачать VMware ESXi ARM Edition 1.9 можно по этой ссылке. Напомним, что апгрейд с прошлых версий этого гипервизора не поддерживается, каждую новую версию нужно устанавливать заново (но доступна опция "Preserve VMFS" для сохранения ВМ на томах).
Многие компании сталкиваются сегодня с необходимостью переезжать на другую платформу виртуализации из-за сложностей, связанных с поддержкой зарубежных решений, а также ростом курсов валют. Сегодня мы расскажем об одной из альтернатив, которую предлагает российскому бизнесу компания HOSTVM, и рассмотрим алгоритм миграции на платформу. Сама по себе платформа HOSTVM представляет собой российскую версию гипервизора, построенного на базе открытого исходного кода KVM...
На сайте проекта VMware Labs обновился продукт Community Networking Driver for ESXi до версии 1.2.7. Напомним, что этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe. О прошлой версии этих драйверов мы писали осенью прошлого года вот тут.
Давайте посмотрим, что нового появилось в версии 1.2.7 сетевых драйверов:
Поддержка устройств Intel I225 с любым идентификатором PHY ID
Поддержка новых устройств Intel I226-K (также для любых PHY ID)
Исправлен возможный дэдлок в изменяющемся MTU
Исправлено возможное зависание RX при операциях device layer ops
Исправлена возможная ошибка PHY reset failure
Драйверы работают для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройств сейчас выглядит так:
Установка драйверов производится следующей командой (после этого нужно перезагрузить хост):
esxcli software vib install -d /path/to/the offline bundle zip
Скачать пакет драйверов VMware Community Networking Driver for ESXi 1.2.7 можно по этой ссылке.
Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere
ESXi and Virtual Machines
Guest Operating Systems
Virtual Infrastructure Management
Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках.
Документ очень полезный, состоит из почти ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.
Скачать Performance Best Practices for VMware vSphere 7.0, Update 3 можно по этой ссылке.
Недавно мы писали о выходе новой версии пакета продуктов VMware Cloud Foundation 4.4, предназначенного для создания виртуального датацентра организации. Напомним, что он включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.
Напомним, что одной из новых возможностей VCF 4.4 стало то, что теперь сервис SSH отключен на всех хостах ESXi по умолчанию - это новая конфигурация, которая применяется в соответствии с рекомендациями по безопасности.
Если по какой-то причине на одном или нескольких хостах в рамках доменов рабочей нагрузки (workload domains) вам нужно использовать SSH, то вот как можно это сделать.
Чтобы включить SSH на всех доменах и хостах ESXi вашей инфраструктуры, нужно выполнить следующую консольную команду SDDC Manager как root:
/opt/vmware/sddc-support/sos --enable-ssh-esxi --domain-name ALL
Если нужно включить SSH на одном из доменов, то делается это так:
Все необходимые функции для работы с API по управлению сертификатами были добавлены в PowerCLI версии 12.4 в конце прошлого года, и теперь можно полноценно управлять ими с помощью сценариев.
Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:
Для работы с Trusted Certificate Store
можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:
#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates
Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }
Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:
#Read the certificate or certificate chain from a .pem file
$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw
#Add it to the trusted certificate stores of the vCenter and the ESXi servers
Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain
Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:
2. Управление SSL-сертификатами компьютеров на сервере vCenter Server
Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).
Сначала с помощью этого командлета проверяем текущий сертификат машины vCenter:
Get-VIMachineCertificate -VCenterOnly
После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:
После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:
Перед установкой SSL-сертификата машины мы должны убедиться, что корневой сертификат нашего CA добавлен в хранилище сертификатов vCenter Server. Помните, что замена сертификата вызовет перезагрузку vCenter.
3. Управление SSL-сертификатами машин для серверов ESXi
Если мы хотим управлять сертификатами полностью самостоятельно, нужно также заменить и сертификаты хостов ESXi. Рабочий процесс в этом случае выглядит несколько сложнее. Сначала нужно изменить настройку режима управления сертификатами хостов ESXi на custom на сервере vCenter и перезагрузить его.
После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.
Так же, как и для vCenter, перед установкой сертификата машины нужно убедиться, что корневой сертификат нашего центра сертификации добавлен в доверенное хранилище сертификатов на хосте ESXi и других серверах, с которыми он взаимодействует, то есть остальные хосты ESXi и vCenter.
$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `
-Location (Get-Datacenter "My Datacenter")`
-User "My User" `
-Password "My Password"
Мы уже давно не писали об обновлении утилиты RVTools, предназначенной для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах. В начале февраля вышло обновление этого средства - RVTools 4.3.1.
Давайте посмотрим, что там нового:
RVTools теперь использует VMware vSphere Management SDK 7.0U3.
Новая вкладка vSource, на которой отображается информация о сервере, где исполняется веб-сервис SDK, который используется для сбора данных (это сервер vCenter или хост ESXi).
Новая колонка Host UUID на вкладке vHost.
Новые чекбоксы в разделе Health, которые включают/отключают сообщения о безопасности и производительности.
Раньше колонка UUID заполнялась значениями SMBIOS UUID, которые не уникальны. Теперь там отображается уникальный 128-битный UUID.
Улучшение производительности при обработке данных.
На вкладке vHealth появились советы по улучшению производительности ввода-вывода и памяти.
Исправления ошибок.
Также приведем основные улучшения RVTools с момента выпуска четвертой версии:
Новая вкладка vUSB, отображающая хосты с присоединенными USB-устройствами.
Новая вкладка vFileInfo с информацией обо всех файлах на датасторах vSphere (полная информация включается чекбоксом Get fileinfo detail information").
Log4net обновлен до версии 2.0.12 (защита от уязвимости CVE-2018-1285).
Отображение информации о том, является ли объект плейсхолдером резервной инфраструктуры VMware SRM.
Новая колонка Virtual machine tags на вкладках vInfo, vCPU, vMemory, vDisk, vPartition, vCD, vFloppy, vNetwork, vSnapshot, vTools.
Новая колонка вкладки vInfo: min Required EVC Mode Key.
Новая колонка вкладки vMemory: Memory Reservation Locked To Max.
Новые колонки вкладки vRP: Resource Pool path, Resource Pool tags, число ВМ в пуле ресурсов и object ID.
Новые колонки вкладки vCluster: Cluster tags, custom attributes и object ID.
Новые колонки вкладки vHost: число ВМ в пуле ресурсов, vSAN Fault Domain Name, Host tags, in Maintenance Mode и in Quarantine Mode.
Новые колонки вкладки dvSwitch: Distributed VirtualSwitch tags, custom attributes и object ID.
Новые колонки вкладки dvPort: Distributed VirtualSwitch Port Group tags и object ID.
Новые колонки вкладки vDatastore: число ВМ в пуле ресурсов, Datastore tags, custom attributes и object ID.
Новые колонки вкладки vNetwork: ipv4 и ipv6, NIC label, "Internal Sort Column".
Новые колонки вкладки vDisk: Disk key, disk path, "Internal Sort Column".
Новые колонки вкладки vPartition: "Internal Sort Column", Disk key.
Новый чекбокс в настройках "Exclude tags" и параметр CLI -ExcludeTags.
Объем отображается не в MB, а в MiB.
Предупреждение о том, что данные собраны не со всех ВМ.
Мы уже писали о том, что на сервере VMware ESXi может возникать ошибка "No space left on device" при выполнении различных операций. Тогда мы объясняли, что такая ситуация может произойти из-за исчерпания числа свободных объектов inodes.
Причина такого поведения может заключаться не только в отсутствии свободных нод. Для начала надо проверить, что проблема действительно не в них. Делается это с помощью команды:
stat -f /
Либо можно использовать также команду df -i.
Если все в порядке с айнодами, то проблема может заключаться в так называемых "small file blocks" (SFB) и "large file blocks" (LFB), которые на VMFS создаются под нужды файловой системы для разных типов файлов. Суть самой проблемы в том, что иногда SFB кончаются, и VMFS запускает механизм конвертации LFB в SFB, но получившиеся SFB не становятся доступными сразу. Подробнее об этой механике рассказано в KB 87482.
Продолжаем рассказывать технические подробности о работе продукта StarWind Virtual SAN, позволяющего создавать программные и программно-аппаратные отказоустойчивые кластеры iSCSI для виртуальных сред. Сегодня мы поговорим о расширенных настройках протокола iSCSI на стороне StarWind и на стороне VMware ESXi, чтобы обеспечить непрерывное функционирование приложений в виртуальных машинах при обрыве соединений.
Стек работы с хранилищами VMware ESXi настроен таким образом, чтобы адекватно реагировать на кратковременную потерю сигнала в канале iSCSI, которая может возникнуть по разным причинам (кто-то перекоммутировал соединение, дрогнул порт и т.п.). По умолчанию расширенные настройки iSCSI выставлены так, чтобы переживать кратковременные сбои в рамках одного пути в интервале 25-35 секунд. В это время I/O-запросы будут копиться в очереди, а потом, либо произойдет продолжение передачи при восстановлении текущего соединения, либо хост переключится на резервный путь (failover) текущего или резервного адаптера.
В то время, как такое поведение не является критичным для большинства приложений, иногда есть специфические требования, которые надо выполнять для отдельных систем. Например, если речь идет о системе видеонаблюдения, то там задержка в полминуты является неприемлемой, и ее надо обрабатывать быстрее.
Для этого, если вы используете хранилища StarWind Virtual SAN, есть специальные настройки реагирования на подобные ситуации.
Итак, для начала вам нужно остановить службы StarWind Virtual SAN:
В консоли StarWind Management Console проверить, что все устройства StarWind HA находятся в статусе "Synchronized" на всех серверах
Проверить, что все датасторы имеют активные задублированные пути для всех серверов StarWind, а политика доступа по нескольким путям (MPIO) установлена в Round Robin
На StarWind VSAN для Windows нужно выполнить команду для остановки служб StarWind: net stop starwindservice
На виртуальном модуле StarWind VSA нужно выполнить такую команду: systemctl stop StarWindVSA
Далее открываем конфигурационный файл:
На StarWind VSAN для Windows: C:\Program Files\StarWind Software\StarWind\StarWind.cfg
На виртуальном модуле StarWind VSA: nano /opt/StarWind/StarWindVSA/drive_c/StarWind/StarWind.cfg
Далее там находим параметр iScsiPingCmdSendCmdTimeoutInSec и выставляем его значение, например в "1" (одна секунда).
Ну и, наконец, надо запустить службы StarWind VSAN:
На StarWind VSAN для Windows: net start starwindservice
На виртуальном модуле StarWind VSA: systemctl start StarWindVSA
Теперь нужно добраться до расширенных настроек iSCSI инициатора VMware ESXi. Открываем Advanced Options для адаптера в разделе Storage Adapters нужного нам инициатора:
И смотрим, какие настройки там выставлены:
Нас интересует:
RecoveryTimeout - это как раз время, через которое активный путь помечается как "мертвый" (переводится в DEAD_STATE), когда по нему больше не приходит команд ввода-вывода.
NoopInterval - это интервал, с которым происходит пассивное тестирование неактивных путей на предмет того, живы ли они.
NoopTimeout - это время, через которое происходит пометка неактивного пути как DEAD, если по нему не получено ответа.
Эти настройки по умолчанию установлены в оптимальные с точки зрения вероятности отказа/потерь значения. Меняйте их только, если у вас есть особые требования приложений по непрерывной доступности хранилищ, и вы знаете, какое поведение системы хотите получить. Уменьшение таймаутов, очевидно, ведет к загрузке сети пингами каналов iSCSI и дополнительной нагрузке на устройства.
Как знают многие администраторы, еще в прошлом году в ESXi 7 Update 2 компания VMware стала убирать различные настройки из основного конфигурационного файла esx.conf. Кстати, и не только оттуда. Например, раньше глобальные настройки FDM (он же HA - High Availability) хранились в файле /etc/opt/vmwware/fdm/fdm.cfg. Теперь их там тоже нет - они переехали во внутреннее хранилище ConfigStore, работать с которым нужно с помощью утилиты командной строки configstorecli.
То же самое произошло и с NTP - теперь настройки времени, хранящиеся в /etc/ntp.conf (для NTP) и /etc/ptp.conf (для PTP), недоступны для редактирования через файлы конфигураций. Кстати, если вы не знаете, чем NTP отличается от PTP, у нас есть отличная статья на эту тему (а вот тут - о поддержке PTP в vSphere 7 Update 2).
Более того, теперь все файлы каталога /etc помечены как только для чтения и не сохраняют своих изменений при перезагрузке!
Так что работать с большинством настроек теперь нужно через ConfigStore. В частности, для NTP и PTP есть 2 основных команды, которые взаимодействуют с ConfigStore для конфигурации времени:
Получение настроек времени
# esxcli system ntp get
# esxcli system ptp get
Установка настроек времени
# esxcli system ntp set
# esxcli system ptp set
Если вы хотите узнать список всех конфигурационных файлов, которыми теперь заведует ConfigStore, можно выполнить следующую команду в консоли ESXi:
RSS
