Bug 193292

Summary: [xen] XenServer PVHVM guest clock problems
Product: Base System Reporter: Mark Felder <feld>
Component: kernAssignee: Roger Pau Monné <royger>
Status: Closed FIXED    
Severity: Affects Some People Keywords: patch
Priority: ---    
Version: 10.0-RELEASE   
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
Patch to disable the PV timer none

Description Mark Felder freebsd_committer freebsd_triage 2014-09-03 18:50:02 UTC 
Disclaimer:

I can confirm the following problem does not happen with 9.x XENHVM kernel guest after migration. I cannot confirm behavior after suspend/resume at this time as I have not tested it recently and do not have a test server readily available.

Overview:

FreeBSD 10.0+ uses a newer virtualization guest mode called PVHVM. As a guest on Citrix XenServer (confirmed 6.2 SP1 with all patches) it fails to set the clock correctly upon migrating a FreeBSD guest or resuming a FreeBSD guest. This might be a hypervisor problem. There are two different behaviors based on the action you take.


XM / XSM (Xen Migration / Xen Storage Migration):

It does not matter if you are just migrating between hosts in a pool or between pools. Upon successful migration you will find that the FreeBSD guest server's clock is off -- it is set to UTC/GMT. Example: If your FreeBSD guest timezone is -0500 and you migrate the VM midday at 12:00, after successful migration the clock will be 17:00. You will have to manually run ntpdate to correct the time skew and it can cause a lot of problems.


Suspend / Resume (Suspension of the VM at the HyperVisor level, not FreeBSD zzz/ZZZ level):

After resuming the VM the clock is not set at all. Immediately executing date(1) will show something like:

Thu Jan  1 00:00:00 CDT 1970

Or a few seconds after, of course. Again, this will be a major disruption to the operation of the FreeBSD OS.
Comment 1 Roger Pau Monné freebsd_committer freebsd_triage 2014-09-04 17:33:00 UTC 
I can at least confirm that save/restore is working fine with upstream Xen, see for example the output of one of the Xen CI loop tests:

http://www.chiark.greenend.org.uk/~xensrcts/logs/30083/test-amd64-i386-freebsd10-amd64/10.ts-guest-saverestore.log

It clearly shows that the date is correct after restore. I guess the following commit is missing on XenServer:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=f8e8fd56bd7d5675e8331b4ec74bae76c9dbf24e

There's a related commit that also fixes a bug in suspend/resume for PVHVM (which I guess hasn't been backported to XenServer yet):

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=32c864a35ece2c24a336d183869a546798a4b241

Without both of this the PV timer is not really usable when doing suspend/resume on PVHVM. I would recommend as a workaround to manually set kern.timecounter.hardware to HPET for example and kern.eventtimer.timer to LAPIC if you plan to perform suspensions until this is fixed on XenServer.
Comment 2 Mark Felder freebsd_committer freebsd_triage 2014-09-04 18:44:26 UTC 
Do you have any reason to believe that changing kern.timecounter.hardware and kern.eventtimer.timer before a XM or XSM will prevent those clock issues from happening as well? Or is that a completely different issue?


Thanks!
Comment 3 Roger Pau Monné freebsd_committer freebsd_triage 2014-09-05 14:35:16 UTC 
No, sorry, I'm on vacations and I'm kind of spaced out. Changing the eventtimer and timecounter would not solve the issues, and AFAICT there's no way to change the clock from sysctl. The only option is to comment the clock_register call in the xen timer code (sys/dev/xen/timer/timer.c). I will look into adding a sysctl to disable registering the PV clock when I'm back from vacations.
Comment 4 Roger Pau Monné freebsd_committer freebsd_triage 2014-09-15 16:28:00 UTC 
Created attachment 147352 [details]
Patch to disable the PV timer

The following patch should allow you to disable the PV timer at boot time by setting "hw.xen.disable_pv_timer=1" on /boot/loader.conf. Could you please test it to see if that solves your problems?