Что такое guest os vmware

Обновлено: 06.07.2024

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

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

Как и в большинстве случаев, все начинается с общих рекомендаций:

Необходимо использовать поддерживаемую ESXi версию операционной системы. Для этого стоит обратиться к матрице совместимости. Для неподдерживаемых ОС может отсутствовать пакет VMware Tools;
Рекомендуется устанавливать последнюю доступную версию VMware Tools в гостевую ОС и выполнять ее обновление после каждого обновления ESXi. Не стоит забывать, что поддержка Balloon Driver появляется только с установкой VMware Tools;
Стоит отключить заставки экрана и прочую анимацию. В Linux системах стоит отключить X-server (графическую оболочку), если она не используется. Все эти компоненты потребляют дополнительные ресурсы CPU и могут сказываться на производительности виртуальных машин;
Планируйте операции резервного копирования, проверок антивируса и т.п. в периоды минимальной нагрузки на систему. Но и во время минимальной нагрузки не стоит запускать все операции разом, если есть возможность растянуть операции по времени – стоит этим воспользоваться;
Всегда стоит синхронизировать время виртуальной машины с серверами NTP, если таковых нет, можно выполнять синхронизацию времени с помощью VMware Tools. Не стоит использовать два метода синхронизации одновременно.

Measuring Performance in Virtual Machines

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

Для корректного мониторинга производительности виртуальной машины следует использовать инструменты такие как клиент vSphere, esxtop, resxtop и т.п.

Guest Operating System CPU Considerations

Side-Channel Vulnerability – защита от подобного рода атак защищает гостевые операционные системы, однако может сказаться на производительности виртуальных систем, особенно, в случае ограниченных ресурсов CPU.

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

Virtual NUMA (vNUMA)

Virtual NUMA позволяет гостевой операционной системе больше понять о нижележащей архитектуре NUMA хоста ESXi и тем самым более грамотно управлять оперативной памятью и расположением в ней данных.

Использование vNUMA позволяет получить прирост в производительности для «больших» машин, особенно для систем и приложений, сильно зависящих от NUMA.

При использовании vNUMA необходимо иметь ввиду следующие моменты:

Топология vNUMA виртуальной машины базируется на низлежащей топологии NUMA хоста и «пробрасывается» в виртуальную машину только при операциях Power Cycle (включение\выключение виртуальной машины. Перезагрузка с помощью ОС не считается за Power Cycle). В связи с этим, в случае миграции виртуальной машины на хост, архитектура NUMA которого отличается, производительность VM может снизиться. Рекомендуется строить кластеры из хостов с одинаковой NUMA архитектурой;
При выставлении параметров CPU/Memory для виртуальной машины, всегда стоит учитывать топологию NUMA хоста, на которой эта машина будет работать. В некоторых процессорах размер NUMA ноды не всегда может быть равен количеству ядер этого процессора. Такие вещи стоит учитывать;
Для наилучшей производительности, виртуальная машина должна оставаться в рамках одной NUMA ноды. Если размер NUMA ноды – 6 ядер, стоит рассмотреть вопрос, чтобы не выдавать машине количество ядер больше чем 6. Если уместиться в рамках одной NUMA ноды не получается, стоит постараться сконфигурировать машину так, чтобы задействовать минимально возможное количество NUMA нод.
Несмотря на то, что Hyper-Threading добавляет «логические ядра», увеличивая их общее суммарное количество, стоит быть внимательным при выделении виртуальной машине большего количества ядер, чем есть физических ядер на хосте. Хотя это и допустимо, в случае нехватки ресурсов, потенциально могут начаться проблемы;
Начиная с версии vSphere 6.5, изменение значения corespersocket виртуальной машиныбольше не оказывает влияния на vNUMA. В настоящее время данное значение влияет на количество отображаемых процессоров в ОС и может влиять на лицензирование ПО, установленного внутри виртуальной машины. В случае, если необходимо «пробросить» желаемую vNUMA топологию, можно воспользоваться параметром numa.vcpu.followcorespersocket;
По умолчанию vNUMA включается для виртуальных машин с количеством vCPU больше чем 8. Для того, чтобы включить поддержку vNUMA с меньшим количеством vCPU, можно использовать параметр numa.vcpu.min = X в конфигурационном файле vmx виртуальной машины;
Включение возможности CPU HotAdd отключает возможность использования vNUMA для виртуальной машины, в связи с чем гостевая операционная система всегда будет видеть одну NUMA ноду, вне зависимости от физической архитектуры. Учитывая вероятное снижение производительности у виртуальной машины, стоит включать функцию HotAdd только для тех машин, где это будет действительно необходимо. Как альтернативу HotAdd, стоит рассмотреть возможность отключения VM на момент увеличения количества vCPU, что позволит сохранить возможность использования vNUMA и снизить потери в производительности.

Guest Operating System Storage Considerations

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

Для большинства гостевых ОС, дисковым адаптером по умолчанию будет LSI Logic Parallel, либо LSI Logic SAS, в зависимости от выбранной операционной системы и версии оборудования vHardware. ESXi так же позволяет использовать адаптер PVSCSI, который в большинстве случае снижает нагрузку на CPU и потенциально увеличивает пропускную способность. Данный адаптер является наилучшим выбором для машин с высоким дисковым вводом-выводом. Стоит учесть, что не все операционные системы поддерживают загрузку с дисков, подключенных к данному адаптеру;
Начиная с vSphere 6.5 появилась поддержка адаптеров NVMe (vNVME). Поскольку vNMVE рассчитан на работу с flash устройствами и устройствами NVMe, данный тип контроллера не лучший выбор при работе с обычными дисковыми подсистемами;
Значение глубины очереди дисковой подсистемы, или же Queue Depth может значительно влиять на производительность дискового ввода-вывода, например, слишком маленькое значение может крайне ограничивать ввод-вывод виртуальных машин. Следует свериться с документацией производителя на предмет оптимальных значений Queue Depth для их оборудования;
В некоторых случаях большие дисковые запросы на ввод-вывод могут разбиваться драйвером дисковой подсистемы на более мелкие, тем самым увеличивая общее количество операций. Имеет смысл сконфигурировать размер блоков в операционной системе;
В случае, если дисковая подсистема использует диски 4KB native (4Kn), либо 512B emulation (512e), получить наилучшую производительность можно при использовании приложений, которые выравнивают свой ввод-вывод блоками по 4К (изначально использовались блоки размером в 512 байт).

Guest Operating System Networking Considerations

При создании виртуальной машины, ESXi позволяет выбрать один из нескольких типов сетевых адаптеров (vNIC). Выбор зависит от выбранной гостевой операционной системы и версии vHardware.

В случаях, если операционная система не имеет встроенных драйверов для выбранного типа сетевого адаптера, они могут быть установлены в систему вместе с пакетом VMware Tools.

Types of Virtual Network Adapters

Существует три основных типа адаптеров: emulated, paravirtualized и hybrid.

К emulated, либо эмулированным адаптерам относятся:

Vlance – который эмулирует AMD 79C970 PCnet32 NIC. Драйвера для данного устройства присутствуют в большинстве 32 битных ОС;
E1000 – эмулирует Intel 82545EM NIC. Драйвера доступны в большинстве свежих ОС;
E1000e – он же Intel 82545EM NIC. Драйвера для данного типа адаптера менее распространены среди современных ОС.

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

Таких адаптеров 3:

VMXNET;
VMXNET2 – основан на базе адаптера VMXNET, добавляет ряд улучшений по сравнению со своим предшественником;
VMXNET3 –поддерживает все функции, а так же ряд других улучшений относительно двух адаптеров выше.

Последний тип адаптеров – Flexible. Это сетевой адаптер, который может эмулировать Vlance, а также может функционировать как адаптер VMXNET в зависимости от выбранного драйвера.

Стоит так же понимать, что скорость сетевого интерфейса, который отображается в гостевой ОС не является скоростью интерфейса гипервизора. Так, например, при использовании сетевого адаптера VMXNET3, в операционной системе скорость подключения будет 10GB/s, в то время как сам ESXi подключен к сети линками на скорости 1гигабит.

Selecting Virtual Network Adapters

Для получения наилучшей производительности, всегда стоит использовать адаптер VMXNET3, если он поддерживается операционной системой. Для этого требуется виртуальная машина версии 7 и выше, а также, установка пакета VMware Tools в некоторых случаях (в большинстве случаев это касается ОС семейства Windows).

В системах, в которых адаптер VMXNET3 не поддерживается, рекомендуется использовать адаптер E1000e.

Если же и E1000e не поддерживается системой, использование Flexible адаптера может помочь.

Virtual Network Adapter Features and Configuration

В случае, если две виртуальные машины подключены к одному vSwitch ESXi, передача сетевого трафика между ними происходит в рамках хоста и не задействует сетевые адаптеры, тем самым, не ограничивая их скорость;
Сетевые адаптеры E1000, E1000e, VMXNET2, VMXNET3 поддерживают Jumbo Frames. Для включения данной функции, необходимо выставить значение MTU=9000 в драйвере сетевого интерфейса. Все остальные устройства на пути сетевого трафика, включая vSwitch, должны так же быть сконфигурированы с поддержкой Jumbo Frames;
TCP Segmentation Offload (TSO) включается автоматически и поддерживается сетевыми адаптерами E1000, E1000e, VMXNET2, VMXNET3. TSO может улучшить производительность даже в случаях, если низлежащее устройство его не поддерживает;
По аналогии с TSO, по умолчанию включается так же Large Receive Offload (LRO), но поддерживается данная функция только адаптерами VMXNET2 и VMXNET3. LRO поддерживается большинством Linux систем, однако для систем Windows должен быть соблюден ряд условий – vHardware 11+, VMXNET3, Windows Server 2012+, VMXNET driver 1.6.6.0 и выше, включенная поддержка Receive Segment Coalescing (RSC) в ОС;
В некоторых ситуациях, низкая пропускная способность сети в виртуальной машине может быть связана с недостаточным количеством буферов для приема сетевых пакетов. В случае, если данного буфера недостаточно, сетевые пакеты будут отброшены на уровне VMKernel, а производительность сети будет снижена. Для VMXNET количество буферов на прием и передачу по 100 в каждую сторону с максимально возможным количеством – 128. Для VMXNET2 – 150 и 256, с максимальным количеством буферов для входящего трафика в 512. Отрегулировать данные параметры можно в vmx файле виртуальной машины. Для адаптеров E1000, E1000e и VMXNET3 максимальное количество буферов контролируется драйвером ОС и может максимально составлять 4096;
Множественные очереди приема и передачи (RSS или scalable I/O) позволяют обрабатывать сетевые пакеты на нескольких CPU одновременно. Без данной технологии, весь сетевой трафик обрабатывается только на одном CPU, что, соответственно, медленней и в некоторых случаях может стать узким местом. Сетевые адаптеры E1000e и VMXNET3 поддерживают данную функцию, для большинства операционных систем, начиная от Windows 2003. Начиная с версии ESXi 5.0 и последующих версий VMware Tools, драйвера для VMXNET3 автоматически включают поддержку RSS и множественные очереди. Количество очередей может быть 1,2,4, либо 8, в зависимости от количества vCPU виртуальной машины.

В качестве заключения:

На этом часть про конфигурацию виртуальных машин подходит к концу. На основании предложенных рекомендаций стоит отметить, что конфигурация виртуальной машины – это крайне важный процесс. Следует с понимаем подходить к вопросу выделения ресурсов VM таких как CPU и оперативная память, принимать в расчет конфигурацию NUMA хостов, где будет работать данная машина. Так же следует выбирать правильный дисковый контроллер для виртуальной машины, а также наиболее «современный» из доступных сетевых адаптеров.

Начнём с того, что есть два типа свапинга, которые могут происходить на ESXi хосте. Их очень часто путают, поэтому давайте условно будем называть их Тип 1 и Тип 2.

Расположение данных VMware ESXi по умолчанию

Тип 1. VMX swapping (vSwap)

Это самый простой тип свапинга для описания. Память выделяется не только для виртуальных машин, а также и для различных компонент хоста, к примеру, для монитора виртуальных машин (VMM) и виртуальных устройств. Такая память может быть свапирована для того, чтобы выделить более нуждающимся виртуальным машинам больше физической памяти. По словам VMware эта возможность может высвободить от 50MB до 10MB памяти, для каждой виртуальной машины без существенного ухудшения производительности.

Тип 2. Guest OS Swapping

ESXi Host swapping

vSwap (Тип 1) по умолчанию сохраняется в .vswp файл в папке с виртуальной машиной. NetApp рекомендует сохранять vSwap (Тип 1) на выделенный датастор.

Такой файл существует только для запущенных виртуальных машин – при запуске гипервизор создаёт этот файл и удаляет при выключении виртуальной машины. Обратите внимание на размер этого файла — он равен разнице между сконфигурированной памятью для виртуальной машины и резервом физической памяти за этой машиной. Таким образом обеспечивается наличие заданного пространства памяти, когда виртуальная машина стартует (не зависимо от того, какая память используется — настоящая физическая или vSwap). Резерв заботится о том, чтобы виртуальная машина получила нужное пространство всегда в физической памяти хоста. А разница между резервом и настроенной памятью виртуальной машины сохраняется в vswp файл.

Ниже пример запуска виртуальной машины с 4GB памяти и резервом 2GB. Помните, что vSwap удаляется после выключения? А если в этот момент датастор хранящий эту виртуальную машину заполнится и останется свободного 1.8GB пространства, что произойдёт?

Что можно с этим сделать? Конечно же можно высвободить пространство на датасторе или расположить vSwap (Тип 1) на другом датасторе. По умолчанию он хранится в папке с виртуальной пашиной. Если это «standalone» хост: Configuration > Software > Virtual Machine Swapfile Location. Расположение vSwap файлов также можно изменить на уровне настроек каждой виртуальной машины. Откройте настройки виртуальной машины и выберите вкладку Options:

Если этот хост часть кластера, загляните в настройки кластера Store the swapfile in the datastore specified by the host

Далее выберите датастор где будет храниться vSwap (Тип 1).

Зачем располагать свап на отдельный датастор?

Рекомендуемая схема расположения Swap'а для NetApp FAS

Во-первых стоит отметить что общее правило VMware гласит по возможности располагать vSwap (Тип 1) в папке с виртуальной машиной, так как вынесение на отдельный датастор может замедлить vMotion. Но в частном случае VMware + NetApp FAS вступает другая рекомендация. NetApp рекомендует хранить vSwap (Тип 1) на отдельном выделенном, одном для всех виртуальных машин датасторе, так как в этом случае разница при миграции vMotion практически нивелирована. VMware рекомендует, чтобы пространство под vSwap (Тип 1) было больше или равно разнице сконфигурированной и зарезервированной для виртуальной машины памяти. Иначе виртуальные машины могут не стартовать. Пример: у нас есть 5 виртуальных машин с размером памяти 4GB и резервацией для каждой 3GB.

Минимальный размер датастора для vSwap Тип 1:
5VM * (4 GB — 3GB )= 5GB

Если на хосте нет свободных физических 5VM * 3GB = 15 GB памяти, машины могут не стартовать, выводя ошибку:
The host does not have sufficient memory resources to satisfy the reservation

И в то же время будет создан Event log

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

В-третьих это снепшоты и дедубликация на уровне хранилища. Так как у нетапа снепшоты не влияют на производительность, они являются нормой жизни, выполняются постоянно и являются частью парадигмы резервного копирования NetApp для систем FAS. Свап это абсолютно бесполезная информация при резервном копировании и восстановлении. Если он интенсивно используется, а снепшоты часто снимаются, в снепшотах будет «захвачена» и храниться, все время жизни снепшота, эта бесполезная информация. А так как свап постоянно меняется, а спепшот захватывает только новые изменённые данные, в каждом таком снепшоте будет храниться эти новые изменённые данные из свапа, беспощадно поедая полезное пространство под бесполезные данные на хранилище. Дедублицировать свап нет никакого резона, ведь данные в свапе не нужны при восстановлении и никогда не будут считаны. В этом смысле удобно выносить свапы на отдельный датастор. NetApp рекомендует располагать свап на отдельный датастор с выключенными снепшотами и дедубликацией, так мы можем ещё сильнее уменьшить оверхед в снепшотах и на репликации.

NetApp не рекомендует использовать локальные диски (стр 76-78, DEC11) на хосте, для хранения vSwap (Тип 1) потому, что такая конфигурация имеет негативное влияние на скорость выполнения операции vMotion.

Стоит ли выносить Тип 2 Swap?

Размещение временных данных, таких как Swap и Pagefile.sys на выделенный датастор (создав выделенный виртуальный диск для этой цели) позволяет не дедублицировать и не бэкапировать эти данные также как и vSwap (Тип 1). Очень важно не забыть указать этот диск как Independent, чтобы агент VSC не заставлял FAS снимать снепшоты с раздела хранящего Swap файлы (Тип 2).

У NetApp нет рекомендаций относительно Swap Тип 2, вынесение этих данных является опциональным дизайном, у которого есть свои плюсы и минусы:

В дополнение к вынесенному vSwap Тип 1, вынесение Swap Тип 2 ещё сильнее уменьшит оверхед на снепшотах, и как следствие увеличит пропускную способность для репликации. В ACB для DR решений наличие Swap'а (оба типа) не нисет никакой смысловой нагрузки, ведь он не используется при старте системы. Если мы перестанем хранить Swap (Тип 2) в снепшотах и резервных копиях, при локальном восстановлении это не должно вызывать каких-либо проблем, так как восстанавливаемый .vmx config файл будет содержать ссылку на VMDK файл хранящий раздел со Swap'ом, ведь тот будет находиться на том же месте. Но это добавит дополнительные шаги при восстановлении на удалённой площадке, в таких конфигурациях как SRM , SnapProtect и других DR решений.

Опциональная схема расположения данных на NetApp FAS

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

Raspberry Pi 4 Model B 4GB RAM;
источник питания Qualcomm GA-QC810;
кабель USB A to USB type C;
карта MicroSD 16GB;
адаптер MicroSD to USB;
USB флешка 32GB;
USB флешка 16GB;
кабель HDMI-mini to HDMI;
комплект клавиатура+мышь с беспроводным адаптером;
ноутбук с Ubuntu 20.04;
кабель RJ-45;
монитор.

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

Обратите внимание, что на момент написания статьи VMWare ESXi не поддерживает модуль Wi-Fi, для подключения к сети используется только проводной интерфейс.

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

Обновление EEPROM

Первым делом обновите EEPROM «малинки». Эта процедура выполняется в Raspberry PI OS. Эта ОС должна быть предустановлена на Raspberry PI, но, если вы уже устанавливали другую ОС, это не проблема.

Скачиваем Raspberry Pi Imager с официального сайта. Для Ubuntu программа распространяется в виде deb-пакета. Далее в терминале переходим в каталог со скачанным пакетом и устанавливаем его:

Могут возникнуть ошибки, связанные с неразрешенными зависимостями. Необходимые зависимости устанавливаются с помощью команды apt:

Если зависимости и Imager успешно установились, можно приступать к установке Raspberry Pi OS.

Окно Raspberry Pi Imager v1.4 с выбранными ОС и накопителем
Подключаем MicroSD-карту к ноутбуку и запускаем утилиту. В качестве ОС выбираем Raspberry Pi OS (32-bit), а в качестве SD Card — подключенную MicroSD-карту. Убедитесь, что выбрали правильное устройство, так как нажатие кнопки «write» сотрет все данные на устройстве и запишет туда файлы выбранной ОС.

Запись Raspberry Pi OS на MicroSD-карту
После завершения записи утилита дополнительно проверит корректность записанных данных. Если все хорошо, то устанавливаем MicroSD-карту в Raspberry Pi и запускаем. После загрузки ОС нас приветствует первоначальная настройка ОС. Отвечаем на ее вопросы и ближе к концу соглашаемся обновить ПО.

Обновлений EEPROM не найдено
После обновления ПО можно приступать к обновлению EEPROM. Сначала проверим наличие обновлений:

У нас установлена актуальная версия, поэтому необходимости выполнять обновление нет. Однако если версия CURRENT все же отличается от LATEST, то обновляемся:

Теперь, когда EEPROM обновлен, приступаем к установке образа UEFI.

Установка UEFI

Карточку необходимо отформатировать в FAT32 и примонтировать в удобное место:

Обратите внимание, что мы создаем файловую систему прямо на накопителе без использования таблицы разделов. Далее скачиваем и распаковываем архив с содержимым репозитория raspberrypi/firmware.

В репозитории нас интересует содержимое каталога boot, кроме файлов с расширением .img, которые представляют собой образы с ядром ОС Linux. Избавляемся от img-файлов и копируем содержимое каталога на MicroSD-карту:

Так как это оригинальные файлы прошивки, в них нет UEFI. Скачиваем модули с UEFI отдельно на странице релизов:

Если вы используете Raspberry Pi с 4 ГБ оперативной памяти, то в config.txt необходимо добавить строчку gpu_mem=16:

После этого добавляем файлы на MicroSD-карту:

Далее отмонтируем карту, устанавливаем ее в Raspberry Pi и запускаем.

Экран выбора загрузки
Если все сделано корректно, то UEFI быстро загрузится и «малинка» предложит зайти в настройки или продолжить загружаться.

UEFI Setup Utility на Raspberry Pi
Заходим в Setup и видим достаточно привычную для серверов картину. Однако глаз «цепляется» за строку «3072 MB RAM». Объяснение этому достаточно простое. По умолчанию оперативная память ограничивается до 3 ГБ для совместимости с другими ОС.

Отключение искусственного ограничения оперативной памяти
Так как нам нужна вся доступная на «малинке» оперативная память, то находим пункт Limit RAM to 3 GB по пути Device Manager — Raspberry PI Configuration — Advanced Configuration и устанавливаем в Disabled. После этого сохраняем настройки нажатием клавиши F10 и выходим из Setup Utility. Для применения настроек необходимо выполнить перезагрузку, о чем нас и попросят. Соглашаемся на перезагрузку, и наш Raspberry Pi готов к установке гипервизора.

Подготовка установочной флешки

Заходим на страничку ESXi Arm Edition, выбираем ESXi-Arm-ISO, соглашаемся с лицензией Technical Preview и принимаем факт, что Flings — это экспериментальное ПО и его стоит использовать только для тестовых целей.

Подключаем в Raspberry Pi флешку с образом и чистую флешку, которая будет выполнять роль системного диска, и включаем «малинку».

Назначение порядка загрузки
По умолчанию порядок загрузки UEFI начинается с попыток загрузиться по сети. Так как мы работаем с флешками, то заходим в Setup Utility и меняем порядок в следующем пункте настроек: Boot Maintenance Manager — Boot Options — Change Boot Order — Change the order. Записи меняют приоритет по нажатию кнопок ±. Устанавливаем флешки первыми.

После установки приоритета необходимо нажать Enter для сохранения нового порядка, а затем сохранить изменения в конфигурации с помощью F10. Перезагружаем Raspberry Pi и наконец попадаем в установщик VMware ESXi.

Установка VMware ESXi

Дополнительные параметры для установщика
Ранее мы говорили, что предпочтительным способом общения с установщиком является использование монитора и клавиатуры, а не консоли. Эта рекомендация имеет наибольшую силу во время начала установки. При использовании клавиатуры можно нажать Shift + O и задать параметры для установщика, в то время как в консольном режиме это невозможно.

Мы как раз воспользуемся этим для ограничения раздела VMFS-L до 1 ГБ. Нажимаем Shift + O и прописываем autoPartitionOSDataSize=1024. Так у нас останется место на Datastore для виртуальных машин. К сожалению, нам не удалось заставить ESXi видеть другие USB-накопители и iSCSI-устройства, поэтому ограничение раздела VMFS-L — это пока единственный способ выделить место для хранилища ВМ.

Отвечаем на вопросы установщика, и спустя 10 минут VMware ESXi установлена. Обратим внимание, что установщик не задает вопросы про сетевые интерфейсы. Проводной интерфейс настроен получать адрес по DHCP, а беспроводной игнорируется системой.

Главная страница веб-интерфейса VMware ESXi
Если установка прошла успешно, то перезагружаем Raspberry Pi, извлекаем установочную флешку и дожидаемся загрузки гипервизора. Операционная система попытается получить адрес по DHCP на проводном интерфейсе, и если ей это удастся, то этап установки завершен.

Запуск виртуальной машины

Во время установки гипервизора мы ограничили размер VMFS-L раздела до 1 ГБ, что позволило оставить 20 ГБ под datastore — место, где виртуальные машины хранят свои данные. Мы бы очень хотели воспользоваться возможностью загрузки готовых OVA-образов, но, к сожалению, под архитектуру ARM64 такие образы не находятся.

При создании виртуальной машины нужно уделить особое внимание количеству оперативной памяти и размеру диска гостевой ОС. Во-первых, диск гостевой ОС должен быть от 16 ГБ, чтобы установщику было где развернуться. Во-вторых, количество свободного места на VMFS-разделе должно превышать количество выделенной оперативной памяти для ВМ.

Таким образом, при наличии 20 ГБ свободного места на VMFS получилось создать виртуальную машину с 2 ГБ оперативной памяти и 18 ГБ постоянной памяти. При нарушении этого условия виртуальная машина откажется запускаться, и одной из причин будет No space left on device.

Гостевая Debian 10 Buster и характеристики виртуальной машины
После множества попыток нам удалось установить Debian 10 на виртуальной машине в следующей конфигурации:

2 vCPU;
1 ГБ RAM;
17 ГБ диск.

один раздел для всего на 17 ГБ;
не использовать swap;
из компонентов на выбор поставить только SSH Server.

Заключение

Мы добились желаемого и не просто поставили гипервизор на Raspberry Pi, но и установили гостевую ОС, которая корректно работает. Хочется отметить, что запуск VMware ESXi на «малинке» был увлекательной и местами нетривиальной задачей.

Несмотря на малую вычислительную мощность Raspberry Pi, вероятно в будущем, ее можно применить в качестве бюджетного хоста-свидетеля (witness) для программно-определяемого хранилища VMware vSAN.

Вторая часть моего осмысления гайда от VMware рассказывает о моментах, связанных с центральным процессором. Затрагиваются такие важные темы как Hyper-Threading, NUMA и Power Management.

ESXi General Considerations

Основные моменты, касающиеся гипервизоров:

При планировании ресурсов на гипервизоре, необходимо так же учитывать нужды самого ESXi;
Выделять виртуальным машинам столько ресурсов, сколько они требуют. Выделение большего, чем требуется, количества ресурсов иногда может снизить производительность машины, нежели увеличить. Так же это может сказаться на машинах, которые располагаются на том же хосте;
Отключить неиспользуемое физическое оборудование. Сетевые порты, USB контроллеры, CD/DVD и т.п. Подобное оборудование может потреблять ресурсы CPU, некоторые PCI устройства могут потреблять так же ОЗУ;
Неиспользуемое виртуальное оборудование в VM стоит так же отключить. Это может влиять на производительность;
Рекомендуется использовать версию виртуального оборудования vHardware, которая поддерживается всеми хостами в кластере. Например, машина с версией оборудования 17 сможет запускаться только на хостах с vSphere 7.0.

ESXi CPU Considerations

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

Производительность большинства систем будет сравнима с работой системы на «голом железе». Для малого процента рабочих нагрузок, сильно зависящих непосредственно от CPU, может быть замечена деградация в производительности.

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

Хорошая практика – периодически наблюдать за загрузкой CPU:

В случае, если load average в esxtop больше 1 – система нагружена;
В целом, загрузка процессора на хосте в районе 80% является разумным пределом. Загрузка CPU на 90% соответствует серьезной перегрузке.

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

Самый простой пример – однопотоковое приложение, работающее на многопроцессорной системе.

Даже если гостевая ОС не использует все доступные ей процессоры, некоторые процессорные инструкции выполняются даже на незадействованных ядрах, создавая нагрузку на хост.

Hyper-Threading

Hyper-Threading, который так же называют SMT (simultaneous multithreading) позволяет представлять процессорное ядро, как два логических процессора, позволяющих запускать два независимых потока на одном физическом ядре одновременно.

Количество процессорных ядер в консоли vSphere будет удвоено. CPU 0 и 1 будут относиться к первому физическому ядру, 2 и 3 ко второму и так далее.

Hyper-Threading не удваивает производительность, но добавляет ее небольшой, а иногда и ощутимый прирост.

Включить использование HT можно в настройках BIOS (он должен поддерживать данную технологию). Обычно, включен по-умолчанию.

При использовании CPU Affinity (привязка vCPU виртуальной машины к ядрам процессора), не стоит привязывать машину\машины к двум логическим ядрам одного физического ядра. Например, привязать машину к ядрам 0 и 1, которые в итоге будут являться одним физическим ядром. Это может негативно сказаться на производительности.

NUMA, или же Non-Uniform Memory Access — «неравномерный доступ к памяти», одна из первых вещей, которую стоит учитывать при определении ресурсов виртуальной машины.

Скорость доступа к «своей» памяти выше, чем к памяти «удаленной», поэтому в NUMA-системах стоит учитывать этот момент для минимизации доступа к удаленной памяти без необходимости.

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

NUMA нода (не всегда, но в большинстве случаев) – один физический процессор и его локальная оперативная память.

Более подробно я бы рекомендовал прочесть про NUMA в книге Host Resources Deep Dive.

Как уже было сказано в прошлой части, за работу NUMA в BIOS отвечает параметр Node Interleaving. Значение Disabled для данного параметра включает NUMA, соответственно ESXi начинает определять локальную и удаленную память для каждого процессора. Если параметр включен, система работает в режиме UMA, разделения на локальную и удаленную память не производится.

Виртуальные машины могут быть поделены на две категории:

Виртуальная машина, количество vCPU которой равно, либо меньше, количества физических ядер одной NUMA ноды;
Виртуальная машина, количество vCPU которой больше, чем есть в одной NUMA ноде. Такие машины называются Wide VM.

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

Однако, у машин, которым важна пропускная способность ОЗУ, производительность, при нахождении в нескольких NUMA нодах, может быть выше. Для этого можно использовать параметр maxPerMachineNode, который определяет количество vCPU, при достижении которого будет включаться технологии vNUMA (об этом будет далее).

При использовании Hyper-Threading, виртуальная машина с количеством vCPU большим, чем количество физических ядер в процессоре, но меньшим, чем количество логических процессоров в одной NUMA ноде (количество физических ядер * 2), может получить преимущества NUMA, при включенном флаге numa.vcpu.preferHT в конфигурационном файле VM. В таком случае, виртуальная машина будет исполняться (по крайней мере стараться) в рамках одного физического процессора, за счет логических ядер HT.

Например, у нас имеется сервер с двумя процессорами по 4 ядра. Соответственно, при включении HT у нас будет доступно 8 логических ядер на каждом из CPU. При использовании параметра preferHT, и количестве vCPU 6, машина будет выполняться на одном процессоре, а не на двух, попадая при этом в рамки NUMA узла. Стоит понимать, что при этом машина не получит производительность полноценных 6 ядер.

Добавлю от себя, что в большинстве случаев нужно стараться не выходить за рамки NUMA узла (как по количество vCPU, так и по количеству оперативной памяти), чтобы получить наилучшую производительность для виртуальной машины.

Snoop Mode Selection

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

Существует 5 методов:

Early Snoop (ES);
Home Snoop (HS);
Home snoop with Directory and Opportunistic Snoop Broadcast (HS with DIS + OSB);
Cluster-on-Die (COD);
Sub-NUMA cluster (SNC).

Cluster-on-Die позволяет логически разбить процессор на несколько NUMA узлов, каждый из которых состоит из нескольких ядер данного CPU.

Sub-NUMA cluster похож на COD, с отличиями в использовании LLC (last level cache, кэш 3-го уровня).

AMD EPYC Processor NUMA Settings

Настоятельно рекомендую ознакомиться с архитектурой процессоров AMD EPYC.

Во втором поколении процессоров AMD EPYC появились некоторые и обновленные настройки BIOS:

NUMANodesperSocket(NPS) – позволяет презентовать двухсокентную систему как одну NUMA ноду (NPS0), презентовать каждый CPU как NUMA ноду (NPS1), представлять каждый CPU как две NUMA ноды (NPS2), а так же как четыре ноды (NPS4);
CCX(CoreCacheComplex)asNUMADomain – Если включен, представлять каждый CCX как NUMA домен, если выключен, представлять весь CPU как NPS.

Persistent Memory (PMem) in NUMA Systems

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

Host Power Management in ESXi

ESXi поддерживает следующие политики для Power Management:

High performance – не использует никакие технологии энергосбережения. Обеспечивает максимальную производительность для систем, при полной утилизации процессорных ресурсов;
Balanced – политика по умолчанию. Уменьшает потребление энергии процессором с минимальным, либо вообще отсутствующим влиянием на производительность;
Low power – Большее сохранение электроэнергии, но и большее влияние на производительность;
Custom – Настраиваемая политика.

Используемая по умолчанию политика Balanced в большинстве случаев не оказывает влияния на производительность высокоинтенсивных приложений и систем. Но, как уже говорилось ранее, она может оказать влияние на работоспособность чувствительных к задержкам приложений. В данном случае рекомендуется использовать политику «High Performance», обеспечивающую максимальную производительность без включения техник энергосбережения.

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

Читайте также: