Управление числом vCPU и ядер в виртуальной машине

При создании виртуальных машин на различных гипервизорах (VMWare, KVM, Hyper-V и т.д.) вы можете обратить внимание, что иногда виртуальная машина может не видеть все выделенные ей виртуальные ядра (vCPU). В нашем случае виртуальной машине на KVM были выделены 8 vCPU, на нее установлена Windows 10. Однако Windows определяла эти ядра как отдельные процессоры, из которых можно использовать только 2 vCPU.

Виртуальная машина Windows 10 не видит все ядра

Если открыть диспетчер устройств Windows, можно убедится, что все выделенные ядра видны в качестве 8 отдельных виртуальных процессоров типа QEMU Virtual CPU version 2,5 .

При этом в свойствах Windows 10 (Computer -> Properties) и в Task Manage видно, что на компьютере доступны только 2 процессора QEMU Virtual CPU.

То есть сколько бы вы не добавили виртуальных ядер, Windows 10 все равно сможет использовать только два. При этом соседний виртуальный сервер с Window Server 2016 на этом же гипервизоре видит все 16 выделенных ему vCPU.

Количество поддерживаемых процессоров в Windows 10

Проблема заключается в том, что в десктопных редакциях Windows (Windows 10/8.1/7) есть ограничение на максимальное количество физических процессоров (сокетов) , которое компьютер может использовать:

• Windows 10 Home – 1 CPU
• Windows 10 Professional – 2 CPU
• Windows 10 Workstation – до 4 CPU
• Windows Server 2016 – до 64 CPU

Однако это ограничение не распространяется на ядра. Т.е. для повышения производительности вы можете использовать процессор с большим количеством ядер . Большинство гипервизоров умеют предоставлять vCPU в виде процессоров, процессорных ядер или даже потоков. Т.е. вместо 8 виртуальных CPU вы можете предоставить vCPU в виде 2 сокетов по 4 ядра в каждом. Рассмотрим, как в различных системах виртуализации выделить виртуальные процессоры в виде ядер и как это связать с архитектурой NUMA, использующейся в современных процессорах.

Управление виртуальными ядрами и vCPU в KVM

В моей виртуальной машине KVM c Windows 10 , все назначенные виртуальные ядра считаются отдельными процессорами.

Чтобы использовать все ресурсы CPU, выделенные виртуальной машине нужно, чтобы виртуальная машина видела не 8 процессоров, а один 8-ядерный процессор, 2 процессора по 4 ядра или 1 процессор с 4 ядрами по 2 потока. Попробуем изменить способ назначения виртуальных ядер для ВМ на KVM.

Выключите виртуальную машину:

# virsh shutdown server.vpn.ru – где server.vpn.ru это имя виртуальной машины.

Выведите текущую XML конфигурацию виртуальной машины KVM:

# virsh dumpxml server.vpn.ru

Нам интересен блок с описанием процессоров:

<vcpu placement='static'>8</vcpu>_x000D__x000D_<cputune>_x000D__x000D_<shares>1000</shares>_x000D__x000D_</cputune>_x000D__x000D_ <resource>_x000D__x000D_<partition>/machine</partition>_x000D__x000D_</resource>_x000D__x000D_<os>_x000D__x000D_<type arch='x86_64' machine='pc-i440fx-rhel7.6.0'>hvm</type>_x000D__x000D_<bootmenu enable='yes'/>_x000D__x000D_</os>_x000D__x000D_<features>_x000D__x000D_<acpi/>_x000D__x000D_<apic/>_x000D__x000D_<pae/>_x000D__x000D_ </features>_x000D_

Как видим, у нас указано просто 8 vCPU. Изменим конфигурацию:

# virsh edit server.vpn.ru

И после </features> добавим:

<cpu mode='host-passthrough' check='none'>_x000D__x000D_<topology sockets='1' cores='4' threads='2'/>_x000D__x000D_</cpu>_x000D_

Где:

• host-passthrough — режим эмуляции при котором на виртуальной машине будет показан физический процессор узла кластера (ноды).
• sockets='1' — указываем что процессор 1
• cores='4' — указываем, что процессор имеет 4 ядра
• threads='2' — указываем, что ядра у нас по 2 потока

Сохраните конфигурационный файл и запустите ВМ. Авторизуйтесь в гостевой ВМ с Windows 10 и в Task Manager или Resource Monitor проверьте, что ОС видит все выделенные виртуальные ядра.

Также в свойства системы теперь стал отображаться физический процессор хоста I ntel(R) Xeon(R) Silver 4114 CPU , а не виртуальный.

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

Настройка виртуальных процессоров и количества ядер в VMWare

Вы можете изменить способ презентации vCPU для виртуальной машины VMWare из интерфейса vSphere Client.

1. Выключите ВМ и откройте ее настройки;
2. Разверните секцию CPU ;
3. Изменим конфигурацию ВМ так, чтобы гостевая ОС видела 2 процессора по 4 ядра. Измените значение Cores per Socket на 4. Это означает, что гостевая ОС будет видеть два четырех –ядерных процессора (2 сокета по 4 ядра);
4. Сохраните изменения и запустите ВМ.

Архитектура NUMA и виртуальные vCPU

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

При назначении ядер на сокете учитывайте наличие NUMA архитектуры (используется в большинстве современных CPU). Не рекомендуется назначать вашей ВМ количество ядер на сокет (и общее количество vCPU) больше, чем доступно ядер на вашем физическом сокете/процессоре (ноде NUMA). При размещении на одной физической ноде NUMA, виртуальная машина сможет использовать быструю локальную RAM, доступную на конкретной ноде NUMA. Иначе для выполнения операции процессам придется ждать ответа от другой ноды NUMA (что несколько более долго).

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

Если количество требуемых vCPU превышает количество ядер на 1 физическом сокете (ноде NUMA), нужно создать несколько виртуальных сокетов (процессоров) с необходимым количество ядер. Также не желательно использовать нечетное количество процессоров (лучше добавить 1 vCPU)

Это позволит сохранить производительность виртуальной машины.

Например, для 2 процессорного хоста с 10 ядрами (суммарно доступно 40 vCPU с учетом Hyper — Threading ), при настройке vCPU для ВМ оптимально использовать такие конфигурации:

Например, ВМ с Microsoft SQL Server 2016 Enterprise Edition 16 vCPU в конфигурации 8 сокетов по 2 ядра будет работать хуже, чем в конфигурации 2 сокета по 8 ядер.

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