Hey Dzaku,
This sounds like a RedHat / KVM bug...
Bug 742736 - Use rtc tickpolicy catchup by default for windows guests
Their solution looks like this.
Quote:
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
</clock>
|
your current configuration
Quote:
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
<timer name='hypervclock' present='yes'/>
</clock>
|
Admittedly, I'm unsure why a programmable interval timer set to "delay" would impact your real time clock, however it's often helpful to isolate specific calls until you find the one going balls up. So, if left to my own devices I'd probably...
Save your config, strip out all other timer references from the clock element (use the config section from the bug report). See if you can reproduce the problem (we're testing to see if the pit timer interacting with the real time clock is at the heart of the problem). If that works, think about why you need the PIT timer.
If that doesn't work, create a timer as the first entry of the clock element
Quote:
|
timer name='platform' tickpolicy='catchup'
|
As I understand the KVM clock structure, the 'platform' timer establishes policy for all other timers in the VM, so perhaps that will solve your problem.
Sorry I don't have a silver bullet for you, but you live in a boat city in Poland so I'm thinking you appreciate a challenge...
KVM trouble width time
