Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6180 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Какие есть версии и номера билдов VMware vCenter, ESXi, Tools и Connection Server?

Простой способ скопировать конфигурацию VMware ESXi через vCenter без SSH с помощью скрипта


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

Автор не хотел вручную создавать резервные копии каждого ESXi хоста, так как это не масштабируется. Вместо этого он создал PowerShell скрипт под названием vCenter ESXi Config Backup, который выполняет в автоматическом режиме.

Вы можете найти скрипт на его GitHub: https://github.com/thedxt/VMware#vcenter-esxi-config-backup.

Требования:

Как это работает:

Скрипт vCenter ESXi config backup подключается к VMware vCenter, далее использует его для подключения к каждому ESXi хосту и последовательно создает резервную копию каждой конфигурации. Поскольку скрипт использует vCenter, вам не нужно включать SSH на каких-либо ESXi хостах для выполнения резервного копирования.

  • По умолчанию, скрипт предполагает, что вы не подключены к vCenter, и запросит вас подключиться к vCenter. Вы можете изменить это поведение, если вы уже подключены к vCenter, установив опциональный параметр connected со значением Yes.
  • Скрипт проверяет, существует ли указанная вами папка для резервного копирования. Если папка не существует, скрипт создаст ее.
  • Затем скрипт получает все ESXi хосты в vCenter, подключается к каждому из них и создает резервную копию конфигурации. Скрипт сохраняет резервную копию в указанную вами папку.
  • После завершения резервного копирования скрипт переименовывает файл резервной копии, добавляя к имени хоста установленную версию ESXi, номер сборки и дату резервного копирования.

Для использования скрипта необходимо предоставить несколько параметров. Первый параметр — vcenter, за которым следует FQDN-имя вашего vCenter. Второй параметр — folder, за которым следует расположение, куда вы хотите сохранить резервные копии конфигурации ESXi.

Вот пример запуска сценария:

esxi-conf-backup -vcenter "vcenter.contoso.com" -folder "C:\ESXi-Backup"

Вот пример вывода этой команды:

Вот пример того, как должна выглядеть команда, если вы уже подключены к vCenter:

esxi-conf-backup -vcenter "vcenter.contoso.com" -folder "C:\ESXi-Backup" -connected Yes

Вот пример вывода этой команды:


Таги: VMware, ESXi, Backup, vCenter, PowerCLI

VMware vSphere 8 Update 3 Core Storage - что нового?


Вчера мы писали о новых возможностях последнего пакета обновлений VMware vSphere 8.0 Update 3, а сегодня расскажем что нового появилось в плане основных функций хранилищ (Core Storage).

Каждое обновление vSphere 8 добавляет множество возможностей для повышения масштабируемости, устойчивости и производительности. В vSphere 8 Update 3 продолжили улучшать и дорабатывать технологию vVols, добавляя новые функции.

Продолжая основной инженерный фокус на vVols и NVMe-oF, VMware также обеспечивает их поддержку в VMware Cloud Foundation. Некоторые функции включают дополнительную поддержку кластеризации MS WSFC на vVols и NVMe-oF, улучшения по возврату свободного пространства (Space Reclamation), а также оптимизации для VMFS и NFS.

Ключевые улучшения

  • Поддержка растянутых кластеров хранилищ (Stretched Clusters) для vVols
  • Новая спецификация vVols VASA 6
  • Кластеризация VMDK для NVMe/TCP
  • Ограничение максимального количества хостов, выполняющих Unmap
  • Поддержка NFS 4.1 Port Binding и nConnect
  • Дополнительная поддержка CNS/CSI для vSAN

vVols

Поддержка растянутого кластера хранилища vVols на SCSI

Растянутый кластер хранения vVols (vVols-SSC) был одной из самых запрашиваемых функций для vVols в течение многих лет, особенно в Европе. В vSphere 8 U3 добавлена поддержка растянутого хранилища vVols только на SCSI (FC или iSCSI). Первоначально Pure Storage, который был партнером по дизайну этой функции, будет поддерживать vVols-SSC, но многие из партнеров VMware по хранению также активно работают над добавлением данной поддержки.

Почему это заняло так много времени?

Одна из причин, почему реализация vVols-SSC заняла столько времени, заключается в дополнительных улучшениях, необходимых для защиты компонентов виртуальных машин (VMCP). Когда используется растянутое хранилище, необходимо наличие процесса для обработки событий хранения, таких как Permanent Device Loss (PDL) или All Paths Down (APD). VMCP — это функция высокой доступности (HA) vSphere, которая обнаруживает сбои хранения виртуальных машин и обеспечивает автоматическое восстановление затронутых виртуальных машин.

Сценарии отказа и восстановления

  • Контейнер/datastore vVols становится недоступным. Контейнер/datastore vVols становится недоступным, если либо все пути данных (к PE), либо все пути управления (доступ к VP, предоставляющим этот контейнер) становятся недоступными, либо если все пути VASA Provider, сообщающие о растянутом контейнере, отмечают его как UNAVAILABLE (новое состояние, которое VP может сообщить для растянутых контейнеров).
  • PE контейнера vVols может стать недоступным. Если PE для контейнера переходит в состояние PDL, то контейнер также переходит в состояние PDL. В этот момент VMCP будет отвечать за остановку виртуальных машин на затронутых хостах и их перезапуск на других хостах, где контейнер доступен.
  • Контейнер или PE vVols становится доступным снова или восстанавливается подключение к VP. Контейнер вернется в доступное состояние из состояния APD, как только хотя бы один VP и один PE станут доступны снова. Контейнер вернется в доступное состояние из состояния PDL только после того, как все виртуальные машины, использующие контейнеры, будут выключены, и все клиенты, имеющие открытые файловые дескрипторы к хранилищу данных vVols, закроют их.

Поведение растянутого контейнера/хранилища данных довольно похоже на VMFS, и выход из состояния PDL требует уничтожения PE, что может произойти только после освобождения всех vVols, связанных с PE. Точно так же, как VMFS (или устройство PSA) не может выйти из состояния PDL, пока все клиенты тома VMFS (или устройства PSA) не закроют свои дескрипторы.

Требования

  • Хранилище SCSI (FC или iSCSI)
  • Макс. время отклика между хостами vSphere — 11 мс
  • Макс. время отклика массива хранения — 11 мс
  • Выделенная пропускная способность сети vSphere vMotion — 250 Мбит/с
  • Один vCenter (vCenter HA не поддерживается с vVols)
  • Контроль ввода-вывода хранения не поддерживается на datastore с включенным vVol-SSC

Дополнительная поддержка UNMAP

Начиная с vSphere 8.0 U1, config-vvol теперь создается с 255 ГБ VMFS vVol вместо 4 ГБ. Это добавило необходимость в возврате свободного пространства в config-vvol. В 8.0 U3 VMware добавила поддержку как ручного (CLI), так и автоматического UNMAP для config-vvol для SCSI и NVMe.

Это гарантирует, что при записи и удалении данных в config-vvol обеспечивается оптимизация пространства для новых записей. Начиная с vSphere 8.0 U3, также поддерживается команда Unmap для хранилищ данных NVMe-oF, а поддержка UNMAP для томов SCSI была добавлена в предыдущем релизе.

Возврат пространства в хранилищах виртуальных томов vSphere описан тут.

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

Поддержка кластеризации приложений на NVMe-oF vVols

В vSphere 8.0 U3 VMware расширила поддержку общих дисков MS WSFC до NVMe/TCP и NVMe/FC на основе vVols. Также добавили поддержку виртуального NVMe (vNVME) контроллера для гостевых кластерных решений, таких как MS WSFC.

Эти функции были ограничены SCSI на vVols для MS WSFC, но Oracle RAC multi-writer поддерживал как SCSI, так и NVMe-oF. В vSphere 8.0 U3 расширили поддержку общих дисков MS WSFC до vVols на базе NVMe/TCP и NVMe/FC. Также была добавлена поддержка виртуального NVMe (vNVME) контроллера виртуальной машины в качестве фронтенда для кластерных решений, таких как MS WSFC. Обратите внимание, что контроллер vNVMe в качестве фронтенда для MS WSFC в настоящее время поддерживается только с NVMe в качестве бэкенда.

Обновление отчетности по аутентификации хостов для VASA Provider

Иногда при настройке Storage Provider для vVols некоторые хосты могут не пройти аутентификацию, и это может быть сложно диагностировать. В версии 8.0 U3 VMware добавила возможность для vCenter уведомлять пользователей о сбоях аутентификации конкретных хостов с VASA провайдером и предоставили механизм для повторной аутентификации хостов в интерфейсе vCenter. Это упрощает обнаружение и решение проблем аутентификации Storage Provider.

Гранулярность хостов Storage Provider для vVols

С выходом vSphere 8 U3 была добавлена дополнительная информация о хостах для Storage Provider vVols и сертификатах. Это предоставляет клиентам и службе поддержки дополнительные детали о vVols при устранении неполадок.

NVMe-oF

Поддержка NVMe резервирования для кластерного VMDK с NVMe/TCP

В vSphere 8.0 U3 была расширена поддержка гостевой кластеризации до NVMe/TCP (первоначально поддерживалась только NVMe/FC). Это предоставляет клиентам больше возможностей при использовании NVMe-oF и желании перенести приложения для гостевой кластеризации, такие как MS WSFC и Oracle RAC, на хранилища данных NVMe-oF.

Поддержка NVMe Cross Namespace Copy

В предыдущих версиях функция VAAI, аппаратно ускоренное копирование (XCOPY), поддерживалась для SCSI, но не для NVMe-oF. Это означало, что копирование между пространствами имен NVMe использовало ресурсы хоста для передачи данных. С выпуском vSphere 8.0 U3 теперь доступна функция Cross Namespace Copy для NVMe-oF для поддерживаемых массивов. Применение здесь такое же, как и для SCSI XCOPY между логическими единицами/пространствами имен. Передачи данных, такие как копирование/клонирование дисков или виртуальных машин, теперь могут работать значительно быстрее. Эта возможность переносит функции передачи данных на массив, что, в свою очередь, снижает нагрузку на хост.

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

VMFS

Сокращение времени на расширение EZT дисков на VMFS

В vSphere 8.0 U3 был реализован новый API для VMFS, чтобы ускорить расширение блоков на диске VMFS, пока диск используется. Этот API может работать до 10 раз быстрее, чем существующие методы, при использовании горячего расширения диска EZT на VMFS.

Виртуальные диски на VMFS имеют тип аллокации, который определяет, как резервируется основное хранилище: Thin (тонкое), Lazy Zeroed Thick (толстое с занулением по мере обращения) или Eager Zeroed Thick (толстое с предварительным занулением). EZT обычно выбирается на VMFS для повышения производительности во время выполнения, поскольку все блоки полностью выделяются и зануляются при создании диска. Если пользователь ранее выбрал тонкое выделение диска и хотел преобразовать его в EZT, этот процесс был медленным. Новый API позволяет значительно это ускорить.

Кликните на картинку для просмотра анимации:

Ограничение количества хостов vSphere, отправляющих UNMAP на VMFS datastore

В vSphere 8.0 U2 VMware добавила возможность ограничить скорость UNMAP до 10 МБ/с с 25 МБ/с. Это предназначено для клиентов с высоким уровнем изменений или массовыми отключениями питания, чтобы помочь уменьшить влияние возврата пространства на массив.

Кликните на картинку для просмотра анимации:

По умолчанию все хосты в кластере, до 128 хостов, могут отправлять UNMAP. В версии 8.0 U3 добавлен новый параметр для расширенного возврата пространства, называемый Reclaim Max Hosts. Этот параметр может быть установлен в значение от 1 до 128 и является настройкой для каждого хранилища данных. Чтобы изменить эту настройку, используйте ESXCLI. Алгоритм работает таким образом, что после установки нового значения количество хостов, отправляющих UNMAP одновременно, ограничивается этим числом. Например, если установить максимальное значение 10, в кластере из 50 хостов только 10 будут отправлять UNMAP на хранилище данных одновременно. Если другие хосты нуждаются в возврате пространства, то, как только один из 10 завершит операцию, слот освободится для следующего хоста.

См. статью Space Reclamation on vSphere VMFS Datastores.

Пример использования : esxcli storage vmfs reclaim config set -l <Datastore> -n <number_of_hosts>

Вот пример изменения максимального числа хостов, отправляющих UNMAP одновременно:

 

PSA

Поддержка уведомлений о производительности Fabric (FPIN, ошибки связи, перегрузка)

VMware добавила поддержку Fabric Performance Impact Notification (FPIN) в vSphere 8.0 U3. С помощью FPIN слой инфраструктуры vSphere теперь может обрабатывать уведомления от SAN-коммутаторов или целевых хранилищ о падении производительности каналов SAN, чтобы использовать исправные пути к устройствам хранения. Он может уведомлять хосты о перегрузке каналов и ошибках. FPIN — это отраслевой стандарт, который предоставляет средства для уведомления устройств о проблемах с соединением.

Вы можете использовать команду esxcli storage FPIN info set -e= <true/false>, чтобы активировать или деактивировать уведомления FPIN.

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

NFS

Привязка порта NFS v4.1 к vmk

Эта функция добавляет возможность байндинга соединения NFS v4.1 к определенному vmknic для обеспечения изоляции пути. При использовании многопутевой конфигурации можно задать несколько vmknic. Это обеспечивает изоляцию пути и помогает повысить безопасность, направляя трафик NFS через указанную подсеть/VLAN и гарантируя, что трафик NFS не использует сеть управления или другие vmknic. Поддержка NFS v3 была добавлена еще в vSphere 8.0 U1. В настоящее время эта функция поддерживается только с использованием интерфейса esxcli и может использоваться совместно с nConnect.

См. статью "Настройка привязки VMkernel для хранилища данных NFS 4.1 на хосте ESXi".

Поддержка nConnect для NFS v4.1

Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.

При добавлении нового хранилища данных NFSv4.1, количество соединений можно указать во время монтирования, используя команду:

esxcli storage nfs41 add -H <host> -v <volume-label> -s <remote_share> -c <number_of_connections>

Максимальное количество соединений на сессию по умолчанию ограничено "4", однако его можно увеличить до "8" с помощью продвинутого параметра NFS:

esxcfg-advcfg -s 8 /NFS41/MaxNConnectConns
esxcfg-advcfg -g /NFS41/MaxNConnectConns

Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.

Для существующего хранилища данных NFSv4.1, количество соединений можно увеличить или уменьшить во время выполнения, используя следующую команду:

esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>

Это не влияет на многопутевую конфигурацию. NFSv4.1 nConnect и многопутевые соединения могут сосуществовать. Количество соединений создается для каждого из многопутевых IP.

esxcli storage nfs41 add -H <IP1,IP2> -v <volume-label> -s <remote_share> -c <number_of_connections>

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

CNS/CSI

Поддержка 250 файловых томов для vSAN ESA

В настоящее время CNS поддерживает только 100 файловых томов. В vSphere 8.0 U3 этот лимит увеличен до 250 томов. Это поможет масштабированию для клиентов, которым требуется больше файловых хранилищ для постоянных томов (PVs) или постоянных запросов томов (PVCs) в Kubernetes (K8s).

Поддержка файловых томов в топологии HCI Mesh в одном vCenter

Добавлена поддержка файловых томов в топологии HCI Mesh в пределах одного vCenter.

Поддержка CNS на TKGs на растянутом кластере vSAN

Появилась поддержка растянутого кластера vSAN для TKGs для обеспечения высокой доступности.

Миграция PV между несвязанными datastore в одном VC

Возможность перемещать постоянный том (PV), как присоединённый, так и отсоединённый, с одного vSAN на другой vSAN, где нет общего хоста. Примером этого может быть перемещение рабочей нагрузки Kubernetes (K8s) из кластера vSAN OSA в кластер vSAN ESA.

Поддержка CNS на vSAN Max

Появилась поддержка развертывания CSI томов для vSAN Max при использовании vSphere Container Storage Plug-in.


Таги: VMware, vSphere, Storage, Update, VVols, ESXi, VMFS, NFS

Новая версия VMware VMmark 4 - первые результаты бенчмарков уже доступны


VMware VMmark 4.0 - это бесплатный кластерный бенчмарк, который измеряет производительность и масштабируемость виртуальных корпоративных сред.

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

VMmark 4 также включает инфраструктурные нагрузки, такие как vMotion, Storage vMotion, Cross vMotion и Clone & Deploy. В дополнение к ним, VMware vSphere DRS также работает в тестируемом кластере для балансировки нагрузок. В VMmark 4.0 было сделано улучшение полностью автоматизированного процесса развертывания, который появился в VMmark 3 - это сокращает время, необходимое пользователям для получения ценных результатов. Большинство пользователей теперь смогут перейти от загружаемого шаблона VMmark до результатов VMmark 4 примерно за два часа для "турбо" запуска.

Бенчмарк VMmark 4:

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

Обновления удобства использования VMmark 4:

  • Новый режим "Быстрый старт" для развертывания, запуска и получения результатов бенчмарка с помощью одной команды.
  • Новые режимы развертывания, которые позволяют большую гибкость в распределении виртуальных машин по более разнообразным хранилищам.
  • Функциональность частичных модулей (Partial Tile) для увеличения гранулярности бенчмарка через предписанное включение рабочих нагрузок приложений в конечный модуль.
  • Дизайн "Автоматизация в первую очередь" - многие основные операции администрирования vSphere теперь доступны пользователям. Операции, такие как deleting_all_vmmark4, manual_xvmotion и power_vmmark4_tiles, помогают пользователям в полной автоматизации VMmark 4. Посмотрите вывод команды vmmark4service для получения списка из более чем 20 новых доступных операций.
  • Улучшенная HTML-отчетность - пользователи теперь автоматически получают улучшенный HTML-вывод для пропускной способности, качества обслуживания и операций инфраструктуры для каждого запуска.
  • Новое приложение "disclosure creator", которое упрощает и автоматизирует создание HTML файлов.
  • Сбор данных о потреблении энергии - новый подход VMmark 4 к пониманию потребления энергопотребления. Этот режим собирает метрики энергопотребления на тестируемых системах и генерирует улучшенный HTML-отчет, чтобы помочь пользователям посчитать потребление энергии как хостами, так и виртуальными машинами.
  • Интеграция оповещений - оповещения в Slack и Google Chat легко встраиваются в VMmark 4 и включаются одним параметром.

Рабочие нагрузки приложений VMmark 4:

  • NoSQLBench - это новая рабочая нагрузка приложения в VMmark 4, используемая для анализа производительности новой распределенной NoSQL базы данных Apache Cassandra на 3 узлах.
  • SocialNetwork - эта новая рабочая нагрузка приложения в VMmark использует Docker-контейнеры для моделирования социальной сети с операциями, такими как создание постов, подписка на пользователей и т.д.
  • DVDstore (обновлено до версии 3.5) - включает PostgreSQL и параллельную загрузку базы данных, сокращая время на развертывание первого модуля.
  • Weathervane (обновлено до версии 2.0) - это масштабируемое веб-приложение, имитирующее онлайн-аукцион, теперь работает в Kubernetes контейнерах и в виртуальных машинах.
  • Standby - сервер Standby имитирует heartbeat-сервер, который периодически пингуется, чтобы убедиться, что он все еще работает и подключен.

Инфраструктурные нагрузки VMmark 4:

  • vMotion - эта операция инфраструктуры выполняет живую миграцию одной из Standby ВМ по круговой схеме, чтобы смоделировать современные операции системного администратора.
  • Storage vMotion - для этой операции одна из ВМ AuctionWebF мигрируется на указанное пользователем хранилище для обслуживания, а затем через некоторое время возвращается в исходное место.
  • Cross vMotion (XvMotion) - эта операция одновременно перемещает одну из ВМ DS3WebA на альтернативный хост и хранилище для обслуживания. Аналогично операции Storage vMotion, через некоторое время ВМ возвращается в исходное место.
  • Автоматическое балансирование нагрузки (DRS) - VMmark требует, чтобы DRS был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.

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

Также на днях стали доступны первые результаты тестирования производительности различного оборудования с помощью VMmark 4.0. Их можно посмотреть вот тут.


Таги: VMware, VMmark, Update, Performance, ESXi, vSphere

Новый Linux-вариант вредоносного ПО TargetCompany Ransomware, которое нацелено на серверы VMware ESXi


В блоге Angry Admin появилась интересная статья, посвященная новому варианту основанного на Linux ПО, которое использует пакет TargetCompany Ransomware для атаки серверов VMware ESXi.

Важное событие в сфере кибербезопасности: исследователи Trend Micro выявили новый вариант Linux из печально известного семейства программ-вымогателей TargetCompany.

Этот вариант специально нацелен на среды VMware ESXi, используя сложный пользовательский shell-скрипт для доставки и выполнения вредоносных программ. Известный под несколькими псевдонимами, включая Mallox, FARGO и Tohnichi, ветка TargetCompany представляет собой постоянную угрозу с момента ее появления в июне 2021 года, в основном сосредотачиваясь на атаках на базы данных в Тайване, Южной Корее, Таиланде и Индии.

Эволюция вымогателя TargetCompany

Вымогатель TargetCompany первоначально привлек внимание своими агрессивными атаками на различные системы баз данных, такие как MySQL, Oracle и SQL Server. В феврале 2022 года антивирусная компания Avast сделала значительный прорыв, выпустив бесплатный инструмент для расшифровки, который мог противодействовать известным на тот момент вариантам вымогателя. Однако к сентябрю 2022 года группа вымогателей восстановила свои позиции, переключив внимание на уязвимые серверы Microsoft SQL и используя Telegram в качестве платформы для угроз жертвам утечками данных.

Новый Linux-вариант вымогателя: подробный обзор

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

После проникновения в целевую систему, вымогатель проверяет наличие среды VMware ESXi, выполняя команду uname и ища строчку "vmkernel". Затем создается файл "TargetInfo.txt", который отправляется на сервер управления и контроля (C2). Этот файл содержит важную информацию о жертве, такую как имя хоста, IP-адрес, сведения об операционной системе, зарегистрированные пользователи и их привилегии, уникальные идентификаторы и подробности о зашифрованных файлах и каталогах.

Скрытные операции и атрибуция

Операции вымогателя разработаны так, чтобы оставлять минимальные следы. После завершения своих задач, shell-скрипт удаляет полезную нагрузку с помощью команды ‘rm -f x’, эффективно уничтожая любые доказательства, которые могли бы помочь в расследованиях после инцидента. Аналитики Trend Micro приписали эти атаки актору по имени «vampire», который также был упомянут в отчете Sekoia в прошлом месяце. IP-адреса, связанные с доставкой полезной нагрузки и получением информации о жертве, были отслежены до интернет-провайдера в Китае, хотя этого недостаточно для точного определения происхождения атакующего.

Влияние и рекомендации

Исторически вымогатель TargetCompany в основном нацеливался на машины под управлением Windows. Появление варианта для Linux и акцент на средах VMware ESXi подчеркивают эволюционирующую тактику и расширяющийся вектор угроз этой заразы. В отчете Trend Micro подчеркивается важность надежных мер кибербезопасности для противодействия этой растущей угрозе. Основные рекомендации включают включение многофакторной аутентификации (MFA), регулярное резервное копирование (в том числе на immutable хранилища) и поддержание обновленными всех систем. Кроме того, исследователи предоставили список индикаторов компрометации, включая хэши для версии вымогателя для Linux, пользовательского shell-скрипта и образцы, связанные с актором «vampire».

Заключение

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

1. Включите многофакторную аутентификацию (MFA)

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

2. Отключите доступ по SSH

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

3. Используйте режим блокировки (lockdown mode)

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

4. Регулярное резервное копирование

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

5. Обновляйте системы

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

6. Сегментация сети

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

7. Обучение сотрудников

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

8. Внедрите сильные политики безопасности

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

9. Развертывание передовых решений безопасности

Используйте передовые решения безопасности, такие как обнаружение и реагирование на конечных точках (Endpoint Detection and Response, EDR), системы обнаружения вторжений (IDS) и системы предотвращения вторжений (IPS), чтобы обнаруживать и смягчать угрозы в режиме реального времени.

10. Мониторинг сетевого трафика

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

11. План реагирования на инциденты

Разработайте и регулярно обновляйте план реагирования на инциденты. Убедитесь, что все члены команды знают свои роли и обязанности в случае атаки вымогателя.

12. Ограничение привилегий пользователей

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

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


Таги: VMware, ESXi, Security, Ransomware, Linux

Редактирование настроек SMBIOS (hardware manufacturer и vendor) для виртуального (Nested) VMware ESXi 


Вильям Лам написал интересную статью о том, как можно редактировать настройки SMBIOS для вложенного/виртуального (Nested) VMware ESXi в части hardware manufacturer и vendor.

Nested ESXi продолжает оставаться полезным ресурсом, который часто используется администраторами: от прототипирования решений, воспроизведения проблем клиентов до автоматизированных развертываний лабораторий, поддерживающих как VMware Cloud Foundation (VCF), так и VMware vSphere Foundation (VVF).

Хотя с помощью Nested ESXi можно сделать почти все, но имитировать или симулировать конкретные аппаратные свойства, такие как производитель или поставщик (hardware manufacturer и vendor), не совсем возможно или, по крайней мере, очень сложно. Коллега Вильяма Люк Хакаба нашел хитрый трюк, играя с настройками загрузочных ROM виртуальной машины по умолчанию, которые поставляются с ESXi и VMware Desktop Hypervisors (платформы Workstation/Fusion).

Виртуальная машина vSphere может загружаться, используя либо BIOS, либо EFI прошивку, поэтому в зависимости от желаемого типа прошивки вам нужно будет изменить либо файл BIOS.440.ROM, либо EFI64.ROM. Эти файлы ROM можно найти в следующих каталогах для соответствующих гипервизоров VMware:

  • ESXi: /usr/lib/vmware/roms
  • VMware Fusion: /Applications/VMware Fusion.app/Contents/Library/roms
  • VMware Workstation: C:\Program Files (x86)\VMware\VMware Workstation\x64

Примечание: не редактируйте файлы ROM по умолчанию, которые поставляются с гипервизором VMware, сделайте их копию и используйте измененную версию, которую могут использовать виртуальные машины в VMware vSphere, Fusion или Workstation. Кроме того, хотя эта статья посвящена виртуальной машине Nested ESXi, это также должно работать и на других гостевых операционных системах для отображения информации SMBIOS.

Редактирование BIOS

Шаг 1 - Скачайте и установите Phoenix BIOS Editor. Установщик Phoenix BIOS Editor имеет проблемы при запуске на системе Windows Server 2019, и единственным способом завершить установку - это изменить совместимость приложения на Windows 8, что позволит успешно завершить установку.

Шаг 2 - Скачайте и откройте файл BIOS.440.ROM с помощью Phoenix BIOS Editor, затем перейдите на панель DMI Strings для изменения нужных полей.

Когда вы закончите вносить все изменения, перейдите в меню "Файл" и нажмите "Собрать BIOS" (Build BIOS), чтобы создать новый файл ROM. В данном примере это файл BIOS.440.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi. Второй вариант позволит вам повторно использовать один и тот же кастомный файл ROM в нескольких виртуальных машинах, поэтому, с точки зрения тестирования, возможно, вам захочется создать несколько файлов ROM в зависимости от ваших нужд и просто перенастроить виртуальную машину для использования нужного файла ROM.

Шаг 4 - Чтобы кастомный файл ROM мог быть использован нашей виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку (Advanced Setting) виртуальной машины, которая указывает путь к нашему кастомному файлу ROM:

bios440.filename = "BIOS.440.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить нашу виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS, как показано на скриншоте ниже.

Редактирование EFI

Шаг 1 - Скачайте и установите HEX-редактор, который может редактировать файл EFI ROM. Например, ImHex - довольно удобный с точки зрения редактирования, но поиск определенных строк с помощью этого инструмента является нетривиальной задачей.

Шаг 2 - Скачайте и откройте файл EFI64.ROM с помощью редактора ImHex и найдите строку "VMware7,1". Как только вы найдете расположение этой строки, вам нужно аккуратно отредактировать значения hex, чтобы получить желаемые ASCII строки.

Кроме того, вы можете использовать UEFITool (версия 28 позволяет модифицировать ROM), который имеет гораздо более удобный и функциональный поиск, а также позволяет извлекать часть файла ROM для редактирования с помощью HEX-редактора. В этой утилите можно использовать поиск (CTRL+F), и как только он находит нужный раздел, двойным щелчком по результату переходите к точному месту в файле ROM. Чтобы извлечь раздел для редактирования, щелкните правой кнопкой мыши и выберите "Extract as is" и сохраните файл на рабочий стол.

Затем вы можете открыть конкретный раздел с помощью ImHex, чтобы внести свои изменения.

После того как вы сохранили свои изменения, не теряйте указатель в UEFITool. Теперь мы просто заменим раздел нашим измененным файлом, щелкнув правой кнопкой мыши и выбрав "Replace as is", указав измененный раздел. Вы можете подтвердить, что изменения были успешными, просто найдя строку, которую вы заменили. Затем перейдите в меню "Файл" и выберите "Сохранить образ файла" (Save image file), чтобы создать новый файл ROM. В данном случае - это файл EFI64.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi.

Шаг 4 - Чтобы наш кастомный файл ROM мог быть использован виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку ВМ в файл vmx, которая указывает путь к нашему кастомному файлу ROM:

efi64.filename = "EFI64.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS.

Как видно на скриншоте, Вильяму удалось изменить только модель оборудования, но не значение вендора.

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


Таги: VMware, VMachines, ESXi, Hardware, Nested, Blogs

Как правильно вывести хост VMware ESXi из эксплуатации в виртуальном датацентре


Многие администраторы часто добавляют новые хосты ESXi, но довольно редко обсуждается вопрос о том, как правильно выводить из эксплуатации хост VMware ESXi. Об этом интересную статью написал Stephen Wagner.

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

Итак, процесс: как списать хост ESXi

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

Вкратце процесс выглядит так:

  • Перевод ESXi в режим обслуживания (Maintenance Mode)
  • Удаление хоста из распределенного коммутатора vSphere Distributed Switch (vDS)
  • Отключение и размонтирование томов iSCSI LUN
  • Перемещение хоста из кластера в датацентр как отдельного хоста
  • Удаление хоста из инвентаря (Inventory)
  • Выполнение расширенных процедур

Вход в режим обслуживания

Мы переходим в режим обслуживания, чтобы убедиться, что на хосте не запущены виртуальные машины. Вы можете просто щелкнуть правой кнопкой мыши по хосту и войти в режим обслуживания (Enter Maintenance Mode):

Если хост ESXi входит в состав кластера VMware vSAN, то вам будут предложены опции того, что нужно сделать с данными на нем хранящимися:

Удаление хоста из окружения vSphere Distributed Switch (vDS)

Необходимо аккуратно удалить хост из любых распределенных коммутаторов vDS (VMware Distributed Switches) перед удалением хоста из сервера vCenter.

Вы можете создать стандартный vSwitch и мигрировать адаптеры vmk (VMware Kernel) с vDS на обычный vSwitch, чтобы поддерживать связь с сервером vCenter и другими сетями.

Обратите внимание, что если вы используете коммутаторы vDS для подключений iSCSI, необходимо заранее разработать план по этому поводу, либо размонтировать/отключить iSCSI LUN на vDS перед удалением хоста, либо аккуратно мигрировать адаптеры vmk на стандартный vSwitch, используя MPIO для предотвращения потери связи во время выполнения процесса.

Размонтирование и отключение iSCSI LUN

Теперь вы можете приступить к размонтированию и отключению iSCSI LUN с выбранного хоста ESXi:

  • Размонтируйте тома iSCSI LUN с хоста
  • Отключите эти iSCSI LUN

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

Перемещение хоста из кластера в датацентр как отдельного хоста

Хотя это может быть необязательным, это полезно, чтобы позволить службам кластера vSphere (HA/DRS) адаптироваться к удалению хоста, а также обработать реконфигурацию агента HA на хосте ESXi. Для этого вы можете просто переместить хост из кластера на уровень родительского дата-центра.

Удаление хоста из инвентаря

После перемещения хоста и прошествия некоторого времени, вы теперь можете приступить к его удалению из Inventory. Пока хост включен и все еще подключен к vCenter, щелкните правой кнопкой мыши по хосту и выберите «Remove from Inventory». Это позволит аккуратно удалить объекты из vCenter, а также удалить агент HA с хоста ESXi.

Повторное использование хоста

Начиная с этого момента, вы можете войти напрямую на хост ESXi с помощью локального пароля root и выключить хост. Сделать этого можно также с помощью обновленного VMware Host Client.


Таги: VMware, ESXi, vSphere, Blogs

Вышел бета-релиз нового VMware Host Client для управления отдельными серверами ESXi от Broadcom


На днях VMware от Broadcom представила бета-версию нового издания продукта для управления отдельными хостами ESXi - VMware Host Client. Все пользователи, зарегистрированные в программе бета-тестирования vSphere, могут получить доступ к новой бета-версии Host Client и загрузить обновленный графический интерфейс для работы с серверами ESXi.

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

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

Бета-версия нового Host Client — это веб-приложение, которое может быть использовано в macOS, Windows или Linux. Оно не связано с конкретной версией ESXi и, таким образом, может подключаться как к самым последним версиям гипервизора, так и к более старым. При подключении к ESXi можно сохранить данные подключения, чтобы обеспечить легкое переключение между серверами.

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

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

  • Просмотр общей информации о ESXi – емкость ресурсов, оборудование, конфигурация, история производительности.
  • Просмотр списка виртуальных машин, расположенных на хосте ESXi.
  • Управление виртуальной машиной – операции c питанием, снапшоты, изменение настроек ВМ и открытие ее консоли.
  • Просмотр алармов, событий и предупреждений, связанных с хостом ESXi.
  • Живой мониторинг задач, связанных с хостом ESXi.
  • Управление хранилищем – просмотр деталей и увеличение емкости.

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

Имейте в виду, что устаревший Host Client входит в состояние снятия с производства. Он все еще будет доступен и поддерживаться в общедоступной версии следующего крупного выпуска vSphere и будет сосуществовать с новым пользовательским интерфейсом ESXi. Однако в ходе обновлений следующего мажорного релиза поддержка устаревшего Host Client будет прекращена, и он не будет доступен версии +1.

Скачать бета-версию нового VMware Host Client можно по этой ссылке, заполнив там соответствующую форму.


Таги: VMware, Host Client, Client, ESXi, vSphere, Update, Beta

Как получить бесплатную пробную версию VMware vSphere и других продуктов на 60 дней?


В связи с тем, что бесплатный сервер виртуализации VMware ESXi Free больше недоступен (он же vSphere Hypervisor), многие начинающие пользователи задумались о том, как получить платформу VMware vSphere для ознакомления и тестирования, не покупая сам продукт сразу.

Для многих продуктов VMware (в том числе vSphere) есть бесплатная пробная лицензия на 60 дней, которую вы можете получить самостоятельно. Тут есть 2 ограничения:

  • Если вы и ваша компания находитесь в России или Беларуси, то легально получить такую лицензию не получится.
  • Не все продукты VMware имеют пробные версии на 60 дней, некоторые решения нужно запрашивать через партнеров или в отделе продаж VMware (как правило, это специфические Enterprise-решения).

Итак, рассмотрим этот процесс на примере VMware vSphere. Идем по этой ссылке:

https://www.vmware.com/try-vmware.html

В поиске вбиваем интересующий нас продукт, например, vSphere. Там будет несколько результатов (например, лабораторные работы), находим нужный нам Trial и кликаем по ссылке.

Если у вас уже есть аккаунт VMware Connect, то вы можете зайти под ним в разделе справа. Если же нет, то его можно создать (Create an Account):

Если вы уже использовали пробную версию vSphere на 60 дней в прошлом, то второй раз попробовать продукт уже не получится. Если же вы делаете это впервые, то у вас будет кнопка Register, которая позволит вам зарегистрироваться в программе пробного использования:

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

После этого в разделе License&Download вам будет доступна лицензия на полнофункциональную версию vSphere Cloud Foundation (VCF) на 60 дней, а также ссылки на скачивание компонентов VMware vSphere.

Также вы можете скачать VMware vSphere и ее компоненты в любой момент по следующей ссылке (для этого не нужно регистрироваться в программе пробного периода):

https://customerconnect.vmware.com/en/downloads/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/8_0


Таги: VMware, vSphere, ESXi, Бесплатно, VCF

Тестирование производительности рабочих нагрузок Oracle на платформе VMware vSAN ESA


Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.

Компания VMware провела тестирование работы баз данных Oracle в среде vSAN ESA и опубликовала некоторые результаты.

Тестовый стенд

Тестовая площадка представляла собой кластер из 8 узлов vSAN 8 Express Storage Architecture (ESA) со следующими настройками:

  • Версия vCenter 8.0.2 сборка 22385739
  • 8 серверов Lenovo ThinkAgile VX7531 Node, 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU @ 2.60GHz, 1TB RAM
  • VMware ESXi 8.0.2, сборка 22380479 с vSAN ESA (все хранилища - NVMe)
  • Oracle 21.13 Grid Infrastructure, ASM Storage и Linux udev (размер блока базы данных 8k)
  • OEL UEK 8.9

Детали кластера vSAN Express Storage Architecture (ESA) "env175" показаны ниже. Кластер ESA состоит из 8 серверов Lenovo ThinkAgile VX7531, как показано на картинке:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU на частоте 2.60GHz и 1TB RAM:


Каждый сервер Lenovo ThinkAgile VX7531 имеет 6 внутренних накопителей NVMe, таким образом каждый сервер дает 6 внутренних устройств NVMe в качестве емкости датастора vSAN ESA:

Информация о сервере ThinkAgile VX7531 "env175-node1.pse.lab" в части деталей HBA и внутренних устройств NVMe:

Политики хранения кластера vSAN Express Storage Architecture (ESA) показаны на картинке ниже.

Базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана только для получения эталонных метрик для сравнения, кроме того, настоящая производственная нагрузка никогда не настраивается с FTT=0 (количество допустимых отказов) и без RAID (то есть без защиты).

  • Oracle ESA – FTT0 – NoRAID
  • Oracle ESA – FTT1 – R5
  • Oracle ESA – FTT2 – R6

Детали виртуальной машины "Oracle21C-OL8-DB_ESA" показаны на картинке ниже.

Виртуальная машина имеет 28 vCPU, 256 ГБ RAM. Один экземпляр базы данных "ORA21C" был создан с опцией multi-tenant на базе инфраструктуры Oracle Grid (ASM). Версия базы данных - 21.13 на операционной системе OEL UEK 8.9.

Oracle ASM использовалась как платформа хранения данных с Linux udev для обеспечения персистентности устройств. Oracle SGA и PGA были установлены на 64G и 10G соответственно. Также были соблюдены все лучшие практики платформы Oracle на VMware.

Виртуальная машина "Oracle21C-OL8-DB_ESA" имеет 4 контроллера vNVMe для дополнительной производительности:

58 устройств хранения привязаны к ВМ "Oracle21C-OL8-DB_ESA", они показаны ниже:

  • NVME 0:0 – 80G для OS (/)
  • NVME 0:1 – 80G для Oracle Grid и бинарников RDBMS
  • NVME 0:2 – 100G для GRID_DG
  • NVME 0:3 – 200G для DATA_DG
  • NVME 0:4 – 200G для DATA_DG
  • NVME 0:5 – NVME 0:12 – 8 дисков vmdk, каждый 25 ГБ – REDO_DG
  • NVME 1:0 – 1:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
  • NVME 2:0 – 2:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
  • NVME 3:0 – 3:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG

Детали тестов разных политик хранения vmdk для ВМ "Oracle21C-OL8-Customer" показаны ниже:

  • Тест 1 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT0 – NoRAID"
  • Тест 2 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT1 – R5"
  • Тест 3 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT2 – R6"

Детали группы дисков Oracle ASM показаны ниже:

Тестовый сценарий

Результаты ниже являются тестовым сценарием, демонстрирующим преимущества производительности использования vSAN 8 vSAN Express Storage Architecture (ESA) для бизнес-критичных производственных нагрузок Oracle.

Генератор нагрузки SLOB был запущен против 2 TB табличного пространства SLOB с 3 различными политиками хранения.

  • Oracle ESA – FTT0 – NoRAID
  • Oracle ESA – FTT1 – R5
  • Oracle ESA – FTT2 – R6

В качестве генератора нагрузки для этого эксперимента был выбран SLOB 2.5.4.0 с следующими установленными параметрами SLOB:

UPDATE_PCT=30
RUN_TIME=300
SCALE=25G
WORK_UNIT=1024

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

Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.

В VMware провели несколько прогонов SLOB для вышеупомянутого кейса и сравнили метрики Oracle, как показано в таблице ниже.

Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.

Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.

Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.

Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:

  • Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
  • Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
  • Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов

Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":

В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".


Таги: VMware, vSAN, Oracle, Performance, ESXi, Storage, VMDK, ESA

Куда делся бесплатный VMware ESXi Free Edition (vSphere Hypervisor)?


Как знают многие администраторы платформы vSphere, после покупки компании VMware гигантом Broadcom было официально решено изменить продуктовую линейку vSphere на модель лицензирования по подписке и оставить два Enterprise-издания - VMware vSphere Foundation (VVF - решение для онпремизных сред) и VMware Cloud Foundation (VCF - облачная платформа на базе различных сервис-провайдеров). Мы это также объясняли в картинках, на которых видно, что большинство продуктов теперь доступны как аддоны к указанным выше изданиям. Также остались и решения для небольших организаций - это VMware vSphere Essentials Plus Kit (VVEP) и VMware vSphere Standard (VVS).

Многие пользователи уже привыкли, что бесплатный гипервизор VMware ESXi Free (он официально назывался vSphere Hypervisor) доступен для скачивания с сайта VMware, но вот уже месяц назад это стало недоступно. Причина проста - бесплатного издания больше нет, виртуализация от VMware теперь поставляется только за деньги.

Официальное оповещение пользователей об этом находится в KB 2107518 от 14 февраля этого года - End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x).

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

Кстати, видно, что энтузиасты, эксперты и блоггеры также не очень довольны этим фактом, поэтому, возможно, Broadcom еще вернется к вариантам бесплатной виртуализации для целей обучения и совсем малых инсталляций. Не зря же в статье базы знаний написано "at this time", поэтому посмотрим...


Таги: VMware, vSphere, Free, Бесплатно, ESXi

Вышли VMware ESXi 8.0 Update 2b и vCenter 8.0 Update 2b


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

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

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

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

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

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

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

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


Таги: VMware, vSphere, Update, ESXi, vCenter

Интересная сессия VMware Explore 2023 - как защитить VMware ESXi и vCenter от программ-вымогателей (Ransomware)


Ransomware стало настоящей напастью последних лет - выплаты компаний злоумышленникам, зашифровавшим данные и держащим их в заложниках, перевалили за миллиард долларов в прошлом году (и это только то, что известно). Серверы VMware ESXi и vCenter, являющиеся основными компонентами инфраструктуры vSphere, представляют главную мишень для атак Ransomware.

В рамках конференции VMware Explore Europe 2023 прошла интересная сессия, где рассматривались примеры из реального мира по борьбе с программами-вымогателями, а также обсуждались проактивные методики, которые позволят избежать атаки или минимизировать последствия:

Вот основные выводы, которые суммаризуют выступление выше:

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

2. Важно провести различие между защитой рабочих нагрузок (виртуальные машины, серверы, клиенты, AD) и защитой инфраструктурной платформы (vSphere, хранилище и т.д.), поскольку каждое требует различных мер безопасности. Эти аспекты должны быть отделены друг от друга.

3. Понимание путей атаки, ведущих к появлению программы-вымогателя в инфраструктуре vSphere, является ключевым. Эти пути включают начальный доступ, использование Active Directory и различные способы добраться и атаковать vCenter Server и ESXi.

4. Восстановление среды vSphere после атаки не должно включать в себя выплату выкупа. Платеж атакующим увеличивает риск будущих атак и не гарантирует полного решения проблемы.

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

6. Очистка и восстановление скомпрометированных компонентов, таких как виртуальные машины, vCenter Server и хосты ESXi после атаки, требует тщательного рассмотрения и технического анализа (форензика).

7. Для защиты vSphere от атак должны быть предприняты несколько мер, включая сегментацию vSphere от рабочих нагрузок и клиентов, использование EDR/XDR/SIEM для конечных точек и vSphere, установку обновлений безопасности и следование рекомендациям по защите платформы vSphere.

8. Предотвращение выполнения стороннего кода в ESXi может быть достигнуто через настройки, такие как execInstalledOnly, которые предотвращают выполнение нежелательных файлов и скриптов.

9. UEFI Secure Boot может использоваться для проверки целостности файлов загрузки и ядра ESXi, что защищает от угроз с использованием неподписанных VIB.

10. Деактивация доступа к Shell для не-root пользователей ESXi может предотвратить боковое движение от vCenter к ESXi, что является важной мерой для остановки или замедления атакующего.


Таги: VMware, vSphere, Ransomware, ESXi, vCenter, Security

Минимальное число хостов VMware vSAN ESA в зависимости от типа RIAD


С выходом обновленной версии VMware vSAN 8 в этом решении появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

Дункан Эппинг в ответ на запрос пользователей решения vSAN ESA сделал интересный пост на тему минимально необходимого числа хостов, которое требуется для поддержания определенного уровня избыточности - RAID-0/1/5/6.

В VMware vSAN 8 Update 1 появился адаптивный алгоритм записи, который существенно уменьшает избыточность записи на RAID-конфигурации. Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

Теперь для vSAN ESA на базе RAID-5, в зависимости от размера кластера, могут быть использованы конфигурации 2+1 или 4+1, а конфигурация 3+1 больше не поддерживается. При этом для RAID-1 и RAID-6 в конфигурациях ничего не изменилось.

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


Таги: VMware, vSAN, ESA, Storage, Hardware, Performance, ESXi

Новые возможности VMware ESXi Arm Edition 1.15 (теперь это ESXi for ARM)


На прошлой неделе мы писали о том, что компания VMware возвращает раздел Flings, где будут собраны полезные утилиты и инструменты, которые ранее были доступны администраторам и разработчикам через ресурс VMware Labs. Также совсем недавно VMware объявила о выпуске обновления ESXi Arm Edition 1.15, ну а сам продукт теперь называется ESXi for ARM.

О версии ESXi Arm Edition 1.14 мы писали вот тут. Напомним, что это решение представляет собой гипервизор для архитектуры ARM на базе кода ESXi. В будущем он найдет свое применение в таких решениях, как Project Monterey.

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

  • Поддержка счетчиков производительности Virtual CPU Performance Counters
  • Исправление виртуального UEFI для пакета Arm Architecture Compliance Suite
  • Обновление драйвера EQOS:
    • Исправление перестановки байтов в MAC-адресе
    • Добавлена поддержка управления потоком данных IEEE 802.3x
  • Поддержка устройств PCIe на Raspberry Pi Compute Module 4
  • Отчет о версии и ревизии SoC, определенной Arm DEN0028 (как возвращается вызовом SMCCC_ARCH_SOC_ID SMC), через телеметрию.

Вот список платформ, на которых сейчас поддерживается работа ESXi for ARM, а также оборудования, где обширного тестирования не было, но гипервизор должен работать:

Скачать VMware ESXi for ARM можно по этой ссылке. Полный комплект документации доступен тут.


Таги: VMware, ESXi, ARM, Update, Labs

Общие рекомендации при апгрейдах и накатывании обновлений в среде VMware vSphere


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


Таги: VMware, vCenter, Update, Upgrade, vSphere, ESXi

5 способов закрыть неотвечающую виртуальную машину в VMware vSphere из консоли ESXi


Администраторы виртуальной инфраструктуры VMware vSphere время от времени сталкиваются с проблемой завершения зависших виртуальных машин. Если в клиенте vSphere Client сделать этого не удаются, приходится заходить в сервисную консоль ESXi или в командную строку PowerCLI/PowerShell и проводить там операции по завершению процесса этой ВМ. Сегодня мы расскажем о 5 способах, которыми это можно сделать.

1. С использованием PowerCLI

Stop-VM - это командлет, используемый для завершения работы виртуальной машины. На самом деле он используется для выключения ВМ, но добавление параметра kill приведет к завершению соответствующих процессов ВМ на ESXi, фактически уничтожая ее. Делается это так:

Stop-VM -kill <отображаемое имя ВМ> -Confirm:$false

2. С использованием esxcli

Esxcli - это интерфейс командной строки (CLI), который предоставляет доступ к ряду пространств имен, таких как vm, vsan, network и software, позволяя выполнять задачи, изменять настройки и так далее. Таким образом, если вам нужно завершить работу неотвечающей виртуальной машины с использованием esxcli, можно действовать следующим образом:

  • Получить список виртуальных машин, размещенных на ESXi:

esxcli vm process list

Красным выделен идентификатор World ID виртуальной машины.

  • Скопируйте значение World ID и выполните команду:

esxcli vm process kill --type=soft -w=796791

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

Параметр type принимает три значения:

  • Soft – позволяет процессу VMX завершиться корректно, аналогично команде kill -SIGTERM
  • Hard – немедленно завершает процесс VMX, аналогично команде kill -9 или kill -SIGKILL
  • Force – останавливает процесс VMX, когда не работают варианты Soft или Hard

3. С использованием утилиты vim-cmd

Vim-cmd - это еще одна утилита командной строки, очень похожая на esxcli, но с несколько иным синтаксисом. Также она может использоваться для управления ВМ и другими ресурсами. Соответственно, вот как используется vim-cmd для завершения работы ВМ:

1. Выведите все ВМ на текущем подключенном хосте ESXi и запишите vmid (первый столбец) неотвечающей ВМ:

vim-cmd vmsvc/getallvms

2. Получите состояние питания ВМ, используя ее vmid. Этот шаг необязателен, так как вы уже знаете, что с ВМ что-то не так:

vim-cmd vmsvc/power.getstate 36

3. Сначала попробуйте вариант power.shutdown:

vim-cmd vmsvc/power.shutdown 36

4. Если по какой-то причине ВМ не удается выключить, попробуйте использовать вместо этого power.off:

vim-cmd vmsvc/power.off 36

Следующий скриншот демонстрирует пример использования указанных выше команд для завершения работы ВМ.

4. С использованием esxtop

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

Вот как это делается:

Нажмите Shift+v, чтобы изменить представление на виртуальные машины:

Нажмите <f>, чтобы отобразить список полей, затем нажмите <c>. Это добавит столбец с идентификатором Leader World ID (LWID) в представление. Нажмите любую клавишу, чтобы вернуться в главное меню.

  • Найдите зависшую виртуальную машину в столбце Name и запишите ее LWID.
  • Нажмите k и введите значение LWID в строке запроса World to kill (WID). Нажмите Enter:

Чтобы быть полностью уверенным, подождите 30 секунд перед тем, как проверить, что виртуальная машина больше не отображается в списке. Если она все еще там, попробуйте снова. В случае неудачи, скорее всего, вам придется перезагрузить хост ESXi.

5. С помощью традиционной команды kill

Это самый грубый метод завершения работы виртуальной машины. Но он документирован на сайте VMware, хотя и немного по-другому. Виртуальная машина представляет собой серию процессов, выполняемых на ESXi. Используя команду ps ниже, можно вывести процессы, связанные, например, с виртуальной машиной под названием Web Server.

ps | grep "Web Server"

Если вы внимательно посмотрите, вы увидите, что значение во втором столбце одинаково для всех процессов. Это значение идентификатора VMX Cartel, которое, хотя и отличается от значения World ID, все же может быть использовано для завершения работы виртуальной машины следующим образом:

kill 797300

Если процессы продолжают работать, попробуйте kill -9 <идентификатор процесса>:

kill -9 797300


Таги: VMware, ESXi, VMachines, vSphere

Обновленный документ Performance Best Practices for VMware vSphere 8.0 Update 2


В начале года мы писали о документе "Performance Best Practices for VMware vSphere 8.0", в котором приведены основные рекомендации по обеспечению высокой производительности флагманской платформы виртуализации компании VMware. В середине этого года было сделано обновление этого руководства, которое было выпущено под названием "Performance Best Practices for VMware vSphere 8.0 Update 1".

В конце октября вышел очередной апдейт этого сверхполезного документа на 100 страницах - "Performance Best Practices for VMware vSphere 8.0 Update 2".

В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно vSphere 8 Update 2 и vSAN 8 Update 2.

Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

  • Hardware for Use with VMware vSphere (страница 11)
  • ESXi and Virtual Machines (страница 25)
  • Guest Operating Systems (страница 55)
  • Virtual Infrastructure Management (страница 67)

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

Скачать Performance Best Practices for VMware vSphere 8.0 Update 2 можно по этой ссылке.


Таги: VMware, Performance, vSphere, ESXi, vSAN, Whitepaper, Update

Платформы VMware vSphere 8 Update 2 и vSAN 8 Update 2 доступны для скачивания (Initial Availability)


Компания VMware объявила о том, что ее флагманская платформа виртуализации vSphere 8 Update 2 и решение для создания отказоустойчивых кластеров vSAN 8 Update 2, анонсированные ранее в рамках конференции Explore 2023, стали доступны для скачивания в рамках фазы Initial Availability (напомним, что для vCenter Server это фаза General Availability).

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

Для скачивания VMware vSAN 8 Update 2 используйте вот эту ссылку. Обратите также внимание на красное предупреждение вверху:


Таги: VMware, vSphere, ESXi, vCenter, vSAN, Update

Новый документ VMware: "Troubleshooting TCP Unidirectional Data Transfer Throughput"


Недавно опубликованный компанией VMware технический документ "Troubleshooting TCP Unidirectional Data Transfer Throughput" описывает, как устранить проблемы с пропускной способностью однонаправленной (Unidirectional) передачи данных по протоколу TCP. Решение этих проблем, возникающих на хосте vSphere/ESXi, может привести к улучшению производительности. Документ предназначен для разработчиков, опытных администраторов и специалистов технической поддержки.

Передача данных по протоколу TCP очень распространена в средах vSphere. Примеры включают в себя трафик хранения между хостом VMware ESXi и хранилищем данных NFS или iSCSI, а также различные формы трафика vMotion между хранилищами данных vSphere.

В компании VMware обратили внимание на то, что даже крайне редкие проблемы с TCP могут оказывать несоразмерно большое влияние на общую пропускную способность передачи данных. Например, в некоторых экспериментах с чтением NFS из хранилища данных NFS на ESXi, кажущаяся незначительной потеря пакетов (packet loss) в 0,02% привела к неожиданному снижению пропускной способности чтения NFS на 35%.

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

Рассматриваемые проблемы с TCP включают в себя потерю пакетов и их переотправку (retransmission), длительные паузы из-за таймеров TCP, а также проблемы с Bandwidth Delay Product (BDP). Для проведения анализа используется решение Wireshark и описывается профиль для упрощения рабочего процесса анализа. VMware описывает системный подход к выявлению общих проблем с протоколом TCP, оказывающих значительное влияние на пропускную способность канала передачи данных - поэтому инженерам, занимающимся устранением проблем с производительностью сети, рекомендуется включить эту методологию в стандартную часть своих рутинных проверок.

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

Скачать whitepaper "Troubleshooting TCP Unidirectional Data Transfer Throughput" можно по этой ссылке.


Таги: VMware, Network, Performance, vSphere, ESXi, Whitepaper

Новые возможности решения VMware ESXi Arm Edition 1.14


Через неделю после конференции Explore 2023 компания VMware выпустила новую версию платформы ESXi Arm Edition 1.14, которая уже доступна на сайте проекта VMware Labs. Напомним, что это решение представляет собой гипервизор для архитектуры ARM на базе кода ESXi. В будущем он найдет свое применение в таких решениях, как Project Monterey. О прошлой версии ESXi для ARM 1.13 мы писали в июне этого года.

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

  • Исправление проблем с загрузкой SMP на некоторых микроархитектурах.
  • Улучшение поддержки узлов high physical addresses memory.
  • Добавлена поддержка 3 видов сетевых адаптеров NC USB:
    • Realtek RTL8153 serial 1G USB Network Adaptor
    • Realtek RTL8152 serial 100M USB Network Adaptor
    • ASIX AX88179/AX88178A serial 1G USB Network Adaptor

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

Скачать последнюю версию VMware ESXi Arm Edition 1.14 можно по этой ссылке.


Таги: VMware, ESXi, ARM, Update, Hardware, Labs

Анонсы VMware Explore 2023: ранний доступ к ESXi Lifecycle Management Service


Продолжаем рассказ об анонсах новых продуктов и технологий, сделанных на прошедшей в конце августа конференции VMware Explore 2023 в Лас-Вегасе, которая многие годы является главным событием в сфере виртуализации.

21 августа 2023 года компания VMware объявила о раннем доступе (Early Availability) к сервису управления жизненным циклом VMware ESXi, который предоставляет простое и удобное управление парком серверов ESXi в средах vSphere через облако VMware при поддержке сотрудников службы поддержки вендора. Сервис управления жизненным циклом облегчает внедрение обновлений и апгрейдов vSphere для нескольких vCenter и клиентских дата-центров.

Вот преимущества использования это нового облачного сервиса:

  • Внедрение стандартизации в vCenter и дата-центрах:
    • Внедрение утвержденных образов во всех дата-центрах.
    • Полное соответствие установленных образов требованиям комплаенса.
    • Постоянное обновление версий ESXi.
  • Предотвращение или уменьшение потенциальных угроз безопасности:
    • Применение патчей безопасности сразу после их выпуска.
    • Контроль соответствия требованиям безопасности.
  • Быстрые обновления и сокращение времени общего обслуживания:
    • Лучшие практики и процедуры уже встроены в рабочие процессы.
    • Параллельные обновления аналогичных кластеров на разных vCenter.
  • Больше шансов на успешный апгрейд инфраструктуры:
    • Проведение предварительной проверки перед обновлением для выявления проблем.
    • Стейджинг и подготовка кластеров и хостов к обновлению до его начала.
  • Быстрые решения от службы поддержки VMware:
    • Контекстная помощь и поиск в базе знаний.
    • Простая кнопка "Создать запрос в службу поддержки".
    • Быстрое решение проблем с помощью телеметрии и логов.

Сервис ESXi Lifecycle Management Service может предоставлять end-to-end рабочие процессы по управлению жизненным циклом, которые включают уведомления о новых обновлениях, квалификацию обновлений для связанных объектов (кластеры, хосты) и группировку целевых объектов (кластеры, хосты) для предварительной проверки и обновлений. Также сервис предоставляет статус рабочих процессов обновления, показывая, какие объекты (кластеры, хосты) находятся в процессе выполнения, выполнены успешно или завершились сбоем. В случае неудачных обновлений вы можете углубиться до уровня хоста, просмотреть базовые логи для устранения проблем и повторить рабочий процесс обновления.

Сейчас VMware предлагает ограниченное количество пробных версий сервиса управления жизненным циклом ESXi в средах, предоставляемых компанией. Если вы заинтересованы, отсканируйте QR-код ниже, заполните форму, и с вами свяжутся, чтобы назначить время вашего раннего доступа к пробной версии продукта.


Таги: VMware, vSphere, ESXi, Lifecycle, Enterprise, Cloud

Анонсы VMware Explore 2023: VMware vSphere 8 Update 2


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

На этот раз мы расскажем об одном из главных для администраторов виртуальной среды анонсов - релизе платформы VMware vSphere 8 Update 2. Надо сразу сказать, что в третьем квартале будет доступен не только второй пакет обновлений последней версии платформы, но и нововведения облачной подписки vSphere+, о которой мы уже рассказывали.

Итак, давайте посмотрим, что нового в vSphere 8 U2:

1. Повышение операционной эффективности

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

Давайте посмотрим подробнее:

  • Служба управления жизненным циклом ESXi – особенно важным нововведением является новый облачный сервис в vSphere+, который позволяет администраторам централизованно оркестрировать обновления на всем их парке хостов ESXi. Множество операций жизненного цикла (такие как патчи и обновления) должны выполняться учетом сервисов VMware vCenter и границ кластера. Новый облачный сервис, доступный клиентам vSphere+, позволит IT-администраторам обновлять весь парк одинаково настроенных хостов ESXi через несколько серверов vCenter и кластеров одной операцией и централизованно отслеживать ход выполнения из Cloud Console. Рассмотрим пример: с традиционным vSphere, одно обновление требуется для каждого кластера хостов ESXi, и максимальное количество хостов на кластер - 32. Предположим, у пользователя есть 32 000 хостов ESXi, распределенных по 1 000 кластерам. Чтобы обновить весь их парк ESXi, пользователю потребуется выполнить 1 000 отдельных операций обновления. С сервисом управления жизненным циклом ESXi требуется всего одно обновление для каждой стандартной конфигурации оборудования, независимо от количества кластеров. Большинство IT-организаций стандартизируют свои конфигурации оборудования, поэтому в этом случае разумно предположить, что у этого клиента может быть всего около 3-5 стандартных конфигураций оборудования (в зависимости от того, у скольких поставщиков серверов они покупают). Это означает, что они могут обновить весь свой парк ESXi всего за 3-5 операций обновления, что составляет малую долю от 1 000 обновлений, необходимых с традиционным развертыванием vSphere. С сервисом управления жизненным циклом ESXi обновления потребуют гораздо меньше времени и усилий и могут выполняться чаще, позволяя клиентам оставаться более защищенными от ошибок и использовать все последние возможности ESXi.

Кстати, теперь есть возможность попробовать существующие и новые функции vSphere+ перед покупкой:

  • Сокращение времени простоя при обновлении vCenter – впервые это было введено для клиентов vSphere+ в прошлом году, но теперь доступность этой функции расширена для всех версий vSphere. Во время обновления время простоя vCenter сокращается примерно с часа до нескольких минут (реальное время может отличаться). По сути, это время, необходимое для завершения работы служб на старом vCenter и запуска служб на новом. Таким образом, необходимые плановые окна обслуживания стали гораздо короче. Обновления можно проводить чаще, так как это гораздо проще сделать, тем самым оперативно переходить на последние версии vCenter.

  • Поддержка Microsoft Entra ID (ранее Azure AD) для федерации идентификаторов – за последние пару лет VMware постоянно расширяла поддержку сторонних поставщиков идентификации, включая Microsoft Active Directory Federation Service (ADFS) и недавно была добавлена служба Okta Identity Service. С этим выпуском эта поддержка расширяется далее, включая Microsoft Entra ID (ранее Azure AD). Когда аутентификация обрабатывается сторонним поставщиком идентификации, таким как Entra ID, аутентификация больше не обрабатывается vSphere. Поскольку логины и пароли больше не хранятся внутри vSphere, проверки безопасности проходят проще, быстрее или вообще не требуются.

2. Повышение производительности рабочих нагрузок

С сенсационным появлением ChatGPT в ноябре 2022 года в индустрии возник огромный интерес к генеративному ИИ (GenAI). К январю 2023 года ChatGPT стал самым быстрорастущим потребительским программным приложением в истории, получив более 100 миллионов пользователей. В результате GenAI теперь является стратегическим приоритетом для многих организаций. vSphere была на переднем крае ИИ с момента введения AI-Ready Enterprise Platform в марте 2021 года, и с этим последним выпуском VMware продолжает масштабировать и совершенствовать технологию виртуализации GPU. Наряду с улучшениями, связанными с ИИ, VMware также расширяет доступность технологии Data Processing Unit (DPU) на большем количестве аппаратных платформ, чтобы клиенты могли ощутить эти преимущества производительности.

Тут появились следующие вещи:

  • Увеличение максимального количества устройств vGPU на VM с 8 до 16 – большие рабочие нагрузки (особенно ИИ) продолжают требовать все больше и больше мощности GPU. В этом последнем выпуске было увеличено максимальное количество устройств vGPU, которое может быть назначено одной ВМ, до 16, что удвоило верхний предел производительности для больших рабочих нагрузок. Для ИИ это означает, что вы можете сократить время обучения моделей AI/ML и запускать модели самого высокого класса с большими наборами данных.

  • Размещение рабочих нагрузок и балансировка нагрузки с учетом GPU в DRS – VMware обнаружила сценарии, в которых рабочие нагрузки могут не полностью использовать доступные ресурсы GPU. Чтобы решить эти проблемы, был улучшен механизм балансировки нагрузки. Теперь DRS учитывает размеры профилей vGPU и объединяет vGPU одного размера на одном хосте. Это также помогает с начальным размещением при включении машин с поддержкой GPU, что позволяет избежать потери емкости GPU из-за фрагментации. Размещение рабочей нагрузки и балансировка нагрузки теперь учитывает GPU, и DRS будет стараться размещать рабочие нагрузки с аналогичными требованиями к профилю на одном хосте. Это повышает использование ресурсов GPU, что снижает затраты, так как для достижения желаемого уровня производительности требуется меньше аппаратных ресурсов графического модуля.

  • Расширение поддержки DPU, включая серверное оборудование Lenovo и Fujitsu – год назад, с введением vSphere 8, VMware представила поддержку DPU, позволяя клиентам переносить инфраструктурные рабочие нагрузки с CPU на специализированный модуль DPU, тем самым повышая производительность бизнес-нагрузок. С этим релизом клиенты, использующие серверы Lenovo или Fujitsu, теперь смогут использовать преимущества интеграции vSphere DPU и его преимущества в производительности.

3. Ускорение инноваций для DevOps

Для потребителей инфраструктуры, таких как инженеры DevOps или разработчики, самообслуживание имеет первостепенное значение. Необходимость отправки электронного письма или создания запроса для получения доступа к инфраструктурным услугам, таким как серверы, хранилище или сеть - очень замедляют процессы. С того момента, как VMware представила интеграцию с Kubernetes в 2020 году, продолжается улучшение функций самообслуживания, и этот релиз не исключение. Помимо предоставления пользователям инфраструктуры более быстрого доступа, также была упрощена настройка среды Kubernetes для администраторов ИТ или инженеров DevOps.

Вот что было сделано:

  • Новый Image Registry Service для виртуальных машин – для инженеров DevOps или других пользователей, которым нужно создавать виртуальные машины, нужен такой способ хранения образов ВМ, чтобы их можно было повторно использовать или расшаривать их. Этот релиз предоставляет новый Image Registry Service, позволяя потребителям публиковать, изменять и удалять образы с использованием API Kubernetes. Образы могут быть использованы для развертывания машин VM Service. С новым реестром команды DevOps, разработчики и другие потребители VM могут публиковать и управлять образами ВМ в режиме самообслуживания, позволяя создавать их быстрее без необходимости помощи администраторов.

  • Поддержка VM Service для Windows и GPU VM Service - это отличный способ предоставления ВМ в режиме самообслуживания, но в прошлом он был ограничен только машинами Linux и выбранными конфигурациями. Этот релиз убирает эти ограничения. VM Service может быть использован для развертывания машин на Windows наряду с Linux. Также ВМ может быть развернута с любым виртуальным железом, настройками безопасности, устройствами, поддержкой multi-NIC, и устройствами passthrough, которые поддерживаются в vSphere, что позволяет достичь полного соответствия традиционным машинам vSphere. Важно отметить, что теперь VM Service может быть использован для развертывания рабочих ВМ, которые требуют GPU.

  • Импорт и экспорт конфигурации Supervisor Cluster – конфигурация супервизор-кластера может занять много времени из-за множества требуемых настроек. Если у вас много кластеров, эта сложность повышается. Теперь конфигурацию Supervisor cluster можно сохранять и экспортировать в другие кластеры. Вы легко можете экспортировать существующую конфигурацию кластера и импортировать в новый супервизор-кластер, минуя ручной процесс конфигурации. Кроме того, это позволит вам более легко воспроизводить стандартную конфигурацию на большом количестве супервизор-кластеров.

4. Прочие улучшения

Здесь нужно отметить следующее:

  • Virtual Hardware версии 21 - теперь ВМ получают следующие характеристики:
    • Увеличено максимальное количество vGPU для ВМ до 16.
    • Можно подключать до 256 дисков NVMe к ВМ.
    • Поддерживается спецификация NVMe 1.3 для пользователей Windows и кластерное переключение при отказе Windows Server с дисками NVMe.
    • Проверки на совместимость для новых ОС: Red Hat 10, Oracle 10, Debian 13 и FreeBSD 15.
    • Помните, чтобы полностью использовать эти возможности, вам нужны как vSphere 8 update 2, так и Virtual Hardware 21.
  • Расширение поддержки NSX Advanced Load Balancer - NSX-T Load Balancer был объявлен устаревшим, начиная с версии NSX-T 3.2, будьте готовы к скорым изменениям. Начните уже сейчас использовать NSX Advanced Load Balancer или Avi load balancer. Это актуально только для новых установок (Greenfield installations).

  • Quality of Service для GPU-нагрузок - с vGPU "время приостановки" (время, когда виртуальная машина временно приостанавливается) во время миграции может быть значительным. Обновление vSphere 8 до версии 2 предоставляет администраторам прекрасный инструмент для оценки максимально возможного времени приостановки ВМ с поддержкой vGPU. Это определяется на основе скорости сети и размера памяти vGPU.

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

  • Упрощенное развертывание виртуальных машин Windows - в процессе развертывания виртуальных машин Windows были сделаны существенные улучшения. Теперь пользователи могут определить путь OU при создании спецификаций настройки, что приводит к тому, что виртуальные машины Windows развертываются и настраиваются в соответствии с указанным путем OU, оптимизируя их интеграцию в Active Directory.

  • Оптимизированные профили конфигурации (vSphere Configuration Profiles) - введенные в vSphere 8 и усовершенствованные в vSphere 8 Update 1, функциональные возможности профилей конфигурации vSphere получили дальнейшее улучшение в Update 2. Всеобъемлющий рабочий процесс в пользовательском интерфейсе облегчает создание, редактирование и применение профилей конфигурации vSphere. Теперь нет необходимости экспортировать документ JSON для редактирования - хотя опция остается. В пользовательский интерфейс была добавлена новая вкладка "Draft", позволяющая пользователям создавать, редактировать и применять черновики или копии существующей конфигурации.

  • Улучшенный vSphere Lifecycle Manager (vLCM) - решение vLCM стало настоящим спасением для многих администраторов, и его возможности продолжают улучшаться. На данный момент он поддерживает узлы vSAN Witness и кластеры vSAN, но vSphere 8 Update 2 вносит заметные изменения. Это обновление позволяет vLCM управлять узлами Witness, участвующими в нескольких кластерах vSAN.

  • Reliable network recovery - что касается восстановления сети, то для сред, работающих с одним или несколькими распределенными коммутаторами vSphere, процесс восстановления vCenter из резервной копии был упрощен. Когда vCenter восстанавливается из устаревшей резервной копии, он автоматически согласует версии с текущей версией распределенного коммутатора на хостах ESXi.

Доступность для загрузки платформы VMware vSphere 8 Update 2 ожидается в третьем квартале этого года.


Таги: VMware, vSphere, Update, ESXi, vCenter

Уязвимость CVE-2022-40982 Gather Data Sampling (GDS/Downfall) для хостов VMware ESXi 8 - проверьте и обновитесь


На днях на сайте virten.net появилась информация об уязвимости CVE-2022-40982 Gather Data Sampling (GDS/Downfall) хостов VMware ESXi 8 инфраструктуры vSphere, которая может быть полезна для администраторов.

8 августа этого года компания Intel рассказала о проблеме "transient execution side-channel vulnerability" (уязвимость побочного канала при переходном выполнении), которая затрагивает определенные процессоры. В особых микроархитектурных состояниях CPU возможно раскрытие информации после transient-исполнения команд в некоторых векторных модулях исполнения, что может привести к ситуации, когда аутентифицированный пользователь может получить неавторизованный доступ к информации через механику локального доступа. Подробнее об уязвимости CVE-2022-40982 можно почитать тут.

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

Чтобы понять, имеет ли ваш процессор данную дыру в безопасности, вам нужно получить о нем следующую информацию: CPU Family, Model и Stepping. Сделать это можно через PowerShell с помощью скрипта Get-CPUid, который вы можете скачать здесь.

Если вы посмотрели на вывод колонок и узнали там свой процессор из таблицы, а в колонке на сайте Intel увидели значение "MCU", то вам нужно накатывать обновление микрокода вашего сервера для защиты от угроз данного типа. Для получения обновления вам нужно связаться с вендором вашего серверного оборудования (например, ссылки для HP и Dell приведены выше).


Таги: VMware, Intel, Security, CPU, Hardware, ESXi

Как использовать USB-флешки как датасторы на платформе VMware vSphere 8


На сайте проекта virten.net появилось отличное руководство о том, как правильно настроить USB-накопитель (обычную флэшку), подключенный к хосту VMware ESXi 8.0 в качестве датастора, откуда можно запускать виртуальные машины. Для производственной среды этого делать, само собой, не рекомендуется, а вот для тестирования различных возможностей хоста vSphere данная инструкция может оказаться очень полезной.

Итак:

Рекомендации по выбору USB-накопителя

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

Предварительные условия

Некоторые команды требуют доступа по SSH к хосту ESXi, который можно включить из vSphere Client:

vSphere Client > ESXi Host > Configure > System > Services > SSH > Start

Это же можно сделать из VMware ESXi Host Client:

ESXi Host Client > Host > Manage >  Services > TSM-SSH > Start

После этого вы можете зайти на хост ESXi по SSH с помощью любого клиента, например, PuTTY.

Шаг 1 - отключаем USB Passthrough

Дефолтное поведение хоста ESXi при присоединении USB-накопителя к хосту - дать возможность его проброса в виртуальную машину через механизм USB Passthrough. Поэтому нам нужно отключить этот механизм.

Есть 3 способа это сделать:

  • На базе устройства с помощью команды esxcli passthrough
  • На базе модели с использованием расширенных настроек USB quirks
  • Полностью отключить его для всех устройств, отключив сервис usbarbitrator

1 - Отключаем USB Passthrough на базе устройства

Этот способ основан на параметрах USB Bus и Vendor ID. Эта настройка сохраняется при перезагрузке, но учтите, что она может перестать работать в условиях, когда изменяются идентификаторы Bus ID или Device ID (например, вы воткнете флэшку в другой порт, либо будет присоединено другое устройство на время отсутствия флэшки в порту).

Итак, втыкаем USB-накопитель в хост ESXi и соединяемся с ним по SSH как root. Выводим список USB-устройств командой:

esxcli hardware usb passthrough device list

Для следующей команды вам потребуется записать параметры четырех выделенных колонок в формате Bus#:Dev#:vendorId:productId (например, 1:4:1058:1140).

Отключаем проброс для устройства:

esxcli hardware usb passthrough device disable -d 1:4:1058:1140

После этого перезагружать хост ESXi не требуется.

2 - Отключаем USB Passthrough, используя USB Quirks

Второй вариант отключает USB Passthrough для конкретной модели (сочетание идентификатора производителя и идентификатора продукта) с использованием расширенных настроек USB Quirks.

Вставьте USB-накопитель в ваш ESXi, подключитесь к хосту ESXi с использованием SSH и войдите под root. Далее просмотрите доступные USB-устройства. Первое число - это идентификатор производителя, второе число - идентификатор продукта:

lusb

Для установки USB Quirks нужно указать ID в следующем формате (см. скриншот выше): 0xDeviceID:0xVendorID  (например, 0x1058:0x1140).

Отключите USB passthrough, используя следующую команду:

esxcli system settings advanced set -o /USB/quirks -s 0x1058:0x1140:0:0xffff:UQ_MSC_NO_UNCLAIM

Здесь уже нужно перезагрузить хост ESXi для применения изменений.

3 - Отключаем USB Arbitrator

Перед началом процедуры не втыкаем флэшку в сервер.

Заходим в клиент vSphere Client, идем в ESX > Configure > System > Advanced System Settings и нажимаем Edit... Далее найдем параметр USB.arbitratorAutoStartDisabled и установим его в значение 1:

После этого перезагружаем хост ESXi и уже после этого втыкаем флэшку в сервер.

То же самое можно сделать с помощью CLI-команды через SSH (после нее можно уже втыкать флэшку):

/etc/init.d/usbarbitrator stop

Также можно отключить USB Arbitrator следующей командой, которая будет применена после перезагрузки хоста:

# chkconfig usbarbitrator off

Шаг 2 - создаем VMFS Datastore на флэшке

После того, как вы отключили проброс USB, можно создавать датастор через vSphere Client, кликнув правой кнопкой на хосте ESXi и выбрав Actions > Storage > New Datastore... (в ESXi Host Client это делается в разделе Storage > New Datastore).

Если ваше устройство не отображается в мастере New Datastore, нужно сделать ресканирование хранилищ (опция Rescan Storage по правому клику) и убедиться, что устройство присутствует в списке.

Если и это не помогло, то можно попробовать создать датастор с помощью командной строки. Находим путь к устройству (Device Path в формате mpx.vmhba##). Для этого запускаем команду:

esxcli storage core device list |grep '^mpx' -A3

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

Если у вас несколько устройств одного размера, то после подключения нужного вам устройства загляните в лог /var/log/vmkernel.log и посмотрите там наличие вот такой записи:

vmkernel: Successfully registered device "mpx.vmhba34:C0:T0:L0" from plugin "NMP" of type 0

Это и есть ваша флэшка. Теперь создаем переменную с этим устройством:

DISK="/vmfs/devices/disks/mpx.vmhba34:C0:T0:L0"

После этого создаем метку для данного устройства:

partedUtil mklabel ${DISK} gpt

Теперь с помощью утилиты partedUtil создадим раздел с идентификатором GUID=AA31E02A400F11DB9590000C2911D1B8:

partedUtil "setptbl" "${DISK}" "gpt" "1 2048 $(eval expr $(partedUtil getptbl ${DISK} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1) AA31E02A400F11DB9590000C2911D1B8 0"

И отформатируем раздел в формат VMFS:

vmkfstools -C vmfs6 -S usbdrive ${DISK}:1

После этого ваш том, созданный на флэшке, появится в списке датасторов хоста.

Для бесплатного резервного копирования виртуальных машин можно использовать скрипт ghettoVCB.

Если вы заметите, что скорость копирования на/с датастора с помощью команд cp, mv или scp очень медленная, то вы можете использовать механизм Storage vMotion или утилиту vmkfstool для копирования данных.

Например, вот так можно склонировать VMDK-диск:

vmkfstools -i <src>.vmdk <dst>.vmdk

Известные проблемы

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

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

cpu0:65593)LVM: 11136: Device mpx.vmhba34:C0:T0:L0:1 detected to be a snapshot:

То есть датастор определяется как снапшот. Список снапшотов вы можете вывести командой:

# esxcli storage vmfs snapshot list
583b1a72-ade01532-55f6-f44d30649051
Volume Name: usbflash
VMFS UUID: 583b1a72-ade01532-55f6-f44d30649051
Can mount: true
Reason for un-mountability:
Can resignature: true
Reason for non-resignaturability:
Unresolved Extent Count: 1

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

# esxcli storage vmfs snapshot mount -u 583b1a72-ade01532-55f6-f44d30649051

Таги: VMware, USB, VMFS, Storage, Hardware, vSphere, ESXi

Пропуск сканирования/ресканирования LUN, выделенных для кластеров WSFC на томах pRDM в среде VMware vSphere


В некоторых случаях, когда клиенты используют физические тома pRDM в своей среде, время загрузки хоста VMware ESXi или повторное сканирование хранилища может занимать больше времени, чем обычно. Причина этих долгих процессов заключается в том, что каждый LUN, подключенный к хосту, сканируется при загрузке или во время повторного сканирования хранилища. Обычно тома RDM используются для класторов Microsoft WSFC или других кластерных приложений и не используются хостом напрямую. Во время сканирования ESXi пытается прочитать разделы на всех дисках, но не может это сделать для устройств, постоянно зарезервированных WSFC. В связи с этим, загрузка хоста или повторное сканирование устройств хранения может занимать большое время. WSFC использует механизм SCSI-3 Persistent Reservation для контроля блокировки между узлами WSFC, что блокирует возможность чтения их хостами ESXi.

VMware рекомендует внедрять постоянное резервирование (perennial reservation) для всех хостов ESXi, на которых размещаются узлы ВМ, использующие RDM. Для получения более подробной информации посмотрите статью KB1016106.

Итак, возникает вопрос: как можно заставить хост не сканировать эти RDM, тем самым сокращая время загрузки или повторного сканирования?

Существует флаг устройства под названием "Perennially Reserved", который сообщает хосту, что RDM не должен сканироваться, и что устройство используется в другом месте на постоянной основе. До vSphere 7 этот флаг можно было включить только через CLI и для этого требовался UUID (naa.ID).

Команда для установки флага в значение true:

esxcli storage core device setconfig -d <naa.id> --perennially-reserved=true

Установку флага можно проверить командой:

esxcli storage core device list -d <naa.id>

В выводе команды в случае установленного флага будет следующая строка:

Is Perennially Reserved: true

При установке этой опции ее нужно запустить для каждого соответствующего тома RDM, используемого кластером WSFC, и на каждом хосте ESXi с доступом к этому RDM. Вы также можете установить флаг "Perennially Reserved" в профилях хостов.

С выпуском vSphere 7, возможность установки флага "Perennially Reserved" в значение "true" была добавлена в пользовательский интерфейс в разделе устройств хранения. Также было добавлено поле для отображения текущего значения флага "Perennially Reserved".

После выбора RDM для постоянного резервирования, у вас есть возможность отметить устройство как зарезервированное ("Mark as perennially reserved") для текущего хоста или нескольких хостов в кластере. Это устраняет ручной процесс установки опции для каждого хоста через CLI. Также вы все еще можете использовать для этих целей ESXCLI, PowerCLI или профили хостов.

Когда вы нажмете Yes статус резервирования для устройств обновится в интерфейсе:

Теперь для зарезерированных устройств будет доступна опция снятия этого флага ("Unmark as perennially reserved"):

Важное примечание: вы должны использовать флаг "Perennially Reserved" только для RDM или LUN, которые вы не хотите сканировать. LUN стандартных хранилищ ESXi НЕ должны быть помечены этим флагом.

Ну и весь этот процесс можно также увидеть в видео от VMware:


Таги: VMware, vSphere, ESXi, Storage, LUN

Вышла новая версия VMware ESXi Arm Edition 1.13


Совсем недавно мы писали об инициативах компании VMware в сфере архитектуры процессоров ARM, а вот на днях компания объявила о релизе новой версии флагманской платформы - VMware ESXi Arm Edition 1.13. Напомним, что это решение представляет собой гипервизор для архитектуры ARM на базе кода ESXi. В будущем он найдет свое применение в таких решениях, как Project Monterey. О прошлой версии ESXi для ARM 1.12 мы писали в марте этого года.

Давайте посмотрим на новые возможности ESXi Arm Edition 1.13:

  • Теперь поддерживается обновление с более ранних релизов ESXi-Arm 1.x Fling с использованием как ESXi-Arm ISO, так и автономного пакета.
  • Добавлена поддержка контроллеров AHCI SATA, которые не поддерживают 64-битное адресацию на системах с памятью, расположенной выше 4GB
  • Исправлена ошибка с выпадением в розовый экран смерти (PSOD) на системах GIGABYTE Ampere Altra и Altra Max с SATA HBA на базе ASM1164 при наличии одного или нескольких SATA дисков
  • Исправлено возможное повреждение данных для виртуального устройства NVMe
  • Таблицы виртуального UEFI ACPI теперь показывают только настроенные последовательные порты. Для первого найденного создается таблица ACPI SPCR.
  • Поддержка реального времени UEFI (RTC) теперь включена на системах на базе Rockchip.
  • Исправлено возможное зависание при выключении на системах на базе Rockchip при использовании встроенных сетевых адаптеров.
  • Апгрейды с использованием образов профилей автономного пакета (zip) теперь возможны на всех системах.
  • Исправлены сбои подключения vVols.
  • Добавлены функции высокой доступности для vCenter Server 8.0+ (подробнее об этом тут).

Скачать последнюю версию VMware ESXi Arm Edition 1.13 можно по этой ссылке.


Таги: VMware, Labs, ESXi, ARM, Update, Hardware

Продукты VMware и устройства на базе архитектуры ARM


Как многие знают, сейчас процессоры на базе архитектуры ARM постепенно входят в повседневную жизнь, как для администраторов корпоративных инфраструктур в части специфического оборудования, так и для обычных пользователей благодаря компьютерам на базе архитектуры Apple Silicon с процессорами M1/M2 (в основном, это ноутбуки MacBook).Сегодня мы рассмотрим 3 основных инициативы компании VMware в этой сфере...


Таги: VMware, ARM, Hardware, ESXi, Apple, Microsoft, Macbook

Для чего нужны и как работают профили Configuration Profiles в VMware vSphere 8 Update 1


Многие администраторы помнят, что при анонсе платформы vSphere 8 в прошлом году компания VMware представила технологическое превью технологии Configuration Profiles, которая пришла на смену устаревшему механизму Host Profiles. В недавно состоявшемся релизе vSphere 8 Update 1 движок Configuration Profiles стал полностью поддерживаться в производственной среде. Теперь администраторы могут начать использование этой функциональности и смигрировать в эту среду...


Таги: VMware, vSphere, ESXi, Update

Новые возможности Core Storage в VMware vSphere 8 Update 1


Недавно мы писали об анонсированных новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 1, выход которой ожидается в ближайшее время. Параллельно с этим компания VMware объявила и о выпуске новой версии решения VMware vSAN 8 Update 1, предназначенного для создания высокопроизводительных отказоустойчивых хранилищ для виртуальных машин, а также об улучшениях подсистемы хранения Core Storage в обеих платформах.

Недавно компания VMware также выпустила большую техническую статью "What's New with vSphere 8 Core Storage", в которой детально рассмотрены все основные новые функции хранилищ, с которыми работают платформы vSphere и vSAN. Мы решили перевести ее с помощью ChatGPT и дальше немного поправить вручную. Давайте посмотрим, что из этого вышло :)

Итак что нового в части Core Storage платформы vSphere 8 Update 1

Одно из главных улучшений - это новая система управления сертификатами. Она упрощает возможность регистрации нескольких vCenter в одном VASA-провайдере. Это положит основу для некоторых будущих возможностей, таких как vVols vMSC. Такж есть и функции, которые касаются масштабируемости и производительности. Поскольку vVols могут масштабироваться гораздо лучше, чем традиционное хранилище, VMware улучшила подсистему хранения, чтобы тома vVols работали на больших масштабах.

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

Новая спецификация VASA 5 была разработана для улучшения управления сертификатами vVols, что позволяет использовать самоподписанные сертификаты для многовендорных развертываний vCenter. Это решение также решает проблему управления сертификатами в случае, когда независимые развертывания vCenter, работающие с различными механизмами управления сертификатами, работают вместе. Например, один vCenter может использовать сторонний CA, а другой vCenter может использовать сертификат, подписанный VMCA. Такой тип развертывания может быть использован для общего развертывания VASA-провайдера. Эта новая возможность использует механизм Server Name Indication (SNI).

SNI - это расширение протокола Transport Layer Security (TLS), с помощью которого клиент указывает, какое имя хоста он пытается использовать в начале процесса handshake. Это позволяет серверу показывать несколько сертификатов на одном IP-адресе и TCP-порту. Следовательно, это позволяет обслуживать несколько безопасных (HTTPS) веб-сайтов (или других служб через TLS) с одним и тем же IP-адресом, не требуя, чтобы все эти сайты использовали один и тот же сертификат. Это является концептуальным эквивалентом виртуального хостинга на основе имени HTTP/1.1, но только для HTTPS. Также теперь прокси может перенаправлять трафик клиентов на правильный сервер во время хэндшейка TLS/SSL.

2. Новая спецификация vVols VASA 5.0 и некоторые детали функций

Некоторые новые функции, добавленные в vSphere 8 U1:

  • Изоляция контейнеров - работает по-разному для поставщиков VASA от различных производителей. Она позволяет выполнять настройку политики контроля доступа на уровне каждого vCenter, а также дает возможность перемещения контейнеров между выбранными vCenter. Это дает лучшую изоляцию на уровне контейнеров, а VASA Provider может управлять правами доступа для контейнера на уровне каждого vCenter.
  • Аптайм - поддержка оповещений об изменении сертификата в рамках рабочего процесса VASA 5.0, который позволяет обновлять сертификат VMCA в системах с несколькими vCenter. Недействительный или истекший сертификат вызывает простой, также возможно возникновение простоя при попытке регистрации нескольких vCenter с одним VASA Provider. В конфигурации с несколькими vCenter сертификаты теперь можно обновлять без простоя.
  • Улучшенная безопасность для общих сред - эта функция работает по-разному для поставщиков VASA от производителей. Все операции могут быть аутентифицированы в контексте vCenter, и каждый vCenter имеет свой список контроля доступа (ACL). Теперь нет самоподписанных сертификатов в доверенном хранилище. VASA Provider может использоваться в облачной среде, и для этого также есть доступная роль в VASA 5.0.
  • Обратная совместимость - сервер ESXi, который поддерживает VASA 5.0, может решать проблемы с самоподписанными сертификатами и простоями, возникающими в случае проблем. VASA 5.0 остается обратно совместимым и дает возможность контролировать обновление в соответствии с требованиями безопасности. VASA 5.0 может сосуществовать с более ранними версиями, если производитель поддерживает эту опцию.
  • Гетерогенная конфигурация сертификатов - работает по-разному для поставщиков VASA от производителей. Теперь используется только подписанный сертификат VMCA, дополнительный CA не требуется. Это позволяет изолировать доверенный домен vSphere. VASA 5.0 позволяет использовать разные конфигурации для каждого vCenter (например, Self-Managed 3rd Party CA Signed Certificate и VMCA managed Certificate).
  • Не необходимости вмешательства администратора - поддержка многократного развертывания vCenter с использованием VMCA, которая не требует от пользователя установки и управления сертификатами для VP. Служба SMS будет отвечать за предоставление сертификатов. Теперь это работает в режиме Plug and Play с автоматической предоставлением сертификатов, без вмешательства пользователя, при этом не требуется никаких ручных действий для использования VASA Provider с любым vCenter.
  • Комплаенс безопасности - отсутствие самоподписанных сертификатов в доверенных корневых центрах сертификации позволяет решить проблемы соответствия требованиям безопасности. Не-СА сертификаты больше не являются частью хранилища доверенных сертификатов vSphere. VASA 5.0 требует от VASA Provider использовать сертификат, подписанный СА для связи с VASA.

3. Перенос Sidecar vVols в config-vvol вместо другого объекта vVol

Sidecars vVols работали как объекты vVol, что приводило к накладным расходам на операции VASA, такие как bind/unbind. Решения, такие как First Class Disks (FCD), создают большое количество маленьких sidecars, что может ухудшить производительность vVols. Кроме того, поскольку может быть создано множество sidecars, это может учитываться в общем количестве объектов vVol, поддерживаемых на массиве хранения. Чтобы улучшить производительность и масштабируемость, теперь они обрабатываются как файлы на томе config-vvol, где могут выполняться обычные операции с файлами. Не забывайте, что в vSphere 8 был обновлен способ байндига config-vvol. В результате, с новым механизмом config-vvol уменьшается число операций и задержки, что улучшает производительность и масштабируемость.

Для этой функциональности в этом релизе есть несколько ограничений при создании ВМ. Старые виртуальные машины могут работать в новом формате на обновленных до U1 хостах, но сам новый формат не будет работать на старых ESXi. То есть новые созданные ВМ и виртуальные диски не будут поддерживаться на хостах ниже версии ESXi 8 U1.

5. Улучшения Config-vvol, поддержка VMFS6 config-vvol с SCSI vVols (вместо VMFS5)

Ранее Config-vvol, который выступает в качестве каталога для хранилища данных vVols и содержимого VM home, был ограничен размером 4 ГБ. Это не давало возможности использования папок с хранилищем данных vVols в качестве репозиториев ВМ и других объектов. Для преодоления этого ограничения Config-vvol теперь создается как тонкий объект объемом 255 ГБ. Кроме того, вместо VMFS-5 для этих объектов будет использоваться формат VMFS-6. Это позволит размещать файлы sidecar, другие файлы VM и библиотеки контента в Config-vvol.

На изображении ниже показаны Config-vvol разных размеров. Для машины Win10-5 Config-vvol использует исходный формат 4 ГБ, а ВМ Win10-vVol-8u1 использует новый формат Config-vvol объемом 255 ГБ.

6. Добавлена поддержка NVMe-TCP для vVols

В vSphere 8 была добавлена поддержка NVMe-FC для vVols. В vSphere 8 U1 также расширена поддержка NVMe-TCP, что обеспечивает совместное использование NVMeoF и vVols. См. статью vVols with NVMe - A Perfect Match | VMware.

7. Улучшения NVMeoF, PSA, HPP

Инфраструктура поддержки NVMe end-to-end:

Расширение возможностей NVMe дает возможность поддержки полного стека NVMe без какой-либо трансляции команд SCSI в NVMe на любом уровне ESXi. Еще одной важной задачей при поддержке end-to-end NVMe является возможность контроля multipath-плагинов сторонних производителей для управления массивами NVMe.

Теперь с поддержкой GOS протокол NVMe может использоваться для всего пути - от GOS до конечного таргета.

Важным аспектом реализации VMware трансляции хранилищ виртуальных машин является поддержка полной обратной совместимости. VMware реализовала такой механизм, что при любом сочетании виртуальных машин, использующих SCSI или контроллер vNVMe, и целевого устройства, являющегося SCSI или NVMe, можно транслировать путь в стеке хранения. Это дизайн, который позволяет клиентам переходить между SCSI- и NVMe-хранилищами без необходимости изменения контроллера хранилищ для виртуальной машины. Аналогично, если виртуальная машина имеет контроллер SCSI или vNVMe, он будет работать как на SCSI-, так и на NVMeoF-хранилищах.

Упрощенная диаграмма стека хранения выглядит так:

Для получения дополнительной информации о NVMeoF для vSphere, обратитесь к странице ресурсов NVMeoF.

8. Увеличение максимального количества путей для пространств имен NVMe-oF с 8 до 32

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

9. Увеличение максимального количества кластеров WSFC на один хост ESXi с 3 до 16

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

Для получения дополнительной информации о работе Microsoft WSFC на vSphere можно обратиться к следующим ресурсам:

10. Улучшения VMFS - расширенная поддержка XCOPY для копирования содержимого датасторов между различными массивами

ESXi теперь поддерживает расширенные функции XCOPY, что оптимизирует копирование данных между датасторами разных массивов. Это поможет клиентам передать обработку рабочих нагрузок на сторону хранилища. Функция уже доступна в vSphere 8 U1, но по факту миграция данных между массивами должна поддерживаться на стороне хранилища.

11. Реализация NFSv3 vmkPortBinding

Данная функция позволяет привязать соединение NFS для тома к конкретному vmkernel. Это помогает обеспечить безопасность, направляя трафик NFS по выделенной подсети/VLAN, и гарантирует, что трафик NFS не будет использовать mgmt-интерфейс или другие интерфейсы vmkernel.

Предыдущие монтирования NFS не содержат этих значений, хранящихся в config store. Во время обновления, при чтении конфигурации из конфигурационного хранилища, значения vmknic и bindTovmnic, если они есть, будут считаны. Поэтому обновления с предыдущих версий не будут содержать этих значений, так как они являются необязательными.

12. Улучшения VM Swap

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

  • Увеличена производительность включения/выключения ВМ
  • Увеличена производительность vMotion

Изменения в способе создания/удаления Swap-файлов для томов vVols помогли улучшить производительность включения/выключения, а также производительность vMotion и svMotion.

13. Улучшения Config vVol и сохранение привязки

Здесь были сделаны следующие доработки:

  • Уменьшено время запроса при получении информации о ВМ
  • Добавлено кэширование атрибутов vVol - размер, имя и прочих

Конфигурационный vVol - это место, где хранятся домашние файлы виртуальной машины (vmx, nvram, logs и т. д.) и к нему обычно обращаются только при загрузке или изменении настроек виртуальной машины.

Ранее использовалась так называемая "ленивая отмена связи" (lazy unbind), и происходил unbind конфигурационного vVol, когда он не использовался. В некоторых случаях приложения все же периодически обращались к конфигурационному vVol, что требовало новой операции привязки. Теперь эта связь сохраняется, что уменьшает задержку при доступе к домашним данным виртуальной машины.

14. Поддержка NVMeoF для vVols

vVols были основным направлением развития функциональности хранилищ VMware в последние несколько версий, и для vSphere 8.0 это не исключение. Самое большое обновление в ядре хранения vSphere 8.0 - добавление поддержки vVols в NVMeoF. Изначально поддерживается только FC, но со временем будут работать и другие протоколы, провалидированные и поддерживаемые с помощью vSphere NVMeoF. Теперь есть новая спецификация vVols и VASA/VC-фреймворка - VASA 4.0/vVols 3.0.

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

Еще одним преимуществом NVMeoF vVols является настройка. При развертывании после регистрации VASA фоновая установка завершается автоматически, вам нужно только создать датастор. Виртуальные эндпоинты (vPE) и соединения управляются со стороны VASA, что упрощает настройку.

Некоторые технические детали этой реализации:

  • ANA Group (Асимметричный доступ к пространству имен)

С NVMeoF реализация vVols немного отличается. С традиционными SCSI vVols хранилищами контейнер является логической группировкой самих объектов vVol. С NVMeoF это варьируется в зависимости от того, как поставщик массива реализует функциональность. В общем и целом, на хранилище группа ANA является группировкой пространств имен vVol. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Пространства имен выделяются и активны только по запросу BIND к провайдеру VASA (VP). Пространства имен также добавляются в группу ANA при запросе BIND к VP. Пространство имен остается выделенным/активным до тех пор, пока последний хост не отвяжет vVol.

  • vPE (virtual Protocol Endpoint)

Для традиционных vVols на базе SCSI, protocol endpoint (PE) - это физический LUN или том на массиве, который отображается в появляется в разделе устройств хранения на хостах. С NVMeoF больше нет физического PE, PE теперь является логическим объектом, представлением группы ANA, в которой находятся vVols. Фактически, до тех пор, пока ВМ не запущена, vPE не существует. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Как только ВМ запущена, создается vPE, чтобы хост мог получить доступ к vVols в группе ANA. На диаграмме ниже вы можете увидеть, что vPE указывает на группу ANA на массиве.

  • NS (пространство имен, эквивалент LUN в NVMe)

Каждый тип vVol (Config, Swap, Data, Mem), созданный и использующийся машиной, создает NS, который находится в группе ANA. Это соотношение 1:1 между vVol и NS позволяет вендорам оборудования легко масштабировать объекты vVols. Обычно поставщики поддерживают тысячи, а иногда и сотни тысяч NS. Ограничения NS будут зависеть от модели массива.

На диаграмме вы можете увидеть, что сама виртуальная машина является NS, это будет Config vVol, а диск - это другой NS, Data vVol.

Вы можете узнать больше о технических деталях NVMe-FC и vVols в этой статье блога: "vVols with NVMe - A Perfect Match | VMware".

15. Улучшения NVMeoF

  • Поддержка 256 пространств имен и 2K путей с NVMe-TCP и NVMe-FC

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

Продолжая работать на этим, VMware увеличила поддерживаемое количество пространств имен и путей как для NVMe-FC, так и для TCP.

  • Расширение reservations для устройств NVMe

Добавлена поддержка команд reservations NVMe для использования таких решений, как WSFC. Это позволит клиентам использовать возможности кластеризованных дисков VMDK средствами Microsoft WSFC с хранилищами данных NVMeoF. Пока поддерживается только протокол FC.

  • Поддержка автообнаружения для NVMe Discovery Service на ESXi

Расширенная поддержка NVMe-oF в ESXi позволяет динамически обнаруживать совместимые со стандартом службы NVMe Discovery Service. ESXi использует службу mDNS/DNS-SD для получения информации, такой как IP-адрес и номер порта активных служб обнаружения NVMe-oF в сети.

Также ESXi отправляет многоадресный DNS-запрос (mDNS), запрашивая информацию от сущностей, предоставляющих службу обнаружения DNS-SD. Если такая сущность активна в сети (на которую был отправлен запрос), она отправит (одноадресный) ответ на хост с запрошенной информацией - IP-адрес и номер порта, где работает служба.

16. Улучшение очистки дискового пространства с помощью Unmap

  • Снижение минимальной скорости очистки до 10 МБ/с

Начиная с vSphere 6.7, была добавлена функция настройки скорости очистки (Unmap) на уровне хранилища данных. С помощью этого улучшения клиенты могут изменять скорость очистки на базе рекомендаций поставщика их массива. Более высокая скорость очистки позволяла многим пользователям быстро вернуть неиспользуемое дисковое пространство. Однако иногда даже при минимальной скорости очистки в 25 МБ/с она может быть слишком высокой и привести к проблемам при одновременной отправке команд Unmap несколькими хостами. Эти проблемы могут усугубляться при увеличении числа хостов на один датастор.

Пример возможной перегрузки: 25 МБ/с * 100 хранилищ данных * 40 хостов ~ 104 ГБ/с

Чтобы помочь клиентам в ситуациях, когда скорость очистки 25 МБ/с может приводить к проблемам, VMware снизила минимальную скорость до 10 МБ/с и сделала ее настраиваемой на уровне датасторов:

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

  • Очередь планирования отдельных команд Unmap

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

17. Контейнерное хранилище CNS/CSI

Теперь вы можете выбрать политику Thin provisioning (EZT, LZT) через SPBM для CNS/Tanzu.

Цель этого - добавить возможность политик SPBM для механизма создания/изменения правил политик хранения, которые используются для параметров выделения томов. Это также облегчает проверку соответствия правил выделения томов в политиках хранения для SPBM.

  • Операции, поддерживаемые для виртуальных дисков: создание, реконфигурация, клонирование и перемещение.
  • Операции, поддерживаемые для FCD: создание, обновление политики хранения, клонирование и перемещение.

18. Улучшения NFS

Инженеры VMware всегда работают над улучшением надежности доступа к хранилищам. В vSphere 8 были добавлены следующие улучшения NFS, повышающие надежность:

  • Повторные попытки монтирования NFS при сбое
  • Валидация монтирования NFS

Ну как вам работа ChatGPT с правками человека? Читабельно? Напишите в комментариях!


Таги: VMware, Storage, Update, ChatGPT, ESXi, vSAN, vSphere, vCenter

Анонсировано обновление платформы VMware vSphere 8.0 Update 1


В марте компания VMware анонсировала скорую доступность первого пакета обновлений своей флагманской платформы виртуализации VMware vSphere 8.0 Update 1. Напомним, что прошлая версия VMware vSphere 8.0 была анонсирована на конференции VMware Explore 2022 в августе прошлого года.

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

1. Полная поддержка vSphere Configuration Profiles

В vSphere 8.0 эта функциональность впервые появилась и работала в режиме технологического превью, а в Update 1 она полностью вышла в продакшен. Эта возможность представляет собой новое поколение инструментов для управления конфигурациями кластеров и заменяет предыдущую функцию Host Profiles. Ее особенности:

  • Установка желаемой конфигурации на уровне кластера в форме JSON-документа
  • Проверка хостов на соответствие желаемой конфигурации
  • При выявлении несоответствий - перенастройка хостов на заданный уровень конфигурации

В vSphere 8 Update 1 возможности Configuration Profiles поддерживают настройку распределенных коммутаторов vSphere Distributed Switch, которая не была доступна в режиме технологического превью. Однако, окружения, использующие VMware NSX, все еще не поддерживаются.

Существующие кластеры можно перевести под управление Configuration Profiles. Если для кластера есть привязанный профиль Host Profile, то вы увидите предупреждение об удалении профиля, когда кластер будет переведен в Configuration Profiles. Как только переход будет закончен, Host Profiles уже нельзя будет привязать к кластеру и хостам.

Если кластер все еще использует управление жизненным циклом на базе бейзлайнов, то сначала кластер нужно перевести в режим управления image-based:

vSphere Configuration Profiles могут быть активированы при создании нового кластера. Это требует, чтобы кластер управлялся на основе единого определения образа. После создания кластера доступна кастомизация конфигурации. Более подробно о возможностях Configuration Profiles можно почитать здесь.

2. vSphere Lifecycle Manager для отдельных хостов

В vSphere 8 появилась возможность управлять через vSphere Lifecycle Manager отдельными хостами ESXi под управлением vCenter посредством vSphere API. В Update 1 теперь есть полная поддержка vSphere Client для этого процесса - создать образ, проверить и привести в соответствие, а также другие функции.

Все, что вы ожидаете от vSphere Lifecycle Manager для взаимодействия с кластером vSphere, вы можете делать и для отдельных хостов, включая стейджинг и функции ESXi Quick Boot.

Также вы можете определить кастомные image depots для отдельных хостов - это полезно, когда у вас есть хост, который находится на уровне edge и должен использовать depot, размещенный совместно с хостом ESXi, во избежание проблем с настройкой конфигурации при плохом соединении удаленных друг от друга хостов ESXi и vCenter.

3. Различные GPU-нагрузки хоста на базе одной видеокарты

В предыдущих версиях vSphere все рабочие нагрузки NVIDIA vGPU должны были использовать тот же самый тип профиля vGPU и размер памяти vGPU. В vSphere 8 U1 модули NVIDIA vGPU могут быть назначены для различных типов профилей. Однако, размер памяти для них должен быть, по-прежнему, одинаковым. Например, на картинке ниже мы видим 3 виртуальных машины, каждая с разным профилем (B,C и Q) и размером памяти 8 ГБ. Это позволяет более эффективно разделять ресурсы между нагрузками разных видов.

NVIDIA позволяет создавать следующие типы профилей vGPU:

  • Profile type A - для потоково доставляемых приложений или для решений на базе сессий
  • Profile type B - для VDI-приложений
  • Profile type C - для приложений, требовательных к вычислительным ресурсам (например, machine learning)
  • Profile type Q - для приложений, требовательных к графике

4. Службы Supervisor Services для vSphere Distributed Switch

В vSphere 8 Update 1, в дополнение к VM Service, службы Supervisor Services теперь доступны при использовании сетевого стека vSphere Distributed Switch.

Supervisor Services - это сертифицированные в vSphere операторы Kubernetes, которые реализуют компоненты Infrastructure-as-a-Service, тесно интегрированные со службами независимых разработчиков ПО. Вы можете установить и управлять Supervisor Services в окружении vSphere with Tanzu, чтобы сделать их доступными для использования рабочими нагрузками Kubernetes. Когда Supervisor Services установлены на Supervisors, инженеры DevOps могут использовать API для создания инстансов на Supervisors в рамках пользовательских пространств имен.

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

5. Функция Bring Your Own Image для VM Service

Возможность VM Service была доработана, чтобы поддерживать образы ВМ, созданные пользователями. Теперь администраторы могут собирать собственные пайплайны сборки образов с поддержкой CloudInit и vAppConfig.

Администраторы могут добавить эти новые шаблоны ВМ в Content library, чтобы они стали доступны команде DevOps. А сами DevOps создают спецификацию cloud-config, которая настроит ВМ при первой загрузке. Команда DevOps отправляет спецификацию ВМ вместе cloud-config для создания и настройки ВМ.

Более подробно об этом можно почитать тут и тут.

6. Консоли виртуальных машин для DevOps

DevOps могут теперь получать простой доступ к виртуальным машинам, которые они развернули, с использованием kubectl.

В этом случае создается уникальная ссылка, по которой можно получить доступ к консоли ВМ, и которая не требует настройки разрешений через vSphere Client. Веб-консоль дает по этому URL доступ пользователю к консоли машины в течение двух минут. В этом случае нужен доступ к Supervisor Control Plane по порту 443.

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

7. Интегрированный плагин Skyline Health Diagnostics

Теперь развертывание и управление VMware Skyline Health Diagnostics упростилось за счет рабочего процесса, встроенного в vSphere Client, который дает возможность просто развернуть виртуальный модуль и зарегистрировать его в vCenter.

Skyline Health Diagnostics позволяет вам:

  • Диагностировать и исправлять различные типы отказов в инфраструктуре
  • Выполнять проверку состояния компонентов (health checks)
  • Понимать применимость VMware Security Advisories и связанных элементов
  • Обнаруживать проблемы, которые влияют на апдейты и апгрейды продукта

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

8. Улучшенные метрики vSphere Green Metrics

В vSphere 8.0 появились метрики, которые отображают потребление энергии виртуальными машинами с точки зрения энергоэффективности виртуального датацентра. В vSphere 8.0 Update 1 теперь можно отслеживать их на уровне отдельных ВМ. Они берут во внимание объем ресурсов ВМ, чтобы дать пользователю более точную информацию об энергоэффективности на уровне отдельных нагрузок. Разработчики также могут получать их через API, а владельцы приложений могут получать агрегированное представление этих данных.

Метрика Static Power - это смоделированное потребление мощности простаивающих ресурсов ВМ, как если бы она был хостом bare-metal с такими же аппаратными параметрами процессора и памяти. Static Power оценивает затраты на поддержание таких хостов во включенном состоянии. Ну а Usage - это реально измеренное потребление мощности ВМ в активном режиме использования CPU и памяти, которые запрашиваются через интерфейс (IPMI - Intelligent Platform Management Interface).

9. Функция Okta Identity Federation для vCenter

vSphere 8 Update 1 поддерживает управление идентификациями и многофакторной аутентификацией в облаке, для чего на старте реализована поддержка Okta.

Использование Federated identity подразумевает, что vSphere не видит пользовательских учетных данных, что увеличивает безопасность. Это работает по аналогии со сторонними движками аутентификации в вебе, к которым пользователи уже привыкли (например, логин через Google).

10. Функции ESXi Quick Boot для защищенных систем

vSphere начала поддерживать Quick Boot еще с версии vSphere 6.7. Теперь хосты с поддержкой TPM 2.0 проходят через безопасный процесс загрузки и аттестации, что позволяет убедиться в неизменности хоста - а это надежный способ предотвратить атаки malware. Quick Boot теперь стал полноценно совместимым процессом в vSphere 8 Update 1.

11. Поддержка vSphere Fault Tolerance с устройствами vTPM

Функции непрерывной доступности VMware vSphere Fault Tolerance (FT) позволяют подхватить исполнение рабочей нагрузки на резервном хосте без простоя в случае проблем основной ВМ. Теперь эта функция поддерживает ВМ, настроенные с устройствами vTPM.

Модели Virtual TPM - это важный компонент инфраструктуры, используемый такими решениями, как Microsoft Device Guard, Credential Guard, Virtualization-Based Security, Secure Boot & OS attestation, а также многими другими. Это, зачастую, и часть регуляторных требований комплаенса.

12. Поддержка Nvidia NVSwitch

В рамках партнерства с NVIDIA, VMware продолжает расширять поддержку продуктового портфеля этого вендора.

Эта технология используется в high-performance computing (HPC) и для AI-приложений (deep learning, научное моделирование и анализ больших данных), что требует работы модулей GPU совместно в параллельном режиме. В современном серверном оборудовании различные приложения ограничены параметрами шины. Чтобы решить эту проблему, NVIDIA создала специальный коммутатор NVSwitch, который позволяет до 8 GPU взаимодействовать на максимальной скорости.

Вот нюансы технологий NVLink и NVSwitch:

  • NVLink - это бэкенд протокол для коммутаторов NVSwitch. NVLink создает мост для соединений точка-точка и может быть использован для линковки от 2 до 4 GPU на очень высокой скорости.
  • NVSwitch требует, чтобы более 4 GPU были соединены, а также использует поддержку vSphere 8U1 NVSwitch для формирования разделов из 2, 4 и 8 GPU для работы виртуальных машин.
  • NVLink использует архитектуру Hopper, что предполагает создания пары GPU, которые передают до 450 GB/s (то есть общая скорость до 900 GB/s).

Для сравнения архитектура Gen5 x16 может передавать на скорости до 64 GB/s, то есть NVLink и NVSwitch дают очень существенный прирост в скорости.

13. Функции VM DirectPath I/O Hot-Plug для NVMe

В прошлых релизах добавление или удаление устройств VM DirectPath IO требовало нахождения ВМ в выключенном состоянии. Теперь же в vSphere 8 Update 1 появилась поддержка горячего добавления и удаления устройств NVMe через vSphere API.

На этом пока все, в следующих статьях мы расскажем об улучшениях Core Storage в vSphere 8 Update 1.


Таги: VMware, vSphere, Update, ESXi, vCenter, NVIDIA

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43    >   >>
Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

26/08/2024:  VMware Explore 2024 Лас-Вегас
04/11/2024:  VMware Explore 2024 Барселона

Быстрый переход:
VMware VMachines Offtopic NAKIVO vStack Gartner Veeam Vinchin StarWind Nakivo IT-Grad Cloud Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Explore vSAN Update VCF NSX Aria Tanzu EUC Private AI Avi Broadcom Workstation Community Skyline HCX AI Host Client Chargeback Horizon Labs SASE Workspace ONE Networking Backup Ransomware Tools Performance Lifecycle VCP Network AWS Intel API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes V2V vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP ONE DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint Stretched Director ESA Troubleshooting Android Python Upgrade ML Hub Guardrails CLI VCPP Memory Driver Foundation HPC Orchestrator Optimization Bugs SVMotion Diagram Ports SIOC Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Работа с дисками виртуальных машин VMware.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2024, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge