Bug 820625

Summary: Unable to change CPU affinity of QEMU-KVM VMs after resuming laptop from suspend
Product: [Fedora] Fedora Reporter: Dennis H <hous3y>
Component: kernelAssignee: Justin M. Forbes <jforbes>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: crobinso, gansalmon, itamar, jforbes, jonathan, kernel-maint, kzak, madhu.chinakonda, mluscon
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-05 15:10:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dennis H 2012-05-10 14:08:18 UTC
Description of problem:

I have a Windows 7 x86_64 VM and a Fedora Rawhide VM running on qemu-kvm. The host of these VMs is a Dell Latitude E6510 laptop with a quad core Intel i7 cpu running Fedora 16. On a fresh poweron of the laptop everything works normally, I can change the CPU pinning of the VMs without any problem. If I suspend the laptop and resume then all VMs are bound to CPU0. Taskset returns an invalid argument when trying to change the affinity of the qemu-kvm processes. Using virsh and virt-manager to try to change the pinning returns the same errors. I can change the affinity of any other processes without issue. I have had this problem for a couple months now.

Version-Release number of selected component (if applicable):
libvirt-client-0.9.6-5.fc16.x86_64
libvirt-0.9.6-5.fc16.x86_64
libvirt-python-0.9.6-5.fc16.x86_64
kernel-3.3.4-3.fc16.x86_64
util-linux-2.20.1-2.3.fc16.x86_64
qemu-kvm-0.15.1-4.fc16.x86_64

How reproducible:
Every time I suspend and resume the laptop, and it only affects libvirt guests. All other processes can change cpu affinity fine. It does not matter if I start any guests or not. Restarting libvirtd does not help. I have to reboot the machine to clear the issue.

Steps to Reproduce:
1. Boot laptop
2. suspend laptop
3. start guests
4. try to change guest cpu affinity

-OR-

1. Boot laptop
2. start guests
3. suspend laptop
4. try to change guest cpu affinity


Actual results:

#for example, init can run on all four CPUs:
sudo taskset -pc 1
pid 1's current affinity list: 0-3
#the qemu-kvm processes are pegged to cpu 0
sudo taskset -pc 1 4424
pid 4424's current affinity list: 0
taskset: failed to set pid 4424's affinity: Invalid argument

Expected results:
affinity list should show 0-3 for all processes, and should be able to modify affinity.

Additional info:

virsh # capabilities
<capabilities>

  <host>
    <uuid>44454c4c-3600-1032-8057-b8c04f574e31</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Nehalem</model>
      <vendor>Intel</vendor>
      <topology sockets='1' cores='4' threads='1'/>
      <feature name='rdtscp'/>
      <feature name='xtpr'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='monitor'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
      <feature name='vme'/>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='1'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
          </cpus>
        </cell>
      </cells>
    </topology>
  </host>

  <guest>
    <os_type>hvm</os_type>
    <arch name='i686'>
      <wordsize>32</wordsize>
      <emulator>/usr/bin/qemu</emulator>
      <machine>pc-0.14</machine>
      <machine canonical='pc-0.14'>pc</machine>
      <machine>fedora-13</machine>
      <machine>pc-0.13</machine>
      <machine>pc-0.12</machine>
      <machine>pc-0.11</machine>
      <machine>pc-0.10</machine>
      <machine>isapc</machine>
      <domain type='qemu'>
      </domain>
      <domain type='kvm'>
        <emulator>/usr/bin/qemu-kvm</emulator>
        <machine>pc-0.14</machine>
        <machine canonical='pc-0.14'>pc</machine>
        <machine>fedora-13</machine>
        <machine>pc-0.13</machine>
        <machine>pc-0.12</machine>
        <machine>pc-0.11</machine>
        <machine>pc-0.10</machine>
        <machine>isapc</machine>
      </domain>
    </arch>
    <features>
      <cpuselection/>
      <deviceboot/>
      <pae/>
      <nonpae/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' toggle='no'/>
    </features>
  </guest>

  <guest>
    <os_type>hvm</os_type>
    <arch name='x86_64'>
      <wordsize>64</wordsize>
      <emulator>/usr/bin/qemu-system-x86_64</emulator>
      <machine>pc-0.14</machine>
      <machine canonical='pc-0.14'>pc</machine>
      <machine>fedora-13</machine>
      <machine>pc-0.13</machine>
      <machine>pc-0.12</machine>
      <machine>pc-0.11</machine>
      <machine>pc-0.10</machine>
      <machine>isapc</machine>
      <domain type='qemu'>
      </domain>
      <domain type='kvm'>
        <emulator>/usr/bin/qemu-kvm</emulator>
        <machine>pc-0.14</machine>
        <machine canonical='pc-0.14'>pc</machine>
        <machine>fedora-13</machine>
        <machine>pc-0.13</machine>
        <machine>pc-0.12</machine>
        <machine>pc-0.11</machine>
        <machine>pc-0.10</machine>
        <machine>isapc</machine>
      </domain>
    </arch>
    <features>
      <cpuselection/>
      <deviceboot/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' toggle='no'/>
    </features>
  </guest>

</capabilities>

Comment 1 Justin M. Forbes 2012-05-10 16:39:09 UTC
There are some patches floating around to get this resolved fairly soon, but for now, it is a known issue.  I will get the patches in once they are worked out.

Comment 2 Cole Robinson 2012-06-05 15:10:58 UTC

*** This bug has been marked as a duplicate of bug 714271 ***