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@redhat.com

<mailto: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.