The command implementation for Windows guest has this limitation. If no time to set has been provided the documentation for the command states that time should be read from RTC. However, on Windows bare GetSystemTime() is used, which does not read anything from RTC rather than return system time. Yeah, that system time which is wrong (after stop & cont) and which we want to set.
However, there's no simple way to read RTC on windows yet [1], so until the time somebody comes with bright implementation, we should at least document the command implementation limitation. 1: http://msdn.microsoft.com/en-us/library/aa908981.aspx Signed-off-by: Michal Privoznik <mpriv...@redhat.com> --- qga/qapi-schema.json | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json index 376e79f..91821ef 100644 --- a/qga/qapi-schema.json +++ b/qga/qapi-schema.json @@ -121,7 +121,10 @@ # given value, then sets the Hardware Clock (RTC) to the # current System Time. This will make it easier for a guest # to resynchronize without waiting for NTP. If no @time is -# specified, then the time to set is read from RTC. +# specified, then the time to set is read from RTC. On Windows +# guests there's implementation limitation that does not read the +# time from RTC if no time has been provided. Users are advised +# to allways pass a value for Windows guests. # # @time: #optional time of nanoseconds, relative to the Epoch # of 1970-01-01 in UTC. -- 2.0.5
