Thank you Itamar, this is very helpful. When we restart our testing, we will test this and update this post for future users to find.

snip

actually, i wonder which flag its missing that libvirt did not detect it as any supported model.

endsnip

I can see if i can compare the function flags to determine the model of the processor, and perhaps this will give us a clue as to a functional differentiation between the netburst architecture and core architecture for your purposes.

Does the hypervisor do anything different based on which extensions are passed? I believe

I would note that RHEV system requirements is simply 64 bit and virtualization extensions, I suppose all processors should be supported, including older ones. I also assume the system will not run newer processors as hosts, so I guess that the developers will have to update this list of capabilities to be passed to qemu libvirt in the future, and that the list of processors will become longer and more confusing over time.

I suppose you could have a facility where the user can query and manage the host processor and the profile of capabilities passed to qemu?

Might it not be best to avoid identifying the "branding" the processor, and instead concentrate on identifying and informing the user which capabilities are found and will be passed to guests. You could warn users if certain capabilities are absent which may be important, and expect the user to update their hardware as they see fit. I frankly do not typically care about processor functions unless I am lacking one that is required by the system I am running ie: vx extensions. I assume that other features may limit which OS you run ie pae, nx, sse2 being required for Windows 8. Otherwise I assume that extensions may increase performance or are not used by most operating systems and software.

for example:

"the system found the following processor features on this host: vmx,sse2. The following features will be passed to guests: qemu64,+sse2 . Note that some processors may lack features that are required by guest os's or are recommended for better performance. Note that this processor lacks NX extensions and may not run Windows 8 guests.

Thank you again for your assistance in understanding our situation, Itamar

Apologies if I am misunderstanding the situation, and my suggestions are out of context.

Sincerely

Peter

On Sun, Feb 9, 2014 at 6:02 PM, Itamar Heim <iheim@redhat.com> wrote:

On 02/02/2014 12:36 AM, Peter Galgano wrote:

Thanks for your help with the config change, Itamar

So am I correct that the config change is to be made in the
serverCPUList setting?

yes.

May I please request the proper format of the configuration lines, and
clear documentation of how to apply this workaround?

i went to 3.0 tag in the git repo.

it was:
select fn_db_add_config_value('ServerCPUList','2:Intel Xeon w/o XD/NX:vmx,sse2:qemu64,-nx,+sse2; 3:Intel Xeon:vmx,sse2,nx:qemu64,+sse2; 4:Intel Conroe Family:vmx,sse2,nx,cx16,ssse3:qemu64,+sse2,+cx16,+ssse3; 5:Intel Penryn Family:vmx,sse2,nx,cx16,ssse3,sse4_1:qemu64,+sse2,+cx16,+ssse3,+sse4.1; 6:Intel Nehalem Family:vmx,sse2,nx,cx16,ssse3,sse4_1,sse4_2,popcnt:qemu64,+sse2,+cx16,+ssse3,+sse4.1,+sse4.2,+popcnt; 2:AMD Opteron G1 w/o NX:svm,sse2:qemu64,-nx,+sse2; 3:AMD Opteron G1:svm,sse2,nx:qemu64,+sse2; 4:AMD Opteron G2:svm,sse2,nx,cx16:qemu64,+sse2,+cx16; 5:AMD Opteron G3:svm,sse2,nx,cx16,sse4a,misalignsse,popcnt,abm:qemu64,+sse2,+cx16,+sse4a,+misalignsse,+popcnt,+abm;','2.2');

I think this would work for you (check you have sse2 today via cat /proc/cpuinfo | grep sse2)

3:Intel Xeon:vmx,sse2,nx:qemu64,+sse2
(change the number from 3 to something which doesn't exist in the current ServerCPUList you have.

format is:
3 - sort/id
Intel Xeon - display name
vmx,sse2,nx - flags engine verifies appear in getVdsCaps for this host
qemu64,+sse2 - the cpu/flags engine passes to vdsm to pass to libvirt/qemu

Perhaps we can collect our older processors into some "other" supported
but not "known or proper or whatever" models. Your system can give us a
warning for attempting an unexpected processor, but hosts are allowed to
run. Isn't it obvious that an older processor may provide lesser
capability compared to a newer one?

I'm installing on this hardware to gain experience with ovirt. and put a
lab server together to test a roadmap to HA. I understand that i may not
be the targeted audience, and you may not support all hardware..

Respectfully to the developers, in my opinion I don't have an arbitrary
set of cpu flags, I have two xeon 5060 "dempsey" processors which have
been visualization workhorses for years. They are well known have a
standard set of "flags" happily run about every known operating system
and visualization environment except Ovirt at this point. Having
stumbled on this limitation, and having spent hours trying to figure it
out, it could be considered arbitrary that my processor didn't work
without warning. Respectfully I think think it is most appropriate that
the system allows my processor to run hosts and if it is not supported
the system should provide a helpful message that provides some hope of
being able to google a workaround or whatever.