[Expired for linux (Ubuntu) because there has been no activity for 60
days.]
** Changed in: linux (Ubuntu)
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1157914
It would be as well to try it out - particularly as the package has been
updated recently.
I tried a fresh install of Trusty and when 'vmtoolsd' is running from
the 'open-vm-tools' package, the output from 'vmware-toolbox-cmd stat
hosttime' and 'date' are the same after a restore from vmware
On Mar 12, 2014, at 07:31 AM, Neil Wilson wrote:
It would be as well to try it out - particularly as the package has been
updated recently.
Indeed. I installed it, timesync is enabled, removed ntp, and indeed after
about a 20m suspend, once resumed time syncs up again. Since I've not noticed
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
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
On Mar 11, 2014, at 07:56 PM, Serge Hallyn wrote:
Is it safe to assume that other VMs - other Ubuntu releases, or other
distros, or windows, do not have this behavior?
I haven't tried other guest OSes. I'll give Debian and Windows 7 a try.
--
You received this bug notification because you are
I don't see the issue on Windows XP. Only when running Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1157914
Title:
time never catches up to reality after VM sleep
To manage notifications
Barry,
Can you check you VMWare settings for the virtual machine and check that
'synchronise time' is checked in the Advanced Section.
Also do you have the 'open-vm-tools' installed (i.e. is vmtoolsd running
which is what does the time sync to the Host every 60 seconds).
--
You received this
On Mar 11, 2014, at 08:31 PM, Neil Wilson wrote:
Can you check you VMWare settings for the virtual machine and check that
'synchronise time' is checked in the Advanced Section.
Yes, that is checked.
Also do you have the 'open-vm-tools' installed (i.e. is vmtoolsd running
which is what does the
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
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
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1157914
Title:
time
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
** Changed in: indicator-datetime (Ubuntu)
Status: Incomplete = New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1157914
Title:
time never catches up to reality after VM sleep
To manage
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1157914
Title:
So if the entire system's time is falling out of sync after sleep, this
isn't an indicator-datetime bug.
Reassigning to systemd... though I'm not positive this is the right
package
** Package changed: indicator-datetime (Ubuntu) = systemd (Ubuntu)
--
You received this bug notification
On Mar 06, 2014, at 02:06 AM, Charles Kerr wrote:
Is this still an issue in Trusty? I rewrote the sleep/skew detection
code post-13.10 so if you have a convenient setup I'd love to hear how
this goes.
Hi. It's still a problem in Trusty. I have a fairly fresh and up-to-date
Trusty VM, which I
It sounds like you're saying that the entire system's time is off, not
just the indicator's display of it.
What happens when you run date from the command line? Does that time
match the actual time, or the lagging time being displayed by the
indicator?
--
You received this bug notification
On Mar 06, 2014, at 09:37 PM, Charles Kerr wrote:
It sounds like you're saying that the entire system's time is off, not
just the indicator's display of it.
Correct.
What happens when you run date from the command line? Does that time
match the actual time, or the lagging time being displayed
Hi Barry,
Is this still an issue in Trusty? I rewrote the sleep/skew detection
code post-13.10 so if you have a convenient setup I'd love to hear how
this goes.
** Changed in: indicator-datetime (Ubuntu)
Status: Confirmed = Incomplete
--
You received this bug notification because you
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: indicator-datetime (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1157914
27 matches
Mail list logo
