Re: [Xen-devel] [XEN-3.4] pv_ops dom0 time/clock handling --solved

[Daniel Schroeder <sec@xxxxxxxxxxxxxxx>]

Jeremy Fitzhardinge wrote:
> Daniel Schroeder wrote:
>> Wed May 27 09:33:12 CEST 2009
>> Mi Mai 27 11:33:13 CEST 2009
>>   
> 
> That does look like some kind of TZ issue, but I'm not sure where it
> would be.
> 
>> btw: i have checked with 32 bit pvops and 64 bit pvops dom0 and the time
>>  in the domU is correct with the 64bit pvops dom0 kernel...this wasnt
>> the same domU...so, next step for me, is to copy the domU to the 64bit
>> system and try again...to verify, that this only happens for me with
>> 32bit pvops dom0...
>>   
> 
> How odd.
> 
>>> One difference between pvops time handling and the -xen kernels, is that
>>> they defaulted to slaving the domU time off the hypervisor at all times,
>>> so a system time change would propagate into guests.  I don't implement
>>> that in pvops kernels, so they'll maintain independent time unless you
>>> explicitly sync with some mechanism like ntp.
>>>     
>> hmm...does this mean, that i have to use ntp in domU if i use the pvops
>> kernel? Because time changes in dom0 doesnt propagate into domUs?
>>   
> 
> It will set its initial time-of-day clock from the hypervisor's at boot,

hmm...hwclock --show on affected system:

hwclock --show
Wed May 27 23:06:20 2009  -0.778274 seconds

hwclock was set to localtime...

on not affected system

hwclock --show
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access
method.

i have changed the settings in my distro from hwclock localtime to UTC,
reset the hwclock
hwclock --utc --systohc
rebooted
everything is fine now...

:)

thx!
daniel

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