If vCenter Server (VirtualCenter Server) fails, VMs do *NOT* stop running. A VM won’t stop running unless the ESX/ESXi host upon which it is running fails. Additionally, once VMware HA is configured, the loss of vCenter Server won’t prevent VMware HA from operating, so that if an ESX/ESXi host fails, VMware HA *WILL* restart that host’s VMs on another host in the cluster.

Thanks for your comment!

I have came across a great post & video on the upcoming VMware FT at http://www.virtualizationteam.com/virtualization-vmware/vmware-esx-40-ft-fault-tolerant-sneak-peek.html so check it out to find out VMware upcoming surprise with VMware 4.0. It will be the best available continuity feature available in the virtualization market. what do u think?

Enjoy,
Virtualization Master

VMware FT is great technology and only validates the efforts and offerings of Marathon and Citrix. everRun FT will be very similar in nature compared to VMware FT, and as you stated, it just adds the dimension of component level re-direction and can be deployed without shared storage.

Some customers may choose to tier their highly available applications and adopt a lower collapse ratio over a dense consolidation ratio per server. Like they do with teired storage taday.

Where component level HA brings value are in those situations where customers are cost conscious and deploy on Blade solutions or inexpensive rack and stack such as Dell 2950′s where real-estate is a limitation in terms of slot count. I single failed component which represents a SPOF can cause a service level outage of VMs without initiating an HA event. many customers deploy on this class server based on cost. There are simply not enough slots in some cases to team across multiple NIC’s or you are in a trade off where you deploy a single FC-HBA. In that case even redundant FC switches do not help.

Again, these are common deployments and I am not insinuating that IT people are ignorant for choosing a blade architecture. There are always trade-offs… fast safe or cheap and companies are budget conscious in today’s market.

Healthy competition is just plain a good thing for the customers and drives innovation on

I believe you are correct about the single vCPU limitation on VMs that will be protected by VMware FT.

Jack,

All virtualization solutions have their strengths and their weaknesses. VMware is not perfect and isn’t necessarily the right solution for every organization–and the same could be said of Hyper-V, XenServer, KVM, or Virtual Iron.

Mike,

If you’re in agreement with me, then I must not have been “neutral” enough!

Seriously, though, it’s important to recognize that everRun does have some advantages over VMware HA, and VMware HA has some advantages over everRun. Organizations need to choose the solution that best fits their needs.

Thanks for putting a “neutral” perspective on things. I think you’re spot on in your analysis. I also agree with Duncan on the value of DRS in helping to distribute load in the cluster so you can actually use VMware FT without impacting other loads.

Keep up the good work on the blog!

I would not say VMWare has any kind of upper hand, (nor does XenServer) necessarily. VMware’s touted “memory over-commit”, one of the few features left that they can lord over Xen, makes re-starting in HA more complex. XenServer’s “weakness” in dedicating static memory to VMs actually makes it far more predictable in deciding if sufficient resources on remaining hosts are available to start VMs from a failed host.

This is still a “niche” feature to protect non-critical apps on low-powered VMs, but let’s look at reality. the world of virtualization is evolving rapidly, and also-rans like Xen and Hyper-V are gaining features far more rapidly than VMware expected.

It appears that a lot of value-add is going to come from third-parties, which might erode some of the price advantages of Citrix / Virtual Iron etc., but will certainly give the “kitchen-sink-of-features” approach of VMware a challenge to those who prefer the “best-of-breed” cliche’ over “one-throat-to-choke.”

It doesn’t say that it won’t work with another guest OS, but if it works anything like everRun FT it requires drivers inside the guest and possibly modifications to the HAL.

We currently have multiple everRun FT installations, and the biggest limitation we’ve run into is that the guest VM can only use a single CPU(or core). I was excited to hear the VMware announcement because the services we’re using everRun for would benefit from SMP, but could easily be virtualized; however one of the comments on Mike D.’s blog seems to indicate that VMware FT has the same single CPU limitation.

I was not aware that everRun VM Level 3 protection was only for Windows-based VMs; do you have a link for that information? If that’s true, then it clearly tilts the balance toward VMware FT, which is guest OS-agnostic.

I would also agree that the addition of DRS to a VMware FT-based solution is quite valuable, because the secondary VM can be intelligently placed anywhere within the cluster based on resource availability. I haven’t seen any indication that everRun can do the same; in fact, it looks like they work only with host pairs.