Le top KVM affiche une charge CPU élevée sur l'hôte pour Windows7, bien que Windows soit inactif

nous avons un environnement de virtualisation avec 4 machines virtuelles (2 x linux, 1 x w2k3, 1 x win7). Dans le système hôte (Debian Jessie), le haut affiche toujours une charge de CPU de 30 à 70% (ou plus) pour le process qemu de l'invité win7 même si le gestionnaire de tâches à l'intérieur de l'invité est à zéro charge de l'ordinateur.

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 

Performance du gestionnaire de tâches chez l'invité

À l'intérieur de l'invité, il y a un MSSQL 2008 R2 Express en cours d'exécution. Traceflag -T8038 est configuré pour cela (selon les réglages de performance de proxmox ). En outre, la tablette est supprimée de la configuration et le dispositif à ballonnet est désactivé à l'intérieur des invités (car je ne sais pas comment le désactiver dans la configuration VM). En outre, il exécute également un server Pervasive SQL 8 pour démarrer une ancienne database bsortingeve.

La chose étrange est que la charge de la CPU dans la partie supérieure baisse à un niveau adéquat (1-3%) si j'enleve complètement toutes les NIC de l'invité. En fait, en tant que NIC, j'ai traversé l'une des NIC physiques (un Intel I350). Mais le comportement est le même pour les NIC virtualisées. Tout cela a été testé sans aucun client connecté.

Configuration réelle des invités:

 <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' resortinges='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> 

Quelques conseils que cela pourrait provoquer et comment améliorer?

J'ai eu un problème similaire dans le passé, avec l'invocation IRQ dans l'invité et une charge élevée sur l'hôte. Vous devez isoler ce qui, dans l'invité, met en panne la CPU. Le candidat principal est à la fois l'instance MSSQL et la bibliothèque hal.dll.

Pour déboguer, procédez comme suit:

  • arrête votre instance MSSQL. La charge de l'hôte diminue-t-elle? Si c'est le cas, vous avez trouvé le coupable. Le point est que MSSQL utilise une fréquence de timer élevée (1 ms), même en mode veille. Sur le métal nu, ce n'est pas un problème (le système utilisera simplement plus de watts), mais sur une virtualisation, cela peut être une préoccupation. Si possible, vous devez identifier la source de timer utilisée par Windows et essayer de créer entre les disponibles. Comme solution de contournement, il existe un patch pour augmenter la temporisation de l'horloge jusqu'à 12ms. Pour plus d'informations, consultez ici et ici .
  • Si le point n.1 n'apporte aucun avantage, peut-être que le problème est lié à HAL. Je vois que vous utilisez deux vCPU; essayez de démarrer la VM avec une seule vCPU. Cela change-t-il quelque chose? Si non, faites une capture d'écran de l'onglet matériel de Windows (en élargissant le nœud HAL) et reportez-vous ici.

EDIT: Ok, il semble que ni MSSQL ni HAL ne soient la cause principale de votre chargement hôte. Passez à la deuxième phase de debugging:

  • Arrêtez votre machine virtuelle et supprimez, à partir de sa définition, tous les périphériques USB. Redémarrez la machine et vérifiez la charge de l'hôte: elle a changé?
  • Dans le cas powertop , utilisez l'utilitaire powertop pour surveiller l'activité CPU de l'hôte. Ici, vous devriez voir ce que la routine / interruption du logiciel est la plus performante. Dirigez-vous en 30 secondes et reportez-vous ici.

J'ai trouvé le coupable. Nous avons un server USB-sur-IP ( Longshine LCS-US204 ) dans notre environnement. Le logiciel client a été installé sur cette VM spécifique. Après la désinstallation du logiciel client, la charge de la CPU sur l'hôte est passée à un niveau adéquat. On dirait qu'il était à la search de connections tout le time. La suppression de tous les périphériques virtio-serial a apporté une autre petite amélioration, maintenant la charge de l'hôte est d'environ 2-3% lorsque Windows est inactif. Merci de votre aide.