Estou migrando de Xen para Kvm.
No Xen, consegui fixar facilmente o cpus do host para vms convidado e também para fixar o cpus do host ao "dom0" .
No Kvm, também posso fixar facilmente o cpus do host aos vms convidados, mas, até onde posso ver, nada impede que o aplicativo executado no sistema operacional do host use esses cpus. Eu quero evitar o caso em que um programa em execução no host falhe / aumente a latência dos convidados.
Eu poderia fazer manualmente uma política de cgroup elaborada, mas talvez esteja faltando uma configuração em libvirt / centos7 ?
Também há também uma configuração "emulatorpin" para os hóspedes. Devo fixar o "emulador" ao cpus host dedicado ou devo apenas restringi-lo ao cpus convidado ? O objetivo é limitar ao máximo a latência do convidado .
Se entendi sua pergunta corretamente, o que você deseja alcançar é restringir o hipervisor para que ele possa usar apenas uma única CPU/núcleo (ou um número limitado) para seus próprios processos, manipulação de interrupções e tudo mais. E que todos os outros núcleos podem ser atribuídos pela libvirt a sistemas convidados.
Relativamente simples é o
isolcpus
parâmetro de inicialização que permite isolar uma ou mais CPUs do agendador. Isso evita que o escalonador agende quaisquer threads de espaço do usuário nesta CPU.ou seja, no seu hipervisor em
/etc/default/grub
conjunto:isso deve impedir que qualquer programa de espaço do usuário no hipervisor use núcleos > 1. A Libvirt pode então fixar servidores virtuais nos núcleos livres restantes.
Não tenho certeza se o
isolcpus
parâmetro de inicialização também garante que todas as interrupções sejam restritas a esses núcleos. Caso contrário, as interrupções também têm sua própria propriedade de afinidade,smp_affinity
, que define os processadores que tratarão da solicitação de interrupção. O valor de afinidade de interrupção para uma solicitação de interrupção específica é armazenado no/proc/irq/irq_number/smp_affinity
arquivo associado e o padrão é definido com/proc/irq/default_smp_affinity
. smp_affinity é armazenado como uma máscara de bits hexadecimal que representa todos os processadores no sistema. O valor padrão é f, significando que uma solicitação de interrupção pode ser tratada em qualquer processador do sistema. Definir esse valor como 1 significa que apenas o processador 0 pode lidar com a interrupção.A ferramenta para controlar a afinidade de processador e agendamento para RHEL e CentOS 7 é chamada
tuna
No Linux, se você deseja que um processo use apenas uma CPU específica em seu host, o
taskset
comando pode ajudarexecutando um novo programa em dois cpus:
Para alterar a afinidade da CPU do processo já em execução:
não existe dom0 no kvm, você tem o módulo do kernel kvm, então tudo está integrado no kernel, não é como no xen que você tem o dom0 como domínio privilegiado, então você pode fixar o processo que o kernel roda.
isolcpus
agora está obsoleto :usar
cpuset
comlibvirt