Why do database servers have different time_source values
According to MSDN, SQL Server uses the following logic to decide which timer to use:

Windows does not have an API to indicate what source QueryPerformanceCounter is using at this time so SQL Server 2008 R2 startup times the invocation of QueryPerformanceCounter (10 times) and when it exhibits repeated, small cycle behavior (&lt; 600 cycles) the QueryPerformanceCounter will be used to accept invariant TSC timings instead of the GetTickCount/timeBeginPeriod interrupt timing behavior.   If the timing exceeds 600 cycles the multi-media timer behavior of SQL Server is used instead.
Note:  Windows is exposing the timer source API for QueryPerformanceCounter in a Windows 2008 R2 based fix so the timing source determination by SQL Server will be replaced with the API call in a future build.  Target releases are the SP1 of Windows 2008 R2 and SQL Server 2008 R2.

The above explanation indirectly answers your questions:

SQL Server uses an internal process to determine which timer to use.
You cannot tell SQL Server 2008 R2 which timer to use, other than by using trace flags 8049 and 8038.  In my testing, neither of those trace flags made any difference to the timer_source column of sys.dm_os_sys_info.


We rebooted the majority of our servers over the weekend.  I compared the list of machines using MULTIMEDIA_TIMER from before and after the reboot.  I can now report that some of the servers that were using the MULTIMEDIA_TIMER are now using QUERY_PERFORMANCE_COUNTER and vice-versa.
Since our servers are virtualized, I presume simultaneously booting machines in our virtualized environment is resulting in some machines taking longer than 600 CPU cycles to return a value through the QueryPerformanceCounter API.  This effect appears to be randomly distributed across our environment.