Короткий ответ

«VM медленная» — это три разных контура: CPU (в том числе steal при overcommit на pve1), диск (гость vs хостовый iowait), сеть (vmbr0, модель NIC, firewall). Снимите метрики в госте и на хосте до добавления vCPU. Steal лечится не «ещё 8 ядер этой VM», а снижением переподписки или миграцией.

Не путайте с зависшим qemu: если консоль мертва — остановка.

Симптомы и как отличить

Типичная картина:

  • пользователи: «1С/RDP тормозит»;
  • в Linux-госте top поле st;
  • Windows: CPU 10%, диск 100% в Task Manager;
  • или CPU 100% без steal — приложение.

Отличия:

Что видноКуда
На хосте %wa высокийIO wait
df 100%Диск заполнен
Пакеты теряются, TCP ретрансмитыСеть VM
После migrate стало лучшеCPU type/нагрузка узла

Возможные причины

  1. Overcommit CPU: много vCPU × VM на мало pCPU, steal.
  2. Хостовый диск/thin/NFS, гости все медленные.
  3. В госте e1000/rtl вместо virtio, software checksum.
  4. Balloon вытолкнул память, гость в paging.
  5. NUMA: VM больше сокета без numa: 1.
  6. Антивирус/индексация/один процесс в госте — вообще не гипервизор.

Диагностика

Хост pve1:

pveversion
qm status 101 --verbose
qm config 101
top -b -n 1 | head
iostat -x 1 3

Смотрите cpu:, cores, memory, balloon, net0 (virtio или нет), scsi0 (virtio-scsi vs ide).

В Linux-госте:

top
vmstat 1 5
iostat -x 1 3
ip -s link

Поле st в top — steal. В Windows: PerfMon \Hyper-V Hypervisor Virtual Processor(*)\% Guest Run Time недоступен как на Hyper-V; ориентир — Latency диска и сравнение с хостовым iostat. Agent:

qm agent 101 ping

Решение

Сценарий A. Steal высокий

Снизьте vCPU у слонов, разнесите VM по узлам, включите CPU affinity только если понимаете NUMA. Добавление ядер этой VM при полном хосте увеличивает steal. Миграция 101 на свободный узел — быстрый тест.

Сценарий B. Диск

Если хостовый wait высокий — статья IO wait. Если хост тихий, а в госте диск 100% — процесс внутри, фрагментация NTFS, нет virtio-scsi, тонкий диск на заполненном пуле. Модель диска: scsihw: virtio-scsi-single предпочтительнее IDE. Не переключайте шину вслепую без снимка/backup: может не найти boot.

Сценарий C. Сеть

net0: virtio=...,bridge=vmbr0. e1000 оставьте только для установщиков без драйвера. Проверьте firewall=1 на NIC и правила, не «firewall off навсегда». Дуплекс/offload — после доказательства ретрансмитов.

Сценарий D. Память

Выключите агрессивный balloon на SQL/файловых серверах или зафиксируйте min_memory. Смотрите paging в госте. Не давайте VM 64 ГБ при 32 ГБ на хосте «потому что balloon».

Сценарий E. CPU type

Для одной машины на современном узле host быстрее. Для кластера — общий тип (x86-64-v2-AES в PVE 8). Смена типа требует выключения VM, не live.

Как мерить честно и не лечить диск добавлением vCPU

Синтетика sysbench cpu в госте при высоком steal покажет «медленный CPU», хотя виноват планировщик хоста. Смотрите одновременно top на pve1 (%st нет на хосте в том же смысле) и load, сколько kvm runnable.

qm config 101 | grep -E 'cores|sockets|cpu:|affinity|balloon|memory|scsihw|net0'
cat /proc/pressure/io 2>/dev/null
cat /proc/pressure/cpu 2>/dev/null

PSI (/proc/pressure) на хосте PVE 8 (ядро 6.x) показывает, есть ли stall CPU/IO. some avg300 по io при тихом %wa в одном семпле top — очередь была, вы не попали в пик.

В госте Windows «CPU 100%» одного MsMpEng — не virtio. «Disk 100%» при хостовом await 2 ms — фрагментация/индексация/pagefile на том же scsi0, что ОС. Вынос pagefile/SQL data на второй виртуальный диск иногда полезнее, чем +vCPU.

Смена scsihw и модели NIC требует драйверов в госте и часто reboot VM. Делайте в окне, с backup, не в пятницу на 1С.

Как проверить, что проблема устранена

Повторите тот же бенчмарк, что был медленным (не синтетику в вакууме): время отчёта, копирование файла, RDP. В госте st близок к 0 в простое. Хостовый iostat не в потолке. qm config 101 фиксирует осознанную модель NIC/диска. После ребута гостя эффект держится.

Сверьте qm config 101 на предмет ide0/sata для системного диска: на механике и даже на SSD это даёт лишние прерывания по сравнению с virtio-scsi. Менять шину — окно и backup, не живой эксперимент на 1С. Параллельно посмотрите, не включён ли в госте софтовый RAID/BitLocker на виртуальном диске без нужды: для гипервизора это двойная запись.

Если не помогло

  • Только один сервис медленный: приложение/БД, не PVE.
  • Nested virt: вложенный гипервизор почти всегда медленнее.
  • GPU/USB passthrough: IOMMU latency, смотрите отдельно.
  • Время в госте скачет: chrony/w32tm, не CPU.
  • После апдейта PVE регресс: сравните pveversion -v и changelog, не откатывайте ядро без проверки.

Профилактика

  • Не раздавать vCPU «по числу лицензий SQL» всем подряд на одном узле.
  • virtio-scsi + virtio-net в шаблонах.
  • Мониторинг steal, balloon, latency диска гостя.
  • CPU type единый в кластере.
  • Окна backup не в рабочий пик 1С.

FAQ

Нужно ли всегда включать NUMA?

Если VM не больше одного сокета и мало RAM — часто нет. Если RAM/ядра пересекают сокет — смотрите numa: 1 и топологию.

kvm64 медленнее x86-64-v2-AES?

Да, старый совместимый тип. PVE 8 по умолчанию уже не kvm64. Не возвращайтесь к kvm64 «для миграции на очень старый узел» без нужды.

Почему 8 vCPU медленнее 2?

Лицензии, парковка ядер Windows, overcommit, lock contention. Измерьте, не масштабируйте вслепую.

Balloon «освобождает RAM хосту» — включать всем?

Не на нагрузке, чувствительной к paging. Хосту лучше не overcommit RAM.

Гость Windows без qemu-guest-agent — это причина тормозов?

Не напрямую. Без агента хуже freeze для backup и IP в GUI. На latency CPU это не главный рычаг.