I've converted a number of physical servers (NT, W2k3) to our VI3 infrastructure over the past few months but the last one I did is having some major problems keeping accurate time.
It's a w2k3 SP0 box and loses ~40 mins over a 45 minute period and when I watch the second-hand on the clock, it stumbles round so 1 second change takes 5-6 'real' seconds sometimes.
I'm using the w32time service to keep time and not synching with the ESX host but I don't understand why the time is so far out. The only difference to the other P2Vs I've done is that the converter service/time de-scheduler service is still visible in the Services tab (but not running).
thanks for the suggestion but I don't see how this explains why I am seeing this anomalous behaviour on a single VM when all my other new and converted VMs are running perfectly happy on the same infrastructure. There are many ways to sync time in the virtual environment and ESX/NTP/VMtools is not a cure-all as far as I can tell.
The only difference between this and other conversions is that it may have had the Converter agent installed when I P2Vd it (from a previous conversion attempt).
Would this have had an impact - I've had to clear off a lot of the converter files post-conversion - they didn't seem to get removed automatically.
read the paper - best method for timesync is using the vmware tools.
please try using the tools and come back if it doesn`t work with the tools.
forget about ntp or other methods
Sorry, not sure I understand...you're saying don't bother with NTP but how else do we keep the ESX hosts in line? Without syncing the hosts themselves, the vmware tools time syncing will be different between hosts..that sounds like a recipe for disaster - in a Windows domain environment anyway.
I think we're getting off track here - forget the timekeeping choices - I just want to explain why this 1 VM is having so much trouble syncing time when all our other windows VMs are all hunky dory...just can't figure it.
i am having the same issue with a machine that was p2v'd all other vm's on the host work fine except this one which loses a 'lot' of time. it would be nice to know why this is happenening so ill keep looking into it
I didn't resolve this and went for the nuclear option - complete rebuild of the VM. After this, no more problems so something went screwy in the conversion process somewhere....
Hmm...another instance of the same problem.
Another conversion a few weeks ago and now it's leaking time like nobody's business. It's lost nearly two hours in the two hours it has been running...
Have you tried reinstalling vmware tools?
Under the VM's settings, does it list the correct build of your OS under the name drop down list?
Please have a look at the following documentation:
Thanks - reinstalled the 'Tools and things are looking a lot better - not going to say it's ok until it's been running for a few days/weeks though!
Any ideas why the reinstall was needed?
Vmware converter has it's own repository for vmware tools for ESX. This makes things much easier and automated, however it also can be an issue.
For example, suppose you were converting to ESX 3.5 with converter 3.0.2. ESX is newer then converter and therefore the version of tools may not be the correct build required for that VM. If ever you have an issue with mouse/keyboard/video/network/time, reinstall tools manually. If you are able to, simply choose not to install tools via converter and do so yourself afterwards.
Thanks - but I never use the Converter to install VMware Tools - I always do it manually from the VI Client later.
Anyway, news is that the Tools reinstall didn't solve the problem - have tracked it down to the application itself. When the app kicks in, it completely shafts the VM and it grinds to a halt time-wise (ticks by 1 OS second every 30 'real' seconds or so). I can turn it on and off like a tap by starting and stopping the application.
It doesn't appear to be under extreme load in terms of CPU/RAM so i'm a bit puzzled as to why it's having such an effect on the VM....