On 2014/9/5 1:40, Laine Stump wrote: > I do point out the existence of exactly the problem that you are fixing. > However, there is a problem with the way you're fixing it if the clock > for the domain is set like this: > > <clock offset ='variable' basis='localtime'/> > > The problem is that when the domain was started, its *state* (but not > persistent config) was modified to convert the localtime adjustment into > an adjustment relative to UTC (and the basis type in the state was of > course also changed from VIR_DOMAIN_BASIS_TYPE_LOCALTIME to > VIR_DOMAIN_BASIS_TYPE_UTC). See this commit for details: > > > http://libvirt.org/git/?p=libvirt.git;a=commit;h=cde8ca2dfda6b69eebb70695e5a42b0cc6bd2c38 Thanks to your reply. I think I understand what you mean. If basis is 'localtime', the active config is modified to basis='utc' and of course 'adjustment' is adjusted to a new offset which is relative to UTC. But I met the opposite result. My host's timezone was CST(UTC +8:00). Clock configuration is <clock offset='variable' adjustment='120' basis='localtime'>. I started the VM and found the unexpected result. In the active config(/var/run/libvirt/qemu/*.xml), basis was utc, but adjustment was 120(which was expected to 120 + 8*3600). In the persistent config, basis was localtime and adjustment was 120. Use gdb and set breakpoint to qemuProcessHandleRTCChange. Adjust the VM's hardware clock. The result also shows me the state(active config) is not right. (gdb) p vm->def->clock.data $3 = {utc_reset = 120, variable = {adjustment = 120, basis = 0, adjustment0 = 120}, timezone = 0x78 <Address 0x78 out of bounds>} (gdb) p vm->newDef->clock.data $4 = {utc_reset = 120, variable = {adjustment = 120, basis = 1, adjustment0 = 0}, timezone = 0x78 <Address 0x78 out of bounds>} The difference between vm->def and vm->newDef is there clock.data.variable.basis. Your patch[1] modified the basis to utc, but it seems to only take effect to active config. [1]http://libvirt.org/git/?p=libvirt.git;a=commit;h=cde8ca2dfda6b69eebb70695e5a42b0cc6bd2c38 > (there is also some discussion of why this was done in the mailing list > archives for that patch and for others in the same series). > > So if you just copy that UTC-based adjustment into the persistent > config, it will now be incorrect by the difference between UTC and > localtime. Even doing the math to "adjust the adjustment" by that amount > would end up with an incorrect result if the domain passed through a > daylight time to normal time boundary while it was running (including > migrating from a host in one timezone to a host in another timezone that > currently had a different setting for DST). And you can't modify the > basis type in the persistent config because... well, just *because* :-) > (seriously, I think that would be taking too many liberties with the > user-supplied config). > > On the other hand, the documentation for <clock offset='variable' ...> > specifically says that a change to the RTC will be preserved across > domain restarts (well, it says "reboots", which technically is different > as it doesn't involve terminating and restarting the qemu process, but I > think we all know what the author intended to say there). If my result above it true(if I don't miss anything), I think we should resolve the issue of active config not the persistent one. And fortunately my patch seems to do the right thing because of the localtime-basis adjustment in persistent config. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list