I had a fun day resolving a licensing issue for a client. This one was a little different than I had seen in the past. The cluster in question is an eight node cluster running ESX 3.5. The error message that I received when trying to perform a vMotion was “Unable to migrate from HostA to HostB: Virtual machine has 2 virtual CPUs, but the host only supports 1. The number of virtual CPU’s may be limited by the guest OS selected for the virtual machine or by the licensing for the host.”
At first, I thought this might be an issue with the virtual machine being a 64bit Windows 2008 virtual machine with multiple virtual CPU’s. After further review of the environment I discovered this issue was happening with all multi-processor virtual machines. I also discovered that this issue was happening on six of the eight hosts in the cluster.First step was to look for any obvious licensing issues. All the hosts in the cluster were reporting that it was using the correct license server and in the configuration tab, on all the hosts, appeared to have all the correct licensed features. I opened the VMware License Server tool and restarted the license server service itself and then re-read the license file. Once that was complete, I verified that the correct amounts of licenses were being used and everything, license related, was showing what I expected. Still, no luck on the vMotion working properly, which also keeps DRS from working properly.
This was beginning to get me a little concerned, especially if anything else were to go wrong with any of the hosts in the cluster. One last thing to try before I sounded the alarm, resetting the license service on the hosts itself. To do this I went to the configuration tab for the host in the vCenter client. On the licensed features link I was able to change the ESX Server Edition from ESX Server Standard to Unlicensed. Once the host was unlicensed, I change the ESX Server Edition back to ESX Server Standard. I repeated this step on the six hosts that were throwing this error and then tested several multi-processor virtual machines to make sure the issue was completely resolved. All the virtual machines were now able to vMotion around, from host to host. The cluster was back to a fully functional state.
As for the root cause, I am not quite sure, but believe that there may have been some sort of error or latency in communication from the hosts to the license server itself. I verified that the license server was running the latest version and all indication from vCenter was that the license server was communicating with the hosts. This was the first time I have seen this kind of error before and was a little bit of a pain to track down but I am relieved that the solution was easy and non intrusive.
This could be one of the reasons VMware moved from a License Server model to a License Key per host model for VMware vSphere 4.0.