Created attachment 1100263 [details] vdsm log Description of problem: Vdsm daemon failed to start on hosts without cpu under number 1, because incorrect cpu affinity with traceback: Traceback (most recent call last): File "/usr/share/vdsm/vdsm", line 166, in run __set_cpu_affinity() File "/usr/share/vdsm/vdsm", line 280, in __set_cpu_affinity taskset.set(os.getpid(), cpu_set, all_tasks=True) File "/usr/lib/python2.7/site-packages/vdsm/taskset.py", line 82, in set raise Error(rc, out, err) Error: Process failed with rc=1 out=["pid 129019's current affinity list: 8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152"] err=["taskset: failed to set pid 129019's affinity: Invalid argument"] Version-Release number of selected component (if applicable): vdsm-4.17.11-0.el7ev.noarch How reproducible: Always Steps to Reproduce: 1. Start vdsm daemon on host that not have cpu under number 1 # cat /proc/cpuinfo processor : 8 cpu : POWER8E (raw), altivec supported clock : 3690.000000MHz revision : 2.1 (pvr 004b 0201) processor : 16 cpu : POWER8E (raw), altivec supported clock : 3690.000000MHz revision : 2.1 (pvr 004b 0201) .... 2. 3. Actual results: vdsm daemon failed to start with above exception Expected results: vdsm succeed to start Additional info: problem in vdsm config file ('cpu_affinity', '1', 'Comma separated whitelist of CPU cores on which VDSM is allowed ' 'to run. The default is "1", meaning VDSM can be scheduled by ' ' the OS to run on the second core of the system. ' 'Valid examples: "1", "0,1", "0,2,3"') if I change it to 'cpu_affinity', '', all works fine
Seems to be related the enablement of BZ #1279431
Decreasing Severity as there is a configuration workaround to pin to a different cpu or disable it altogether This is not ppc specific, any platform with offline cpu1 would demonstrate the same. We should have go with 0
patches merged on both master and 3.6 branch -> MODIFIED
This bug is referenced in 4.17.12 git log and has target release unset. Please check
Verified on vdsm-4.17.12-0.el7ev.noarch
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.