Bug 1370230 - Restore current timestamp after restore
Summary: Restore current timestamp after restore
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-25 16:26 UTC by David Ashley
Modified: 2024-12-17 12:09 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-12-17 12:09:20 UTC
Embargoed:


Attachments (Terms of Use)

Description David Ashley 2016-08-25 16:26:58 UTC
Description of problem: Currently when a domain is restored from a saved state the current time in the new running state is relative to the saved state i.e. when the domain is restored the current time in the running domain is incorrect.


Version-Release number of selected component (if applicable): N/A


How reproducible: Always.


Steps to Reproduce:
1. Save a running domain using either a managed save or a file/save.
2. Sometime later restore the domain.
3. The current time in the running domain will be relative to the saved state, not the real time or date.

Actual results: The time in the domain is never updated after a restore. Even if the domain is running the ntp daemon.


Expected results: The time in the domain should be reset to reflect the current real time.


Additional info: This should actually be easy to fix by adding a qemu-ga command after the restore (guest-set-time) so that the correct time is used by the domain. Of course, this may have consequenses for users who actually expect the time to not be reset in a restored domain. But I think this will be a small minority of users and most users would actually expect the time to changes after a restore to the current time.

Comment 1 Daniel Berrangé 2024-12-17 12:09:20 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.


Note You need to log in before you can comment on or make changes to this bug.