2:33 p.m.
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(a)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.
>