Roger that. Well, backports without version change is one of the main reasons I use (RH)EL, so depends you look at it. Anyway, it does not seem like a big thing affecting users, so good job on finding a fix. Thanks.
Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Marcus" <shadow...@gmail.com> > To: dev@cloudstack.apache.org > Sent: Friday, 6 February, 2015 16:22:15 > Subject: Re: [VOTE] Apache CloudStack 4.5.0 RC1 > CentOS *6* users, that is... > > > On Fri, Feb 6, 2015 at 8:19 AM, Marcus <shadow...@gmail.com> wrote: >> If a vm is pv enabled, it gets the kvmclock timer xml attribute, >> regardless. Setting kvmclock.disable makes that timer xml explicitly >> disable kvmclock, it doesn't remove it from the xml (You might be >> thinking "why do we need a setting to enable it if we have to >> explicitly disable it to make it go away?"... this is again due to >> variations in version behavior, some versions make pv guests have >> kvmclock regardless unless explicitly disabled). There were some >> issues in certain kvm (kernel) versions that would cause problems with >> live migration and kvmclock, so this option would fix that if someone >> runs into it, but we can't leverage this agent option to remove the >> xml that the ubuntu 12.04 libvirt version doesn't support. >> >> Nux, some more background, at one point system vms were having various >> issues because of clock drift. A few of the other hypervisor platforms >> were leveraging their hypervisor to fix this. Running ntp in the >> system vm was mentioned (and perhaps even implemented, I'd have to go >> back and look), but some didn't like that solution, either, because >> without a project to add ntp settings as a 'thing' in cloudstack it >> would require internet access or an admin rolling their own system vm. >> Network issues aside, f you look around at the greater KVM ecosystem >> there is quite a bit of back and forth on whether kvmclock or NTP is >> ideal, and the best option seems to be to have both. >> >> So that, combined with the live migration issues, is what introduced >> the kvmclock xml both to make it available to pv guests and to >> explicitly disable it if there are issues. >> >> I spoke to Mike about this last night, and hopefully we'll be seeing a >> fix that simply acts like older CS versions if we detect the feature >> is unsupported. So we'll automagically work on newer platforms like >> Ubuntu 13+ and CentOS 7 and fail back correctly for old Ubuntu, with >> the only downside being that CentOS users can't leverage kvmclock even >> though their build supports it (the fault of RH backporting features >> without changing versions). >> >> >> >> >> On Fri, Feb 6, 2015 at 1:02 AM, Nux! <n...@li.nux.ro> wrote: >>> That's unfortunate, but I don't think many people will care. >>> >>> Pretty much everyone in virt uses ntp religiously and am yet to hear >>> complains >>> about clock performance in VMs. >>> >>> Having said that, could the feature be enforceable through agent.properties >>> if >>> desired? Something like Rohit is suggesting with kvmclock.disable=false? >>> >>> Lucian >>> >>> -- >>> Sent from the Delta quadrant using Borg technology! >>> >>> Nux! >>> www.nux.ro >>> >>> ----- Original Message ----- >>>> From: "Marcus" <shadow...@gmail.com> >>>> To: dev@cloudstack.apache.org >>>> Sent: Friday, 6 February, 2015 06:45:14 >>>> Subject: Re: [VOTE] Apache CloudStack 4.5.0 RC1 >>> >>>> I think we can wrap this in a version check as we have many other >>>> things, that way Ubuntu 12.04 users who leverage newer libvirt >>>> packages (as I'm temped to believe the majority of actual deployments >>>> do) can still see the benefit, and we don't have to worry about >>>> targeting a specific release. This will have the negative side effect >>>> of not allowing centos 6.x people from leveraging their backported >>>> support since their version numbers are deceptive, but it's probably > >>> the smartest, most compatible way to indroduce it.
