12:36 a.m.
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(a)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(a)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.