VMware Cloud Community
FreddyFredFred
Hot Shot
Hot Shot

windows date/time taking a long time to update after a snapshot revert

I've got users with snapshots on their test vms that when they revert, it seems to take windows several minutes (maybe 5 sometimes) to adjust the clock. These snapshots include memory so I get complaints occasionally they tests fail because the time/date are wrong. Windows is up and running and ready to go but the date/time isn't right.

Restarting the vmware tools service is one fix but requires manual intervention. I thought vmware triggered the update relatively quickly after a revert but that doesn't seem to be the case all the time.

I have not made any special changes to the vm configs, everything is default.

Is there anything I can do to make windows force the time/date to adjust much faster after a revert?

13 Replies
vijayrana968
Virtuoso
Virtuoso

Are those servers a part of active domain ? If yes then the default NTP for those servers should be a domain controller. To ensure this run a cmd command on windows server w32tm /query /status

Check third last and second last line for status.

Also make sure you have not selected to Synchronize Time with ESXI host in VMware Tools options in VM edit settings.

0 Kudos
FreddyFredFred
Hot Shot
Hot Shot

The VMs are part of a domain and they are not set to sync with the host.

I thought what happened is that vmware tools causes the date/time to jump ahead (using the esxi host as the reference) and then windows time sync will pull things closer as needed via ntp.

I spun a quick vm to test with but it's working as expected (time jumps within seconds of the revert) so I'll need to find a user with a problematic vm. I've seen the issue and I was watching at the console of the vm and after 2-3 minutes the time still had not fixed itself.

0 Kudos
vijayrana968
Virtuoso
Virtuoso

Probably we both need to look at this as I’m having same issue in my lab    Completely Disable Time Synchronization for your VM - Virtualize Applications

0 Kudos
FreddyFredFred
Hot Shot
Hot Shot

what version of vmware tools you running? My test vm is latest (10.2.5) but the ones I have seen the problem on are older

0 Kudos
golddiggie
Champion
Champion

I have to ask... Are these VMs running all the time and they just need a clean state to revert to and won't need to roll up the snapshot into the VM at some point? If so, I would consider switching from using snapshots to setting the virtual disk to be non-persistent. Basically, while the VM is powered up/running, writes to the drive remain. If you shut down the VM (not reboot it) then those changes go away (back to 'clean' state).

If that's not an option, then what OS are the VMs running? How up to date are the patches on them? Were the snapshots taken when a different DST was in effect?

FreddyFredFred
Hot Shot
Hot Shot

Interesting idea about the non-persistent disks but in this case I don't think it would work since users take snapshots with all kinds of different configs and will bounce around, they're not simply  reverting to a clean state.

As for the OS, I'm not 100% certain but from memory one of the users was running 2012 R2. I can't answer patch level or DST though but I'm sure it's all over the place and it's going to be a bit of a job to try and gather that info.

Even if DST was involved, wouldn't that be irrelevant since vmware will use the hosts time to set the clock / date? We're not talking about the time being 1hr off but the date/time just not "snapping" to the correct value until several minutes later.

0 Kudos
golddiggie
Champion
Champion

When the snapshots were taken (on the problem children) was the memory state also captured???

0 Kudos
FreddyFredFred
Hot Shot
Hot Shot

yes, the memory state was captured. Cold boot doesn't seem to be a problem, only snaps that have memory state.

0 Kudos
golddiggie
Champion
Champion

Your issue with those VMs is, in all likely-hood, due to the memory state also being included in the snapshot. I stopped using that checkbox a long time ago. If the VMs where this was NOT selected don't have the issue, then there's your sign.

BTW, I really don't like it when 'developers' use snapshots and keep them around for extended periods of time. There are better ways to set up VMs for use by developers, where you won't have so many issues (or use so much storage space). IMO/IME, they use snapshots thinking that they have zero impact and are great. meanwhile, they are impacting the performance of the VMs and they are also consuming more and more storage space every second they exist.

IMO, snapshots = evil if allowed to live for more than a few days.

0 Kudos
FreddyFredFred
Hot Shot
Hot Shot

To the best of my knowledge, when a snapshot with memory is reverted, vmware is supposed to get the vmware tools to adjust the time within the guest OS to match the time of the esxi host it's running on. This happens almost instantly on a test vm I just created with a memory snapshot but I've also seen it not work for several minutes on other vms and this is what I want to fix.

I've given up trying to ask them to uncheck the memory box, cleaning up their snapshots, powering off/deleting vms not being used for a while. It's like herding cats!

If you have a better way for all the developers and qa people to work or for me to provide them resources, please share. There's no production stuff on the hosts they use so they only people they hurt are themselves.

0 Kudos
golddiggie
Champion
Champion

Depending on your budget level, you could try using something like vRealize Automation to allow them to spin up new VMs (from a set of templates for their use) as needed (with approvals for anything over certain parameters). If you have no budget (or it's worse than going for a root canal to get approval) then we'll need to get more creative. Depending on how many developers you have molesting your environment, and how many VMs they have, you could have some options. One group at the software company I worked at last had several VMs based off the same VM, with the same name and IP address, but with different software versions on them (for the company software). They would simply power on (and off) the ones they needed to use. While it might not be AS fast as using snapshots, it was very trouble free. It could consume some more storage, depending on how many VMs they actually need, but if they don't need high performance, just go thin provisioned. If they want more VMs, then get them to pitch in for more storage capacity to fill the need (with room to spare).

It baffles me how some software companies want all these capabilities, to use VMs, but when you tell them that because they're using three times the amount of resources they originally claimed they would use, that more needs to be purchased. Then they cry poor. Meanwhile, they're spending thousands, each month (or week) on other crap that is a waste of funds.

0 Kudos
FreddyFredFred
Hot Shot
Hot Shot

We're already using vRealize Orchestrator with workflows I developed to spin vms from templates and a custom front end portal to do the requests and I'll probably hit 2000 vms before the end of the year and money isn't the problem.

I don't know how we got side tracked but I was asking about why vmware wasn't behaving as expected when it comes to reverting snapshot and adjusting the date/time. I still don't have an answer.

golddiggie
Champion
Champion

IMO, you should look deeper into the software/OS on the troubled VMs.

0 Kudos