Libvirt (Qemu+KVM+Virt-manager) гостевые ОС люто юзают ресурсы гипервизора

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

а таймеры для виндового гостя кто включать будет?

 <hyperv>
      <tlbflush state='on'/>
      <ipi state="on"/>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <vpindex state='on'/>
      <runtime state='on'/>
      <synic state='on'/>
      <stimer state='on'/>
      <reset state='on'/>
    </hyperv>

Спасибо

https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/optimizing-windows-virtual-machines-on-rhel_installing-and-managing-windows-virtual-machines-on-rhel

неважно будь то Win либо Lin.

А вот тормоза на вм с линуксом уже странно. У меня на debian 12 такого нет

Попробуй начать с базовой проверки

virt-host-validate

может в uefi сервера виртуализацию зачем-то отключили

HP ProLiant DL360 G5

что-то древнее, проверь работу аппаратной поддержки виртуализации

root@tarh-work:~# virt-host-validate 
  QEMU: Checking for hardware virtualization                                 : PASS
  QEMU: Checking if device /dev/kvm exists                                   : PASS
  QEMU: Checking if device /dev/kvm is accessible                            : PASS
  QEMU: Checking if device /dev/vhost-net exists                             : PASS
  QEMU: Checking if device /dev/net/tun exists                               : PASS
  QEMU: Checking for cgroup 'cpu' controller support                         : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support                     : PASS
  QEMU: Checking for cgroup 'cpuset' controller support                      : PASS
  QEMU: Checking for cgroup 'memory' controller support                      : PASS
  QEMU: Checking for cgroup 'devices' controller support                     : PASS
  QEMU: Checking for cgroup 'blkio' controller support                       : PASS
  QEMU: Checking for device assignment IOMMU support                         : PASS
  QEMU: Checking if IOMMU is enabled by kernel                               : PASS
  QEMU: Checking for secure guest support                                    : WARN (AMD Secure Encrypted Virtualization appears to be disabled in firmware.)
   LXC: Checking for Linux >= 2.6.26                                         : PASS
   LXC: Checking for namespace ipc                                           : PASS
   LXC: Checking for namespace mnt                                           : PASS
   LXC: Checking for namespace pid                                           : PASS
   LXC: Checking for namespace uts                                           : PASS
   LXC: Checking for namespace net                                           : PASS
   LXC: Checking for namespace user                                          : PASS
   LXC: Checking for cgroup 'cpu' controller support                         : PASS
   LXC: Checking for cgroup 'cpuacct' controller support                     : PASS
   LXC: Checking for cgroup 'cpuset' controller support                      : PASS
   LXC: Checking for cgroup 'memory' controller support                      : PASS
   LXC: Checking for cgroup 'devices' controller support                     : PASS
   LXC: Checking for cgroup 'freezer' controller support                     : FAIL (Enable 'freezer' in kernel Kconfig file or mount/enable cgroup controller in your system)
   LXC: Checking for cgroup 'blkio' controller support                       : PASS
   LXC: Checking if device /sys/fs/fuse/connections exists                   : PASS
root@tarh-work:~# 

От тебя всегда что-то полезное, спасибо.

-> Вот <- выхлоп Вашей команды

После внесения предложенных Вами параметров в конфиг виртуалки - эффект нулевой…=(

Благодарю за ссылку на ред-хатовский ман для дебиан по добавлению драйверов virtio, а также рекомендациям использовать их, но это всё уже сделано

То есть тот факт, что гостевая ОСь стоит Вас никак не смущает? Всё-таки необходимо проверить поддержку аппаратной виртуализации?

Специально для Вас даже поставил утилиту cpu-checker

root@hpkvm:~# /sbin/kvm-ok 
INFO: /dev/kvm exists
KVM acceleration can be used
root@hpkvm:~# 

Покажите выхлоп

grep . /sys/devices/system/cpu/vulnerabilities/*

ps aux|grep qemu при запущенной виртуалке что выдаёт? Интересуют параметры командной строки, с которыми запущен qemu.

добавляйте mitigations=off станет лучше, этим древним процессорам и так не сладко

-> Целая портянка <-

Ну во-первых в debian 11 всё работало штатно. Параметры ЦП я всегда ставил host-passthrough что в 12-ом дебе случилось? А во-вторых не совсем понимаю где поставить параметр mitigations=off не подскажите…? =)

в командную строку ядра при загрузке, делается это в /etc/default/grub, и не забудь update-grub. Потом ребут, и посмотреть, загрузилось ли с нужной строкой, можно с помощью cat /proc/cmdline

Гостям тоже надо поотключать, для винды - через реестр или утилитка есть, называется InSpectre.

А тупит скорее всего поэтому

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled

Отличная митигация, my ass. Лечение головной боли методом отсечения головы. Особенно смешно это в свете того, что ни одной атаки с помощью этих «уязвимостей» в истории человечества зафиксировано не было, равно как и работающих эксплоитов в реальной жизни.

mitigations=off, потом в винде ещё что-то отключать, Это уже костыли получаются. Такого же не должно быть…

Ну во-первых в debian 11 всё работало штатно.

На том же самом сервере (не просто одинаковым по железу, а конкретно на этом) ?

Совершенно верно…! Это говно Этот музейный экспонат больше для тестов. На нём «вчера» стоял deb11 + виртуализация (libvirt). На гостевых ОСях был openvpn и УТМ для реализации бухла, обе ОСи - debian. Всё работало отлично. Тут решил поюзать deb12, перекинул виртуалки на «боевой» сервер, а на этом экспериментирую ну и сопсна проблема изложена выше

Mitigation: VMX disabled

Нифига себе. А все утилиты проверки врут…

Спасибо, записал

Не работает 3д ускорение на kvm

Тут человеку помогла установка пакета qemu-system-gui

Это уже костыли получаются. Такого же не должно быть…

Надо, Федя, надо…

Как правильно заметил pekmop1024, у тебя отключена поддержка виритуализации. Хотя все утилиты и уверяют в обратном, но «vmx disabled» говорит вполне однозначно. Видимо, слишком старый процессор, и других вариантов устранения уязвимости для него не нашлось. Отключай, иначе жизни не будет

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled

Есть ещё вариант попробовать поставить пакет intel-microcode

Но с такими симптомами я чет боюсь. Решать тебе

mitigations=off, потом в винде ещё что-то отключать, Это уже костыли получаются. Такого же не должно быть…

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

Есть ещё вариант попробовать поставить пакет intel-microcode

Категорически рекомендую его наоборот удалить. Равно как и откатить биос на до-спектровую эпоху. Потому что:

• в микрокоте сидят те же митигейшнсы;
• в новых биосах сидит новый микрокот.

Если я правильно понял, конкретно от vmx disabled можно попробовать не mitigations=off, а kvm.nx_huge_pages=off

https://www.kernel.org/doc/html/next/admin-guide/hw-vuln/multihit.html

Можно конечно попробовать гранулярно, но все остальные митигейшнсы скушают до 40% производительности (от сценария использования). Зачем оно?

Пичалька… А этот пакет заливает обновления при каждой загрузке, или навсегда?

При каждой загрузке. Тот что в прошивке - тоже при каждой загрузке - соответственно, прошивки.

Но с микрокотом все не так однозначно. Там и фиксы нужных вещей иногда бывают. А вот mitigations=off - маст хэв.

Благодарю за участие, но пакет установлен ранее. Результат - 0.

Смотрю у себя

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled

Процессор лет на семь посвежее, конечно — Intel(R) Core(TM) i3-4160

Не наблюдаю таких проблем. Только пускаю виртуалки без всяких libvirt, через sh файл с qemu-system-x86_64.

А если дать гостю 2 ядра CPU?

хотя знаешь, тема ещё не закрыта

https://serverfault.com/a/1132872/166198

vmx looks present and not disabled by bios. Vulnerability present, but now vmx is not in use, thus is just disabled. when some kvm is run and use vmx, situations changed:

так и есть. ноут, i5-8250, вм работают (и без тормозов)

itlb_multihit:KVM: Mitigation: Split huge pages

останавливаю ВМ

itlb_multihit:KVM: Mitigation: VMX disabled

ну т.е. попробовать mitigations=off все же стоит, но возможно не оно

Дурацкая идея, но можно проверить: в bookworm перешли на apparmor, и включили его по умолчанию. попробуй для проверки отключить (apparmor=0 в kernel cmdline, после загрузки проверка через aa-status)

и ещё. попробуй не мигрировать ВМ обратно, а создать с нуля одну новую (будет актуальное virtual hardware и конфиг), причем именно linux. без других ВМ. тормоза останутся?

То есть тот факт, что гостевая ОСь стоит Вас никак не смущает?

для установки и работы гостя не требуется

KVM acceleration can be used

ага, именно что CAN BE, но НЕ used. «Может быть использовано» != «использовано».

Примером конфига sh поделишься…?

Брал здесь:

https://gitlab.com/users/post-factum/snippets

В общем снёс к херам 12-ый дебиан, поставил 11-ый, накатил виртуализацию и всё работает штатно, без неадекватных нагрузок на CPU. Возможно в 6-ом кернеле что-то добавили/убрали, возможно Intel(R) Xeon(R) CPU E5450 для него древний, не знаю.

P.S> Установка Deb11 на HP ProLiant DL360 G5 тоже без бубна не обошлась. При установке он сеть не нашёл, а после для работы сети необходимо поставить firmware-bnx2_20210315-3_all.deb только тогда сеть взлетела.

HP ProLiant DL360 G5

В нём два Xeon-а?

Возможно в 6-ом кернеле что-то добавили/убрали

Чтобы не гадать о таких вещах, существует perf

Да, 2

А почему тогда

<cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' cores='4' threads='2'/>

Ведь согласно

/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled

Hyper-threading выключен.

Здесь пишут, что надо NUMA включать
https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines

(если хочется восемь ядер в гостя передать)