Guest additions confuse clock in linux guest (windows 7 host)

[Adrian]

In broken state, guest reports UTC time as local time. No combination of checkboxes and config files inside or outside of the guest seems to help.

Scenario:

New Windows 7 laptop with Core i7 (Sandy Bridge), 64 bit. Install VirtualBox 4.1.2 Create VM expecting ubuntu 64 bit: notice VBox correctly guesses that the hardware clock will be UTC. Install Ubuntu Desktop 10.04 64bit in new VM, specifying timezone near Hong Kong, guest should be online during installation and therefore do ntp early. Notice that the clock is good before installing guest additions. Install guest additions, clock now shows UTC time, not local time, but thinks it's local time. E.g. on my box in China, at midnight UTC, "date -R" thinks it's midnight in China and 4pm in London (winter), when it's actually 8am in China and midnight in London. Try every combination of /etc/default/rcS -> UTC=yes/no, vbox:settings:guest hw clock=UTC, even using vboxmanage to inhibit clock sync. Nothing helps. This is a total show stopper for me and I'm now installing ubuntu natively, which is a bummer cos windows does some things better, like Chinese characters.

[Frank Mehnert]

Uninstall the ntp daemon in the guest because this daemon will conflict with the VirtualBox Guest Additions.

[Adrian]

What an absolute cop-out!

There is a conflict between these two time sync systems, but by what right does the VirtualBox system claim precendence over the world standard? Every system has NTP up and running out of the box, so it is the VBox system which is obsolete and disruptive.

Your suggestion boils down to "we did something silly, the user should clean up the mess, and we think that's just fine." How long do you think it takes the user to even prove that VBox is at fault? This is wasting time for everybody.

[Frank Mehnert]

Calm down my friend and stop insulting us. Removing the ntp daemon is a suggestion to make it work. If you have two time synchronization daemons running in the same system then you will always experience such problems, even on a real system. You might objects that the Guest Additions should just detect the presence of NTP and then disable the time synchronization part of the GA. This is not easily possible because in principle every user-level program could do that synchronization and we can't guess.

[Adrian]

I'm sorry if I lost my rag but your apathy was rather shocking. You seem to agree that switching off VBox's buggy time sync is the right thing to do, but rather than issuing a CR to that effect, you expect millions of users to fight through this mystery for themselves.

You're appealing to a tiny minority of theoretically possible scenarios, to justify screwing things up in the vast majority of cases. The outcome of your highly questionable logic is that you don't need to do anything. You must admit, it does look like apathy.

I never suggested you should detect NTP, let alone worry about some kind of theoretical home-made NTP: I suggested you assume NTP is there, because it almost always is. You currently assume it is not, which is preposterously unlikely, and you break NTP as a result.

It's also wrong to say there would necessarily be problems with two time sync mechamisms. Your mechanism is buggy with or without NTP. If your mechanism had worked, I never would have noticed there were two of them.

Have you calculated how many people are likely to be hit by this? I think it's anybody with the guest hardware clock on UTC, but I'm not sure.

Did you estimate how much trouble it was for me to diagnose this, before you apathetically set the case to minimum priority? At first I didn't suspect VBox at all. I thought it was Ubuntu getting confused about how I'd set the hardware clock. I googled about that to no avail, then I took a close look at the RTP settings, which I never had to worry about before. When that drew a blank I turned to the VBox settings, but THERE IS NO SETTING on the UI for this. If there had been, I might at least have stumbled across the solution by accident. How about a CR to provide one? Eventually I found the command line mantra to switch off the time sync, but I forgot the ""s around the machine name so it FAILED SILENTLY! At this point I exonerated VBox because the problem persisted although I thought I'd switched it off. How about a CR to have VBoxManage print error messages? Now I'd eliminated every possible factor and was completely stumped.

That's 3 different things you could do to contain the damage this is causing, not to mention, actually fixing the bug. Instead, you prefer to waste millions of man hours for the human race because you don't want to take a simple decision to issue a CR to fix the underlying bug, finish the UI/CLI or simply flip the boolean to deactivate this buggy and redundant feature by default.

I know it's tragic when yesterday's code is made obsolete by progress around it, but it's natural and inevitable, and products should not drag useless code around for sentimental reasons. Especially not when it's buggy (a point your email didn't address at all.)

Now then, do you still want to embarrass yourself by insisting that the right and proper thing to do is nothing at all?