During the deployment of the vcOPs vApp for a customer I ran into a new error – well, new for me. While the vApp (v5.8.1) deployed and booted fine, as I was registering it with the vCenter (v 5.1) as part of the initial configuration I got the following error: Unable to get vCenter server certification chain. Off we go to Google… Here’s a quick summary of things to check:
Confirm name resolution is working, username/passwords are right, etc.
Assuming Windows, RDP to vCenter with the user you’re attempting to use or try access via your favorite vSphere management tool
Hop on the console of the UI VM and ping the vCenter by IP and DNS name (username: root initial password: vmware)
Check that your vCenter certificate hasn’t expired. It’s the rui.crt file in c:\ProgramData\VMware\VMware VirtualCenter\SSL. This article has good info on locating and renewing your certificate, should that be your problem.
In the end, my fix came by importing the certificate file to the UI VM manually as outlined in this VMware KB article.
Full disclosure, the symptoms in the above article didn’t match my problem exactly and I don’t like just trying random fixes. However, when I found this Blog Post, in Spanish, with my exact error recommending a similar .cert import process I threw caution to the wind. The exact steps from the Spanish blog didn’t quite work, which could be a result of my inability to read Spanish and/or Google Translate not being perfect, but the VMware KB article was spot on.
After importing the certificate manually and restarting services, all was well and I was able to complete the configuration of vcOPs. By the way, did you know that since vSphere 5.1, all licensed versions of vSphere now include the Foundation edition of vcOPs? More than 5 hosts in your environment and you’ve got enough scale to warrant leveraging this tool. For a limited time, VMware is letting Lewan perform a free vSphere Optimization Check including a 60 day trial of the Standard Edition, complete with the capacity management features, dynamic thresholds, and root cause analysis. Give us a call today to test drive Operations Management!
This came up recently for a customer and while it’s not new news, I thought a quick reminder would be useful. There are a few key points to remember about licensing of Windows Server 2012 in server virtualization projects, these rules apply to XenServer, VMware, Hyper-V, Oracle VM, etc.:
Licenses are applied to physical servers, never to virtual machines. If you are thinking about how you need a license for the VM you are about to build, you’re probably doing something wrong
There is feature parity between Standard and Datacenter editions, Enterprise Ed has been dropped
The only difference between these 2 major editions is in the number of virtual OSE’s (operating system environments, aka a virtual machine) granted with the license
A license covers 2 processor sockets within 1 server, 1 license cannot be purchased to cover 2 servers each containing 1 populated processor
The license allows for one bare-metal install of the operating system, but doesn’t require it – as would be the case if your hypervisor is anything other than Hyper-V
Virtual OSE grants by edition:
Standard: 2 virtual OSE’s per license
Datacenter: unlimited OSE’s per license
More than 1 license of the same edition may be applied to a given physical server to cover additional CPU sockets or additional virtual machines
2 Standard Edition licenses would cover 4 processor sockets and/or up to 4 VM’s
2 Datacenter Edition licenses would cover 4 processor sockets and two * unlimited for the number of VM’s ..that’s like beyond infinity, but 4 CPU sockets.
The license cannot be transferred more than once every 90 days – yeah, you read that right. This rule is to prevent a license from jumping from one host to another to follow live migration activities
This is where most people pause and say “oh..”. That tells me they were purchasing 1 license per VM and just thinking the license moves around with the VM
You need to cover the high water mark of virtual OSE’s for a given host
Standard Ed. list pricing is $882
Datacenter Ed. list pricing is $4809
The break-even point for Datacenter is at 5.45 Standard licenses; in effect, for a density of more than 10 VM’s (5 std licenses each granting 2 OSE’s), you should use a Datacenter Edition license
A real world example: New virtualization customer deploying 3 VMware hosts
We generally size the environment for N+1, meaning we’re planning that 1 of the servers is a “spare” from the perspective of workload sizing – so all the workload can run on just 2 servers; we’re planning for this and so should you in your licensing.
If you plan to run more than 20 total VM’s in this environment, you need 3 Datacenter Edition licenses
20 VM’s running on 2 servers = 10 VM’s/server
10 VM’s requires 5 Standard Edition licenses to have enough OSE grants
More than 10 per server, and it’s now cheaper to have just bought a single Datacenter Edition license
6 * $882 = $5292, which is greater than $4809 for datacenter
Since you don’t know which host (think of a rolling patching cycle) is going to carry the increase load, all the hosts in the environment should be licensed uniformly to this high water mark
Depending on the licensing model, an upgrade from 5 * Standard Edition licenses to a single Datacenter Edition license may not be possible – plan ahead!
If you have OEM licenses that came with your old physical server environment, these are likely not transferrable – they don’t follow the P2V action
With this understanding, while you might have some work to do upfront (or scrambling to get back into compliance now) the long term savings are very real for dense virtualization projects that can leverage the Datacenter Edition license. On a modern 2 socket server with 16 cores/32 threads, 10 VM or greater density is easily achievable
For our reference, I’ve copied the content below:
“Another thing to check if you experience this error is to see if you have jumbo frames enabled on the management network, since this interferes with HA communication.”
To make it crystal clear: disable jumbo frames on your management network with vSphere 5.0 as there’s a problem with it! This problem is currently being investigated by the HA engineering team and will hopefully be resolved.