ТГК: NetIntelRU

Когда программист пишет код, он редко задумывается о том, что происходит с программой после того, как он её написал. Но понимание этого процесса необходимо для эффективной отладки, оптимизации и написания надёжного кода. А ещё, это просто интересно.

Три пути выполнения

Если код компилируемый (например, написан на C++ или Go), то компилятор берет ваш исходный код (.cpp, .rs) и превращает его в так называемый объектный файл (.o или .obj). Это уже почти машинный код, но в нем могут быть "пробелы", например, вызов функции printf, код которой находится в другой библиотеке.

В работу вступает линковка (линкер/компоновщик/сборщик). Его задача взять один или несколько объектных файлов и склеить их в единый, работоспособный исполняемый файл (.exe или ELF). Он находит все недостающие функции (в других объектных файлах или в системных библиотеках), подставляет их реальные адреса на место "пробелов" и создает итоговый файл, готовый к загрузке в память.

Если код интерпретируемый (Python, JavaScript), то ситуация иная. Здесь нет классической компиляции и линковки перед запуском. Файл, который вы запускаете, это исходный текст. В память загружается сама программа-интерпретатор, а уже она получает путь к вашему скрипту. То есть, процесс создается для интерпретатора, а он уже, в свою очередь, будет читать и выполнять ваш код построчно в реальном времени.

Существует и гибридный подход (JIT-компиляция в Java или C#), когда исходный код сначала компилируется в промежуточный байт-код CIL (промежуточный код между высокоуровневым исходным кодом, который пишут разработчики, и машинным кодом, исполняемым процессором), а специальная среда выполнения (виртуальная машина) компилирует его в машинный код уже в процессе работы программы, совмещая гибкость интерпретации и скорость компиляции.

Теперь, когда у нас есть готовый исполняемый файл или запущен интерпретатор, загрузчик (см. Подготовка среды) наконец-то может сделать свою работу. Он открывает файл, считывает его структуру и раскладывает сегменты кода и данных по тем самым зонам в памяти, которые ОС выделила для процесса.

Подготовка среды

Операционная система готовит для программы пространство в памяти. ОС (Операционная система) - это главный менеджер вашего компьютера. Она постоянно слушает, что вы делаете (через графический интерфейс или командную строку). Когда она получает команду "запустить эту программу", она понимает, что задача найти исполняемый файл и подготовить его к работе.

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

ОС отрезает в оперативной памяти (RAM) приватный участок и называется он "виртуальное адресное пространство". Это мощная абстракция, которая дает каждому процессу иллюзию, что у него в распоряжении есть вся память компьютера целиком, начиная с адреса 0 и заканчивая очень большим числом (например, 2^64 в 64-битных системах).

В этом пространстве будут жить сам код программы, данные (глобальные переменные) и служебные структуры, такие как стек для вызовов функций и куча для динамической памяти. Эта изоляция - фундамент безопасности и стабильности системы.

Интересный момент не по теме: Если ОС так тщательно изолирует процессы, как тогда программа-вирус может украсть данные, зашифровать файлы или встроиться в систему? Ответ прост: вирус должен получить разрешение от пользователя или ОС на выход из своей "песочницы". Вирус, запущенный от имени обычного пользователя (без прав админа), не может повредить систему, но он может свободно работать с файлами текущего пользователя. Также вирус может использовать уязвимости и внедриться в другие процессы.

Каждому новому процессу ОС присваивает уникальный номер - Process ID. Так она может отличать твою запущенную косынку от десятков других процессов.

Теперь, когда процесс есть в памяти, специальный компонент ОС, "загрузчик", открывает твой исполняемый файл (.exe или файл в формате ELF) и раскладывает его части по заранее размеченным зонам в памяти.

Управление

Планировщик задач

Загрузчик разместил код в памяти, ОС передала управление процессору. Программа ожила и начала выполнять свои инструкции, но она не одна. На компьютере одновременно работают десятки других процессов. Как ОС управляет этим?

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

Если у тебя четырёхъядерный процессор с Hyper-Threading, он может одновременно выполнять до восьми потоков (по одному на каждое логическое ядро). Однако в системе обычно работают десятки или даже сотни процессов и потоков, что гораздо больше, чем ядер.

Для этого существует планировщик ОС. Его задача эффективно распределять все процессы и потоки по доступным ядрам. Планировщик выделяет каждому потоку квант времени, обычно от нескольких до десятков миллисекунд, запускает поток на одном из ядер, даёт ему поработать, затем принудительно останавливает его, сохраняет контекст (содержимое регистров, счётчик команд и т.д.) и ставит на выполнение следующий поток.

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

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

Системные вызовы

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

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

Когда программе нужно выполнить привилегированную операцию (например, открыть файл, выделить память или отправить данные по сети), она инициирует системный вызов. Для этого используется специальная инструкция процессора (например, syscall или svc), которая вызывает программное прерывание. Это прерывание приостанавливает выполнение программы и передаёт управление ядру ОС.

Ядро проверяет запрос, выполняет необходимые действия (например, чтение файла или выделение памяти), а затем возвращает результат программе и снова передаёт ей управление. Если операция требует ожидания, например, данные ещё не загружены с диска, ядро может временно блокировать программу, чтобы не тратить ресурсы процессора на ожидание.

Управление памятью и файлами

Во время работы программы её потребности в ресурсах могут меняться. ОС постоянно отслеживает это. Если программе требуется выделение или освобождение памяти на уровне ОС (например, при увеличении кучи или создании нового сегмента памяти), она делает системный вызов.

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

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

Исполнение

Исполнение это процесс, при котором процессор выполняет инструкции программы, преобразованные в машинный код.

Выборка (Fetch)

Процессор имеет специальный регистр - счётчик команд (Program Counter, PC или Instruction Pointer, IP), в котором хранится адрес следующей инструкции, которую нужно выполнить. Этот адрес виртуальный, и он преобразуется в физический с помощью MMU (Memory Management Unit).

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

Конвейеризация это технология, при которой процессор разбивает выполнение инструкций на эти этапы и выполняет их параллельно для разных инструкций.

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

Предварительная выборка это механизм, при котором процессор заранее загружает инструкции и данные в кэш, ещё до того, как они понадобятся.

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

Декодирование (Decode)

Скопированная инструкция это просто числа. Процессор должен понять, что она означает. Каждая инструкция состоит из кода операции (opcode), который определяет действие, и операндов, указывающих, с какими данными работать.

Устройство управления анализирует opcode и генерирует сигналы для активации нужных компонентов процессора. Например, для инструкции сложения (ADD EAX, EBX) оно отправит сигнал в арифметико-логическое устройство (АЛУ), чтобы выполнить операцию, и в регистры, чтобы сохранить результат.

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

Пример: Рассмотрим инструкцию MOV EAX, [EBX] (переместить данные из ячейки памяти, адрес которой хранится в EBX, в регистр EAX). На этапе декодирования процессор:

1. Определяет, что это инструкция перемещения данных (MOV).

2. Извлекает адрес из регистра EBX.

3. Подготавливает АЛУ и регистры для передачи данных из памяти в EAX.

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

Выполнение (Execute)

Где процессор берет числа для операций и куда кладет результат? Для этого у него есть своя сверхбыстрая внутренняя память - регистры.

Давайте посмотрим на этот процесс на простом примере. Возьмем строчку кода: c = a + 5;

После того как процессор декодировал инструкцию, соответствующую этой строке, он переходит к выполнению. Процессор загружает значение переменной a из оперативной памяти в один из своих регистров. Затем он загружает константу 5 в другой регистр (например, в RBX).

Он отдает команду своему АЛУ, чтобы сложить то, что лежит в RAX, с тем, что лежит в RBX. АЛУ выполняет сложение, и результат (например, 23) помещается обратно в регистр RAX. Наконец, процессор сохраняет значение из регистра RAX обратно в оперативную память, по адресу, где находится переменная c.

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

Завершение работы и уборка

Завершение работы

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

Когда процессор получает прерывание, текущее состояние программы сохраняется в стек. Процессор передает управление специальной функции в ядре ОС - обработчику прерываний. Это заранее подготовленный код для конкретного устройства.

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

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

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

Для системного вызова ОС выполняет запрошенную операцию и возвращает управление программе, как мы описывали ранее.

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

Уборка

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

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

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

Вся физическая оперативная память (RAM) и место в файле подкачки, которые были заняты процессом, помечаются как свободные. Теперь они могут быть выделены другим процессам.

Его уникальный номер (PID) теперь свободен и может быть выдан новому процессу. Планировщик задач убирает этот процесс из своих очередей на выполнение.

Сборщик мусора (Garbage Collector, GC) это не механизм операционной системы, а компонент среды выполнения конкретного языка программирования. Если уборка, которую делает ОС, это снос целого процесса, то сборщик мусора это уборка внутри процесса, пока он живёт.

Если понравилась статья - рекомендую подписаться на телеграм‑канал NetIntel. Там вы сможете найти множество полезных материалов по IT и разработке!

Для лиги лени: ничего нового, проходите мимо

Часть 1. Общая
Часть 2. Gitlab и Nexus
Часть 3. Ansible и Ansible AWS
Часть 4. Наконец переходим к Proxmox
Часть 5, не запланированная. Обновляем Proxmox с 8.4 до 9.0. Неудачно.
Часть 6. Возвращаемся к запуску Ansible
Часть 7. Разница концепций
Разница концепций. Часть 7.1 Обновления компонентов и система информирования.
Разница концепций. Часть 7.2 Сети
Разница концепций. Часть 7.3 предисловие к теме «Дисковое пространство».
Разница концепций. Часть 7.4 «Локальное дисковое пространство».
Часть 8. Разница концепций
Разница концепций. Часть 8.1 Расположение дисков VM
Разница концепций. Часть 8.2 Добавление дисков к хосту
Разница концепций. Часть 8.3 Настройка нескольких дисков
Разница концепций. Часть 8.4 Управление диском виртуальной машины.
Часть 9. Скорости дисков
Часть 10. Внешние СХД, iSCSI
Часть 11. Система прав

Часть 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

Для лиги лени: ничего нового, проходите мимо

Часть 1. Общая
Часть 2. Gitlab и Nexus
Часть 3. Ansible и Ansible AWS
Часть 4. Наконец переходим к Proxmox
Часть 5, не запланированная. Обновляем Proxmox с 8.4 до 9.0. Неудачно.
Часть 6. Возвращаемся к запуску Ansible
Часть 7. Разница концепций
Разница концепций. Часть 7.1 Обновления компонентов и система информирования.
Разница концепций. Часть 7.2 Сети
Разница концепций. Часть 7.3 предисловие к теме «Дисковое пространство».
Разница концепций. Часть 7.4 «Локальное дисковое пространство».
Часть 8. Разница концепций
Разница концепций. Часть 8.1 Расположение дисков VM
Разница концепций. Часть 8.2 Добавление дисков к хосту
Разница концепций. Часть 8.3 Настройка нескольких дисков
Разница концепций. Часть 8.4 Управление диском виртуальной машины.
Часть 9. Скорости дисков
Часть 10. Внешние СХД, iSCSI

Часть 11. Система прав

Сначала еще раз немного теории.
Про разницу аутентификации (ты чьих будешь, чей холоп ?) и авторизации (у вас есть право) много раз написано. Кроме них есть и единый источник истины (Single Source of Truth, SSOT). Истины для системы управления жизненным циклом пользователеля, User lifecycle management (ULM), то есть для плановых замен паролей и сертификатов, проверка того, что учетная запись еще включена и имеет те же самые права, что и ранее, и прочее.
Есть два подхода – локальное хранение учетных записей, и удаленное хранение учетных записей.
С локальным хранением все понятно, с удаленным хранением тоже - Identity and access management (IAM or IdAM) or Identity management (IdM), ISO/IEC 24760-1 a framework for identity management, и прочие слова.
Вокруг этого начинаются протоколы, фреймворки, методологии, ISO\ГОСТ, и конечные реализации, в том числе реализации системы прав через ролевую модель, RBAC \ ABAC \ PBAC, вот это все.
Отдельно существуют системы хранения секретов – покойный RatticDB, модные современные HashiCorp Vault, Bitwarden Vault, их клоны и так далее.

В чем проблема? Для малой организации на 2 сервера и 20 сотрудников никакой проблемы с раздачей прав нет. Альтернативно одаренные администраторы сразу дают всем права «на все», хотя бывает и хуже. Как вам, например, заведение на Linux серверах учетных записей root1, root2, root3 и передача паролей от них? Потому что менять руками сложно, а ssh \ bash \ Ansible слова слишком страшные.
Реализаций центральной служб каталогов несколько, многие (как  Novell Netware Directory Services (NDS) \ NetIQ eDirectory) уже ушли в небытие. Замена AD на SAMBA не является предметом данной статьи.

Предметом специальных BDSM практик является использование Realmd\ SSSD, или такое отвратительное явление, как хранение сертификатов в домене. Оба извращения не являются предметом данной статьи.

Что есть в Proxmox .
Конечно, в Proxmox есть встроенная авторизация, в web и SSH, и возможность использовать внешние сервисы.

По умолчанию в Proxmox (из коробки) включены:
Linux PAM standard authentication
Proxmox VE authentication server

Можно добавить Microsoft Active Directory (AD), LDAP и OpenID. Можно добавить 2FA.

В чем разница Linux PAM standard authentication и Proxmox VE authentication server?
Отвечает reddit:

long story short: PAM users are normal gnu/linux user, as in username/password that you can use to log in via ssh.

PVEAS otoh are Proxmox users, they cannot be used to log in via ssh, they are stored in the clustered/distributed storage along with proxmox configuration and they are the same on all the nodes of a proxmox clusters

Как это работает в GUI на уровне DC  
Завожу пользователя user_pam как Linux PAM на уровне DC, но в поле заведения пользователя нет пароля.
Есть выбор группы, но нет предопределенных групп.
При попытке смены пароля для пользователя user_pam получаю ошибку:
change password failed: user 'user_pam' does not exist (500)
В /etc/passwd – нет такого юзера.
В /etc/pve/user.cfg есть оба созданных
По команде «pveum user list» выводится таблица того, что насоздавал. В том числе user_pam@pam.
По команде pveum passwd user_pve@pve можно сменить пароль для юзера в PVE
По команде pveum passwd user_pam@pam сменить пароль тоже нельзя – получаю ошибку
change password failed: user 'user_pam' does not exist

Но в таблице (pveum user list) он есть.

Когда я заводил юзера user_pve в realm Proxmox VE, система сразу предложила не только создать юзера, но и назначить ему права из заранее созданных наборов ролей – от Administrator до No access. 
Но это окно почему-то возникает только один раз, и это магия.

В остальных случаях оказывается, что интерфейс писали люди со своими представлениями, и права выставляются на вкладке Permission, это не только именование раздела.
И изнутри свойств объекта user эти права можно только посмотреть. Как и из Permission, или add, или remove

Остальные права выставляются как права на объект в дереве обьектов

В сочетании с ролями «что с ними делать». Наличие двух ролей Administrator и PVEAdmin только делает жизнь веселее

Управление входом в GUI отличается тем же своеобразием.
В CLI я вижу пользователя как root@pam 
Но войти в GUI, как root@pam я не могу, вне зависимости от выбора realm.
То есть, система не может сама опознать, что я ввел @realm, и realm надо выбирать вручную в GUI, и входить без указания @realm.

Управление ролями в GUI тоже отличается неожиданным подходом. К роли можно выбрать привилегии, но в выпадающем списке нет чекбоксов, но работает OnClick и OnClickAgain , то есть выбор по клику. Это было очень неожиданно.

Чуть странная, с первого взгляда, но понятная ролевая модель. То что у Microsoft называется AGDLP, тут соответственно это User <> Group <> Role <> Permissions

Отредактировать права из GUI нельзя, можно только удалить и создать. УДОБНО!

Права на «просто логин» можно дать через роль No Access, ок, понятно.
Права на консоль можно дать через привилегию Sys.Console, только она не работает «из коробки». Привилегию я выдал, причем на /», причем наследование тоже какое-то не очевидное. Но это привилегия не на запуск консоли, а на право на запуск консоли, и консоль снова запрашивает логин-пароль, но user_pve прав на вход в консоль не имеет. Решение «делать через sudoerr» описано, но проблеме со всей системой прав уже семь лет.

Наблюдается расхождение. Пользователь может быть заведен в Linux, и иметь права на SSH, и на su, но не иметь прав на pveum.

Очень, очень странно.

Примечание. В Hyper-V , несмотря на развесистую систему прав, нет делегирования права на только Hyper-V или отдельную оснастку. Можно знатно поиграть в PowerShell Web Access (PSWA),  PswaAuthorizationRule  и security descriptor definition language (SDDL), но это надо знать, во что играть.

Заключение.

Система понятна, много описано, много описано на практических примерах и форуме. Жить можно, но root отключить нельзя.
По многим причинам, в том числе я еще не описывал все приключения с кластеризацией.

Литература
Difference between RBAC vs. ABAC vs. ACL vs. PBAC vs. DAC
Red Hat Chapter 2. Using Active Directory as an Identity Provider for SSSD
Red Hat Chapter 3. Using realmd to Connect to an Active Directory Domain
Realmd and SSSD Active Directory Authentication
Proxmox User Management
Proxmox Proxmox VE Administration Guide - 14. User Management
Proxmox forum group permissions
Proxmox forum "change password failed: user 'johnsmith' does not exist (500)"
Proxmox forum Add user/group account with ssh access and root privileges
Proxmox forum SSH Login with VE Authentication Server
Proxmox Bugzilla Bug 1856 - System Updates with non-root User using Web-GUI
Proxmox CLI pveum(1)
Reddit ELI5: PAM vs PVE Authentication Server
Microsoft PowerShell Web Access in action