On Mar 11, 2014, at 04:54 AM, Serge Hallyn wrote:
Thanks for filing this bug. I'd like to try to reproduce it but need a
few more details. Can you tell us exactly how you set up the vm, how
you start it, and how you initiate suspend? Is this all done through
virt-manager? You say it is a
Thanks, Barry. So IIUC this has nothing to do with qemu, so I'm
switching it to linux.
Is it safe to assume that other VMs - other Ubuntu releases, or other
distros, or windows, do not have this behavior?
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed
Hi,
Thanks for filing this bug. I'd like to try to reproduce it but need a
few more details. Can you tell us exactly how you set up the vm, how
you start it, and how you initiate suspend? Is this all done through
virt-manager? You say it is a vmware fusion vm - does that mean you
started with
This is first and foremost a QEMU or linux bug (not sure which), it
should really update its internal time after suspend. But I suppose ntp
could also listen to resume events (perhaps through pm-utils' /usr/lib
/pm-utils/sleep.d/ scripts); although this should already be covered by
its existing
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1157914
On Mar 08, 2014, at 04:59 PM, Martin Pitt wrote:
This is first and foremost a QEMU or linux bug (not sure which), it
should really update its internal time after suspend. But I suppose ntp
could also listen to resume events (perhaps through pm-utils' /usr/lib
/pm-utils/sleep.d/ scripts); although
