Часть 12. Немного про CPU
Часть 12. CPU type
Часть 12. Hyper-threading и безопасность
Часть 12. Hyper-threading и скорость

Часть 12. CPU type

В свойствах виртуальной машины, а может где-то еще, можно настроить CPU type. Причина появления этой настройки понятна, совместимость разных поколений процессоров.
Разные поколения процессоров имеют разные инструкции. Соответственно, чтобы приложение внутри виртуальной машины после миграции не обнаружило, что на новом физическом сервере более старый процессор не умеет выполнять какую-то инструкцию, на исходном сервере операционной системе (и приложению в ней) заранее сообщается, что там стоит «виртуально более старый процессор».
Для ESXi это называется Enhanced vMotion Compatibility (EVC). И отдельно можно поиграть в CPU Compatibility Masks.
Для Hyper-V это называется Processor Compatibility Mode (CompatibilityForMigrationEnabled)
В некоторых задачах (AES) это может дать х3 снижение производительности, в других почти незаметно.

Можно ли жить без этой настройки ? Можно, и желательно держать в кластере (в любом) одинаковые сервера – не только с одинаковыми CPU, но и с одинаковыми версиями BIOS, и с одинаковой прошивкой микрокодов для CPU в этом BIOS. Не потому, что это обязательно, а потому, что так меньше возможных проблем. И плюс исправления к CPU иногда выходят, не забывайте ставить.

Можно ли мигрировать VM «без этой настройки» ?
Выключенные однозначно да,  у всех.
Включенные в ESXi – нет.
Включенные в Hyper-V – нет, они с и включенной настройки иногда не мигрируют, хотя и по другим причинам.
Включенные в proxmox – я не пробовал.

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

Часть 12. Hyper-threading и безопасность

Когда-то давно, в 2018 году, для Intel нашли уязвимость L1 Terminal Fault (L1TF). Для устранения этой уязвимости, от момента обнаружения до момента выхода исправления, предлагалось, в том числе,:

The L1TF vulnerability introduces risk that the confidentiality of VBS secrets could be compromised via a side-channel attack when Hyper-Threading (HT) is enabled, weakening the security boundary provided by VBS. Even with this increased risk, VBS still provides valuable security benefits and mitigates a range of attacks with HT enabled. Hence, we recommend that VBS continue to be used on HT-enabled systems. Customers who want to eliminate the potential risk of the L1TF vulnerability on the confidentiality of VBS should consider disabling HT to mitigate this additional risk.
Microsoft Guidance to mitigate L1TF variant

После выхода и применения исправлений предлагалось включить HT обратно

Important: Disabling Intel Hyperthreading in firmware/BIOS (or by using VMkernel.Boot.Hyperthreading) after applying vSphere updates and patches is not recommended and precludes potential vSphere scheduler enhancements and mitigations that will allow the use of both logical processors. Mitigation should be done by enabling the ESXi Side Channel Aware Scheduler (see below).
VMware response to ‘L1 Terminal Fault - VMM’ (L1TF - VMM) Speculative-Execution vulnerability in Intel processors for vSphere: CVE-2018-3646

Для проксмокса были те же рекомендации, и предупреждение, цитата

L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details
Problem/message L1TF CPU bug and data leak

На «сейчас», после обновлений «всего», я такой рекомендации, «выключать», не видел. По крайней мере, не видел на более-менее новых процессорах и версиях 8 и 9.

Часть 12. Hyper-threading и скорость

Hyper-threading is an Intel technology that exposes two hardware contexts (threads) from a single physical core. These threads are referred to as logical CPUs. It is a common misconception that hyper-threading doubles the number of CPUs or cores. This is simply not the case. Hyper-threading improves the overall host throughput from 10-30% by keeping the processor pipeline busier and allowing the hypervisor more opportunities to schedule CPU clock cycles and so you should definitely take advantage of hyper-threading by enabling it in the BIOS of the VM host machine.
SQL Server Best Practices, Part II: Virtualized Environments

Есть несколько бытовых мифов про влияние Hyper-threading на скорость VM

Миф первый. HT замедляет работу, потому что это не настоящее ядро.
Этот миф растет из общего непонимания, что такое «ядро», и как с ним работает операционная система. HT это вообще не ядро, это «нить» или «поток исполнения»

Cores are physical processing units.
Threads are virtual sequences of instructions given to a CPU.
Multithreading allows for better utilization of available system resources by dividing tasks into separate threads and running them in parallel.
Hyperthreading further increases performance by allowing processors to execute two threads concurrently.
What Are CPU Cores vs Threads?

Тут я совсем не уверен в том, как это работает с точки зрения именно планировщика по потокам. В общем виде работает это следующим образом:
В случае нормальной работы планировщика (process scheduler \CPU scheduler ), он распределит задачи сначала по 1 потоку на физическое ядро, то есть не «на задача будет выделено физическое ядро», а «задача будет назначена на первый входящий тред физического ядра».
Поэтому в общем случае у вас не будет какой-то мега нагрузки на CPU.
Но, если вы изначально рассчитывали на включение HT и удвоение производительности, то, конечно, забудьте.

Миф второй. У меня огромнейшая нагрузка, поэтому задача, поставленная не на физическое ядро, будет работать медленно.

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

Скорее всего, нет у вас такой нагрузки. Но, если вы считаете, что точно есть, ну что ж, выключайте. В некоторых случаях, если вам так будет спокойнее, и вы не готовы что-то численно измерять, то можете выключить. Или сказать что выключили, иногда «сказать, что выключили и ускорили, ничего не делая» ускоряет работу системы в 1.5 раза.

Миф третий. Надо просто дать побольше ядер.
Выдать можно. Планировщик хоста будет пытаться сбалансировать треды исполнения, потому что он ничего не знает про то, какие задачи исполняются внутри.
При этом, для некоторых, довольно специфичных задач, например в случае, если у вас есть DBA, ваш DBA знает что такое NUMA, ваш DBA не боится им пользоваться, и внутри VM стоит Microsoft SQL Server 2022 или Microsoft SQL Server 2025, то выделить VM «чуть больше» чем физических ядер, и покрутить настройки трансляции NUMA может быть полезным. Про SQL soft numa и релиз ноты вообще читать полезно, как и что-то типа SQL Server Best Practices, Part II: Virtualized Environments
В остальных сценариях не надо так делать. Например, у PostgreSQL может быть грусть и тоска

Реальная сложность для меня, это отсутствие в Linux параметра CPU ready в нужном мне виде. И это не Steal time, про это ниже.
В ESXi CPU ready есть, и виден через esxtop, и в некоторых сценариях необходимо уменьшить, именно уменьшить число vCPU - Lowering the number of vCPUs reduces the scheduling wait time
Читать по теме:

CPU Ready Time Issues in ESXi Environments Running SQL Server VMs
Determining if multiple virtual CPUs are causing performance issues
How CPU management works on VMware ESXi 6.7

Для Windows server 2025 были введены новые метрики - CPU jitter counters, CPU Wake Up Time Per Dispatch, CPU Contention Time Per Dispatch, детальнее смотрите в статье CPU oversubscription and new CPU jitter counters in Windows Server 2025.

Для libvirt  есть virt-top . Для поиска источника нагрузки на диски есть iotop и htop, оба кстати не установлены из коробки.
В теме Steal time monitoring есть отсылка на проект vmtop, но как его проверить на пригодность, и как он будет жить, не из коробки и с его зависимостями – мне не очевидно. Последний коммит в проект – 16 апреля 2024.

Из этой характеристики вырастает проблема с аналогом VMware DRS (Distributed Resource Scheduler) или Hyper-V Load Balancing, точнее SCVMM dynamic optimization, особенно если на это намазан толстый слой .. для ESXi  слой ESXi host group  и VM-Host affinity rule , для Hyper-V и SCVMM – слой VM Affinity  \ Anti-affinity и Fault domain.

То есть, функционал (некий! (TM)) в Proxmox есть, Proxmox introduces Cluster Resource Scheduler for Proxmox Virtual Environment 7.3, есть отдельно ProxLB

Отдельно надо сказать про мониторинг. Я не знаю, это в Zabbix так сделано, или в Linux, или не знаю где еще, но при включенном HT, при не понятно каких условиях, нагрузка CPU выглядит как «не выше 50%».

Часть 12. И про кластер

Самое неприятное в статье Cluster Manager, это то, что там все работает от root.
Второе, не самое приятное – Corosync.
Потому что под iSCSI отдельные интерфейсы дай, под Corosync – дай (Corosync network planning), плюс лимит в хостов 20, и новостями типа with over 50 nodes in production. Ну что такое 50 нод, это ж немного. Четыре корзины по 12 лезвий.

Часть 12.Подводя итог

Если открыть статью Bibliography, то окажется, что книга Wasim Ahmed. Mastering Proxmox - Third Edition. Packt Publishing - это 2017 год, The Debian Administrator's Handbook – 2021.
Литературы мало, на русском почти нет совсем (кроме разрозненных статей). Порог входа не то чтобы высокий, но выше, чем у Hyper-V. Части привычного функционала еще нет, или он реализуется посторонними проектами. Метрокластер не понятно, как на таком строить.
Кластерная файловая система под вопросами. 
Крутить локальные виртуалки – пойдет, и даже iSCSI будет работать. Провайдеры, опять же, всякие в наличии. Но это уже совсем другая история

Литература
QEMU / KVM CPU model configuration
Enhanced vMotion Compatibility (EVC) Explained
Как работает и как используется Enhanced vMotion Compatibility (EVC) в кластерах VMware vSphere
Impact of Enhanced vMotion Compatibility on Application Performance
Processor Compatibility Mode in Hyper-V
Processor compatibility for Hyper-V virtual machines
Performance Impact of Hyper-V CPU Compatibility Mode
Proxmox wiki Manual: cpu-models.conf
Proxmox wiki IO Scheduler
Proxmox wiki High Availability
Proxmox wiki Cluster Manager
Proxmox PVE Bibliography
Старая (2010) статья Multi-Core Scaling In A KVM Virtualized Environment
What is a vCPU and How Do You Calculate vCPU to CPU?
Hyper-V NUMA affinity and hyperthreading
VMware response to ‘L1 Terminal Fault - VMM’ (L1TF - VMM) Speculative-Execution vulnerability in Intel processors for vSphere: CVE-2018-3646 (55806)
Mitigation Instructions for CVE-2022-21123, CVE-2022-21125, and CVE-2022-21166 (VMSA-2022-0016) (88632)
Guidance for mitigating L1 Terminal Fault in Azure Stack
Microsoft Guidance to mitigate L1TF variant
Which process scheduler is my linux system using?
Completely Fair Scheduler and its tuning
Linux schedulers – overview
The Linux Scheduler a Decade of Wasted Cores
New EEVDF Linux Scheduler Patches Make It Functionally "Complete"
What Are CPU Cores vs Threads?
CPU oversubscription and new CPU jitter counters in Windows Server 2025

У Broadcom VMware все проще – вот патч (сейчас официально только по подписке), вот компоненты в нем.
У Microsoft  все еще проще – вот MicrosoftUpdate Catalog. Если выходят бесплатные обновления (для 2012 и 2012R2 – только платные, нужна подписка Extended Security Updates (ESU) for Windows Server, для 2008 нужна подписка premium assurance. Но обновления выходят, например:
2025-08 Security Monthly Quality Rollup for Windows Server 2008 R2 for x64-based Systems (KB5063947)

Поэтому можно сходить на
http://download.proxmox.com/debian/pve/dists/bookworm/pve-no...
http://download.proxmox.com/debian/pve/dists/trixie/

Скачать там файл
http://download.proxmox.com/debian/pve/dists/trixie/pve-no-s...

И увидеть, цитата

Package: pve-manager
Maintainer: Proxmox Support Team support@proxmox.com
Installed-Size: 3573
Provides: vlan, vzdump
Depends: apt (>= 1.5~), ..
Recommends: proxmox-firewall, proxmox-offline-mirror-helper, pve-nvidia-vgpu-helper
Conflicts: vlan, vzdump
Breaks: libpve-network-perl (<< 0.5-1)
Replaces: vlan, vzdump
Filename: dists/trixie/pve-no-subscription/binary-amd64/pve-manager_9.0.5_all.deb
Size: 580388

Окей, а как-то поудобнее можно?

Конечно после обновления можно увидеть:
cat /var/log/apt/history.log
Но это после обновления.

Очень, очень не хватает решения типа Windows Server Update Services (WSUS), но для Linux и Proxmox. Foreman+Katello говорят «ок». RedHat Satellite ? SpaceWalk:Satellite ?

Разница концепций. Часть 7.2 Сети

В ESXi «из коробки» все просто. Есть стандартный свитч, vSphere Standard Switch, vSS. Он мало чего умеет «из коробки», но самое главное, что вы можете завести несколько коммутаторов, и распределять физические порты сетевых карт, и порты виртуальных сервисов – самого менеджмента, сервисов, итд, как вам нравится.
Вместе с некоторыми (их опять поменяли) лицензиями вы получали vSphere Distributed Switch (VDS), с дополнительными функциями.
Если хотите добавить в жизнь интима - Single Root I/O virtualization (SR-IOV).
Хотите чего-то большего – покупайте VMware NSX.
У Microsoft в чем-то схожий подход. Есть Hyper-V switch с массой настроек исключительно из powershell.
Хотите большего – добро пожаловать в увлекательный мир Network Controller Server Role.
Хотите того же самого, но иначе – вот вам Set up networking for Hyper-V hosts and clusters in the VMM fabric, вот вам Set up logical networks in the VMM fabric, и вперед.

У Proxmox все немного не так. То есть, так то так, архитектура та же, x86, но.
За уровень «стандартного коммутатора» отвечает стандартный функционал Linux. Проблема в том, что он (как, впрочем, и в Broadcom, и в Microsoft) читаемо и полноценно настраивается только из командной строки. Режима Switch Embedded Teaming (SET) в нем нет, есть active-active bond, но.
Red Hat пыталась сделать что-то такое же, и даже статья есть - 8.3. Comparison of Network Teaming to Bonding, но это Red Hat.
Чтобы в этом разбираться, все равно необходим  базовый уровень знания сети, в масштабе CCNA: Switching, Routing, and Wireless Essentials, он же CCNA Routing & Switching ICND1 100-105 Course. Иначе вопросов будет больше, чем ответов. У Broadcom есть best practice – собирайте actve-active, LACP не нужен. Если вы упрт нркмн, то вот вам beacon probe и shotgun mode, можете упртс. Если хотите совсем упртс, то вот вам air-gap storage fabric, только лучше бы вы так не делали.
У Microsoft есть best practice – просто ставьте SET, он сам разберется.
У proxmox, их-за наличия Bridge, который по сути L2 switch, и iptables, появляется L3 конфигурация с NAT, но планирование сети заставляет каждый раз думать «как лучше-то».

Кроме того, в конфигурации сети отдельно английским по белому написано:

For the cluster network (Corosync) we recommend configuring it with multiple networks. Corosync does not need a bond for network redundancy as it can switch between networks by itself, if one becomes unusable. Some bond modes are known to be problematic for Corosync, see Corosync over Bonds.

Особенно мне понравилась строчка:
We recommend at least one dedicated physical NIC for the primary Corosync link

То есть, поскольку сетевые карты нынче идут, чаще всего, с двумя портами, то надо брать 2 карты по 2 порта, всего 4 порта, и один порт выделять под Corosync. Но если у меня конфигурация нормального человека, 2 порта по 25, это мне что, под кластер надо выделять целых 25G? А не жирновато?
При этом сценарии отказа описаны понятно и обоснованно, но как-то заставляют задуматься. Это же придется ставить на мониторинг не только состояние порта on\off\ CRC, но и, для оптики, уровень сигнала по SFP модулям с обеих сторон, RX power \ TX power.

Середины (типа vSphere Distributed Switch (VDS)) нет.
Зато есть SDN

От теории к практике.
Поскольку для этой серии статей у меня Proxmox развернут как вложенная (nested) виртуализация, то мне придется или переделать всю сеть, или пересобирать рабочие стенды, или ограничиться двумя виртуальными сетевыми картами.

К моему величайшему отвращению, Hyper-V Windows 11 'Default Switch' зачем-то снабжен никак нормально не настраиваемым DHCP сервером. В Server 2012\2016\2019\2022\2025 такого нет, если нет DHCP в сети, значит нет сети.

Конфигурация хоста Hyper-V:
Get-VMSwitch 'Default Switch' | fl – от этого виртуального свича все отключено.
Вот он мне и вредил, поскольку в нем и NAT и DHCP , и ничего в нем не настраивается, согласно Change Hyper-V (Default Switch) IP address range.

The Hyper-V Default Switch will randomly use one these IP address ranges based on the host system IP address:
Start IP: 192.168.0.0 – End IP: 192.168.255.255
Start IP: 172.17.0.0 – End IP: 172.31.255.255

Поэтому я новый виртуальный свитч и сделал, режим external. И все у него хорошо.
Конфигурация proxmox по умолчанию

auto lo
iface lo inet loopback
iface eth0 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.10.202/24
gateway 192.168.10.1
bridge-ports eth0
bridge-stp off
bridge-fd 0

Конфигурация с двумя виртуальными сетевыми картами у меня будет выглядеть так:

auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno2 inet manual

auto bond0

iface bond0 inet manual

bond-slaves eno1 eno2
bond-miimon 100
bond-mode active-backup
bond-xmit-hash-policy layer2+3

auto vmbr0

iface vmbr0 inet static
address  192.168.10.202/24
gateway  192.168.10.1
bridge-ports bond0
bridge-stp off
bridge-fd 0

Конфигурация с VLAN для рабочих сред описана в разделе Example: Use VLAN 5 for the Proxmox VE management IP with VLAN aware Linux bridge, конфигурация The next example is the same setup but a bond is used to make this network fail-safe.

Разница концепций. Часть 7.3 предисловие к теме «Дисковое пространство».

Чтобы понимать незначительные сложности, нужно немного отойти назад, в состояние «дисковых пространств» 15-20 лет назад, и огромный скачок для всего человечества за последние пять лет.

15 назад, в 2010 году, концепция дисковых пространств была достаточно проста.
Есть одиночные локальные диски, которые могут быть включены по IDE (уже крайне редко на тот момент), SATA, SCSI и SAS. Но интерфейс особого значения не имеет (то есть, еще как имеет, но это другая история), потому что глобально выбора конфигурации особо и нет.
Для домашней и офисной техники: 1 диск, без всяких массивов.
Для дисков с операционной системой: аппаратный RAID 1 (зеркало) из 2 дисков. Не надо забывать, что диски тогда были маленькими, как 72GB 2.5-inc SFF 3G Single Port SAS 10K, 146GB SCSI U320 или 146GB hot-plug Serial Attached SCSI (SAS).
Для дисков с данными для «быстрого» доступа: аппаратный RAID 10.
Для дисков с данными для «медленного» доступа: аппаратный RAID 5, если у вас диски меньше 1 терабайта, аппаратный RAID 6, если у вас диски больше 1 терабайта.
Потому что, запишите это уже большими буквами: RAID 5 на дисках бытового и начально-корпоративного сегмента, при размере одиночного диска больше 1 Тб, достаточно часто умирает при стандартном ребилде. Вероятности считайте сами.
Плюс локально включенные коробки с дисками.
И, для дисковых массивов, у вас есть FC 4g (c 2004), FC 8g (с 2008), и с 2007 года есть 10G Ethernet для iSCSI. 25G Ethernet появится только в 2018 году.
NFS поверх 1\10G, конечно, тоже уже есть. Apple File Service (AFS) еще не умер.
Современные технологии быстрого перестроения массивов уже почти есть в HPE Eva.
Еще есть  InfiniBand, но дорого.

Основная проблема – ребилд. Это долго, это дорого с точки зрения потери производительности, но это зачастую проще, чем переставлять ОС или поднимать данные из архивов. Поэтому везде RAID 1\10 и еще раз RAID. Альтернативы были, но все равно, RAID это было просто, понятно, наглядно, и не требует вмешательства администратора, особенно если есть запасной диск.

Сейчас все поменялось.
Окончательно ушли в историю диски на 15.000 и 10.000 оборотов, и та же судьба уже видна для дисков 7200 для массивов, и для дисков 5400 для ноутбуков. SSD с двумя оставшимися вариантами подключения, SAS и NVME, побеждают почти везде.
Появились технологии для гиперскейлеров, и не только – S2D, vSAN (StarWind дано был). И то, и другое, уже не redundant array of inexpensive disks, а Redundant Array of Independent Nodes (RAIN) .
Сети стали быстрее, диски быстрее, объемнее, и возникает другой вопрос – старые RAID контроллеры перестали справляться с производительностью новых дисков. Новые RAID контроллеры тоже не блещут при работе с NVME, но это уже другая история:
NVME Raid – We Need To Go Deeper, или что там на глубине. GPU over NVME, с водяным охлаждением

Проблема даже не в этом, а в том, что нет смысла держать разные диски на передней панели «под ОС и «под данные», с точки зрения работы, закупок, и в целом. Удобнее использовать один тип дисков, и никто не перепутает. В таком случае проще поставить или PCIe карту на 2 m.2 планки, или взять internal M.2 boot module или что-то типа Dell BOSS, собрать недоаппаратный или программный рейд на такой карте, и отдать остальные одинаковые диски, установленные в передние слоты, под данные, собрав тот или иной вид программного рейда.
НО.
Дальше начинаются «проблемы legacy 2.0».
В корпоративном варианте заказчику, за очень дорого, продадут и S2D и vSAN, со всеми их свистелками, типа быстрого перестроения при сбое, RAID 5+6, поддержке RDMA. Продадут со свичами Arista или Mellanox с их скоростями и cut-through (вместо Store-and-Forward), и lossless Ethernet, и так далее. Это все есть, это все работает, как и последние навороты в MPIO для IP в NVIDIA ConnectX-8 .
Это все есть, но это: 1) дорого 2) требует настройки 3)требует переписать драйвера 4)требует настроить сеть и следить за ней.
В то же время, существуют, как продукты, Ceph и drbd, то есть Linstor. И не только.
Они работают, но. Но настройка, скорость работы (задержки, и как следствие IOPS), проблемы связности, проблемы на ребилде, пожирание памяти как не в себя, и так далее.
В домашней лаборатории, где все работает, а отказ или split brain или остановка сервисов не важны – CEPH работает.
В масштабах VK – тоже работает, вопрос какой ценой.
Ceph вырос как проект 2007 года, времен медленных дисков небольшого объема, отсутствия на рынке «дешевого» варианта собрать хранилище на петабайт и больше, и даже работал, но в 2020 - 2021 году начал уходить с рынка. SUSE отказалась от развития, еще кто-то отказывался. FUJITSU Storage ETERNUS CD10000 S2 - The sale of this product was terminated in December 2019.
Причины понятны, сейчас петабайт хранения требует не двух стоек, а двух юнитов в одной стойке, а рынок опять меняется.
Поэтому Ceph для дома – пожалуйста, Ceph для VK облака или каких-то еще облаков – сколько угодно. Ceph для SMB или чуть выше – не знаю, зачем настолько жертвовать производительностью и иметь бонусом головную боль при обновлениях. И еще один не очевидный многим нюанс ниже.
Но люди верят, что он работает (это почти правда, если не рассматривать ребилд), быстрый  (нет), надежный (очень не всегда). Вопрос цены. Люди верят, что можно обмануть систему, взять бесплатное решение, дешевых людей, дешевое железо и получить производительность и надежность «как в облаке, но дешевле».
Кроме того, есть вопросы и к бекапу, и к восстановлению, и много к чему еще.
Но люди верят. Мерять производительность не хотят, тесты ребилда под нагрузкой делать не хотят, некоторые и бекапы не делают.

Сложность и нюансы в понимании (и отсутствии понимания) «зачем все это».
Для одного сервера все равно нужен какой-то RAID, в современных условиях, для одного сервера, с таким бизнесом, которому достаточно одного сервера, может быть аппаратный контроллер и будет неплохим решением. Для двух серверов уже может быть проще собрать отказоустойчивый кластер не на уровне железа и репликации средствами ОС, а через репликацию сервиса. Базы данных это умеют, для репликации файловых кластеров с низкой нагрузкой подойдет что угодно, остальные сервисы типа etcd тоже реплицируются без кластерной файловой системы.

Разница концепций. Часть 7.4 «Локальное дисковое пространство».

Для Hyper-V все проще некуда. Собрал диски – хочешь в soft raid, хочешь в storage space (не путать с S2D), хочешь на аппаратном рейде. Отформатировал, создал тонкие или толстые виртуальные тома ОС, создал на них тонкие (динамические) или толстые файлы (vhdx), отдал файлы виртуальным машинам, и все.
Есть проблемы с производительностью storage space в parity, если вдруг не читали вот это.
Новый ноутбук: скорость, плюсы-минусы, DiskSPD, Hyper-V и продолжение про методику тестирование скорости
Устроено все проще некуда, диск виртуальной машины == файл с заголовком.
Для Broadcom ESXi все еще проще. Создал «на чем есть» storage, создал виртуальные машины с нужными дисками.
Устроено все проще некуда, диск виртуальной машины == 2 файла. Файл с текстовым описанием, и файл с RAW данными.

Для Proxmox начинается проблема выбора: что взять. Есть Ext4, есть ZFS, есть BTRFS. Есть XFS.
Был GlusterFS, но он все, цитата

As GlusterFS is no longer maintained upstream, Proxmox VE 9 drops support for GlusterFS storages. Setups using GlusterFS storage either need to move all GlusterFS to a different storage, or manually mount the GlusterFS instance and use it as a Directory storage. Roadmap

ПОМЕР.

Development has effectively ended. For years Red Hat drove development for its RHGS product, but with the EOL of RHGS at the end of 2024. Date: 2024-06-25

Само разбиение дисков сделано странно.
ISO images в GUI это /var/lib/vz/template/iso
CT templates в GUI это  /var/lib/vz/template/cache
Конфигурация контейнеров /etc/pve/lxc
Конфигурация виртуальных машин /etc/pve/qemu-server

Диски виртуальных машин – о, тут все странно. В конфиге диск прописан как
scsi0: local-lvm:vm-100-disk-0,iothread=1,size=5G
но это блочный lvs том, который виден по команде lvs , или
find /dev | grep vm
И получаем /dev/pve/vm-100-disk-0
или команда
lvdisplay
покажет что где и как.
Неприятно с точки зрения операций с локальными томами. С ZFS та же история.

Разница концепций. Часть 7.5 «Локальное дисковое пространство - добавление».

Окей, создам отдельный том
New-VHD -Path C:\test\Proxmox\ data.vhdx -LogicalSectorSize 4KB -PhysicalSectorSizeByte 4KB -SizeBytes 105GB -Dynamic
добавлю его через GUI к Proxmox, но это уже будет другая история

Литература

Single Root I/O virtualization (SR-IOV)
Set up networking for Hyper-V hosts and clusters in the VMM fabric
Set up logical networks in the VMM fabric
How to configure System Center VMM Part 1 – Basic Design
8.3. Comparison of Network Teaming to Bonding
3.18. Bridge and Bond Configuration
Proxmox Network Configuration
How to enable DHCP on Hyper-V switch
Hyper-V - Default Switch & DHCP Server
Configuring VM Networking on a Hyper-V NAT Switch
A Practical Guide to Hyper-V Virtual Switch Configuration
Change Hyper-V (Default Switch) IP address range

Proxmox Ebook Free Download for Home Labs – тут почему-то удалили pdf, но он есть тут, хотя он и для 7.1

Proxmox for Everyone: Your Complete Guide to Virtualization, Kubernetes, and Homelab Automation (Next-Gen Infrastructure Strategies Book 2) Kindle Edition by da li (Author), PlanB Mr (Author)

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox
Filesystem Features XFS vs BTRFS vs ZFS
VM Disk location (Can't find the VM disk)
How to move VM to another storage

Что делает планировщик, точнее cpu scheduler, при стандартных настройках.
Планировщик старается выдать каждому процессу (каждой VM, за исключением World 0 , и то, если вы не лазали в minroot кривыми ручонками) равное количество процессорного времени.

Что произойдет, если у вас в системе 32 физических ядра, и вы выдали суммарно 32 vCPU core, скажем? 8 VM по 4 CPU core?  Ничего особенного, планировщик разложит задачи по физическим ядрам, и стандартные, не особо нагруженные VM, будут работать как работали. За, правда, исключением случая Storage space и storage space direct (S2D), там будет чуть сложнее. И с vSan не все так просто, но приемлимо.
Что произойдет, если у вас в системе те же 32 физических ядра, и вы выдали суммарно 96 vCPU core, скажем, 24 VM по 4 CPU core?  Тоже ничего особенного, планировщик разложит задачи по физическим ядрам, потом попытается разложить задачи по виртуальным ядрам, потом построит очередь, и будет, так или иначе, эту очередь выполнять. Для ежедневных сценариев и нормальных гипервизоров ситуация с переподпиской CPU 1:1.5 и до 1:3 по физическим ядрам находится между «нормальной» и «терпимой».

Уточнение. Правильнее сказать «годится для начала разговора и осмотра CPU ready». Потому что одно дело у тебя система, которая почти ничего не считает, но крутит данные в памяти, как не в себя, другое дело VDI, третье дело NTP или еще какой сервер, у которого 2 vCPU только из вежливости. Кроме просмотра CPU ready, еще надо смотреть co-stop (%CSTP).

Для VDI сценариев, где 99.99% времени система ждет, пока пользователь нажмет что-то на клавиатуре, нормально будет работать и 1:10.
Оговорка: конечно, не во всех сценариях, и не во всех гипервизорах. Для нагрузки, чувствительной к задержкам, c ESXi 5.5, есть режим Latency-Sensitive. Для VM размером в хост, тоже есть свои настройки. См. разделы литература ниже.

Что произойдет, если у вас в системе те же 32 физических ядра, и вы выдали суммарно 64 vCPU core, скажем по 48 vCPU 2 VM (#1, #2),  и по 8 еще оставшимся 4 (#3, #4, #5, #6)?  Напоминаю, всего у вас в системе 32 ядра / 64 потока.

Будет очень интересно, не переключайтесь

Допустим, планировщик начал с первой машины (VM #1). Первым делом планировщику надо дождаться, пока остальные пять сделают свои дела с CPU, или, пока не пройдет таймаут. Допустим, что планировщику и VM свезло, и Vm #1 полезла на 48 vCPU.
А 48 физических ядер нет. Есть 32. Надо выкидывать остальные задачи куда-то в кеш 2-3-N уровня. Освобождать весь кеш 32+16 потоков, и всякие регистры к ним еще раз. Выполнить сначала одно, потом второе, и при этом попытаться уложиться в таймслот. Начинается то, что зовется context switches. И это я еще не лезу в пособие по архитектуре HT, потому что я даже не представляю, как именно построены очереди исполнения и всякие регистры по отношению к HT и тому, что называется speculative execution.
Окей, худо-бедно выполнились, и !
И пришла беда, откуда не ждали. У Intel Xeon давно есть режим авторазгона. Одни ядра разгоняются, другие нет, в результате угадать, какие ядра останутся на 2.2 , какие захотят работать на 2.4, какие на 2.6 – невозможно. Со всеми последствиями для попытки поддержать синхронность выполнения задач на ядрах со стороны планировщика.
Со стороны почти любого мониторинга это выглядит так, что процессор ничего не делает, и это чистая правда.
Сделаем еще шаг назад. Кроме ядер, в работе фигурирует и оперативная память. И желательно, чтобы данные в памяти (в физической памяти) были поближе к нужному ядру. NUMA, non uniform memory access, в полном расцвете сил. Хорошо, что в этом сценарии она не работает.
Сделаем еще шаг назад. Процессор – это не только калькулятор, это еще и всякие EAX EBX ECX EDX, и прочие данные, и очень не хотелось бы, чтобы специально обученные злодеи выдернули из этих ESI EDI ваш пароль, или хеш от него. Ага, Meltdown и Spectre (там чуть сложнее, конечно).

Начинается шаг 2 - исполнение VM #2 еще на 48 ядер. Даже и не на 48, кстати.

Планировщик пытается сказать процессору «давай, исполняй».

Процессор пытается разогнаться, при этом выкинуть лишние данные из своих кешей, памяти, регистров, и так далее. Точнее, конечно, планировщик командует, ядра делают.
VM #2 пытается всеми своими 48 ядрами, с криками «мне положено, вас тут не стояло», залезть на 32 ядра. Может, успевает даже что-то выполнить на разогнанных ядрах. Может, нет. И планировщик начинает ее выгонять с ядер со словами «завтра досчитаешь, СЛЕДУЮЩИЙ», напевая под нос  What You Waiting For?

Шаг 3

На 32 ядра лезут оставшиеся 4 по 8, быстро исполняются, ну как могут, и на следующем шаге планировщик  опять пытается выполнить VM #1. Но VM 3, 4, 5, 6 работают за разное время, поэтому VM 1 придется подождать, пока выполнятся все задачи на всех ядрах, у всех машин, и только потом планировщик будет пытаться утрамбовать VM #1, примерно так же, как Lock, Shock and Barrel пропихивали Sandy Claws в трубу.

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

Планировщик сидит, курит, и поет

Goodbye
Yes, it's time to say goodbye
Sad, I know, but, hey, you're done with living
It's time to give in
And go and so, goodbye

(но это не точно, может относится к этому более филосовски. Как говорилось, We all bloody die. Except this one here.)

Что сделали

Взяли, и вопреки всем крикам «да что вы делаете, как жить то» - отобрали у самых толстых машин, 1с кстати, лишние ядра. Все равно она ими пользоваться не умеет. И настройки в BIOS покрутили. И стало хорошо.

Литература

Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5

Режим высокой производительности для требовательных виртуальных машин в VMware vSphere 5.5 (Latency Sensitivity).

Performance Tuning for Latency-Sensitive Workloads VMware vSphere 8

Windows Server 2019 Hyper-V host behavior running in the minroot configuration

[Performance] Interpreting CPU Ready values

Нюансы CPU Ready

CPU oversubscription and new CPU jitter counters in Windows Server 2025

x86 Registers

Context Switches

High context switch rate

Infographics: Operation Costs in CPU Clock Cycles: Not all CPU operations are created equal

Context switch-Everything you need to Know

Side-channel aware scheduler (SCA) - SCAv2

Performance Optimizations in VMware vSphere 7.0 U2 CPU Scheduler for AMD EPYC Processors

Optimizing Networking and Security Performance Using VMware vSphere and NVIDIA BlueField DPU with BWI

Understanding ESXi CPU scheduling

Performance of vSphere 6.7 Scheduling Options

Performance Best Practices for VMware vSphere 8.0 Update 3

Maximizing VMware Performance and CPU Utilization

Why VMware Engineers Tell You to Right-size Your VMs: Becau$e Co-$top Will Co$t You Money

Soft-NUMA (SQL Server)

Which vSphere CPU Scheduler to Choose

Determining if multiple virtual CPUs are causing performance issues

PS. Логика Пикабу зачем-то советует тег "другой мир". Окей. Тега broadcom нет, тега Nutanix нет