Хост-машина в виртуализации: железо, технологии и оптимизация производительности

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

Вы поставили гипервизор, создали десяток виртуальных машин, раздали доступы - и первую неделю всё летает. Через месяц начинается: VM подвисают, IOPS просели, а мониторинг рисует красные графики на дашборде. Знакомо? В большинстве случаев причина не в софте, а в том, что железо для виртуализации подбирали по принципу «и так сойдёт».

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

Зачем нужна аппаратная виртуализация

До появления аппаратного ускорения гипервизоры эмулировали процессорные инструкции программно. Это работало, но с двукратным (а то и пятикратным) падением производительности. Потом Intel выпустили VT-x, AMD ответили AMD-V - и правила изменились. Аппаратная виртуализация позволяет гипервизору выполнять код гостевых ОС напрямую на процессоре, без промежуточной трансляции.

Результат - производительность виртуальных машин достигает 85-95% от bare metal. В отдельных случаях на кэш-friendly веб-нагрузках бенчмарки показывают даже больше 100% - за счёт оптимизаций планировщика и кэширования на уровне гипервизора, но это редкое исключение, а не общее правило: рассчитывать стоит на честные 85-95%.

Для Type-1 гипервизоров (ESXi, Proxmox VE, Hyper-V Server) аппаратное ускорение - обязательное требование. Без VT-x/AMD-V вы ограничены софтверной эмуляцией, а это потолок в 2-3 VM на хост с приемлемой латентностью. Type-2 гипервизоры (VirtualBox, VMware Workstation) работают поверх обычной ОС - для тестовых стендов сгодятся, для продакшена нет.

Разница принципиальная: Type-1 получает прямой доступ к железу через VT-x/AMD-V и управляет им без посредников. Type-2 зависит от хостовой ОС - каждый системный вызов проходит через дополнительный слой, и этот слой стоит производительности. Поэтому, когда речь идёт о хосте для 8-15 виртуальных машин в продакшене, выбор гипервизора очевиден - «голый металл» и Type-1.

Отдельная тема - nested virtualization, запуск гипервизора внутри VM. Полезно для обучения, тестирования и CI/CD-пайплайнов. Работает на Intel (VT-x + VMCS shadowing) и AMD (NPT), но с ощутимым падением производительности - 20-40% overhead. Для продакшен-нагрузок вложенная виртуализация не подходит, но для dev-окружений экономит железо.

Процессор: ядра, потоки, nested paging

Выбор CPU для хоста - это не гонка за гигагерцами. Тут три параметра, которые решают всё.

Поддержка VT-x/AMD-V и EPT/NPT. Nested paging (EPT у Intel, NPT у AMD) - технология аппаратной трансляции адресов между гостевой и хостовой памятью. Без неё гипервизор тратит циклы на программный перевод адресов (shadow page tables), и overhead растёт с каждой VM. Ранние серверные Xeon плохо справлялись с этой задачей, но начиная с поколения Nehalem (Intel) и Opteron (AMD) ситуация выровнялась - сегодня EPT/NPT есть в любом серверном процессоре.

Количество ядер и Hyper-Threading. Каждая VM получает виртуальные ядра (vCPU), которые шедулер гипервизора маппит на физические. Hyper-Threading даёт прирост 15-30% на многопоточных нагрузках, но один HT-поток - это не полноценное ядро. Для хоста с 8-15 VM подходят процессоры от 16 физических ядер (Intel Xeon Scalable, AMD EPYC).

Выделение ядер хосту. Гипервизор тоже потребляет ресурсы. Proxmox и ESXi рекомендуют резервировать 1-2 ядра для хостовых процессов. Если отдать всё гостям, сам гипервизор начнёт «заикаться» при пиковых нагрузках.

Частая ошибка - overprovisioning vCPU. Администратор назначает каждой VM по 4-8 vCPU «с запасом», суммарно получается 60 vCPU на хосте с 32 физическими потоками. Шедулер вынужден ждать, пока все vCPU одной VM станут доступны одновременно - и латентность растёт у всех. Правило простое: суммарное количество vCPU не должно превышать физические потоки больше чем в 1,5-2 раза. Для баз данных и нагрузок с высоким CPU utilization - соотношение 1:1.

Ещё один нюанс - NUMA (Non-Uniform Memory Access). Если хост собран на двухсокетной платформе, каждый процессор имеет свой «ближний» банк памяти. VM, чьи vCPU размазаны по двум NUMA-нодам, получают штраф за доступ к удалённой памяти - до 20% деградации. Гипервизоры умеют привязывать VM к конкретной NUMA-ноде (CPU pinning, NUMA affinity), и для тяжёлых VM это стоит настроить вручную.

Оперативная память: ECC, балунинг и дедупликация

RAM для виртуализации - это всегда «мало». Каждая VM съедает свой кусок, плюс гипервизор, плюс кэши, плюс резерв под снапшоты. Скупиться здесь - путь к свопу, а своп в виртуализации - это деградация для всех гостей сразу.

Минимальная планка для серьёзного хоста - 32 ГБ. Для Proxmox VE 2 ГБ зарезервированы под сам гипервизор, плюс примерно 1 ГБ на каждый терабайт ZFS-хранилища (ARC-кэш, без которого ZFS теряет смысл). В реальной эксплуатации хост с 4 ТБ ZFS-пула и десятком VM требует 64-128 ГБ. То есть хост с 10 ТБ ZFS-пулом «съест» 12+ ГБ только на гипервизор и кэш - это надо закладывать заранее.

ECC-память - не опция, а требование. Некорректированная ошибка в RAM может повредить данные сразу нескольким VM. В серверном сегменте ECC - стандарт, но если собираете хост на десктопной платформе (да, такое бывает), убедитесь, что контроллер памяти поддерживает ECC. Подробнее про типы серверной памяти - в разборе серверной оперативной памяти.

Технологии оптимизации памяти в виртуализации:

С любым из трёх механизмов суммарная «выделенная» память всех VM может превышать физическую RAM хоста. Это overcommit - рабочая стратегия, если вы понимаете паттерны нагрузки своих VM.

Хранилище: bottleneck, о котором забывают

Дисковая подсистема - узкое место виртуализации чаще, чем CPU или RAM. Десять VM, каждая пишет логи, обновляет базы, делает fsync - и вот IOPS закончились.

SSD/NVMe - стандарт для хоста. HDD допустимы только для холодного архива. NVMe-накопители с интерфейсом PCIe 4.0/5.0 дают 500 000-1 000 000+ IOPS на случайное чтение - это на два порядка выше, чем у SATA SSD (50 000-100 000 IOPS). Если бюджет позволяет, берите enterprise-накопители с защитой от потери питания (PLP - Power Loss Protection). Десктопные NVMe в серверном сценарии деградируют быстрее из-за постоянной записи.

Отдельный момент - размещение хранилища. Локальные диски проще и быстрее, но привязывают VM к конкретному хосту. Для кластера с live-миграцией нужно общее хранилище: SAN по iSCSI/FC, NFS-шара или распределённое хранилище типа Ceph. Каждый вариант - компромисс между скоростью, отказоустойчивостью и сложностью администрирования. Как это устроено в кластере, разобрано в статье про сборку отказоустойчивого кластера.

Выбор отказоустойчивости зависит от гипервизора и задач:

VirtIO SCSI - паравиртуализированный контроллер, который убирает эмуляцию IDE/AHCI и даёт VM почти нативный доступ к дискам. Включайте его для всех гостей с поддержкой VirtIO-драйверов (Linux из коробки, Windows - через ISO с драйверами от Red Hat).

Для борьбы с «шумными соседями» настраивайте лимиты IOPS и throughput на уровне гипервизора. В Proxmox это делается через параметры диска VM (mbps_rd, mbps_wr, iops_rd, iops_wr).

Сеть: два интерфейса - минимум

Одна сетевая карта на хосте - рецепт проблем. Управляющий трафик (SSH, веб-консоль), трафик VM и трафик хранилища (iSCSI, NFS, Ceph) конкурируют за один канал.

Рекомендация - два NIC и выше. Один для управления и трафика VM, второй - выделенный линк для хранилища. Proxmox VE прямо в документации указывает: 2+ сетевых интерфейса для разделения трафика.

Для СХД с сетевым доступом (iSCSI, NFS) 10GbE - уже не роскошь, а рабочая необходимость. Гигабитный линк даёт потолок ~120 МБ/с - этого мало для 10 VM с активным I/O. RDMA (Remote Direct Memory Access) на InfiniBand или RoCE снимает нагрузку с CPU при сетевых операциях, но требует соответствующих коммутаторов и адаптеров.

VLAN-ы и Linux bridges изолируют трафик разных VM и сегментов сети без физического разделения. На хосте с 15 VM из трёх разных подсетей VLAN - единственный адекватный способ не превращать сетевую конфигурацию в хаос.

Про безопасность: файрвол на уровне хоста - не роскошь. Proxmox предлагает встроенный pve-firewall с правилами для отдельных VM и кластера целиком. ESXi - distributed firewall в составе NSX. Минимальная гигиена - закрыть управляющие интерфейсы от гостевых сетей и ограничить доступ к API гипервизора по IP. Если злоумышленник получит доступ к хосту - он получит доступ ко всем VM разом.

Мониторинг, HA и live-миграция

Запустить VM - полдела. Удержать инфраструктуру в рабочем состоянии при отказе ноды - задача поинтереснее.

DRS (Distributed Resource Scheduler) в VMware vSphere автоматически балансирует VM между хостами кластера. Если одна нода загружена на 90%, а соседняя на 30%, DRS мигрирует VM без участия администратора. Аналоги в Proxmox - HA-менеджер с ручными правилами и приоритетами.

Live-миграция (vMotion у VMware, qm migrate в Proxmox) - перенос работающей VM на другой хост без остановки. Работает за счёт итеративного копирования памяти: сначала передаётся основной объём, потом «грязные» страницы, изменившиеся за время копирования. Условие - общее хранилище (shared storage) или репликация дисков между хостами. Для миграции между хостами с разными поколениями CPU используется EVC (Enhanced vMotion Compatibility), которая маскирует наборы инструкций до общего знаменателя.

Снапшоты - быстрый способ зафиксировать состояние VM перед обновлением или экспериментом. Не замена полноценному бэкапу (снапшот хранится на том же хранилище, что и VM), но спасает от неудачного apt upgrade. У снапшотов есть подводный камень: каждый активный снапшот создаёт дельта-файл, и I/O на запись проходит через цепочку таких дельт. Чем длиннее цепочка - тем выше нагрузка на хранилище. Удаляйте ненужные снапшоты в течение суток, не накапливайте их «на всякий случай».

Пара практических рекомендаций: выставляйте power management на хосте в режим «High Performance» - энергосбережение и виртуализация плохо дружат, C-states увеличивают латентность при выходе из простоя. И настройте мониторинг: CPU ready time, memory ballooning, disk latency - три метрики, по которым вы поймёте, что хосту плохо, раньше, чем это почувствуют пользователи.

CPU ready time особенно показателен: если VM ждёт физических ядер дольше 5% времени - у вас overprovisioning по vCPU. Disk latency выше 20 мс на NVMe - сигнал, что хранилище не справляется. Memory ballooning в активной фазе (драйвер забирает память у гостя) - значит, хост исчерпал RAM и пора либо добавлять модули, либо мигрировать часть VM. Если производительность ВМ проседает, а причина неочевидна, помогает системный разбор - типовые проблемы производительности в виртуальных средах.

Инструменты: esxtop для ESXi, pvesh и rrdtool в Proxmox, Zabbix или Prometheus/Grafana для унифицированного мониторинга нескольких хостов. Отдельно стоит настроить алерты на температуру CPU и состояние RAID/ZFS - деградация массива под нагрузкой виртуализации ускоряет выход дисков из строя.

Как не промахнуться с выбором

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

Подбирайте железо для виртуализации с запасом по RAM (расширить потом проще, чем мигрировать на новый хост), с NVMe-хранилищем для основных VM и с раздельными сетевыми интерфейсами. Проверяйте поддержку IOMMU, если планируете пробрасывать устройства в VM (GPU passthrough, SR-IOV для сетевых карт). И тестируйте нагрузку до продакшена - бенчмарки fio, stress-ng, iperf3 покажут реальные пределы хоста до того, как это сделают пользователи. Полный разбор, как планировать ресурсы под виртуальные машины - CPU, RAM, хранилище - в отдельной статье.

Примерный ориентир по минимальному комплекту для хоста виртуализации на 10-15 VM:

Про гипервизор в 2026 году стоит сказать отдельно: VMware после перехода под Broadcom сменил лицензирование на подписку и в России официально недоступен, поэтому для нового хоста практичный дефолт - Proxmox VE, а при инфраструктуре на Windows - Hyper-V. Что именно поменялось у VMware - в разборе про виртуализацию на базе VMware.

Частые вопросы

Что такое хост-машина простыми словами? Это физический сервер, на котором работает гипервизор и запускаются виртуальные машины. Его процессор, память и диски делятся между гостевыми ВМ. Хост - это «железо», виртуальные машины - «жильцы».

Чем хост-машина отличается от виртуальной? Хост - реальный физический сервер с процессором, памятью и дисками. Виртуальная машина - программная «нарезка» его ресурсов, изолированная среда, которая ведёт себя как отдельный компьютер, но живёт внутри хоста.

Какое соотношение виртуальных и физических ядер допустимо? Для обычных нагрузок суммарное число vCPU не должно превышать физические потоки больше чем в 1,5-2 раза. Для баз данных и ресурсоёмких задач - держите 1:1, иначе растёт латентность у всех ВМ.

Обязательна ли ECC-память на хосте? Для продакшена - да. Ошибка в обычной памяти может повредить данные сразу нескольким ВМ. В серверных платформах ECC - стандарт.

Какой гипервизор выбрать в 2026 году? Для нового хоста в России практичный дефолт - Proxmox VE (открытый, бесплатный, с платной поддержкой по желанию); при инфраструктуре на Windows - Hyper-V. VMware после Broadcom перешёл на подписку и официально в РФ недоступен.

По теме: системные требования Proxmox · как выбрать сервер под виртуализацию · что такое виртуализация сервера · сравнение гипервизоров 2026