Re: [Xen-devel] Xen domU Timekeeping

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Mon, Feb 13, 2012 at 06:18:07PM -0800, Qrux wrote:
> Howdy, all.
> 
> Is there definitive documentation about accurate timekeeping on Linux PV 
> domUs (Xen-4.1.2, Linux-3.1-pvops)?
> 
> Specifically:
> 
>       * Is there a way to keep good time (i.e., bare-metal accuracy) on domU?

It does that now. It uses the same clock as the hypervisor does so there
is no "lost ticks" or such.

> 
>       * What's happened to /proc/sys/xen/independent_wallclock?

No idea. What did that do?

> 
>       * What should be done with /sbin/hwclock (if copied from a dom0)?

Well, nothing. Having a domU change the hardware time is a security
violation. It should not be able to change the hardware time.
> 
>       * Does NTP on domU "work"?  Does adjtimex do anything?

It will fix whatever time issues (if any) of the guest. But it won't
adjust the hardware clock. That can only be done in dom0. So if you run
NTP in dom0 it will do it.
> 
>       * Are there "bad side-effects" to "bad time" on domUs (see below)...?

Sure. If the time is skewed or off there are scheduling issues. Meaning
some applications will run longer (or shorter) than they are suppose to.

> 
> I'd be happy for an: "RTFM @ http://...,"; response, if the docs were 
> definitive.
> 
> ===============================================================================
> 
> In addition, I'm having hard-to-track issues using ext4 on a domU, which I 
> suspect may be related to the timekeeping issue(s).  When I boot this domU 
> the first time, everything comes up nicely.  The kernel has ext2, ext3, and 
> ext4 drivers built in.  I see this on the console:
> 
>       [ 0.283049] EXT3-fs (xvda1): error: couldn't 
> mount...unsupported...features
>       [ 0.288476] EXT2-fs (xvda1): error: couldn't 
> mount...unsupported...features
> 
> which is expected--and makes perfect sense--because I expect the next line to 
> be this:
> 
>       [ 0.318273] EXT4-fs (xvda1): mounted filesystem with ordered data 
> mode...
> 
> And, that is what I observe.  At least, on the first boot...
> 
> But, upon reboot of the domU, I get stuck at the ext3/ext2 errors.  Guessing, 
> I destroyed the nonfunctional domU, and reformatted its drive as ext3.  This 
> worked.  I was able to reboot that domU without a problem.  Google didn't 
> find too much information except this:
> 
>       http://lists.openwall.net/linux-ext4/2009/10/12/12
> 
> But this is from 2009.  And, I'm not sure how relevant it is, directly, but 
> it did make me wonder...Does not having "good time" on domUs affect the 
> ability of the kernel to mount filesystems?  Could that be breaking ext4 on a 
> domU with NTP?  And, despite the article's age, is using ext4 with 
> "barriers=0" still valid advice...?

The issue you are hitting is probably based on what version of backend
you are using. Meaning what version of dom0 you have? It might be that
it needs :
http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg01784.html

> 
> Then...Accidentally, when I had the domU disk device mounted on dom0 
> (debugging, and forgot to umount before xl create), the domU came up 
> fine--albeit slightly pissed off because it thought that the filesystem had 
> errors.  But, it "repaired" the "errors" just fine (I assume they were 
> related to the double-rw-mount), and booted.
> 
> I'm assuming all of this is documented somewhere; I just need a pointer to 
> where to find this info.
> 
> ===============================================================================
> 
> Thanks,
>       Q
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel