O KVM top mostra alta carga de CPU no host para o windows7 guest, embora o Windows esteja em ocioso

Question

temos um ambiente de virtualização com 4 VMs (2 x linux, 1 x w2k3, 1 x win7). No sistema host (Debian Jessie) top sempre mostra uma carga de CPU de 30-70% (ou mais) para o processo qemu do convidado win7, mesmo que o gerenciador de tarefas dentro do guest esteja com carga zero de cpu.

    top - 11:12:08 up 6 days,  1:47,  1 user,  load average: 0,70, 0,62, 0,55
Tasks: 216 total,   2 running, 214 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5,0 us,  3,7 sy,  0,0 ni, 91,3 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:  24776900 total, 21591188 used,  3185712 free,   122680 buffers
KiB Swap:  3905532 total,    60748 used,  3844784 free.   399364 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                              
11138 libvirt+  20   0 10,804g 8,243g  18536 R  70,1 34,9   2137:30 qemu-system-x86                      
12134 libvirt+  20   0 7309216 6,046g  18792 S   3,7 25,6 139:13.88 qemu-system-x86                      
12055 libvirt+  20   0 8900940 4,057g  18500 S   2,3 17,2 109:41.87 qemu-system-x86                      
12041 libvirt+  20   0 2956240 1,388g  18292 S   2,0  5,9  61:38.55 qemu-system-x86                      
 5569 root      20   0 1007924  23456  11012 S   1,0  0,1   1:16.86 libvirtd

DentrodoconvidadoháumMSSQL2008R2Expressemexecução.OTraceflag-T8038estáconfiguradoparaisso(deacordocom ajustes de desempenho do proxmox ). Além disso, o dispositivo tablet é removido da configuração e o dispositivo de balão é desativado dentro do guest (pois não sei como desativá-lo na configuração da VM). Além disso, também executa um servidor Pervasive SQL 8 para disparar um banco de dados antigo.

O mais estranho é que a carga da CPU no topo cai para um nível adequado (1-3%) se eu remover completamente todas as NICs do convidado. Na verdade, como um NIC, passei por um dos NICs físicos (um Intel I350). Mas o comportamento é o mesmo para as NICs virtualizadas. Tudo isso testado sem nenhum cliente conectado.

Configuração real do convidado:

<domain type='kvm'>
  <name>win7</name>
  <uuid>4b62c825-07ce-49b9-be8c-63f1f51ec28c</uuid>
  <memory unit='KiB'>8388608</memory>
  <currentMemory unit='KiB'>8388608</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
    </hyperv>
  </features>
  <cpu mode='host-model'>
    <model fallback='allow'/>
    <topology sockets='1' cores='2' threads='1'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/vg_vm/lv_win7Pro'/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <video>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x07' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Alguma dica sobre o que poderia causar isso e como melhorar?

    

Answer 1

Eu encontrei o culpado. Temos um servidor USB sobre IP ( Longshine LCS-US204 ) em nosso ambiente. O software cliente foi instalado nessa VM específica. Depois de desinstalar o software cliente, a carga da CPU no host desceu para um nível adequado. Parece que ele estava procurando por conexões o tempo todo. A remoção de todos os dispositivos virtio-serial trouxe outra pequena melhoria, agora a carga do host é de cerca de 2-3% quando o Windows está ocioso. Obrigado pela sua ajuda.

    

Answer 2

Eu tive um problema parecido no passado, com storming de IRQ no guest e alta carga no host. Você deve isolar o que, no convidado, está invadindo a CPU. O candidato principal é a instância do MSSQL e a biblioteca hal.dll.

Para depurar, siga estas etapas:

• pare sua instância do MSSQL. A carga do host diminui? Se assim for, você encontrou o culpado. O ponto é que o MSSQL usa uma frequência de temporizador alta (1ms), mesmo quando ocioso. No bare metal isso não é um problema (o sistema simplesmente usará mais alguns watts), mas em um virtualizado pode ser uma preocupação. Se possível, você deve identificar qual fonte de timer o Windows está usando e tentar alternar entre os disponíveis. Como solução alternativa, existe um patch para aumentar as interrupções do temporizador do relógio para 12 ms. Para obter mais informações, consulte aqui e aqui .
• se o ponto n.1 não trouxer benefícios, talvez o problema seja relacionado a HAL. Vejo que você está usando dois vCPU; tente iniciar a VM com uma única vCPU. Isso muda alguma coisa? Se não, faça uma captura de tela da guia de hardware do Windows (expandindo o nó HAL) e reporte aqui.

EDIT: Ok, parece que nem o MSSQL nem o HAL são a causa raiz da carga do seu host. Vá em frente para a segunda fase de depuração:

• interrompa sua máquina virtual e remova, de sua definição, todos os dispositivos USB. Reinicie a máquina e verifique a carga do host: ela mudou?
• se não, use o utilitário powertop para monitorar a atividade da CPU do host. Aqui você deve ver qual rotina de software / interrupção é mais atendida. Corra em 30 segundos e reporte aqui.