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.