Тип процессора "host" значительно замедляет работу Windows 11 (см. https://forum.proxmox.com/threads/cpu-type-host-is-significantly-slower-than-x86-64-v2-aes.159107/), но если переключиться с него, в безопасности Windows появляется желтый предупреждающий значок из-за целостности памяти. Нет ли способа получить и хорошую производительность, и отсутствие предупреждений?

Несколько замечаний по этому поводу: вам не нужен тип CPU "host". Memory Isolation использует Hyper-V для запуска критически важных процессов внутри виртуализированной среды. По сути, сейчас это требует вложенной виртуализации. Как вы, возможно, знаете, вложенная виртуализация может работать медленно и при этом зависит от производителя. Например, поддержка вложенной виртуализации у AMD появилась совсем недавно и пока не так развита, как у Intel. Чтобы минимизировать эффект, можно включить специальные параметры для улучшения производительности. Опция hv-evmcs в интерфейсе Proxmox поможет, но только для процессоров Intel. Рекомендую вручную отредактировать конфигурационный файл /etc/pve/qemu-server для вашей ВМ и добавить туда вот это:  
Код:  
args: -cpu Skylake-Client-v4,vmx,hv-passthrough  

Это включит вложенную виртуализацию и все доступные Hyper-V оптимизации. Вы можете настроить большие страницы памяти по 1 ГБ на хосте и порекомендовать гостю использовать их через pdpe1gb, но в моих тестах разница была незначительной. Microsoft активно работает над улучшением ситуации. В недавно выпущенном QEMU 10.2 добавили ускоритель MSHV, который по сути позволяет запускать Hyper-V ВМ без использования вложенной виртуализации. Я пока не тестировал, но, похоже, скоро мы сможем включать Memory Isolation без потери производительности. С нетерпением жду появления QEMU 10.2 в тестовом репозитории Proxmox pve-test.

Теперь это в тестовом репозитории. Есть баг, из-за которого веб-панель кажется медленной, но на самом деле производительность не снижается, как видно из обсуждения ниже. https://forum.proxmox.com/threads/applying-pve-qemu-kvm-10-2-1-1-may-cause-extremely-high-“i-o-delay”-and-extremely-high-“i-o-pressure-stalls”-patches-in-the-test-repository.182186/page-2

Для меня главная проблема с QEMU — это не необходимость драйверов virtio, а плохая производительность при вложенной виртуализации (чтобы использовать изоляцию памяти Hyper-V). Не думаю, что OpenVMM решает эту проблему. /dev/mshv тоже волшебным образом её не решает; его нужно запускать внутри среды Hyper-V, где он может взаимодействовать с гипервизором L0.

Редактировка: нижеописанное не сработает на «голом» железе. Работать это будет только на Microsoft Hyper-V. Я ошибался. Это попытка Microsoft запустить QEMU напрямую поверх Microsoft Hypervisor (как в Azure Linux root partitions), примерно так же, как QEMU использует KVM в обычном Linux. Особенно это важно для запуска QEMU-виртуалок на инфраструктуре Azure или на любом Linux, где в качестве гипервизора используется MSHV вместо (или возможно параллельно с) KVM.

MSHV (/dev/mshv) — это не то, что устанавливается на «голое» железо так же, как KVM. Microsoft Hypervisor — это гипервизор первого типа, а драйвер MSHV в ядре открывает интерфейс IOCTL через /dev/mshv, но только когда Linux реально работает как root partition поверх Microsoft Hypervisor (например, на Azure или на машине, где гипервизор MS — это гипервизор на уровне прошивки).

MSHV имеет смысл использовать только на Azure или на выделенном железе с Hyper-V root partition. Хотя можно собрать кастомное ядро с HYPERV и попытаться запустить proxmox на этом ядре (удачи):

Код:

# Устанавливаем зависимости для сборки ядра  
sudo apt install -y build-essential libncurses-dev bison flex libssl-dev libelf-dev bc dwarves fakeroot  

# Клонируем репозиторий ядра Microsoft MSHV  
git clone https://github.com/microsoft/OHCL-Linux-Kernel.git  
cd OHCL-Linux-Kernel  

# Используем конфиг с поддержкой MSHV  
cp config-mshv-builtin .config  

# Активируем нужную опцию  
scripts/config --enable CONFIG_HYPERV_ROOT_API  

# Собираем ядро в пакет для Debian  
make -j$(nproc) bindeb-pkg  

# Устанавливаем пакет  
sudo dpkg -i ../linux-image-*.deb  
sudo reboot  

После перезагрузки проверьте:  
ls /dev/mshv

Дайте знать, как у вас успехи. У меня всего один кейс, где это может пригодиться, но я сомневаюсь, что оно стоит всей этой административной головной боли. Пока MSHV не вшит по умолчанию в ядро Proxmox, я бы не стал использовать это в продакшене. Но как исследовательский проект — интересно.

Ты прав — так не получится. Я ошибался. Microsoft Hypervisor не является самостоятельным устанавливаемым компонентом. Он существует в двух формах: встроенный в Windows — активируется, когда ты включаешь роль Hyper-V в Windows Server или Windows 11. Бинарный файл гипервизора загружается при старте через UEFI ещё до запуска самой Windows. И работает внутри Azure — Microsoft запускает его на железе своих дата-центров как гипервизор на уровне микропрограммы, а в качестве основной системы используется Linux. Исследователи, которые пытались достать сам бинарник гипервизора, не смогли выделить его отдельно от установки Hyper-V Server Core. Ссылок на исходный код очень мало, и нет никакой публичной документации о том, как он связан с процессом загрузки Windows.

Но есть и другие варианты, например OpenVMM и в будущем OpenHCL: OpenVMM — это Type-2 виртуальная машина, написанная на Rust. На Linux она работает поверх KVM, то есть использует /dev/kvm как бэкенд ускорения, а не MSHV. По сути, это альтернатива QEMU, но с использованием модели устройств Microsoft Hyper-V (VMBus, storvsp, netvsp) вместо устройств virtio/QEMU. Сам Майкрософт предупреждает, что OpenVMM на хосте пока не готов к запуску пользовательских задач и должен рассматриваться как платформа для разработки новых функций OpenVMM, а не как готовое решение для внедрения.

Так что на Proxmox OpenVMM будет: использовать KVM под капотом (как QEMU), запускать ВМ с устройствами, совместимыми с Hyper-V, но при этом никакой интеграции с интерфейсом Proxmox, хранилищем или сетью не будет. (Я, в любом случае, человек консолей.) Это уже можно запустить на Proxmox как самостоятельный бинарник, но с оговорками:

Код:  
# Установка Rust (OpenVMM написан только на Rust, готовых пакетов нет)  
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh  
source $HOME/.cargo/env  

# Установка зависимостей для сборки  
apt install -y git build-essential protobuf-compiler pkg-config libssl-dev clang  

git clone https://github.com/microsoft/openvmm.git  
cd openvmm  

# Загрузка необходимых пакетов (UEFI прошивки, тестовые ядра, protoc и др.)  
cargo xflowey restore-packages  

# Сборка OpenVMM  
cargo build --release -p openvmm  

Запуск виртуальной машины (пример: Alpine Linux)  
OpenVMM использует CLI-интерфейс, сильно отличающийся от QEMU:

Код:  
# Простая ВМ с бэкендом KVM, используя встроенный UEFI OpenVMM  
./target/release/openvmm \  
   --backend kvm \  
   --memory 1024 \  
   --processors 2 \  
   --disk path=alpine.img \  
   --nic consomme   # встроенный NAT-сетевой интерфейс  

Реальный кейс на сегодня — запуск Windows ВМ с нативными устройствами Hyper-V без необходимости ставить драйверы virtio. Поскольку OpenVMM использует модель устройств Hyper-V напрямую, гостевые Windows видят среду как Hyper-V и не требуют дополнительной установки драйверов. Но повторюсь, это пока не готово к рабочим нагрузкам.  

Более интересное направление — OpenHCL: открытый paravisor от Microsoft, который запускает OpenVMM внутри гостевой системы на более высоком уровне привилегий. Microsoft заявляла, что планирует развивать поддержку OpenHCL для KVM на стороне хоста в сотрудничестве с облачными провайдерами и сообществом Linux/KVM. Это в итоге должно привнести функции защиты конфиденциальности для ВМ в гипервизоры на базе KVM, такие как Proxmox, но пока это работа на будущее.  

Итог: для домашней лаборатории на Proxmox сегодня выгоды от OpenVMM по сравнению с QEMU/KVM немного. Но стоит следить за развитием OpenHCL и KVM. В любом случае, может попробую — длинные пасхальные выходные как раз скоро...