March 2013 - devel - lists.centos.org

ksplice and CentOS
by Karanbir Singh 25 Sep '25

25 Sep '25

hi guys, lots of people on this list are keen on contributing to the CentOS effort - and one place where we could, as a group of people, make a massive difference is being able to deliver a ksplice upgrade model. A couple of people have started in silo's to try and get something together but I feel it might be a good time to try and see if we can do somethng as a group. Do we have people on the list who find the idea of rebootless kernel upgrades interesting ? Is there some desire to try and make that happen within the CentOS Ecosystem ? - KB

24 47

anaconda dependency calculation?
by Nicholas Byrne 04 Aug '25

04 Aug '25

Hi all, I'm trying to find a tool that calculates all dependencies for a specific package or group of packages for use with CentOS 5 (beta) with the intention of putting together a custom single CD build of CentOS 5. With CentOS 4 i used a python script that used the hdrlist module to find all dependencies which borrowed code from a number of sources. I've looked at yumdownloader and how it checks dependencies (using the --resolve option) but if i pass it the list of packages defined in say the Base and the Core yum groups which generally form an absolute minimal install i end up with about 200 packages. If i do a custom install (using beta 1 disks) and deselect everything i end up with over 300 packages. So i'm guessing anaconda calculates dependencies in a slightly different way, can anyone point me to files/code where i should be looking to find out? Thanks very much in advance for help Nick This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential. Any dissemination, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from Quadriga may be monitored. Quadriga cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

6 11

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

initial testing version for DevTools 1.1
by Tru Huynh 16 Aug '13

16 Aug '13

Hi, For the daring users ;) http://people.centos.org/tru/devtools-1.1/ enjoy and report Cheers, Tru -- Tru Huynh (mirrors, CentOS i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

5 26

MariaDB now available for Testing on CentOS-6
by Karanbir Singh 01 May '13

01 May '13

hi guys, quick start: drop http://dev.centos.org/centos/6/mariadb/mariadb.repo into /etc/yum.repos.d/ and yum list mariadb\* This is adapted from the Fedora spec adapted by Johnny for CentOS-6 and upgraded to 5.5.29; we have done some basic testing on these packages and they worked for us. We are now looking for wider testing and feedback about both the packaging, the payload and how its setup as well as any build issues. These packages are setup to replace MySQL on your machine, so be careful. And we consider these rpms to be of Testing grade, unsuiteable for production at this point. Post feedback as follow up to this email, or at bugs.centos.org/ Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

7 14

New drbd83 and drbd-kmod83 testing RPMS available
by Johnny Hughes 27 Mar '13

27 Mar '13

Please look at these drbd83 and drbd-kmod83 testing RPMS: http://bugs.centos.org/view.php?id=6341 The link to the actual RPMS are there, here it is as well: http://people.centos.org/hughesjr/drbd/5/ Please provide feedback to bug 6341 (first link above) and we can get these moved into the extras repo. Thanks, Johnny Hughes

1 0

initscripts-9.03.38-1.el6.centos.1.src.rpm missing?
by Nathaniel W. Turner 24 Mar '13

24 Mar '13

I see that the mirror currently has a binary initscripts-9.03.38-1.el6.centos.1.x86_64.rpm, but I don't see the corresponding initscripts-9.03.38-1.el6.centos.1.src.rpm at http://vault.centos.org/6.4/os/Source/SPackages/ --- am I looking in the wrong place? -- Nathaniel W. Turner http://houseofnate.net/

3 3

Missing packages in CentOS 6.4 x86_64
by John Newbigin 22 Mar '13

22 Mar '13

Hi, This may be by design or there may be a reason for it which I don't know. In the x86_64 repository for CentOS 6.4, the i686 version of these packages below are not up to date. This causes yum to complain about 'Protected multilib versions'. * iscsi-initiator-utils-6.2.0.873-2.el6 * iscsi-initiator-utils-devel-6.2.0.873-2 * control-center-filesystem-2.28.1-38 There may be others but these are the three I had to fix manually on my system. I just downloaded the i686 versions from the i386 repository which seem to work fine. John. -- John Newbigin | ITS Senior Analyst / Programmer Faculty of Information and Communication Technologies ITS | Swinburne University of Technology | Melbourne, Australia O: EN306 | T: +61 3 9214 8185 | M: +61 410 569 362 E: jnewbigin(a)swin.edu.au W: http://www.ict.swin.edu.au/staff/jnewbigin

2 1

an upstream cloud-init
by Karanbir Singh 15 Mar '13

15 Mar '13

Hi, http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RH-COMMON/ Seems to have come online recently ( thanks ghoms for pointing at it ). target seems to be cloud-init and its deps, and only its deps ( they are conveniently marked with a .1 upgrade from corrosponding packages in EPEL ). But the name is interesting, What is is going to show up there ? and what sort of machine roles is the corrosponding repo being exposed to ? I've build the rpms to : https://nazar.karan.org/results/misc/cloud-init/20130315000927/ so feel free to play for now. Can anyone shed any light on the questions ? So we can then make a decision and see howto rope these into the distro repos in the best manner. Also, I suspect epel will need to either do something about these deps ( and they have an older 0.6 based cloud-init there ) - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

1 0

Adding Linux Test Project content to our tests
by Karanbir Singh 14 Mar '13

14 Mar '13

hi, http://ltp.sourceforge.net/ "The Linux™ Test Project is a joint project started by SGI™ and maintained by IBM®, that has a goal to deliver test suites to the open source community that validate the reliability, robustness, and stability of Linux. The LTP testsuite contains a collection of tools for testing the Linux kernel and related features." ----------- In the week leading upto 6.4, Christoph Galuschka and I had started looking at how we might be able to integrate those tests into what we are doing. Since the 6.4 sprint kicked in, we resorted to just running the tests manually; Which worked well. However, I feel its worth putting these tests into the harness we have in place, and making sure they are run whenever we call for 'distro tests' or 'update tests'. One option is to have the entire suite run as a single tests/r_ltp/ suiet under t_functional; the other is to either have its own suite, we can directly import from upstream, or have it be a part of the t_external/ test suite ( along with the likes of wordpress / drupal and other things ). Thoughts ? - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

3 4

Testing Nightly and Status Board
by Karanbir Singh 14 Mar '13

14 Mar '13

hi, At the moment, we run tests on a nightly basis, only in kvm vm's and the results dont go very far. I'd like to propose we use the entire QA bladecenter and run the entire compliment of deploys and tests, then post them in a status board which has some history ( stashboard ? ) Going one step further, we should run the entire t_functional tests as well as start incorporating some of the, now stale, t_external tests. At the moment we do deploys over http and nfs, to local and remote storage, under Xen, KVM, bare-metal and some virtualbox and some vmware hypervisors, for i386 and x86_64. I had a brief chat with Fabian about this yesterday, and we both think its doable, in the short term. Anyone else have thoughts about this ? or want to propose reporting mechanisms that might be better in line with the intended result : to give people a single perspective on the state of things, as a confidence point. And also to allow people to easily add tests that are then run nightly, so they can address their own corner cases. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

4 5

Re: [CentOS-devel] Testing Nightly and Status Board
by Christoph Galuschka 14 Mar '13

14 Mar '13

> hi, > > At the moment, we run tests on a nightly basis, only in kvm vm's and the > results dont go very far. I'd like to propose we use the entire QA > bladecenter and run the entire compliment of deploys and tests, then > post them in a status board which has some history ( stashboard ? ) > > Going one step further, we should run the entire t_functional tests as > well as start incorporating some of the, now stale, t_external tests. > a very good proposal - gets my vote Christoph

1 0

qemu-kvm upgrade path is broken
by Morten Stevens 10 Mar '13

10 Mar '13

Hi, There is an upgrade problem with the latest qemu-kvm package for CentOS-6.4: Upgrading from qemu-kvm-0.12.1.2-2.355.el6_4_4.1.x86_64.rpm to the latest qemu-kvm-0.12.1.2-2.355.el6_4.2.x86_64.rpm package is not possible with "yum update". The problem is: qemu-kvm-0.12.1.2-2.355.el6_4_4.1.x86_64.rpm This package contains el6_4_4.1 instead of el6_4.1. Best regards, Morten

2 1

Re: [CentOS-devel] [Users] 6.4 CR: oVirt 3.1 breaks with missing cpu features after update to CentOS 6.4 (6.3 + CR)
by Patrick Hurrelmann 07 Mar '13

07 Mar '13

On 07.03.2013 16:18, Dan Kenigsberg wrote: > On Thu, Mar 07, 2013 at 03:59:27PM +0100, Patrick Hurrelmann wrote: >> On 05.03.2013 13:49, Dan Kenigsberg wrote: >>> On Tue, Mar 05, 2013 at 12:32:31PM +0100, Patrick Hurrelmann wrote: >>>> On 05.03.2013 11:14, Dan Kenigsberg wrote: >>>> <snip> >>>>>>>> >>>>>>>> My version of vdsm as stated by Dreyou: >>>>>>>> v 4.10.0-0.46 (.15), builded from >>>>>>>> b59c8430b2a511bcea3bc1a954eee4ca1c0f4861 (branch ovirt-3.1) >>>>>>>> >>>>>>>> I can't see that Ia241b09c96fa16441ba9421f61a2f9a417f0d978 was merged to >>>>>>>> 3.1 Branch? >>>>>>>> >>>>>>>> I applied that patch locally and restarted vdsmd but this does not >>>>>>>> change anything. Supported cpu is still as low as Conroe instead of >>>>>>>> Nehalem. Or is there more to do than patching libvirtvm.py? >>>>>>> >>>>>>> What is libvirt's opinion about your cpu compatibility? >>>>>>> >>>>>>> virsh -r cpu-compare <(echo '<cpu match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >>>>>>> >>>>>>> If you do not get "Host CPU is a superset of CPU described in bla", then >>>>>>> the problem is within libvirt. >>>>>>> >>>>>>> Dan. >>>>>> >>>>>> Hi Dan, >>>>>> >>>>>> virsh -r cpu-compare <(echo '<cpu >>>>>> match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >>>>>> Host CPU is a superset of CPU described in /dev/fd/63 >>>>>> >>>>>> So libvirt obviously is fine. Something different would have surprised >>>>>> my as virsh capabilities seemed correct anyway. >>>>> >>>>> So maybe, just maybe, libvirt has changed their cpu_map, a map that >>>>> ovirt-3.1 had a bug reading. >>>>> >>>>> Would you care to apply http://gerrit.ovirt.org/5035 to see if this is >>>>> it? >>>>> >>>>> Dan. >>>> >>>> Hi Dan, >>>> >>>> success! Applying that patch made the cpu recognition work again. The >>>> cpu type in admin portal shows again as Nehalem. Output from getVdsCaps: >>>> >>>> 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,rdtscp,lm,constant_tsc, >>>> arch_perfmon,pebs,bts,rep_good,xtopology,nonstop_tsc, >>>> aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2, >>>> ssse3,cx16,xtpr,pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida, >>>> dts,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem, >>>> model_Conroe,model_coreduo,model_core2duo,model_Penryn, >>>> model_n270 >>>> cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz >>>> cpuSockets = 1 >>>> cpuSpeed = 2393.769 >>>> >>>> >>>> I compared libvirt's cpu_map.xml on both Centos 6.3 and CentOS 6.4 and >>>> indeed they do differ in large portions. So this patch should probably >>>> be merged to 3.1 branch? I will contact Dreyou and request that this >>>> patch will also be included in his builds. I guess otherwise there will >>>> be quite some fallout after people start picking CentOS 6.4 for oVirt 3.1. >>>> >>>> Thanks again and best regards >>> >>> Thank you for reporting this issue and verifying its fix. >>> >>> I'm not completely sure that we should keep maintaining the ovirt-3.1 >>> branch upstream - but a build destined for el6.4 must have it. >>> >>> If you believe we should release a fix version for 3.1, please verify >>> that http://gerrit.ovirt.org/12723 has no ill effects. >>> >>> Dan. >> >> I did none additional tests and the new CentOS 6.4 host failed start or >> migrate any vm. It always boils down to: >> >> Thread-43::ERROR::2013-03-07 >> 15:02:51,950::task::853::TaskManager.Task::(_setError) >> Task=`52a9f96f-3dfd-4bcf-8d7a-db14e650b4c1`::Unexpected error >> Traceback (most recent call last): >> File "/usr/share/vdsm/storage/task.py", line 861, in _run >> return fn(*args, **kargs) >> File "/usr/share/vdsm/logUtils.py", line 38, in wrapper >> res = f(*args, **kwargs) >> File "/usr/share/vdsm/storage/hsm.py", line 2551, in getVolumeSize >> apparentsize = str(volume.Volume.getVSize(sdUUID, imgUUID, volUUID, >> bs=1)) >> File "/usr/share/vdsm/storage/volume.py", line 283, in getVSize >> return mysd.getVolumeClass().getVSize(mysd, imgUUID, volUUID, bs) >> File "/usr/share/vdsm/storage/blockVolume.py", line 101, in getVSize >> return int(int(lvm.getLV(sdobj.sdUUID, volUUID).size) / bs) >> File "/usr/share/vdsm/storage/lvm.py", line 772, in getLV >> lv = _lvminfo.getLv(vgName, lvName) >> File "/usr/share/vdsm/storage/lvm.py", line 567, in getLv >> lvs = self._reloadlvs(vgName) >> File "/usr/share/vdsm/storage/lvm.py", line 419, in _reloadlvs >> self._lvs.pop((vgName, lvName), None) >> File "/usr/lib64/python2.6/contextlib.py", line 34, in __exit__ >> self.gen.throw(type, value, traceback) >> File "/usr/share/vdsm/storage/misc.py", line 1219, in acquireContext >> yield self >> File "/usr/share/vdsm/storage/lvm.py", line 404, in _reloadlvs >> lv = makeLV(*fields) >> File "/usr/share/vdsm/storage/lvm.py", line 218, in makeLV >> attrs = _attr2NamedTuple(args[LV._fields.index("attr")], >> LV_ATTR_BITS, "LV_ATTR") >> File "/usr/share/vdsm/storage/lvm.py", line 188, in _attr2NamedTuple >> attrs = Attrs(*values) >> TypeError: __new__() takes exactly 9 arguments (10 given) >> >> and followed by: >> >> Thread-43::ERROR::2013-03-07 >> 15:02:51,987::dispatcher::69::Storage.Dispatcher.Protect::(run) >> __new__() takes exactly 9 arguments (10 given) >> Traceback (most recent call last): >> File "/usr/share/vdsm/storage/dispatcher.py", line 61, in run >> result = ctask.prepare(self.func, *args, **kwargs) >> File "/usr/share/vdsm/storage/task.py", line 1164, in prepare >> raise self.error >> TypeError: __new__() takes exactly 9 arguments (10 given) >> Thread-43::DEBUG::2013-03-07 >> 15:02:51,987::vm::580::vm.Vm::(_startUnderlyingVm) >> vmId=`7db86f12-8c57-4d2b-a853-a6fd6f7ee82d`::_ongoingCreations released >> Thread-43::ERROR::2013-03-07 >> 15:02:51,987::vm::604::vm.Vm::(_startUnderlyingVm) >> vmId=`7db86f12-8c57-4d2b-a853-a6fd6f7ee82d`::The vm start process failed >> Traceback (most recent call last): >> File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm >> self._run() >> File "/usr/share/vdsm/libvirtvm.py", line 1289, in _run >> devices = self.buildConfDevices() >> File "/usr/share/vdsm/vm.py", line 431, in buildConfDevices >> self._normalizeVdsmImg(drv) >> File "/usr/share/vdsm/vm.py", line 358, in _normalizeVdsmImg >> drv['truesize'] = res['truesize'] >> KeyError: 'truesize' >> >> In webadmin the start and migrate operations fail with 'truesize'. >> >> I could find BZ#876958 which has the very same error. So I tried to >> apply patch http://gerrit.ovirt.org/9317. I had to apply it manually >> (guess patch would need a rebase for 3.1), but it works. > > Thanks for the report. I've made a public backport for this in > http://gerrit.ovirt.org/12836/ and would ask you again to tick that it > is verified by you. > >> >> I now can start new virtual machines successfully on a CentOS 6.4 / >> oVirt 3.1 host. Migration of vm from CentOS 6.3 hosts work, but not the >> other way around. Migration from 6.4 to 6.3 fails: >> >> Thread-1296::ERROR::2013-03-07 15:55:24,845::vm::176::vm.Vm::(_recover) >> vmId=`c978cbf8-6b4d-4d6f-9435-480d9fed31c4`::internal error Process >> exited while reading console log output: Supported machines are: >> pc RHEL 6.3.0 PC (alias of rhel6.3.0) >> rhel6.3.0 RHEL 6.3.0 PC (default) >> rhel6.2.0 RHEL 6.2.0 PC >> rhel6.1.0 RHEL 6.1.0 PC >> rhel6.0.0 RHEL 6.0.0 PC >> rhel5.5.0 RHEL 5.5.0 PC >> rhel5.4.4 RHEL 5.4.4 PC >> rhel5.4.0 RHEL 5.4.0 PC >> >> Thread-1296::ERROR::2013-03-07 15:55:24,988::vm::240::vm.Vm::(run) >> vmId=`c978cbf8-6b4d-4d6f-9435-480d9fed31c4`::Failed to migrate >> Traceback (most recent call last): >> File "/usr/share/vdsm/vm.py", line 223, in run >> self._startUnderlyingMigration() >> File "/usr/share/vdsm/libvirtvm.py", line 451, in >> _startUnderlyingMigration >> None, maxBandwidth) >> File "/usr/share/vdsm/libvirtvm.py", line 491, in f >> ret = attr(*args, **kwargs) >> File "/usr/lib/python2.6/site-packages/vdsm/libvirtconnection.py", >> line 82, in wrapper >> ret = f(*args, **kwargs) >> File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1178, in >> migrateToURI2 >> if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed', >> dom=self) >> libvirtError: internal error Process exited while reading console log >> output: Supported machines are: >> pc RHEL 6.3.0 PC (alias of rhel6.3.0) >> rhel6.3.0 RHEL 6.3.0 PC (default) >> rhel6.2.0 RHEL 6.2.0 PC >> rhel6.1.0 RHEL 6.1.0 PC >> rhel6.0.0 RHEL 6.0.0 PC >> rhel5.5.0 RHEL 5.5.0 PC >> rhel5.4.4 RHEL 5.4.4 PC >> rhel5.4.0 RHEL 5.4.0 PC >> >> But I guess this is fine and migration from higher host version to a >> lower version is probably not supported, right? > > Well, I suppose that qemu would allow migration if you begine with a > a *guest* of version rhel6.3.0. Please try it out. > > Dan. Alright, just verified it. A vm started on a 6.3 host can be successfully migrated to the new 6.4 host and then back to any other 6.3 host. It just won't migrate a vm started on 6.4 to any host running 6.3. Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

1 0

Re: [CentOS-devel] [Users] 6.4 CR: oVirt 3.1 breaks with missing cpu features after update to CentOS 6.4 (6.3 + CR)
by Patrick Hurrelmann 07 Mar '13

07 Mar '13

On 05.03.2013 13:49, Dan Kenigsberg wrote: > On Tue, Mar 05, 2013 at 12:32:31PM +0100, Patrick Hurrelmann wrote: >> On 05.03.2013 11:14, Dan Kenigsberg wrote: >> <snip> >>>>>> >>>>>> My version of vdsm as stated by Dreyou: >>>>>> v 4.10.0-0.46 (.15), builded from >>>>>> b59c8430b2a511bcea3bc1a954eee4ca1c0f4861 (branch ovirt-3.1) >>>>>> >>>>>> I can't see that Ia241b09c96fa16441ba9421f61a2f9a417f0d978 was merged to >>>>>> 3.1 Branch? >>>>>> >>>>>> I applied that patch locally and restarted vdsmd but this does not >>>>>> change anything. Supported cpu is still as low as Conroe instead of >>>>>> Nehalem. Or is there more to do than patching libvirtvm.py? >>>>> >>>>> What is libvirt's opinion about your cpu compatibility? >>>>> >>>>> virsh -r cpu-compare <(echo '<cpu match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >>>>> >>>>> If you do not get "Host CPU is a superset of CPU described in bla", then >>>>> the problem is within libvirt. >>>>> >>>>> Dan. >>>> >>>> Hi Dan, >>>> >>>> virsh -r cpu-compare <(echo '<cpu >>>> match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >>>> Host CPU is a superset of CPU described in /dev/fd/63 >>>> >>>> So libvirt obviously is fine. Something different would have surprised >>>> my as virsh capabilities seemed correct anyway. >>> >>> So maybe, just maybe, libvirt has changed their cpu_map, a map that >>> ovirt-3.1 had a bug reading. >>> >>> Would you care to apply http://gerrit.ovirt.org/5035 to see if this is >>> it? >>> >>> Dan. >> >> Hi Dan, >> >> success! Applying that patch made the cpu recognition work again. The >> cpu type in admin portal shows again as Nehalem. Output from getVdsCaps: >> >> 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,rdtscp,lm,constant_tsc, >> arch_perfmon,pebs,bts,rep_good,xtopology,nonstop_tsc, >> aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2, >> ssse3,cx16,xtpr,pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida, >> dts,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem, >> model_Conroe,model_coreduo,model_core2duo,model_Penryn, >> model_n270 >> cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz >> cpuSockets = 1 >> cpuSpeed = 2393.769 >> >> >> I compared libvirt's cpu_map.xml on both Centos 6.3 and CentOS 6.4 and >> indeed they do differ in large portions. So this patch should probably >> be merged to 3.1 branch? I will contact Dreyou and request that this >> patch will also be included in his builds. I guess otherwise there will >> be quite some fallout after people start picking CentOS 6.4 for oVirt 3.1. >> >> Thanks again and best regards > > Thank you for reporting this issue and verifying its fix. > > I'm not completely sure that we should keep maintaining the ovirt-3.1 > branch upstream - but a build destined for el6.4 must have it. > > If you believe we should release a fix version for 3.1, please verify > that http://gerrit.ovirt.org/12723 has no ill effects. > > Dan. I did none additional tests and the new CentOS 6.4 host failed start or migrate any vm. It always boils down to: Thread-43::ERROR::2013-03-07 15:02:51,950::task::853::TaskManager.Task::(_setError) Task=`52a9f96f-3dfd-4bcf-8d7a-db14e650b4c1`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 861, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 38, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2551, in getVolumeSize apparentsize = str(volume.Volume.getVSize(sdUUID, imgUUID, volUUID, bs=1)) File "/usr/share/vdsm/storage/volume.py", line 283, in getVSize return mysd.getVolumeClass().getVSize(mysd, imgUUID, volUUID, bs) File "/usr/share/vdsm/storage/blockVolume.py", line 101, in getVSize return int(int(lvm.getLV(sdobj.sdUUID, volUUID).size) / bs) File "/usr/share/vdsm/storage/lvm.py", line 772, in getLV lv = _lvminfo.getLv(vgName, lvName) File "/usr/share/vdsm/storage/lvm.py", line 567, in getLv lvs = self._reloadlvs(vgName) File "/usr/share/vdsm/storage/lvm.py", line 419, in _reloadlvs self._lvs.pop((vgName, lvName), None) File "/usr/lib64/python2.6/contextlib.py", line 34, in __exit__ self.gen.throw(type, value, traceback) File "/usr/share/vdsm/storage/misc.py", line 1219, in acquireContext yield self File "/usr/share/vdsm/storage/lvm.py", line 404, in _reloadlvs lv = makeLV(*fields) File "/usr/share/vdsm/storage/lvm.py", line 218, in makeLV attrs = _attr2NamedTuple(args[LV._fields.index("attr")], LV_ATTR_BITS, "LV_ATTR") File "/usr/share/vdsm/storage/lvm.py", line 188, in _attr2NamedTuple attrs = Attrs(*values) TypeError: __new__() takes exactly 9 arguments (10 given) and followed by: Thread-43::ERROR::2013-03-07 15:02:51,987::dispatcher::69::Storage.Dispatcher.Protect::(run) __new__() takes exactly 9 arguments (10 given) Traceback (most recent call last): File "/usr/share/vdsm/storage/dispatcher.py", line 61, in run result = ctask.prepare(self.func, *args, **kwargs) File "/usr/share/vdsm/storage/task.py", line 1164, in prepare raise self.error TypeError: __new__() takes exactly 9 arguments (10 given) Thread-43::DEBUG::2013-03-07 15:02:51,987::vm::580::vm.Vm::(_startUnderlyingVm) vmId=`7db86f12-8c57-4d2b-a853-a6fd6f7ee82d`::_ongoingCreations released Thread-43::ERROR::2013-03-07 15:02:51,987::vm::604::vm.Vm::(_startUnderlyingVm) vmId=`7db86f12-8c57-4d2b-a853-a6fd6f7ee82d`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm self._run() File "/usr/share/vdsm/libvirtvm.py", line 1289, in _run devices = self.buildConfDevices() File "/usr/share/vdsm/vm.py", line 431, in buildConfDevices self._normalizeVdsmImg(drv) File "/usr/share/vdsm/vm.py", line 358, in _normalizeVdsmImg drv['truesize'] = res['truesize'] KeyError: 'truesize' In webadmin the start and migrate operations fail with 'truesize'. I could find BZ#876958 which has the very same error. So I tried to apply patch http://gerrit.ovirt.org/9317. I had to apply it manually (guess patch would need a rebase for 3.1), but it works. I now can start new virtual machines successfully on a CentOS 6.4 / oVirt 3.1 host. Migration of vm from CentOS 6.3 hosts work, but not the other way around. Migration from 6.4 to 6.3 fails: Thread-1296::ERROR::2013-03-07 15:55:24,845::vm::176::vm.Vm::(_recover) vmId=`c978cbf8-6b4d-4d6f-9435-480d9fed31c4`::internal error Process exited while reading console log output: Supported machines are: pc RHEL 6.3.0 PC (alias of rhel6.3.0) rhel6.3.0 RHEL 6.3.0 PC (default) rhel6.2.0 RHEL 6.2.0 PC rhel6.1.0 RHEL 6.1.0 PC rhel6.0.0 RHEL 6.0.0 PC rhel5.5.0 RHEL 5.5.0 PC rhel5.4.4 RHEL 5.4.4 PC rhel5.4.0 RHEL 5.4.0 PC Thread-1296::ERROR::2013-03-07 15:55:24,988::vm::240::vm.Vm::(run) vmId=`c978cbf8-6b4d-4d6f-9435-480d9fed31c4`::Failed to migrate Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 223, in run self._startUnderlyingMigration() File "/usr/share/vdsm/libvirtvm.py", line 451, in _startUnderlyingMigration None, maxBandwidth) File "/usr/share/vdsm/libvirtvm.py", line 491, in f ret = attr(*args, **kwargs) File "/usr/lib/python2.6/site-packages/vdsm/libvirtconnection.py", line 82, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1178, in migrateToURI2 if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed', dom=self) libvirtError: internal error Process exited while reading console log output: Supported machines are: pc RHEL 6.3.0 PC (alias of rhel6.3.0) rhel6.3.0 RHEL 6.3.0 PC (default) rhel6.2.0 RHEL 6.2.0 PC rhel6.1.0 RHEL 6.1.0 PC rhel6.0.0 RHEL 6.0.0 PC rhel5.5.0 RHEL 5.5.0 PC rhel5.4.4 RHEL 5.4.4 PC rhel5.4.0 RHEL 5.4.0 PC But I guess this is fine and migration from higher host version to a lower version is probably not supported, right? Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

1 0

Re: [CentOS-devel] [Users] 6.4 CR: oVirt 3.1 breaks with missing cpu features after update to CentOS 6.4 (6.3 + CR)
by Patrick Hurrelmann 05 Mar '13

05 Mar '13

On 05.03.2013 11:14, Dan Kenigsberg wrote: <snip> >>>> >>>> My version of vdsm as stated by Dreyou: >>>> v 4.10.0-0.46 (.15), builded from >>>> b59c8430b2a511bcea3bc1a954eee4ca1c0f4861 (branch ovirt-3.1) >>>> >>>> I can't see that Ia241b09c96fa16441ba9421f61a2f9a417f0d978 was merged to >>>> 3.1 Branch? >>>> >>>> I applied that patch locally and restarted vdsmd but this does not >>>> change anything. Supported cpu is still as low as Conroe instead of >>>> Nehalem. Or is there more to do than patching libvirtvm.py? >>> >>> What is libvirt's opinion about your cpu compatibility? >>> >>> virsh -r cpu-compare <(echo '<cpu match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >>> >>> If you do not get "Host CPU is a superset of CPU described in bla", then >>> the problem is within libvirt. >>> >>> Dan. >> >> Hi Dan, >> >> virsh -r cpu-compare <(echo '<cpu >> match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') >> Host CPU is a superset of CPU described in /dev/fd/63 >> >> So libvirt obviously is fine. Something different would have surprised >> my as virsh capabilities seemed correct anyway. > > So maybe, just maybe, libvirt has changed their cpu_map, a map that > ovirt-3.1 had a bug reading. > > Would you care to apply http://gerrit.ovirt.org/5035 to see if this is > it? > > Dan. Hi Dan, success! Applying that patch made the cpu recognition work again. The cpu type in admin portal shows again as Nehalem. Output from getVdsCaps: 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,rdtscp,lm,constant_tsc, arch_perfmon,pebs,bts,rep_good,xtopology,nonstop_tsc, aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2, ssse3,cx16,xtpr,pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida, dts,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem, model_Conroe,model_coreduo,model_core2duo,model_Penryn, model_n270 cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz cpuSockets = 1 cpuSpeed = 2393.769 I compared libvirt's cpu_map.xml on both Centos 6.3 and CentOS 6.4 and indeed they do differ in large portions. So this patch should probably be merged to 3.1 branch? I will contact Dreyou and request that this patch will also be included in his builds. I guess otherwise there will be quite some fallout after people start picking CentOS 6.4 for oVirt 3.1. Thanks again and best regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

1 0

Re: [CentOS-devel] [Users] 6.4 CR: oVirt 3.1 breaks with missing cpu features after update to CentOS 6.4 (6.3 + CR)
by Patrick Hurrelmann 05 Mar '13

05 Mar '13

On 05.03.2013 10:54, Dan Kenigsberg wrote: > On Tue, Mar 05, 2013 at 10:21:16AM +0100, Patrick Hurrelmann wrote: >> On 04.03.2013 21:52, Itamar Heim wrote: >>> On 04/03/2013 19:03, Patrick Hurrelmann wrote: >>>> Hi list, >>>> >>>> I tested the upcoming CentOS 6.4 release with my lab installation of >>>> oVirt 3.1 and it fails to play well. >>>> >>>> Background: freshly installed CentOS 6.3 host in a Nehalem CPU-type >>>> Cluster with 2 other hosts. Storage is iSCSI. Datacenter and Cluster are >>>> both version 3.1. oVirt 3.1 was installed via Dreyou's repo. >>>> >>>> In CentOS 6.3 all is fine and the following rpms are installed: >>>> >>>> libvirt.x86_64 0.9.10-21.el6_3.8 >>>> libvirt-client.x86_64 0.9.10-21.el6_3.8 >>>> libvirt-lock-sanlock.x86_64 0.9.10-21.el6_3.8 >>>> libvirt-python.x86_64 0.9.10-21.el6_3.8 >>>> vdsm.x86_64 4.10.0-0.46.15.el6 >>>> vdsm-cli.noarch 4.10.0-0.46.15.el6 >>>> vdsm-python.x86_64 4.10.0-0.46.15.el6 >>>> vdsm-xmlrpc.noarch 4.10.0-0.46.15.el6 >>>> qemu-kvm.x86_64 2:0.12.1.2-2.295.el6_3.10 >>>> >>>> >>>> uname -a >>>> Linux vh-test1.mydomain.com 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6 >>>> 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux >>>> >>>> virsh cpu capabilities on 6.3: >>>> <cpu> >>>> <arch>x86_64</arch> >>>> <model>Nehalem</model> >>>> <vendor>Intel</vendor> >>>> <topology sockets='1' cores='4' threads='1'/> >>>> <feature name='rdtscp'/> >>>> <feature name='pdcm'/> >>>> <feature name='xtpr'/> >>>> <feature name='tm2'/> >>>> <feature name='est'/> >>>> <feature name='smx'/> >>>> <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> >>>> >>>> and corresponding cpu features from vdsClient: >>>> >>>> cpuCores = 4 >>>> cpuFlags = fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,mtrr,pge,mca, >>>> cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht, >>>> tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon, >>>> pebs,bts,rep_good,xtopology,nonstop_tsc,aperfmperf,pni, >>>> dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr, >>>> pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida,dts,tpr_shadow,vnmi, >>>> flexpriority,ept,vpid,model_Conroe,model_Penryn, >>>> model_Nehalem >>>> cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz >>>> cpuSockets = 1 >>>> cpuSpeed = 2394.132 >>>> >>>> >>>> So the system was updated to 6.4 using the continuous release repo. >>>> >>>> Installed rpms after update to 6.4 (6.3 + CR): >>>> >>>> libvirt.x86_64 0.10.2-18.el6 >>>> libvirt-client.x86_64 0.10.2-18.el6 >>>> libvirt-lock-sanlock.x86_64 0.10.2-18.el6 >>>> libvirt-python.x86_64 0.10.2-18.el6 >>>> vdsm.x86_64 4.10.0-0.46.15.el6 >>>> vdsm-cli.noarch 4.10.0-0.46.15.el6 >>>> vdsm-python.x86_64 4.10.0-0.46.15.el6 >>>> vdsm-xmlrpc.noarch 4.10.0-0.46.15.el6 >>>> qemu-kvm.x86_64 2:0.12.1.2-2.355.el6_4_4.1 >>>> >>>> >>>> uname -a >>>> Linux vh-test1.mydomain.com 2.6.32-358.0.1.el6.x86_64 #1 SMP Wed Feb 27 >>>> 06:06:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux >>>> >>>> virsh capabilities on 6.4: >>>> <cpu> >>>> <arch>x86_64</arch> >>>> <model>Nehalem</model> >>>> <vendor>Intel</vendor> >>>> <topology sockets='1' cores='4' threads='1'/> >>>> <feature name='rdtscp'/> >>>> <feature name='pdcm'/> >>>> <feature name='xtpr'/> >>>> <feature name='tm2'/> >>>> <feature name='est'/> >>>> <feature name='smx'/> >>>> <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> >>>> >>>> and corresponding cpu features from vdsClient: >>>> >>>> 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,rdtscp,lm,constant_tsc,arch_perfmon, >>>> pebs,bts,rep_good,xtopology,nonstop_tsc,aperfmperf,pni, >>>> dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr, >>>> pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida,dts,tpr_shadow,vnmi, >>>> flexpriority,ept,vpid,model_coreduo,model_Conroe >>>> cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz >>>> cpuSockets = 1 >>>> cpuSpeed = 2394.098 >>>> >>>> Full outputs of virsh capabilities and vdsCaps are attached. The only >>>> difference I can see is that 6.4 exposes one additional cpu flags (sep) >>>> and this seems to break the cpu recognition of vdsm. >>>> >>>> Anyone has some hints on how to resolve or debug this further? What more >>>> information can I provide to help? >>>> >>>> Best regards >>>> Patrick >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> >>> seems like a vdsm issue - can you check if you have this patch (not sure >>> its related): >>> >>> commit 558994f8ffe030acd1b851dfd074f3417681337b >>> Author: Mark Wu <wudxw(a)linux.vnet.ibm.com> >>> Date: Tue Oct 9 11:18:10 2012 +0800 >>> >>> Fix a bug in the naming convertion of cpu feature 'sse4_x' >>> >>> The list slice opertion missed the last character. It caused >>> the feature name couldn't get chance to be converted into >>> libvirt's naming. >>> >>> Change-Id: Ia241b09c96fa16441ba9421f61a2f9a417f0d978 >>> Signed-off-by: Mark Wu <wudxw(a)linux.vnet.ibm.com> >>> Reviewed-on: http://gerrit.ovirt.org/8413 >>> Reviewed-by: Dan Kenigsberg <danken(a)redhat.com> >>> Reviewed-by: Michal Skrivanek <michal.skrivanek(a)redhat.com> >>> >>> diff --git a/vdsm/libvirtvm.py b/vdsm/libvirtvm.py >>> index 64a3b6b..bd43b56 100644 >>> --- a/vdsm/libvirtvm.py >>> +++ b/vdsm/libvirtvm.py >>> @@ -735,7 +735,7 @@ class _DomXML: >>> >>> for feature in features[1:]: >>> # convert Linux name of feature to libvirt >>> - if feature[1:5] == 'sse4_': >>> + if feature[1:6] == 'sse4_': >>> feature = feature[0] + 'sse4.' + feature[6:] >>> >>> f = self.doc.createElement('feature') >>> >> >> My version of vdsm as stated by Dreyou: >> v 4.10.0-0.46 (.15), builded from >> b59c8430b2a511bcea3bc1a954eee4ca1c0f4861 (branch ovirt-3.1) >> >> I can't see that Ia241b09c96fa16441ba9421f61a2f9a417f0d978 was merged to >> 3.1 Branch? >> >> I applied that patch locally and restarted vdsmd but this does not >> change anything. Supported cpu is still as low as Conroe instead of >> Nehalem. Or is there more to do than patching libvirtvm.py? > > What is libvirt's opinion about your cpu compatibility? > > virsh -r cpu-compare <(echo '<cpu match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') > > If you do not get "Host CPU is a superset of CPU described in bla", then > the problem is within libvirt. > > Dan. Hi Dan, virsh -r cpu-compare <(echo '<cpu match="minimum"><model>Nehalem</model><vendor>Intel</vendor></cpu>') Host CPU is a superset of CPU described in /dev/fd/63 So libvirt obviously is fine. Something different would have surprised my as virsh capabilities seemed correct anyway. Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

1 0

Re: [CentOS-devel] [Users] 6.4 CR: oVirt 3.1 breaks with missing cpu features after update to CentOS 6.4 (6.3 + CR)
by Patrick Hurrelmann 05 Mar '13

05 Mar '13

On 04.03.2013 21:52, Itamar Heim wrote: > On 04/03/2013 19:03, Patrick Hurrelmann wrote: >> Hi list, >> >> I tested the upcoming CentOS 6.4 release with my lab installation of >> oVirt 3.1 and it fails to play well. >> >> Background: freshly installed CentOS 6.3 host in a Nehalem CPU-type >> Cluster with 2 other hosts. Storage is iSCSI. Datacenter and Cluster are >> both version 3.1. oVirt 3.1 was installed via Dreyou's repo. >> >> In CentOS 6.3 all is fine and the following rpms are installed: >> >> libvirt.x86_64 0.9.10-21.el6_3.8 >> libvirt-client.x86_64 0.9.10-21.el6_3.8 >> libvirt-lock-sanlock.x86_64 0.9.10-21.el6_3.8 >> libvirt-python.x86_64 0.9.10-21.el6_3.8 >> vdsm.x86_64 4.10.0-0.46.15.el6 >> vdsm-cli.noarch 4.10.0-0.46.15.el6 >> vdsm-python.x86_64 4.10.0-0.46.15.el6 >> vdsm-xmlrpc.noarch 4.10.0-0.46.15.el6 >> qemu-kvm.x86_64 2:0.12.1.2-2.295.el6_3.10 >> >> >> uname -a >> Linux vh-test1.mydomain.com 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6 >> 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux >> >> virsh cpu capabilities on 6.3: >> <cpu> >> <arch>x86_64</arch> >> <model>Nehalem</model> >> <vendor>Intel</vendor> >> <topology sockets='1' cores='4' threads='1'/> >> <feature name='rdtscp'/> >> <feature name='pdcm'/> >> <feature name='xtpr'/> >> <feature name='tm2'/> >> <feature name='est'/> >> <feature name='smx'/> >> <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> >> >> and corresponding cpu features from vdsClient: >> >> cpuCores = 4 >> cpuFlags = fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,mtrr,pge,mca, >> cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht, >> tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon, >> pebs,bts,rep_good,xtopology,nonstop_tsc,aperfmperf,pni, >> dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr, >> pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida,dts,tpr_shadow,vnmi, >> flexpriority,ept,vpid,model_Conroe,model_Penryn, >> model_Nehalem >> cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz >> cpuSockets = 1 >> cpuSpeed = 2394.132 >> >> >> So the system was updated to 6.4 using the continuous release repo. >> >> Installed rpms after update to 6.4 (6.3 + CR): >> >> libvirt.x86_64 0.10.2-18.el6 >> libvirt-client.x86_64 0.10.2-18.el6 >> libvirt-lock-sanlock.x86_64 0.10.2-18.el6 >> libvirt-python.x86_64 0.10.2-18.el6 >> vdsm.x86_64 4.10.0-0.46.15.el6 >> vdsm-cli.noarch 4.10.0-0.46.15.el6 >> vdsm-python.x86_64 4.10.0-0.46.15.el6 >> vdsm-xmlrpc.noarch 4.10.0-0.46.15.el6 >> qemu-kvm.x86_64 2:0.12.1.2-2.355.el6_4_4.1 >> >> >> uname -a >> Linux vh-test1.mydomain.com 2.6.32-358.0.1.el6.x86_64 #1 SMP Wed Feb 27 >> 06:06:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux >> >> virsh capabilities on 6.4: >> <cpu> >> <arch>x86_64</arch> >> <model>Nehalem</model> >> <vendor>Intel</vendor> >> <topology sockets='1' cores='4' threads='1'/> >> <feature name='rdtscp'/> >> <feature name='pdcm'/> >> <feature name='xtpr'/> >> <feature name='tm2'/> >> <feature name='est'/> >> <feature name='smx'/> >> <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> >> >> and corresponding cpu features from vdsClient: >> >> 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,rdtscp,lm,constant_tsc,arch_perfmon, >> pebs,bts,rep_good,xtopology,nonstop_tsc,aperfmperf,pni, >> dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr, >> pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida,dts,tpr_shadow,vnmi, >> flexpriority,ept,vpid,model_coreduo,model_Conroe >> cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz >> cpuSockets = 1 >> cpuSpeed = 2394.098 >> >> Full outputs of virsh capabilities and vdsCaps are attached. The only >> difference I can see is that 6.4 exposes one additional cpu flags (sep) >> and this seems to break the cpu recognition of vdsm. >> >> Anyone has some hints on how to resolve or debug this further? What more >> information can I provide to help? >> >> Best regards >> Patrick >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > > seems like a vdsm issue - can you check if you have this patch (not sure > its related): > > commit 558994f8ffe030acd1b851dfd074f3417681337b > Author: Mark Wu <wudxw(a)linux.vnet.ibm.com> > Date: Tue Oct 9 11:18:10 2012 +0800 > > Fix a bug in the naming convertion of cpu feature 'sse4_x' > > The list slice opertion missed the last character. It caused > the feature name couldn't get chance to be converted into > libvirt's naming. > > Change-Id: Ia241b09c96fa16441ba9421f61a2f9a417f0d978 > Signed-off-by: Mark Wu <wudxw(a)linux.vnet.ibm.com> > Reviewed-on: http://gerrit.ovirt.org/8413 > Reviewed-by: Dan Kenigsberg <danken(a)redhat.com> > Reviewed-by: Michal Skrivanek <michal.skrivanek(a)redhat.com> > > diff --git a/vdsm/libvirtvm.py b/vdsm/libvirtvm.py > index 64a3b6b..bd43b56 100644 > --- a/vdsm/libvirtvm.py > +++ b/vdsm/libvirtvm.py > @@ -735,7 +735,7 @@ class _DomXML: > > for feature in features[1:]: > # convert Linux name of feature to libvirt > - if feature[1:5] == 'sse4_': > + if feature[1:6] == 'sse4_': > feature = feature[0] + 'sse4.' + feature[6:] > > f = self.doc.createElement('feature') > My version of vdsm as stated by Dreyou: v 4.10.0-0.46 (.15), builded from b59c8430b2a511bcea3bc1a954eee4ca1c0f4861 (branch ovirt-3.1) I can't see that Ia241b09c96fa16441ba9421f61a2f9a417f0d978 was merged to 3.1 Branch? I applied that patch locally and restarted vdsmd but this does not change anything. Supported cpu is still as low as Conroe instead of Nehalem. Or is there more to do than patching libvirtvm.py? Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

1 0

6.4 CR: oVirt 3.1 breaks with missing cpu features after update to CentOS 6.4 (6.3 + CR)
by Patrick Hurrelmann 05 Mar '13

05 Mar '13

Hi list, I tested the upcoming CentOS 6.4 release with my lab installation of oVirt 3.1 and it fails to play well. Background: freshly installed CentOS 6.3 host in a Nehalem CPU-type Cluster with 2 other hosts. Storage is iSCSI. Datacenter and Cluster are both version 3.1. oVirt 3.1 was installed via Dreyou's repo. In CentOS 6.3 all is fine and the following rpms are installed: libvirt.x86_64 0.9.10-21.el6_3.8 libvirt-client.x86_64 0.9.10-21.el6_3.8 libvirt-lock-sanlock.x86_64 0.9.10-21.el6_3.8 libvirt-python.x86_64 0.9.10-21.el6_3.8 vdsm.x86_64 4.10.0-0.46.15.el6 vdsm-cli.noarch 4.10.0-0.46.15.el6 vdsm-python.x86_64 4.10.0-0.46.15.el6 vdsm-xmlrpc.noarch 4.10.0-0.46.15.el6 qemu-kvm.x86_64 2:0.12.1.2-2.295.el6_3.10 uname -a Linux vh-test1.mydomain.com 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux virsh cpu capabilities on 6.3: <cpu> <arch>x86_64</arch> <model>Nehalem</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='1'/> <feature name='rdtscp'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='smx'/> <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> and corresponding cpu features from vdsClient: cpuCores = 4 cpuFlags = fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,mtrr,pge,mca, cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht, tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon, pebs,bts,rep_good,xtopology,nonstop_tsc,aperfmperf,pni, dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr, pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida,dts,tpr_shadow,vnmi, flexpriority,ept,vpid,model_Conroe,model_Penryn, model_Nehalem cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz cpuSockets = 1 cpuSpeed = 2394.132 So the system was updated to 6.4 using the continuous release repo. Installed rpms after update to 6.4 (6.3 + CR): libvirt.x86_64 0.10.2-18.el6 libvirt-client.x86_64 0.10.2-18.el6 libvirt-lock-sanlock.x86_64 0.10.2-18.el6 libvirt-python.x86_64 0.10.2-18.el6 vdsm.x86_64 4.10.0-0.46.15.el6 vdsm-cli.noarch 4.10.0-0.46.15.el6 vdsm-python.x86_64 4.10.0-0.46.15.el6 vdsm-xmlrpc.noarch 4.10.0-0.46.15.el6 qemu-kvm.x86_64 2:0.12.1.2-2.355.el6_4_4.1 uname -a Linux vh-test1.mydomain.com 2.6.32-358.0.1.el6.x86_64 #1 SMP Wed Feb 27 06:06:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux virsh capabilities on 6.4: <cpu> <arch>x86_64</arch> <model>Nehalem</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='1'/> <feature name='rdtscp'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='smx'/> <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> and corresponding cpu features from vdsClient: 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,rdtscp,lm,constant_tsc,arch_perfmon, pebs,bts,rep_good,xtopology,nonstop_tsc,aperfmperf,pni, dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr, pdcm,sse4_1,sse4_2,popcnt,lahf_lm,ida,dts,tpr_shadow,vnmi, flexpriority,ept,vpid,model_coreduo,model_Conroe cpuModel = Intel(R) Xeon(R) CPU X3430 @ 2.40GHz cpuSockets = 1 cpuSpeed = 2394.098 Full outputs of virsh capabilities and vdsCaps are attached. The only difference I can see is that 6.4 exposes one additional cpu flags (sep) and this seems to break the cpu recognition of vdsm. Anyone has some hints on how to resolve or debug this further? What more information can I provide to help? Best regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

2 2

another 6.4 gotcha
by Joe Pruett 03 Mar '13

03 Mar '13

something changed in the kvm audio subsystem, so a virt that was suspended during shutdown wouldn't resume after reboot. the logs had complaints of: savevm: unsupported version 2 for 'hda-audio' v1 load of migration failed i poked around on the rh bz site and found a few hits, but they seemed to be related to older versions. i forced a clean boot of my vm and it was happy.

3 3

CetOS-6.4 via 6.3/cr
by Karanbir Singh 01 Mar '13

01 Mar '13

hi, By now most people would have seen or atleast have spotted the 6.3/cr/ repos are populated and updates there announced to the cr-announce list. 6.4 is a big release, lots of changes and lots of feedback about things ( also, we found in our limited testing that there are some surprises around the corners! ) Most people on the -devel list here should know about how we use the /cr/ repo and its implications - So with that in mind, please test the package payloads and provide feedback on this list. We are going to start working on the isos from today/tomorrow and start testing those right away, but in the mean time it would be great if we could get as wide as possible testing done against 6.3 + cr, and then document into the Release Notes whatever comes through. And remember, even if the test passes - let us know what you tested and that it passes'. Its important for us to build a coverage model as well. Thanks - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

9 11

Re: [CentOS-devel] CetOS-6.4 via 6.3/cr
by Iain Douglas 01 Mar '13

01 Mar '13

On 02/28/2013 12:07 AM, Karanbir Singh wrote: > And remember, even if the test passes - let us know what you tested and > that it passes'. Its important for us to build a coverage model as well. I've run my copy of t_functional on an updated system (an x86_64 VM running on VMWare ESXi 5.1) no problems encountered. Iain

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel March 2013