Von: users-bounces(a)ovirt.org [users-bounces(a)ovirt.org]" im Auftrag von "P=

Gesendet: Dienstag, 28. Januar 2014 18:53=0A= An: users(a)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=

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.

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(a)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. > > > >