Probably not, since I implemented the KVM change out of necessity. I mentioned it on-list, but there's not a lot of formal synchronization between the hypervisors for small tweaks like that. If it goes into the service offering that would prompt everyone to look at supporting it, I think. If you would, please take a minute to enter it as a feature request.
On Thu, Apr 17, 2014 at 12:31 PM, mphilli7823 <[email protected]> wrote: > I'm still on 4.2.1, I wonder if the same changes were made with vmware on 4.3 > up... > > > Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone > > <div>-------- Original message --------</div><div>From: Marcus > <[email protected]> </div><div>Date:04/17/2014 1:07 PM (GMT-06:00) > </div><div>To: [email protected] </div><div>Subject: Re: CS cores vs > sockets </div><div> > </div> > With KVM this has been mitigated somewhat in newer code (4.3 and up). > It's a bit rudimentary, but we could expand it to work via config > options. Right now, if the number of cores is divisible by 4, it > creates quad core sockets. If the number is divisible by 6, it creates > hexacore sockets, with the hexacore taking precedence for something > like 12. > > On Thu, Apr 17, 2014 at 11:46 AM, Michael Phillips > <[email protected]> wrote: >> I think this issue may have been raised in the past, but was not addressed.. >> When creating a service offering in CS using multiple "cores" CS, actually >> creates the VM in the background with multiple sockets. Example a 6 "core" >> offering actually translates into a 6 socket offering. This is a problem on >> certain OS's and applications like SQL 2012. SQL 2012 has a 4 socket >> maximum. The easiest fix, might be just to allow the admin to specify how to >> arrive at the core count when creating the service offering. >> http://msdn.microsoft.com/en-us/library/ms143760.aspx >> I can't speak for other hypervisors, but this definitely effects vmware. The >> only workaround without a fix is to change the vm via virtual center... >> Thoughts?
