Bug 873926 - When CPUs in host aren't equal ,libvirt should report error
Summary: When CPUs in host aren't equal ,libvirt should report error
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt   
(Show other bugs)
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Jiri Denemark
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: libvirtCPUconfig
TreeView+ depends on / blocked
 
Reported: 2012-11-07 01:27 UTC by hongming
Modified: 2016-04-27 04:28 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-23 23:11:48 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cpuinfo (3.43 KB, text/plain)
2012-11-07 01:29 UTC, hongming
no flags Details

Description hongming 2012-11-07 01:27:57 UTC
Description of problem:
When CPUs in host aren't equal.libvirt should  report error to user. Or successfully starting one guest will depends on the cpu' capabilities that libvirtd' work threads running on.

There is one test machine which has 4 cpus,but cpu0 doesn't have the monitor flag,and the other cpus have it.When start one guest with sandybridge cpu model . it will success when libvirtd' worker threads on cpu1-3 ,fail on cpu0.


Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.329.el6.x86_64
libvirt-0.10.2-7.el6.x86_64
kernel-2.6.32-335.el6.x86_6 

How reproducible:
100% 

Steps to Reproduce:
# for i in {1..5};do virsh capabilities|grep monitor|wc -l;done
1
1
0
0
0


# virsh capabilities  (There isn't the "monitor" feature ,libvirtd is running on cpu0, but host cpu 1-3 include it)
<capabilities>

<host>
<uuid>5bc55087-5efb-5107-6702-5133293b515f</uuid>
<cpu>
<arch>x86_64</arch>
<model>SandyBridge</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='4' threads='1'/>
<feature name='osxsave'/>
<feature name='pdcm'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='smx'/>
<feature name='vmx'/>
<feature name='ds_cpl'/>
<feature name='dtes64'/>
<feature name='pbe'/>
<feature name='tm'/>
<feature name='ht'/>
<feature name='ss'/>
<feature name='acpi'/>
<feature name='ds'/>
<feature name='vme'/>
</cpu>
......
<capabilities>


# virsh start rhel6.3-new
error: Failed to start domain rhel6.3-new
error: unsupported configuration: guest and host CPU are not compatible:
Host CPU does not provide required features: monitor


# virsh dumpxml rhel6.3-new  (There is the "monitor" feature)
<domain type='kvm'>
   ......
<cpu mode='custom' match='exact'>
<model fallback='allow'>SandyBridge</model>
<vendor>Intel</vendor>
<feature policy='require' name='tm2'/>
<feature policy='require' name='est'/>
<feature policy='require' name='monitor'/>
......
</cpu>
.....
</domain> 

Actual results:
When CPUs in host aren't equal , successfully  starting  one guest will depends on the cpu' capabilities that libvirtd'work threads running on. 

Expected results:
When CPUs in host aren't equal.libvirt should report error to user.


Additional info:

Comment 1 hongming 2012-11-07 01:29:36 UTC
Created attachment 639729 [details]
cpuinfo

Comment 3 Peter Krempa 2012-11-07 10:41:55 UTC
I don't think we should report an error right away. If the processors aren't equal the user is still able to start guests that use the flags that are shared by all the cores. To fix this, we will need to run the CPUID code on every processor and then calculate an intersection of all those flags to get the largest subset of flags that are supported by the system. (And probably introduce som kind of caching of this data so we don't need to re-calculate them every time)

Comment 7 Cole Robinson 2016-03-23 23:11:48 UTC
Yeah given the weirdness of a non-uniform CPU layout, I'm just closing this as DEFERRED, we can address it if anyone ever has problems in production


Note You need to log in before you can comment on or make changes to this bug.