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:
intend to upgrade for this purpose.at <http://purpose.at> this time.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_______________________________________________
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.