FT CPU Limitation

[Broonie27]

Hi There,

I'm new to VMware so here's a silly question. As I understand it there is a limitation of 1 on the number of vCPUs a VM can have when using FT.

Firstly, is this limitation only for FT or is it for HA as well. Secondly, I have 2 x 8 core CPUs on my blade hosts giving me in effect 16 vCPUs as standard. We will not be running anywhere near 16 VMs on these hosts so we are wasting available processing power. Is there any way you can "trick" FT into thinking 2 of the cores on the host are being presented to the VM as a single VCPU?

Cheers

C

[mittim12]

The limitation is not applicable for HA.  I am not aware of any way to trick FT into using multiple CPU.  I would go ahead and ask my local rep for a road map and to see what the future holds. 

[chriswahl]

I saw a demo of a 4 vCPU FT machine at VMworld 2011. The limitation at the time was in the bandwidth required to log that many cores, as it saturated a good chunk of a network connection to log.

[vGuy]

As mentioned above, the single vCPU limitation is only for FT. AFAIK there is no trick to enable FT on an SMP VM, however there was already a preview of FT with multiple vCPUs (so it's indeed under development 😞

http://www.youtube.com/watch?v=Iu24okqNapI

[Broonie27]

So I can't use trhis technique I stumbled across http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101018... ?

[vGuy · Accepted solution]

nope ...as even when configuring multiple cores per single CPU, you'll still be accessing multiple physical cores.

[Broonie27]

many thanks.

[EdWilts]

I'm new to VMware so here's a silly question. As I understand it there is a limitation of 1 on the number of vCPUs a VM can have when using FT.

Firstly, is this limitation only for FT or is it for HA as well.

There's a fundamental difference between FT and HA.  FT requires that every instruction that is run on one guest also has to be executed on an identical guest on another host.  You can therefore understand that there are going to be serious limitations - your guest isn't going to run any faster than the network between the 2 hosts.  If you do this with multiple CPUs, the network requirements are going to go significantly increase (I've heard 10Gbps per CPU but remember that mulitple CPU support has not been delivered yet).

HA, on the other hand, is basically a boot on another host.  All the 2nd host needs to know is where guest can be located when it's required to be booted up.  Host 1 dies and Host 2 gets told to booth guest1 from datastore 1.  Pretty basic stuff (although the implementation is considerably more complex than that!)

FT is rarely required.  FT *hardware* has been out for many years but is rarely purchased.  It's very complex and expensive.  If you're a bank and can't afford to drop any transaction EVER, you might go for FT.  If you're a web server and you don't have FT, you might drop a session and move it to another web server in your farm and most customers can find that acceptable for a signficantly reduced cost.  We all want 7x24 with never any downtime.  Most of us can't afford it.

[TomHowarth]

Multi vCPU FT Will be here in a future version of ESXi, when that is a question for an NDA Roadmap session and cannot be discussed here in open forum,  if you really need Multi vCPU FT now I suggest you investigate the Marathon product, as this does exactly that

[Broonie27]

Fantastic answer. I'm liking this forum.

[TomHowarth]

you answer is not correct,  in VMware "FT hardware" is nothing more than another set of NICs and a vmkernel network.

[Ckinze]

I know that i am adding to this comversation 3 years later, but since I have found the issue and it is in no way near the issue given in the answer I will do my best to make it clear for anyone else who has this problem in the future.

The issue is simple

The hal.dll and ntoskrnl.exe in the c:\windows\system32 directory are NOT the same versions.

If you have a service pack installed you can use the cd to extract those files and place them into the c:\windows\system32 directory and your issue will go away, you can boot the OS and get on with your business.

[mcowger]

Tom,

Ed is referring to hardware like stratus, which is a very different implementation than VMware.  And Stratus hardware does work to run ESXi.

[Josh26]

Ed Wilts wrote:

FT is rarely required.  FT *hardware* has been out for many years but is rarely purchased.  It's very complex and expensive.

Rant on.

I've been involved in deployment of some of the listed FT hardware. It went in at a software vendor's recommendation, and for no other reason.

The result was a single server that took 12RU of rack space, cost more than a half-stocked Bladecenter, and, most importantly, fell over every time you breathed on it. "Oh, you applied Windows Updates? We don't support that, it's no wonder your server no BSOD's regularly", and, "oh that bad driver of ours is present on both sides of the hardware mirror" were common statements, from a support team that could only get replacement hardware parts through international shipping.

I had an HP DL380 which, as confirmed by our monitoring software, went down less often and for less time.

I can't express enough what garbage these solutions are. Get two servers, use HA, I can guarantee the end result will be more uptime.

[TomHowarth]

I agree with your comment, but I have never heard of Marathon being called FT in a VMware environment,  FT to me and most of my clients means VMware limited functionality product.

fantastic if you only need a single CPU but no use to protect real workloads