Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).
Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.
Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.
Memory Tiering Enabled
Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size
Tier 1 Memory
Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size
Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).
Устройства NVMe для тиринга
Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).
Вильям Лам написал интересную статью о поддержке технологии Intel Neural Processing Unit (NPU) на платформе VMware ESXi.
Начиная с процессоров Intel Meteor Lake (14 поколения), которые теперь входят в новый бренд Intel Core Ultra Processor (серия 1), встроенный нейронный процессор (Neural Processing Unit, NPU) интегрирован прямо в систему на кристалле (system-on-chip, SoC) и оптимизирован для энергоэффективного выполнения AI-инференса.
Хотя вы уже можете использовать интегрированную графику Intel iGPU на таких платформах, как Intel NUC, с ESXi для инференса рабочих нагрузок, Вильяму стало интересно, сможет ли этот новый нейронный процессор Intel NPU работать с ESXi?
Недавно Вильям получил доступ к ASUS NUC 14 Pro (на который позже он сделает подробный обзор), в котором установлен новый нейронный процессор Intel NPU. После успешной установки последней версии VMware ESXi 8.0 Update 3, он увидел, что акселератор Intel NPU представлен как PCIe-устройство, которое можно включить в режиме passthrough и, видимо, использовать внутри виртуальной машины.
Для тестирования он использовал Ubuntu 22.04 и библиотеку ускорения Intel NPU, чтобы убедиться, что он может получить доступ к NPU.
Шаг 1 - Создайте виртуальную машину с Ubuntu 22.04 и настройте резервирование памяти (memory reservation - это требуется для PCIe passthrough), затем добавьте устройство NPU, которое отобразится как Meteor Lake NPU.
Примечание: вам нужно будет отключить Secure Boot (этот режим включен по умолчанию), так как необходимо установить более новую версию ядра Linux, которая всё ещё находится в разработке. Отредактируйте виртуальную машину и перейдите в VM Options -> Boot Options, чтобы отключить его.
Когда Ubuntu будет запущена, вам потребуется установить необходимый драйвер Intel NPU для доступа к устройству NPU, однако инициализация NPU не удастся, что можно увидеть, выполнив следующую команду:
dmesg | grep vpu
После подачи обращения в поддержку Github по поводу драйвера Intel NPU, было предложено, что можно инициализировать устройство, используя новую опцию ядра, доступную только в версии 6.11 и выше.
Шаг 2 - Используя эту инструкцию, мы можем установить ядро Linux версии 6.11, выполнив следующие команды:
После перезагрузки вашей системы Ubuntu вы можете убедиться, что теперь она использует версию ядра 6.11, выполнив команду:
uname -r
Шаг 3 - Теперь мы можем установить драйвер Intel NPU для Linux, и на момент публикации этой статьи последняя версия — 1.8.0. Для этого выполните следующие команды:
Нам также нужно создать следующий файл, который включит необходимую опцию ядра (force_snoop=1) для инициализации NPU по умолчанию, выполнив следующую команду:
Теперь перезагрузите систему, и NPU должен успешно инициализироваться, как показано на скриншоте ниже.
Наконец, если вы хотите убедиться, что NPU полностью функционален, в библиотеке Intel NPU Acceleration есть несколько примеров, включая примеры малых языковых моделей (SLM), такие как TinyLlama, Phi-2, Phi-3, T5 и другие.
Для настройки вашего окружения Python с использованием conda выполните следующее:
Автор попробовал пример tiny_llama_chat.py (видимо, тренировочные данные для этой модели могли быть основаны на изображениях или художниках).
Независимо от того, используете ли вы новую библиотеку Intel NPU Acceleration или фреймворк OpenVino, теперь у вас есть доступ к ещё одному ускорителю с использованием ESXi, что может быть полезно для периферийных развертываний, особенно для рабочих нагрузок, требующих инференса AI, и теперь с меньшим энергопотреблением.
Следующий пример на Python можно использовать для проверки того, что устройство NPU видно из сред выполнения, таких как OpenVino.
from openvino.runtime import Core
def list_available_devices():
# Initialize the OpenVINO runtime core
core = Core()
# Get the list of available devices
devices = core.available_devices
if not devices:
print("No devices found.")
else:
print("Available devices:")
for device in devices:
print(f"- {device}")
# Optional: Print additional device information
for device in devices:
device_info = core.get_property(device, "FULL_DEVICE_NAME")
print(f"\nDevice: {device}\nFull Device Name: {device_info}")
if __name__ == "__main__":
list_available_devices()
Вильям Лам написал полезную статью о новой фиче вышедшего недавно обновления фреймворка для управления виртуальной инфраструктурой с помощью сценариев - VMware PowerCLI 13.3.
Параметры загрузки ядра (kernel boot options) в VMware ESXi можно добавить во время загрузки ESXi (нажав SHIFT+O) или обновив файл конфигурации boot.cfg, чтобы повлиять на определенные настройки и/или поведение системы.
Раньше было сложно получить полную картину по всем ESXi хостам, чтобы определить, на каких из них используются пользовательские параметры загрузки, особенно в тех случаях, когда они уже не нужны или, что хуже, если кто-то вручную добавил настройку, которую вы не планировали.
В vSphere 8.0 Update 3 добавлено новое свойство bootCommandLine в vSphere API, которое теперь предоставляет полную информацию обо всех параметрах загрузки, используемых для конкретного ESXi хоста.
На днях был выпущен релиз PowerCLI 13.3, который поддерживает последние API, представленные как в vSphere 8.0 Update 3, так и в VMware Cloud Foundation (VCF) 5.2. Вы можете легко получить доступ к этому новому свойству, выполнив следующую команду в сценарии:
Выход платформы VMware vSphere 8 переопределил подход к управлению жизненным циклом и обслуживанием инфраструктуры vSphere. Решение vSphere Lifecycle Manager упрощает управление образами кластеров, обеспечивает полный цикл управления драйверами и прошивками, а также ускоряет полное восстановление кластера. Управление сертификатами происходит без сбоев, а обновления vCenter можно выполнять с гораздо меньшими простоями по сравнению с прошлыми релизами платформы.
vSphere 8 Update 3 продолжает эту тенденцию снижения и устранения простоев с введением функции vSphere Live Patch.
vSphere Live Patch позволяет обновлять кластеры vSphere и накатывать патчи без миграции рабочих нагрузок с целевых хостов и без необходимости перевода хостов в полный режим обслуживания. Патч применяется в реальном времени, пока рабочие нагрузки продолжают выполняться.
Требования данной техники:
vSphere Live Patch является опциональной функцией, которую необходимо активировать перед выполнением задач восстановления.
vCenter должен быть версии 8.0 Update 3 или выше.
Хосты ESXi должны быть версии 8.0 Update 3 или выше.
Настройка Enforce Live Patch должна быть включена в глобальных настройках восстановления vSphere Lifecycle Manager или в настройках восстановления кластера.
DRS должен быть включен на кластере vSphere и работать в полностью автоматическом режиме.
Для виртуальных машин с включенной vGPU необходимо активировать Passthrough VM DRS Automation.
Текущая сборка кластера vSphere должна быть пригодна для применения live-патчинга (подробности ниже).
Как работает Live Patching
Кликните на картинку, чтобы открыть анимацию:
Распишем этот процесс по шагам:
Хост ESXi переходит в режим частичного обслуживания (partial maintenance mode). Частичный режим обслуживания — это автоматическое состояние, в которое переходит каждый хост. В этом особом состоянии существующие виртуальные машины продолжают работать, но создание новых ВМ на хосте или миграция ВМ на этот хост или с него запрещены.
Новая версия компонентов целевого патча монтируется параллельно с текущей версией.
Файлы и процессы обновляются за счет смонтированной версии патча.
Виртуальные машины проходят быструю паузу и запуск (fast-suspend-resume) для использования обновленной версии компонентов.
Не все патчи одинаковы
Механизм vSphere Live Patch изначально доступен только для определенного типа патчей. Патчи для компонента выполнения виртуальных машин ESXi (virtual machine execution component) являются первыми целями для vSphere Live Patch.
Патчи, которые могут изменить другие области ESXi, например патчи VMkernel, изначально не поддерживаются для vSphere Live Patch и пока требуют следования существующему процессу патчинга, который подразумевает перевод хостов в режим обслуживания и эвакуацию ВМ.
Обновления vSphere Live Patches могут быть установлены только на поддерживаемые совместимые версии ESXi. Каждый Live Patch будет указывать, с какой предыдущей сборкой он совместим. vSphere Lifecycle Manager укажет подходящие версии при определении образа кластера. Также вы можете увидеть подходящую версию в репозитории образов vSphere Lifecycle Manager:
Например, patch 8.0 U3a 23658840 может быть применен только к совместимой версии 8.0 U3 23653650. Системы, которые не работают на совместимой версии, все равно могут быть обновлены, но для этого будет использован существующий процесс "холодных" патчей, требующий перевода хостов в режим обслуживания и эвакуации ВМ.
Соответствие образа кластера будет указывать на возможность использования Live Patch.
Быстрое приостановление и возобновление (fast-suspend-resume)
Как упоминалось ранее, патчи для компонента выполнения виртуальных машин в ESXi являются первой целью для vSphere Live Patch. Это означает, что хотя виртуальные машины не нужно эвакуировать с хоста, им нужно выполнить так называемое быстрое приостановление и возобновление (FSR) для использования обновленной среды выполнения виртуальных машин.
FSR виртуальной машины — это ненарушающее работу действие, которое уже используется в операциях с виртуальными машинами при добавлении или удалении виртуальных аппаратных устройств (Hot Add) в работающие виртуальные машины.
Некоторые виртуальные машины несовместимы с FSR. Виртуальные машины, настроенные с включенной функцией Fault Tolerance, машины, использующие Direct Path I/O, и vSphere Pods не могут использовать FSR и нуждаются в участии администратора. Это может быть выполнено либо путем миграции виртуальной машины, либо путем перезагрузки виртуальной машины.
Сканирование на соответствие в vSphere Lifecycle Manager укажет виртуальные машины, несовместимые с FSR, и причину несовместимости:
После успешного восстановления кластера любые хосты, на которых работают виртуальные машины, не поддерживающие FSR, будут продолжать сообщать о несоответствии требованиям. Виртуальные машины необходимо вручную переместить с помощью vMotion или перезагрузить. Только тогда кластер будет полностью соответствовать требованиям (compliant).
Отметим, что
vSphere Live Patch несовместим с системами, работающими с устройствами TPM или DPU, использующими vSphere Distributed Services Engine.
Если у вас нет полноценного способа резервирования конфигураций серверов ESXi, но вы задумались о том, что будет если, то вот тут есть простой и свежий сценарий, который позволить вам сделать бэкап конфигурации и восстановить конфигурацию хостов ESXi.
Автор не хотел вручную создавать резервные копии каждого ESXi хоста, так как это не масштабируется. Вместо этого он создал PowerShell скрипт под названием 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.
Вчера мы писали о новых возможностях последнего пакета обновлений 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 завершит операцию, слот освободится для следующего хоста.
Пример использования : 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.
Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.
При добавлении нового хранилища данных NFSv4.1, количество соединений можно указать во время монтирования, используя команду:
Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.
Для существующего хранилища данных NFSv4.1, количество соединений можно увеличить или уменьшить во время выполнения, используя следующую команду:
esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>
Это не влияет на многопутевую конфигурацию. NFSv4.1 nConnect и многопутевые соединения могут сосуществовать. Количество соединений создается для каждого из многопутевых IP.
В настоящее время 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 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 был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.
Также на днях стали доступны первые результаты тестирования производительности различного оборудования с помощью VMmark 4.0. Их можно посмотреть вот тут.
В блоге 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. Ограничение привилегий пользователей
Ограничьте привилегии пользователей только теми, которые необходимы для выполнения их ролей. Ограничение административных привилегий может предотвратить распространение вымогателей по сети.
Следуя этим советам и оставаясь бдительными, организации могут значительно снизить риск стать жертвой атак вымогателей и защитить свои критически важные системы и данные.
Вильям Лам написал интересную статью о том, как можно редактировать настройки 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:
Примечание: не редактируйте файлы 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." для вендора, изменение значения не оказало никакого эффекта, как показано на скриншоте выше, что, вероятно, указывает на то, что эта информация может храниться в другом месте или содержаться в каком-то встроенном файле.
Многие администраторы часто добавляют новые хосты 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 от 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 (в том числе vSphere) есть бесплатная пробная лицензия на 60 дней, которую вы можете получить самостоятельно. Тут есть 2 ограничения:
Если вы и ваша компания находитесь в России или Беларуси, то легально получить такую лицензию не получится.
Не все продукты VMware имеют пробные версии на 60 дней, некоторые решения нужно запрашивать через партнеров или в отделе продаж VMware (как правило, это специфические Enterprise-решения).
Итак, рассмотрим этот процесс на примере VMware vSphere. Идем по этой ссылке:
В поиске вбиваем интересующий нас продукт, например, vSphere. Там будет несколько результатов (например, лабораторные работы), находим нужный нам Trial и кликаем по ссылке.
Если у вас уже есть аккаунт VMware Connect, то вы можете зайти под ним в разделе справа. Если же нет, то его можно создать (Create an Account):
Если вы уже использовали пробную версию vSphere на 60 дней в прошлом, то второй раз попробовать продукт уже не получится. Если же вы делаете это впервые, то у вас будет кнопка Register, которая позволит вам зарегистрироваться в программе пробного использования:
Далее нужно будет заполнить анкету, где указывается информация о вас и вашей организации:
После этого в разделе License&Download вам будет доступна лицензия на полнофункциональную версию vSphere Cloud Foundation (VCF) на 60 дней, а также ссылки на скачивание компонентов VMware vSphere.
Также вы можете скачать VMware vSphere и ее компоненты в любой момент по следующей ссылке (для этого не нужно регистрироваться в программе пробного периода):
Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.
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", они показаны ниже:
Детали тестов разных политик хранения 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:
Для имитации модели нагрузки с многосхемной работой использовались несколько схем 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
Как знают многие администраторы платформы 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 теперь поставляется только за деньги.
Не то, чтобы это было сделано как-то втихую, но особо нигде и не обсуждалось - ну убрали и убрали. На самом деле, решение это, на наш взгляд, неверное - множество администраторов начинали именно с бесплатного издания, учились на нем азам виртуализации и операциям с виртуальными машинами, делали тестовые лаборатории, создавали кластеры высокой доступности и балансировки нагрузки (на пробных версиях vSphere или ломаных). Теперь же ничего этого нет - чтобы начать эксплуатацию платформы VMware vSphere надо заплатить после пробного периода, но далеко не все могут себе это позволить.
Кстати, видно, что энтузиасты, эксперты и блоггеры также не очень довольны этим фактом, поэтому, возможно, Broadcom еще вернется к вариантам бесплатной виртуализации для целей обучения и совсем малых инсталляций. Не зря же в статье базы знаний написано "at this time", поэтому посмотрим...
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 для множества серверов:
Исправлена ошибка с необнаружением 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.
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 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 возвращает раздел 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 vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...
Администраторы виртуальной инфраструктуры 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 <идентификатор процесса>:
В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно 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 технический документ "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" можно по этой ссылке.
Через неделю после конференции 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 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 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 ожидается в третьем квартале этого года.
На днях на сайте 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 можно почитать тут.
Также вам могут быть полезны следующие ресурсы:
Описание уязвимости Intel Security Advisory - INTEL-SA-00828
Чтобы понять, имеет ли ваш процессор данную дыру в безопасности, вам нужно получить о нем следующую информацию: CPU Family, Model и Stepping. Сделать это можно через PowerShell с помощью скрипта Get-CPUid, который вы можете скачать здесь.
Если вы посмотрели на вывод колонок и узнали там свой процессор из таблицы, а в колонке на сайте Intel увидели значение "MCU", то вам нужно накатывать обновление микрокода вашего сервера для защиты от угроз данного типа. Для получения обновления вам нужно связаться с вендором вашего серверного оборудования (например, ссылки для HP и Dell приведены выше).
На сайте проекта virten.net появилось отличное руководство о том, как правильно настроить USB-накопитель (обычную флэшку), подключенный к хосту VMware ESXi 8.0 в качестве датастора, откуда можно запускать виртуальные машины. Для производственной среды этого делать, само собой, не рекомендуется, а вот для тестирования различных возможностей хоста vSphere данная инструкция может оказаться очень полезной.
Итак:
Рекомендации по выбору USB-накопителя
Касательно форм-фактора или типа USB-накопителей нет никаких ограничений. Вы можете использовать маленькие флешки USB, большие жесткие диски USB 3.5" с высокой емкостью или внешние твердотельные накопители на базе USB. Из-за проблем с производительностью и надежностью, не рекомендуется использовать дешевые USB-флешки для хранилищ.
Предварительные условия
Некоторые команды требуют доступа по SSH к хосту ESXi, который можно включить из vSphere Client:
После этого вы можете зайти на хост 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:
После этого ваш том, созданный на флэшке, появится в списке датасторов хоста.
Для бесплатного резервного копирования виртуальных машин можно использовать скрипт 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
В некоторых случаях, когда клиенты используют физические тома 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).
В выводе команды в случае установленного флага будет следующая строка:
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:
Давайте посмотрим на новые возможности 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 можно по этой ссылке.
RSS
