[
https://issues.apache.org/jira/browse/CLOUDSTACK-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-3443:
-------------------------------------------
These blockers and critical issues are resolved but not verified. Reporters of
these issues please verify the fixes and help close these issues
> Timeoffset on Windows guests not persisted between VM stop/start from
> Cloudstack
> --------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-3443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3443
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Affects Versions: 4.0.0, 4.1.0, 4.2.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 VM.
--
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: http://www.atlassian.com/software/jira
