<div dir="ltr"><div class="gmail_extra">Very interesting,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you for the background,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 10, 2014 at 2:41 PM, Itamar Heim <span dir="ltr"><<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 02/10/2014 09:33 PM, Peter Galgano wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you Itamar, this is very helpful. When we restart our testing, we<br>
will test this and update this post for future users to find.<br>
<br>
snip<br>
<br>
actually, i wonder which flag its missing that libvirt did not<br>
detect it as any supported model.<br>
<br>
<br>
endsnip<br>
<br>
<br>
I can see if i can compare the function flags to determine the model of<br>
the processor, and perhaps this will give us a clue as to a functional<br>
differentiation between the netburst architecture and core architecture<br>
for your purposes.<br>
<br>
Does the hypervisor do anything different based on which extensions are<br>
passed? I believe<br>
<br>
I would note that RHEV system requirements is simply 64 bit and<br>
virtualization extensions, I suppose all processors should be supported,<br>
including older ones. I also assume the system will not run newer<br>
processors as hosts, so I guess that the developers will have to update<br>
this list of capabilities to be passed to qemu libvirt in the future,<br>
and that the list of processors will become longer and more confusing<br>
over time.<br>
<br>
I suppose you could have a facility where the user can query and manage<br>
the host processor and the profile of capabilities passed to qemu?<br>
<br>
Might it not be best to avoid identifying the "branding" the processor,<br>
and instead concentrate on identifying and informing the user which<br>
capabilities are found and will be passed to guests. You could warn<br>
users if certain capabilities are absent which may be important, and<br>
expect the user to update their hardware as they see fit. I frankly do<br>
not typically care about processor functions unless I am lacking one<br>
that is required by the system I am running ie: vx extensions. I assume<br>
that other features may limit which OS you run ie pae, nx, sse2 being<br>
required for Windows 8. Otherwise I assume that extensions may increase<br>
performance or are not used by most operating systems and software.<br>
<br>
for example:<br>
<br>
"the system found the following processor features on this host:<br>
vmx,sse2. The following features will be passed to guests:<br>
qemu64,+sse2 . Note that some processors may lack features that are<br>
required by guest os's or are recommended for better performance. Note<br>
that this processor lacks NX extensions and may not run Windows 8 guests.<br>
<br>
Thank you again for your assistance in understanding our situation, Itamar<br>
<br>
Apologies if I am misunderstanding the situation, and my suggestions are<br>
out of context.<br>
</blockquote>
<br>
<br></div></div>
in theory, you are right, we could just pass the best "lowest common denominator" of hosts in the cluster, etc.<br>
but, cpu's with arbitrary set of flags don't exist in real life, and we were advised by the kvm group to not use such cpu combinations, rather stick to predefined ones (also note, predefined cpu models have more than just cpu flags in them).<br>
<br>
btw, you can set a VM to use '-cpu host', which will tell kvm to use best possible flags from physical hosts (but i think we block live migration in that case)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
Sincerely<br>
<br>
Peter<br>
<br>
On Sun, Feb 9, 2014 at 6:02 PM, Itamar Heim <<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a><br></div><div class="">
<mailto:<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a>>> wrote:<br>
<br>
On 02/02/2014 12:36 AM, Peter Galgano wrote:<br>
<br>
<br>
Thanks for your help with the config change, Itamar<br>
<br>
So am I correct that the config change is to be made in the<br>
serverCPUList setting?<br>
<br>
<br>
yes.<br>
<br>
<br>
<br>
May I please request the proper format of the configuration<br>
lines, and<br>
clear documentation of how to apply this workaround?<br>
<br>
<br>
i went to 3.0 tag in the git repo.<br>
<br>
it was:<br></div>
select fn_db_add_config_value('__<u></u>ServerCPUList','2:Intel Xeon w/o<br>
XD/NX:vmx,sse2:qemu64,-nx,+__<u></u>sse2; 3:Intel<div class=""><br>
Xeon:vmx,sse2,nx:qemu64,+sse2; 4:Intel Conroe<br></div>
Family:vmx,sse2,nx,cx16,ssse3:<u></u>__qemu64,+sse2,+cx16,+ssse3; 5:Intel<br>
Penryn<br>
Family:vmx,sse2,nx,cx16,ssse3,<u></u>__sse4_1:qemu64,+sse2,+cx16,+_<u></u>_ssse3,+sse4.1;<br>
6:Intel Nehalem<br>
Family:vmx,sse2,nx,cx16,ssse3,<u></u>__sse4_1,sse4_2,popcnt:qemu64,<u></u>+__sse2,+cx16,+ssse3,+sse4.1,+<u></u>__sse4.2,+popcnt;<div class=""><br>
2:AMD Opteron G1 w/o NX:svm,sse2:qemu64,-nx,+sse2; 3:AMD Opteron<br>
G1:svm,sse2,nx:qemu64,+sse2; 4:AMD Opteron<br></div>
G2:svm,sse2,nx,cx16:qemu64,+__<u></u>sse2,+cx16; 5:AMD Opteron<br>
G3:svm,sse2,nx,cx16,sse4a,__<u></u>misalignsse,popcnt,abm:qemu64,<u></u>__+sse2,+cx16,+sse4a,+__<u></u>misalignsse,+popcnt,+abm;','2.<u></u>__2');<div><div class="h5"><br>
<br>
I think this would work for you (check you have sse2 today via cat<br>
/proc/cpuinfo | grep sse2)<br>
<br>
3:Intel Xeon:vmx,sse2,nx:qemu64,+sse2<br>
(change the number from 3 to something which doesn't exist in the<br>
current ServerCPUList you have.<br>
<br>
format is:<br>
3 - sort/id<br>
Intel Xeon - display name<br>
vmx,sse2,nx - flags engine verifies appear in getVdsCaps for this host<br>
qemu64,+sse2 - the cpu/flags engine passes to vdsm to pass to<br>
libvirt/qemu<br>
<br>
<br>
<br>
<br>
Perhaps we can collect our older processors into some "other"<br>
supported<br>
but not "known or proper or whatever" models. Your system can<br>
give us a<br>
warning for attempting an unexpected processor, but hosts are<br>
allowed to<br>
run. Isn't it obvious that an older processor may provide lesser<br>
capability compared to a newer one?<br>
<br>
I'm installing on this hardware to gain experience with ovirt.<br>
and put a<br>
lab server together to test a roadmap to HA. I understand that i<br>
may not<br>
be the targeted audience, and you may not support all hardware..<br>
<br>
Respectfully to the developers, in my opinion I don't have an<br>
arbitrary<br>
set of cpu flags, I have two xeon 5060 "dempsey" processors<br>
which have<br>
been visualization workhorses for years. They are well known have a<br>
standard set of "flags" happily run about every known operating<br>
system<br>
and visualization environment except Ovirt at this point. Having<br>
stumbled on this limitation, and having spent hours trying to<br>
figure it<br>
out, it could be considered arbitrary that my processor didn't work<br>
without warning. Respectfully I think think it is most<br>
appropriate that<br>
the system allows my processor to run hosts and if it is not<br>
supported<br>
the system should provide a helpful message that provides some<br>
hope of<br>
being able to google a workaround or whatever.<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br></div></div>