Very interesting, Thank you for the background,
On Mon, Feb 10, 2014 at 2:41 PM, Itamar Heim <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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. >> >> >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
