xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Lloyd Dizon <thecarrionkind@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Todd Deshane <todd.deshane@xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Remi Gacogne <rgacogne-xen@valombre.net>
Subject: Re: [Xen-devel]  Xen timekeeping best practices
Date: Tue, 17 Apr 2012 11:35:03 +0200	[thread overview]
Message-ID: <CAFj8LadgCU4j7BE3VCz6y1j8XT0eyoLwaUw1bbF71VD+2=tbFQ@mail.gmail.com> (raw)
In-Reply-To: <1334650567.11493.17.camel@dagon.hellion.org.uk>

On Tue, Apr 17, 2012 at 10:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-04-17 at 08:41 +0100, Lloyd Dizon wrote:
>> On Mon, Apr 16, 2012 at 4:57 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Mon, 2012-04-16 at 15:45 +0100, Lloyd Dizon wrote:
>> >> On Mon, Apr 16, 2012 at 11:57 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> >
>> >> > On Fri, 2012-04-13 at 18:22 +0100, Todd Deshane wrote:
>> >> > > Adding Xen-devel.
>> >> > >
>> >> > > What are the current timekeeping best practices now?
>> >> >
>> >> > pvops kernels behave as if independent_wallclock == 1, so the existing
>> >> > advice:
>> >> >        set /proc/sys/xen/independent_wallclock to 1 and run ntp on
>> >> >        domU.
>> >> > still applies.
>> >>
>> >> This also applies to Xen 4.0 (4.0.0) if I understood correctly?
>> >
>> > This is entirely a function of the guest kernel version and not the
>> > hypervisor
>> >
>> >> If so and based on previous posts can we resume that this is what is
>> >> recommended:
>> >
>> > If you s/Xen3/Classic XenoLinux Kernels/ and s/Xen4/Paravirt Ops Linux
>> > Kernels/g then I think it is somewhat accurate, at least for the PV
>> > line.
>> >
>> > I must confess I don't really know for the HVM line. I suspect that it
>> > is actually:
>> >
>> > Classic XenoLinux -- no PV time source, independent_wallclock means
>> > nothing, run NTP in the guest
>> >
>> > Paravirt ops kernels _without_ PV time PVHVM extensions -- no PV time
>> > source, independent_wallclock means nothing, run NTP in the guest
>> >
>> > Paravirt ops kernels _with_ PV time PVHVM extensions -- PV time source,
>> > independent_wallclock always == 1, run NTP.
>> >
>> > So in short always run NTP in an HVM guest, regardless of the presence
>> > or absence of PV time extensions
>>
>> I do not fully understand the difference yet between and Classic
>> XenoLinux and Paravirt Ops Kernel (will dig the info later)
>
> Roughly:
>
> classic == old out-of-tree Xen patches, static compile time support for
> Xen. This is the old "2.6.18-xen.hg" tree and includes the "SuSE forward
> port kernels" which are the classic patches kept up to date with recent
> kernels.
>
> pvops == patches in upstream Linux, dynamic support for Xen enabled at
> kernel boot time. pvops supported domU from ~2.6.24 and dom0 from 3.0
> onwards.

Thanks also found info here:
http://wiki.xensource.com/xenwiki/XenDom0Kernels.html


>>  but here
>> is the resume:
>>
>>        -------------------------------------------------------------------------------------------------------------------
>>        |  Xen3: Classic XenoLinux Kern                     |
>>     Xen4: Paravirt Ops Linux Kern                 |
>> --------------------------------------------------------------------------------------------------------------------------
>>  PV    | independent_wallclock = 0 or 1                    |
>> independent_wallclock =  1                                  |
>> --------------------------------------------------------------------------------------------------------------------------
>>  HVM   | -> no PV timesource, no ind. wallclock, run NTP   | -> w/o PV
>> time PVHVM extensions, no ind. wallclock, run NTP |
>>        |                                                   | -> PV
>> time source, ind. wallclock always 1, run NTP         |
>> --------------------------------------------------------------------------------------------------------------------------
>
> It got a bit mangled in transit but it looks reasonable.
>
> You should remove "Xen3" and "Xen4" from the titles since the hypervisor
> version has no bearing on any of this. You can just as easily run a
> pvops kernel on Xen3.x or a classic kernel on Xen4.x (and of course you
> can mix and match those on a single host)
>
> The 3->4 major number transition was mostly just a version number bump,
> it didn't indicate any major change in the API or anything like that --
> any PV kernel should run on any Xen from 3.0 onwards, right through to
> 4.2 (and beyond).
>
>> Should we put this somewhere (wiki) until somebody else proves this is
>> inaccurate ?
>
> Please do put it on the wiki, I think there was a reference to a page (a
> FAQ?) further up thread which seems like as good a place as any to add
> it.

Done.
Anybody please correct the information if inaccurate.
http://wiki.xensource.com/wiki/Xen_FAQ_DomU#How_can_i_synchronize_a_dom0_clock.3F

      reply	other threads:[~2012-04-17  9:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.DEB.2.00.1204131435280.16529@legendary.xserve.fr>
     [not found] ` <CAFj8LacDbEc00x6vSyG+hgkB1omVbcE8aiC0Au7gR=xAGicXeA@mail.gmail.com>
     [not found]   ` <CAMrPLWJE5VpfH6d_3ZumHPqOX3Vi2sV3ppahN-WE=kjO2zejcA@mail.gmail.com>
     [not found]     ` <alpine.DEB.2.00.1204131825410.16529@legendary.xserve.fr>
2012-04-13 17:22       ` [Xen-users] Xen timekeeping best practices Todd Deshane
2012-04-16  9:57         ` Ian Campbell
2012-04-16 12:55           ` [Xen-devel] " Remi Gacogne
2012-04-16 14:45           ` Lloyd Dizon
2012-04-16 14:57             ` [Xen-users] " Ian Campbell
2012-04-17  7:41               ` [Xen-devel] " Lloyd Dizon
2012-04-17  8:16                 ` [Xen-users] " Ian Campbell
2012-04-17  9:35                   ` Lloyd Dizon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFj8LadgCU4j7BE3VCz6y1j8XT0eyoLwaUw1bbF71VD+2=tbFQ@mail.gmail.com' \
    --to=thecarrionkind@gmail.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=rgacogne-xen@valombre.net \
    --cc=todd.deshane@xen.org \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-users@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).