cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Devdeep Singh (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-3443) Timeoffset on Windows guests not persisted between VM stop/start from Cloudstack
Date Wed, 10 Jul 2013 11:37:50 GMT


Devdeep Singh commented on CLOUDSTACK-3443:

Fix would be to persist the platform:timeoffset when a vm is stopped and reapply the value
when the vm is started (recreated) on xenserver host.
> Timeoffset on Windows guests not persisted between VM stop/start from Cloudstack
> --------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-3443
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.1.0
>            Reporter: Devdeep Singh
>            Assignee: Devdeep Singh
>            Priority: Critical
>             Fix For: 4.2.0
> For Windows guests, time is initially driven from the control domain clock. However,
XenServer also stores for each Windows VM a time offset. This represents the difference between
the control domain time and the guest, and is persisted for each VM. if you manually set a
VM to be 2 hours ahead of the control domain (e.g. via a time-zone offset within the guest),
then it will remember that.
> This information is stored by Xenserver in the parameter "platform" in a key/value pair
where the key is "timeoffset". You can check this using "xe vm-param-list uuid=<vmuuid>".
> This information is persisted with Xenserver until the VM exists. The problem is that
Cloudstack stop VM operation is really a destroy on Xenserver. When you start the VM again
a new VM is launched (of course using the same disk). In this process the above information
is lost as Cloudstack doesn't store it and pass it on to the hypervisor when launching the

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message