I have restored an image of a production SQL Server 2008 R2 to a Virtual Machine to test out some changes.
When I try to start SQL Server to recreate
tempdb (in partition that was not restored), it throws the following error:
Your SQL Server installation is either corrupt or has been tampered with (Invalid max number of sockets or cores). Please uninstall then re-run setup to correct this problem.
The command I was using to start SQL Server is the following one:
SQLServr.exe /f /t3608 -s instancename
It would seem like the simplest solution to this would be to have however many cores it's expecting. Since that's not really an option with my current environment, I'm hoping to edit whatever setting is determining how many processors it's expecting.
However, I'm not seeing any documentation on doing this. Can anyone point me in the right direction?
It seems like this would have to be supported for servers that go from two processors to one, or any other kind of processor change.
SQL Server provides a
cpu_count column in the view
sys.dm_os_sys_info. Perhaps if I could modify wherever it is stored to match the server's actual running CPU count, it might start. However I can't find much info on where those values are pulled from, either aside from the docs.microsoft.com page below:
I don't think the problem is related to tempdb. I'm just running it in single user to recreate tempdb, since tempdb was not on the partition that got restored. I think the problem has to do with the fact that the source server had 8 virtual processors, and the destination has 2-4.
I tried updating the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\NUMBER_OF_PROCESSORS but it gives the same error. Seemed like Windows reset it back to the original value on reboot, so I tried it without rebooting afterwards. Still same error.
Storage is a vanilla dynamic
.vhd file. Nothing set for persistence.
SQL Server cannot start due to the error. The intent was to use this installation to test out changes to the existing setup. Reinstalling SQL Server would create a fresh configuration and defeat the purpose of the VM.
I could see how a core licensing issue would come into play, but I figured that there would have to be some method of limping along in the case of a single processor failure on a two proc server.