@JaredBusch said in Domain Time off for some members:

@Donahue said in Domain Time off for some members:

found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.

How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.

look at the picture I posted above. It was vmtoolsd.exe that was causing it to jump forward and svchost.exe that was correcting it. I found this under event 4616

They aren't in the ML community but special shoutout to Ariel Sanchez and Joe Houghes for this help. Somebody needs to get them into ML.

https://twitter.com/TheRealNerdyDad/status/1049365117140447238

@networknerd said in VMware vSphere 6 Showing No CPU or Memory Used:

. I thought the back end data from the screenshot above was populated by data from the hypervisor only and not from VMware Tools, but we shall see.

I would have expected so, given the type of data that it is.

@brandon220 said in How to take advantage of virtualization. Major products get updated:

I plan on setting this up in the lab soon. dm-cache also sounds interesting. I've never touched software RAID because 95% of my environment has been MS for a long time. Always have gone the hw raid route.

https://www.redhat.com/en/blog/improving-read-performance-dm-cache

Redhat did some testing with an SSD but it looks ugly. 5 passes and no performance improvement using a SSD. I suspect they are hamstrung by the patent minefield that is ARC (IBM of all people has this patent BTW) and the subsidiary cool optimizations that have been made to it (ARC was intended for CPU cache originally, your storage fun fact of the day!). Also I suspect the IO path on this thing isn't the cleanest. Looks like the Linux kernel file cache is going to be faster which if I"m using that I might as well just give memory to the guest and let it sort it out (especially with the lack of dedupe or single instancing of this cache).

If your looking to speed stuff up I say get "the good stuff".

We got some PMEM DIMMS in the lab, and this stuff is face melting fast. You can "bolt" it on with a DAX file system, but the best way to use it is with applications that have been redesigned to support it. We forked REDIS to support this and got latency 12x better than using local NVMe drives, and 2.8x better tha DAX.
Oracle had 57x better operational latency.
0_1534916586664_Redis.PNG
0_1534916590424_Oracle.PNG

Interesting read. I hope I never need to use it. Though, I would rather have it and not need it...