[Users] Xeon 5060 support "Dempsey"

[Peter Galgano]

Very interesting,

Thank you for the background,


On Mon, Feb 10, 2014 at 2:41 PM, Itamar Heim <iheim at redhat.com> wrote:

> On 02/10/2014 09:33 PM, Peter Galgano wrote:
>
>> 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.
>>
>
>
> in theory, you are right, we could just pass the best "lowest common
> denominator" of hosts in the cluster, etc.
> 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).
>
> 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)
>
>
>> Sincerely
>>
>> Peter
>>
>> On Sun, Feb 9, 2014 at 6:02 PM, Itamar Heim <iheim at redhat.com
>> <mailto:iheim at 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.
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140210/f0f523b1/attachment-0001.html>