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.
