One Processor Support for "FT" - COME ON!!!

[Jerry_Griffin]

From pg32 of the vSphere Availability Guide

"Symmetric multiprocessor (SMP) virtual machines. Only

virtual machines that support a single vCPU are compatible

with Fault Tolerance."

Is there any future plans to expand this to more than one vcpu?

[s1xth]

I am very unhappy about this also, as I have been pushing FT to some higher ups, should have read the fine print before saying anything...the machines that NEED FT have 4vcpus in my environment, and they use them!

[Jerry_Griffin]

I have been reading up on this to prepare. When I read this I swore it was a typo... I guess not.

For years I felt VMware was doing the right thing, by not taking the 80/20 approach. I guess change of leadership...Change in philosophy.

Welcome to the Microsoft Model.

Oh well I guess that is what sp1 is for right.

[s1xth]

Seriously... I agree with you though, but sadly its not a typo. I was feeling the same way, sometimes I think the change was good, and other times I feel its bad... Very bad.

Sp1??? Don't you mean sp2??? Haha that won't be for a few more releases, but the code to do It is sitting in someone's recycle bin ...

Sent from my Nokia phone

[wila]

Is there any future plans to expand this to more than one vcpu?

VMware policy is that they can't publicly comment on unannounced products, timelines, features, etc.,

This is an enterprise grade feature and taking it into production with support for single processors is maybe not that spectacular, but it does give them time to stabilize the code in a public release. They feel confident to release it now with one processor. Now real life production systems will start running on it in scenarios that haven't been foreseen.

If there are NO problems in the code then they'll know so in a couple of months, if there are issues... then you may have been saved lots of headaches.

Sure SMP support for FT right now would be awesome and I suspect it will come, but in little baby steps so that it has been proven to work well.

There is a reason that ESX is rock stable and that is that it is given the time to get stable.

--

Wil

_____________________________________________________

Visit the VMware developers wiki at http://www.vi-toolkit.com

[AndreTheGiant]

by not taking the 80/20 approach

In fact for the first version of FT there are some limitations.

Andre

**if you found this or any other answer useful please consider allocating points for helpful or correct answers

[Jerry_Griffin]

I understand what you said and it makes sense. But when VI3 was released the features that were demonstrated and talked about worked. There was no processor limitation with vMotion or HA or DRS it just worked. Granted the licensing model was very confusing at best, but those products worked as described. I mean come on if vMotion only would work on VM's with one virtual processor at release time what would have happened then?

What should have happened is VMware should have held this back or called it an "experimental" feature. To hype it up and then release something that only does a limited function is just wrong and very disappointing!

[AndreTheGiant]

I understand your point of view.

Probably a better choice to introduce FT was introduce ALL the features that technology permit (more CPU, also storage replication, ...), but (for the first release) support in a production environment only a few set (as today).

I think that FT log network could make the difference, and today 10Gbs network is not so used (compared to 1Gbs).

Andre

**if you found this or any other answer useful please consider allocating points for helpful or correct answers

[admin]

Just a comment from a VMware insider...

Let me first say that we're equally as excited about supporting multi-vCPUs as you are about using it. That said, let me share a little information about FT:

Solving the problem of achieving lockstep for 2 virtual macines represents hundrends (thousands) of hours of work by our most senior, principal engineers. Needless to say, it wasn't an easy problem to solve! The underlying technology for vLockstep uses Record/Replay to record the indeterministic input from one VM to replay it on a second VM over a logging network. This works great for a single CPU but In SMP

systems, shared memory access by the CPUs is not deterministic and hence recording only the inputs to the VM does not guarantee deterministic replay. This makes vSMP VMs a distinctly harder (and different) problem to solve.

I can't give you specifics on when we will have this support but be assured, we're working hard on it (lots of those same principal engineers).

Aren't there still uniprocessor VMs that are business critical that would require FT? Here's some examples I've heard from other customers:

• print servers

• ROBO (mid-sized) Exchange servers (~1000 mailboxes)

• mid-sized DBs

• other custom in-house apps that don't scale with multiple processors

Just to clarify, we're not artificially limiting the vCPU limits for FT and if we could solve the vSMP problem for vSphere 4.0, we certainly would have. Keep your eyes open, we'll add vSMP support for FT as quickly as we can.

[depping]

I fully agree. I think, at least for my customers, FT will be used for legacy apps that aren't cluster aware. These are mainly old applications which have not been updated for years but are running some sort of batch process which the whole company relies on. These usually don't have more than 1 vCPU.

Although I agree it's a limitation at the moment it is something VMware is working on.

Duncan

VMware Communities User Moderator | VCP | VCDX

-

---

Blogging:

Twitter:

If you find this information useful, please award points for "correct" or "helpful".

[Texiwill]

Hello,

FT is very complex code, and having deterministic processor/memory state is very important. Consider this, when dealing with SMP applications, 1 CPU with multiple threads never causes a race condition or problem. Moving 2 2 CPUs can cause issues, often when moving to 4 CPUs however, these same thread programs that work with 1 or 2 CPUs now fail miserably with race conditions, memory locking and other issues. Debugging these applications is extremely hard because often the problem does not repeat itself in exactly the same way every time.

Lockstep is very much like this. Run an application one on 1 CPU, its a deterministic ordering on the processor. Now run on 2 vCPUs and not you have to handle WHEN instructions enter each vCPU pipeline, when they leave, and how they possibly interact at the memory and IO layers. Run the application again and these instructions may not appear within each vCPU pipeline at exactly the same time as the first run. This gets excacerbated when you go to 4 vCPUs. Now throw into the mix scheduling issues within the vmkernel when you add 6 more VMs to the host. Those timings will once more change.

This is a VERY difficult problem to solve and some of the major players in the thread development world have the same problem VMware now faces. How do you ensure deterministic behavior. Maybe VMware can talk to these folks as they do have thread replay working in some cases.....

Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, DABCC Analyst[/url]
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

[jasoncllsystems]

Yes, this is a know "question" before RC or GA released.

Regards,

MALAYSIA VMware Communities

CLL SYSTEMS

• if you found this or any other answer useful please consider allocating points for helpful or correct answers ***