[Users] Xeon 5060 support "Dempsey"
Thanks in advance for any help you can provide We are testing Ovirt 3.2.2 on a 2007 vintage dual Xeon 5060 (Dempsey) Supermicro Superserver. http://en.wikipedia.org/wiki/Xeon#5000-series_.22Dempsey.22. This hardware runs Centos 6.5 and KVM / virt manager just fine, and we have be running many virtual machines on this hardware with reasonable performance for many years We are getting the message: "Non-Operational state as host does not meet the cluster's minimum CPU level" each time we create a host. After researching this list, we are coming to the conclusion that this older processor is not being recognized by ovirt. Output of virsh -r capabilities and vdsClient -s 0 getVdsCaps are posted below. We havent found anyone with exactly this use case in our research. The closest thread is this: http://lists.ovirt.org/pipermail/users/2012-May/007536.html This poster was able to add some lines to the db to recognize his processor. Here is the advice he received in that post.
ok, indeed an old host. the below config is what we used before going to the 'model' approach, so you can try this out (though highly recommended for newer cpu since they improved virt support in each generation)
set the ServerCPUList config to this string for the relevant cluster compatibility level.
I'm not sure upgrade won't override this for you though, so pay attention on upgrades to such a low level tweak (it's config, but not all configs are really expected to be changed by user)
'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;'
We think we understand what is happening: our processors capabilities will be matched by processor type line 2 or 3, and then the host won't be rendered "non-operational". My Questions: 1. is this the correct change to ServerCPUList config in the db, 2. Is this the proper way to get support for older processors? 3. Is this documented anywhere? Can someone please help with a step by step for less experienced users? 4. Wouldn't it be reasonable to expect Ovirt to support processors that KVM supports by default? What is the minimum perceived processor expected to be? why is is conroe, when perfectly functional processors a few months older cause errors? The server hardware we are using is fine for our purposes, we don't intend to upgrade for this purpose.at this time. Thanks again Peter [root@sun1 /]# virsh -r capabilities <capabilities> <host> <uuid>46d8f975-c4c9-44af-b4f8-d4851e2331e0</uuid> <cpu> <arch>x86_64</arch> <model>cpu64-rhel6</model> <vendor>Intel</vendor> <topology sockets='2' cores='2' threads='2'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='cid'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> [root@sun1 /]# vdsClient -s 0 getVdsCaps HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:f52e99df611'}]} ISCSIInitiatorName = 'iqn.1994-05.com.redhat:f52e99df611' bondings = {'bond0': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond1': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond2': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond3': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond4': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}} bridges = {'br0': {'addr': '192.168.0.5', 'cfg': {'BOOTPROTO': 'none', 'BROADCAST': '192.168.0.255', 'DELAY': '0', 'DEVICE': 'br0', 'GATEWAY': '192.168.0.250', 'IPADDR': '192.168.0.5', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '255.255.255.0', 'NETWORK': '192.168.0.0', 'ONBOOT': 'yes', 'STP': 'on', 'TYPE': 'Bridge'}, 'gateway': '192.168.0.250', 'ipv6addrs': ['fe80::230:48ff:fe78:88cc/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['eth0', 'vnet0'], 'stp': 'on'}} clusterLevels = ['3.0', '3.1', '3.2', '3.3'] cpuCores = '4' cpuFlags = 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,pebs,bts,pni,dtes64,monitor,ds_cpl,vmx,cid,cx16,xtpr,pdcm,lahf_lm,tpr_shadow,model_coreduo' cpuModel = 'Intel(R) Xeon(TM) CPU 3.20GHz' cpuSockets = '2' cpuSpeed = '1200.000' cpuThreads = '8' emulatedMachines = ['rhel6.5.0', 'pc', 'rhel6.4.0', 'rhel6.3.0', 'rhel6.2.0', 'rhel6.1.0', 'rhel6.0.0', 'rhel5.5.0', 'rhel5.4.4', 'rhel5.4.0'] guestOverhead = '65' hooks = {} kvmEnabled = 'true' lastClient = '192.168.0.5' lastClientIface = 'br0' management_ip = '0.0.0.0' memSize = '10020' netConfigDirty = 'False' networks = {'br0': {'addr': '192.168.0.5', 'bridged': True, 'cfg': {'BOOTPROTO': 'none', 'BROADCAST': '192.168.0.255', 'DELAY': '0', 'DEVICE': 'br0', 'GATEWAY': '192.168.0.250', 'IPADDR': '192.168.0.5', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '255.255.255.0', 'NETWORK': '192.168.0.0', 'ONBOOT': 'yes', 'STP': 'on', 'TYPE': 'Bridge'}, 'gateway': '192.168.0.250', 'iface': 'br0', 'ipv6addrs': ['fe80::230:48ff:fe78:88cc/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['eth0', 'vnet0'], 'qosInbound': '', 'qosOutbound': '', 'stp': 'on'}} nics = {'eth0': {'addr': '', 'cfg': {'BOOTPROTO': 'none', 'BRIDGE': 'br0', 'BROADCAST': '', 'DEVICE': 'eth0', 'HWADDR': '00:30:48:78:88:CC', 'IPADDR': '', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '', 'NETWORK': '', 'ONBOOT': 'yes'}, 'hwaddr': '00:30:48:78:88:cc', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {}, 'hwaddr': '00:30:48:78:88:cd', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}} operatingSystem = {'name': 'RHEL', 'release': '5.el6.centos.11.2', 'version': '6'} packages2 = {'kernel': {'buildtime': 1361511086.0, 'release': '358.el6.x86_64', 'version': '2.6.32'}, 'libvirt': {'buildtime': 1387360004, 'release': '29.el6_5.2', 'version': '0.10.2'}, 'mom': {'buildtime': 1385055971, 'release': '6.el6', 'version': '0.3.2'}, 'qemu-img': {'buildtime': 1386101870, 'release': '2.415.el6_5.3', 'version': '0.12.1.2'}, 'qemu-kvm': {'buildtime': 1386101870, 'release': '2.415.el6_5.3', 'version': '0.12.1.2'}, 'spice-server': {'buildtime': 1386756528, 'release': '6.el6_5.1', 'version': '0.12.4'}, 'vdsm': {'buildtime': 1386757669, 'release': '1.el6', 'version': '4.13.2'}} reservedMem = '321' software_revision = '1' software_version = '4.13' supportedENGINEs = ['3.0', '3.1', '3.2', '3.3'] supportedProtocols = ['2.2', '2.3'] uuid = '53D19F64-D663-A017-8922-0030487888CC' version_name = 'Snow Man' vlans = {} vmTypes = ['kvm']
Von: users-bounces@ovirt.org [users-bounces@ovirt.org]" im Auftrag von "P= eter Galgano [peter@cleftstoneworks.com]=0A= Gesendet: Dienstag, 28. Januar 2014 18:53=0A= An: users@ovirt.org=0A= Betreff: [Users] Xeon 5060 support "Dempsey"=0A= =0A= Thanks in advance for any help you can provide=0A= =0A= We are testing Ovirt 3.2.2 on a 2007 vintage dual Xeon 5060=0A= (Dempsey) Supermicro Superserver.=0A= ...=0A= 4. Wouldn't it be reasonable to expect Ovirt to support processors =0A= that KVM supports by default? What is the minimum perceived =0A= processor expected to be? why is is conroe, when perfectly =0A= functional processors a few months older cause errors?=0A= =0A= Hello Peter,=0A= =0A= welcome to the list. The OVirt developers are quite open to =0A= enhancement. So the best would be to open a Redhat bugzilla=0A= entry for that request. =0A= =0A= In the meantime you should give the the database update a try.=0A= I don't know how but the value you are searching for is in the=0A=
This is a multi-part message in MIME format. ------=_NextPartTM-000-7a016d22-d780-4774-8c97-83b266d7ecd0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable table vdc_options in the engine schema:=0A= =0A= # su - postgres=0A= # psql=0A= # \c engine=0A= # select * from vdc_options where option_name=3D'ServerCPUList';=0A= -------------------------------------=0A= 304 | ServerCPUList | 3:Intel Conroe Family:vmx,nx,model...=0A= 305 | ServerCPUList | 3:Intel Conroe Family:vmx,nx,model...=0A= ...=0A= =0A= Markus=0A= ------=_NextPartTM-000-7a016d22-d780-4774-8c97-83b266d7ecd0 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-7a016d22-d780-4774-8c97-83b266d7ecd0--
On 01/28/2014 06:53 PM, Peter Galgano wrote:
Thanks in advance for any help you can provide
We are testing Ovirt 3.2.2 on a 2007 vintage dual Xeon 5060 (Dempsey) Supermicro Superserver. http://en.wikipedia.org/wiki/Xeon#5000-series_.22Dempsey.22. This hardware runs Centos 6.5 and KVM / virt manager just fine, and we have be running many virtual machines on this hardware with reasonable performance for many years
We are getting the message: "Non-Operational state as host does not meet the cluster's minimum CPU level" each time we create a host.
After researching this list, we are coming to the conclusion that this older processor is not being recognized by ovirt.
Output of virsh -r capabilities and vdsClient -s 0 getVdsCaps are posted below.
We havent found anyone with exactly this use case in our research. The closest thread is this:
http://lists.ovirt.org/pipermail/users/2012-May/007536.html
This poster was able to add some lines to the db to recognize his processor. Here is the advice he received in that post.
> ok, indeed an old host. > the below config is what we used before going to the 'model' approach, so you can try this out (though highly recommended for newer cpu since they improved virt support in each generation) > > set the ServerCPUList config to this string for the relevant cluster compatibility level. > > I'm not sure upgrade won't override this for you though, so pay attention on upgrades to such a low level tweak (it's config, but not all configs are really expected to be changed by user) > > '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;'
We think we understand what is happening: our processors capabilities will be matched by processor type line 2 or 3, and then the host won't be rendered "non-operational". My Questions:
1. is this the correct change to ServerCPUList config in the db, 2. Is this the proper way to get support for older processors? 3. Is this documented anywhere? Can someone please help with a step by step for less experienced users? 4. Wouldn't it be reasonable to expect Ovirt to support processors that KVM supports by default? What is the minimum perceived processor expected to be? why is is conroe, when perfectly functional processors a few months older cause errors?
The server hardware we are using is fine for our purposes, we don't intend to upgrade for this purpose.at <http://purpose.at> this time.
Thanks again
Peter
[root@sun1 /]# virsh -r capabilities
<capabilities>
<host> <uuid>46d8f975-c4c9-44af-b4f8-d4851e2331e0</uuid> <cpu> <arch>x86_64</arch> <model>cpu64-rhel6</model> <vendor>Intel</vendor> <topology sockets='2' cores='2' threads='2'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='cid'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu>
[root@sun1 /]# vdsClient -s 0 getVdsCaps HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:f52e99df611'}]} ISCSIInitiatorName = 'iqn.1994-05.com.redhat:f52e99df611' bondings = {'bond0': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond1': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond2': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond3': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond4': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}} bridges = {'br0': {'addr': '192.168.0.5', 'cfg': {'BOOTPROTO': 'none', 'BROADCAST': '192.168.0.255', 'DELAY': '0', 'DEVICE': 'br0', 'GATEWAY': '192.168.0.250', 'IPADDR': '192.168.0.5', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '255.255.255.0', 'NETWORK': '192.168.0.0', 'ONBOOT': 'yes', 'STP': 'on', 'TYPE': 'Bridge'}, 'gateway': '192.168.0.250', 'ipv6addrs': ['fe80::230:48ff:fe78:88cc/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['eth0', 'vnet0'], 'stp': 'on'}} clusterLevels = ['3.0', '3.1', '3.2', '3.3'] cpuCores = '4' cpuFlags = 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,pebs,bts,pni,dtes64,monitor,ds_cpl,vmx,cid,cx16,xtpr,pdcm,lahf_lm,tpr_shadow,model_coreduo' cpuModel = 'Intel(R) Xeon(TM) CPU 3.20GHz' cpuSockets = '2' cpuSpeed = '1200.000' cpuThreads = '8' emulatedMachines = ['rhel6.5.0', 'pc', 'rhel6.4.0', 'rhel6.3.0', 'rhel6.2.0', 'rhel6.1.0', 'rhel6.0.0', 'rhel5.5.0', 'rhel5.4.4', 'rhel5.4.0'] guestOverhead = '65' hooks = {} kvmEnabled = 'true' lastClient = '192.168.0.5' lastClientIface = 'br0' management_ip = '0.0.0.0' memSize = '10020' netConfigDirty = 'False' networks = {'br0': {'addr': '192.168.0.5', 'bridged': True, 'cfg': {'BOOTPROTO': 'none', 'BROADCAST': '192.168.0.255', 'DELAY': '0', 'DEVICE': 'br0', 'GATEWAY': '192.168.0.250', 'IPADDR': '192.168.0.5', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '255.255.255.0', 'NETWORK': '192.168.0.0', 'ONBOOT': 'yes', 'STP': 'on', 'TYPE': 'Bridge'}, 'gateway': '192.168.0.250', 'iface': 'br0', 'ipv6addrs': ['fe80::230:48ff:fe78:88cc/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['eth0', 'vnet0'], 'qosInbound': '', 'qosOutbound': '', 'stp': 'on'}} nics = {'eth0': {'addr': '', 'cfg': {'BOOTPROTO': 'none', 'BRIDGE': 'br0', 'BROADCAST': '', 'DEVICE': 'eth0', 'HWADDR': '00:30:48:78:88:CC', 'IPADDR': '', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '', 'NETWORK': '', 'ONBOOT': 'yes'}, 'hwaddr': '00:30:48:78:88:cc', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {}, 'hwaddr': '00:30:48:78:88:cd', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}} operatingSystem = {'name': 'RHEL', 'release': '5.el6.centos.11.2', 'version': '6'} packages2 = {'kernel': {'buildtime': 1361511086.0, 'release': '358.el6.x86_64', 'version': '2.6.32'}, 'libvirt': {'buildtime': 1387360004, 'release': '29.el6_5.2', 'version': '0.10.2'}, 'mom': {'buildtime': 1385055971, 'release': '6.el6', 'version': '0.3.2'}, 'qemu-img': {'buildtime': 1386101870, 'release': '2.415.el6_5.3', 'version': '0.12.1.2'}, 'qemu-kvm': {'buildtime': 1386101870, 'release': '2.415.el6_5.3', 'version': '0.12.1.2'}, 'spice-server': {'buildtime': 1386756528, 'release': '6.el6_5.1', 'version': '0.12.4'}, 'vdsm': {'buildtime': 1386757669, 'release': '1.el6', 'version': '4.13.2'}} reservedMem = '321' software_revision = '1' software_version = '4.13' supportedENGINEs = ['3.0', '3.1', '3.2', '3.3'] supportedProtocols = ['2.2', '2.3'] uuid = '53D19F64-D663-A017-8922-0030487888CC' version_name = 'Snow Man' vlans = {} vmTypes = ['kvm']
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
the history here is that kvm team added "known models" like conroe, penryn, etc. it is just a config change and we can help with the proper format, you will probably need to re-do it for newer cluster levels. we moved to the "proper cpu models" (penryn, conroe, etc.) since the "arbitrary set of cpu flags" was deemed unpredictable wrt robustness of what a guest OS may expect, and older cpu models weren't prevalent.
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? May I please request the proper format of the configuration lines, and clear documentation of how to apply this workaround? 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. Sincerely Peter *Peter Galgano* *The CleftStone Works* Cell: 610-914-6294 [image: Inline image 1] 760 Seem Drive, Kutztown, PA 19530 Ph 610.683.9348, Fx 610.683.9349 *www.cleftstoneworks.com <http://cleftstoneworks.com/>* *Like us: facebook.com/cleftstoneworks <http://facebook.com/cleftstoneworks>* On Sat, Feb 1, 2014 at 12:01 PM, Itamar Heim <iheim@redhat.com> wrote:
On 01/28/2014 06:53 PM, Peter Galgano wrote:
Thanks in advance for any help you can provide
We are testing Ovirt 3.2.2 on a 2007 vintage dual Xeon 5060 (Dempsey) Supermicro Superserver. http://en.wikipedia.org/wiki/Xeon#5000-series_.22Dempsey.22. This hardware runs Centos 6.5 and KVM / virt manager just fine, and we have be running many virtual machines on this hardware with reasonable performance for many years
We are getting the message: "Non-Operational state as host does not meet the cluster's minimum CPU level" each time we create a host.
After researching this list, we are coming to the conclusion that this older processor is not being recognized by ovirt.
Output of virsh -r capabilities and vdsClient -s 0 getVdsCaps are posted below.
We havent found anyone with exactly this use case in our research. The closest thread is this:
http://lists.ovirt.org/pipermail/users/2012-May/007536.html
This poster was able to add some lines to the db to recognize his processor. Here is the advice he received in that post.
> ok, indeed an old host. > the below config is what we used before going to the 'model' approach, so you can try this out (though highly recommended for newer cpu since they improved virt support in each generation) > > set the ServerCPUList config to this string for the relevant cluster compatibility level. > > I'm not sure upgrade won't override this for you though, so pay attention on upgrades to such a low level tweak (it's config, but not all configs are really expected to be changed by user) > > '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;'
We think we understand what is happening: our processors capabilities will be matched by processor type line 2 or 3, and then the host won't be rendered "non-operational". My Questions:
1. is this the correct change to ServerCPUList config in the db, 2. Is this the proper way to get support for older processors? 3. Is this documented anywhere? Can someone please help with a step by step for less experienced users? 4. Wouldn't it be reasonable to expect Ovirt to support processors that KVM supports by default? What is the minimum perceived processor expected to be? why is is conroe, when perfectly functional processors a few months older cause errors?
The server hardware we are using is fine for our purposes, we don't intend to upgrade for this purpose.at <http://purpose.at> this time.
Thanks again
Peter
[root@sun1 /]# virsh -r capabilities
<capabilities>
<host> <uuid>46d8f975-c4c9-44af-b4f8-d4851e2331e0</uuid> <cpu> <arch>x86_64</arch> <model>cpu64-rhel6</model> <vendor>Intel</vendor> <topology sockets='2' cores='2' threads='2'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='cid'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu>
[root@sun1 /]# vdsClient -s 0 getVdsCaps HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:f52e99df611'}]} ISCSIInitiatorName = 'iqn.1994-05.com.redhat:f52e99df611' bondings = {'bond0': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond1': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond2': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond3': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}, 'bond4': {'addr': '', 'cfg': {}, 'hwaddr': '00:00:00:00:00:00', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}} bridges = {'br0': {'addr': '192.168.0.5', 'cfg': {'BOOTPROTO': 'none', 'BROADCAST': '192.168.0.255', 'DELAY': '0', 'DEVICE': 'br0', 'GATEWAY': '192.168.0.250', 'IPADDR': '192.168.0.5', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '255.255.255.0', 'NETWORK': '192.168.0.0', 'ONBOOT': 'yes', 'STP': 'on', 'TYPE': 'Bridge'}, 'gateway': '192.168.0.250', 'ipv6addrs': ['fe80::230:48ff:fe78:88cc/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['eth0', 'vnet0'], 'stp': 'on'}} clusterLevels = ['3.0', '3.1', '3.2', '3.3'] cpuCores = '4' cpuFlags = 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca, cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht, tm,pbe,syscall,nx,lm,constant_tsc,pebs,bts,pni,dtes64, monitor,ds_cpl,vmx,cid,cx16,xtpr,pdcm,lahf_lm,tpr_shadow,model_coreduo' cpuModel = 'Intel(R) Xeon(TM) CPU 3.20GHz' cpuSockets = '2' cpuSpeed = '1200.000' cpuThreads = '8' emulatedMachines = ['rhel6.5.0', 'pc', 'rhel6.4.0', 'rhel6.3.0', 'rhel6.2.0', 'rhel6.1.0', 'rhel6.0.0', 'rhel5.5.0', 'rhel5.4.4', 'rhel5.4.0'] guestOverhead = '65' hooks = {} kvmEnabled = 'true' lastClient = '192.168.0.5' lastClientIface = 'br0' management_ip = '0.0.0.0' memSize = '10020' netConfigDirty = 'False' networks = {'br0': {'addr': '192.168.0.5', 'bridged': True, 'cfg': {'BOOTPROTO': 'none', 'BROADCAST': '192.168.0.255', 'DELAY': '0', 'DEVICE': 'br0', 'GATEWAY': '192.168.0.250', 'IPADDR': '192.168.0.5', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '255.255.255.0', 'NETWORK': '192.168.0.0', 'ONBOOT': 'yes', 'STP': 'on', 'TYPE': 'Bridge'}, 'gateway': '192.168.0.250', 'iface': 'br0', 'ipv6addrs': ['fe80::230:48ff:fe78:88cc/64' ], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['eth0', 'vnet0'], 'qosInbound': '', 'qosOutbound': '', 'stp': 'on'}} nics = {'eth0': {'addr': '', 'cfg': {'BOOTPROTO': 'none', 'BRIDGE': 'br0', 'BROADCAST': '', 'DEVICE': 'eth0', 'HWADDR': '00:30:48:78:88:CC', 'IPADDR': '', 'IPV6INIT': 'no', 'MACADDR': '', 'MTU': '', 'NAME': '', 'NETMASK': '', 'NETWORK': '', 'ONBOOT': 'yes'}, 'hwaddr': '00:30:48:78:88:cc', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {}, 'hwaddr': '00:30:48:78:88:cd', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}} operatingSystem = {'name': 'RHEL', 'release': '5.el6.centos.11.2', 'version': '6'} packages2 = {'kernel': {'buildtime': 1361511086.0, 'release': '358.el6.x86_64', 'version': '2.6.32'}, 'libvirt': {'buildtime': 1387360004, 'release': '29.el6_5.2', 'version': '0.10.2'}, 'mom': {'buildtime': 1385055971, 'release': '6.el6', 'version': '0.3.2'}, 'qemu-img': {'buildtime': 1386101870, 'release': '2.415.el6_5.3', 'version': '0.12.1.2'}, 'qemu-kvm': {'buildtime': 1386101870, 'release': '2.415.el6_5.3', 'version': '0.12.1.2'}, 'spice-server': {'buildtime': 1386756528, 'release': '6.el6_5.1', 'version': '0.12.4'}, 'vdsm': {'buildtime': 1386757669, 'release': '1.el6', 'version': '4.13.2'}} reservedMem = '321' software_revision = '1' software_version = '4.13' supportedENGINEs = ['3.0', '3.1', '3.2', '3.3'] supportedProtocols = ['2.2', '2.3'] uuid = '53D19F64-D663-A017-8922-0030487888CC' version_name = 'Snow Man' vlans = {} vmTypes = ['kvm']
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
the history here is that kvm team added "known models" like conroe, penryn, etc. it is just a config change and we can help with the proper format, you will probably need to re-do it for newer cluster levels.
we moved to the "proper cpu models" (penryn, conroe, etc.) since the "arbitrary set of cpu flags" was deemed unpredictable wrt robustness of what a guest OS may expect, and older cpu models weren't prevalent.
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.
actually, i wonder which flag its missing that libvirt did not detect it as any supported model.
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.
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.
Very interesting, Thank you for the background, On Mon, Feb 10, 2014 at 2:41 PM, Itamar Heim <iheim@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@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.
participants (3)
-
Itamar Heim -
Markus Stockhausen -
Peter Galgano