Last week, I was listening to John Rives, CEO of Amniox, speak about virtualization and clustered VMS (see pictures at http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!2292.entry. Thanks Louis!) at the local SQL Server User Group meeting in Nashville.
John gave a really interesting talk about implementing virtualization and many of the benefits and pitfalls that you might encounter. Most of the content was review for me, but the one concept that was new was a biggee - clock drift.
Clock drift is a situation in which the actual time shown on the physical machine's (PM) clock, for example 3:53 pm today, is no longer in sync with one or more of the clocks of virtual machines' (VM) running on the PM, showing 12:12 pm today and 9:30 pm yesterday. This can happen because the VMs 1) only receive a slice of the PM's total processing power and cycles, thus getting confused on the time, and 2) the application(s) running on the VM do not manually synchronize the VM clock with the PM's clock or an external time source. Naturally, if you're running SQL Server, this can be a huge data integrity problem for you - especially for any transactions that record the date and time.
This is a fairly old-school problem, it turns out, and there are lots of hits when you google for "clock drift virtualization". However, the state of the industry seems to be somewhat immature in that the best hits tended to be blogs and discussion forums rather than vendor documentation or best practices papers. If you're developing applications for SQL Server that might be implemented on a VM, do yourself a favor and make sure you include clock syncronization processes as part of the application. Otherwise, you might have to deal with a nasty clock drift problem.
Regards,
-Kev
