VMware vSphere Reviews

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

Buyer's Guide

VMware vSphere

May 2025

Free Report: VMware vSphere Reviews and More

Learn what your peers think about VMware vSphere. Get advice and tips from experienced pros sharing their opinions. Updated: May 2025.

DOWNLOAD NOW

857,028 professionals have used our research since 2012.

What was my experience with deployment of the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What about the implementation team?

Which other solutions did I evaluate?

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

What was my experience with deployment of the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What about the implementation team?

What was our ROI?

Valuable Features

Improvements to My Organization

Room for Improvement

Use of Solution

Deployment Issues

Stability Issues

Scalability Issues

Customer Service and Technical Support

Initial Setup

ROI

Pricing, Setup Cost and Licensing

Other Solutions Considered

Other Advice

The Dell PowerEdge M520 is a dual cpu socket, half-height blade server that offers up to 20 processor cores and 12 DIMMs per node with up to 16 other half height blades being deployed in a single M1000e blade enclosure. This powerful yet compact server is a great general purpose machine that offers scalability and performance in any size business.

Like other PowerEdge M series blade servers, the M520 operates independently of other blades in the m1000e and has the ability to mix different types of M series servers in the same enclosure.

The M520 uses the Intel C602 chipset and take up to two Intel Xeon E5-2400 or E5-2400 V2 series chips.

For each blade, a total of 12 DIMM slots are available for a potential total of 384GB of RAM spread between 3 channels for each CPU. Depending on the choice of cpu, it is able to operate memory with speeds of up to 1600 MT/s (megatransfers per second) with module sizes of up to 32 GBs DDR3 registered RAM.

On the front of the bezel are 2 USB ports, power button, blade release handle, and slots for 2 2.5” SATA, SSD, or SAS drives.

This server comes with an embedded PERC 110 SATA software RAID controller and can be upgraded to support SAS drives with the PERC H310, H710, H710p mini RAID controllers featuring 6Gb/s of throughput on a dedicated connection to the system board and RAID 0 and 1 capabilities.

Two mezzanine slots are available in the Fabric B and C I/O ports with options that include 1Gbit, 10Gbit adapters, Infiniband or Fibre Channel interfaces on a PCIe 3.0 bus. The M520 also comes with LOM (LAN on motherboard) in the two Broadcom dual port 1Gbit controllers. You’ll need to populate the rear I/O modules with the right types of switches to utilize your server’s network capabilities.

Up to 16 M520s can be installed in an m1000e. The power and cooling for the M520 is drawn from the M1000e enclosure which can hold up to 6 2700W hot-plug power supplies.

This is a 10U modular chassis capable of being populated with different PowerEdge M series blade servers.

Empty, the chassis weighs 98 lbs., fully loaded this modular can weigh a total of 394 lbs.!

The maximum weight of a M520 server is 12 lbs. and are 7.8” tall 2” wide and 21.5” deep.

Each blade can be remotely managed with iDRAC7 Express for Blades with Lifecycle Controller, or with a software upgrade license, iDRAC7 Enterprise for greater control options.

The M520 can run various Windows Server Editions Operating Systems as well as LINUX Red Hat Enterprise. Here is a lively video overview of the M520:

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

What was my experience with deployment of the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What about the implementation team?

What was our ROI?

What's my experience with pricing, setup cost, and licensing?

Which other solutions did I evaluate?

What other advice do I have?

Recently I got some questions about this one. Who is better? Or who is cheaper?

I was worked in VMware and Microsoft, both covered virtualization products. Now, I’m working in one of Cloud Datacenter with many platform like Sun Solaris (Oracle), IBM AS400, IBM iSeries, IBM pSeries, Microsoft Hyper-V (the first Partner Hosted Productivity Cloud – PHPC in Asia), and VMware technologies (vSphere, vCloud and vCAC).

Based on that, don’t think too much about the platform. The most important is the SLA. All platforms is good as long as we manage the SLA. And use the most suitable platform for your applications. If you want to use Microsoft, then Windows Hyper-V 2012R2 is the right one. Don’t use any version below Windows 2012R2.

Anyway, back to the questions. Let’s make a simple requirement. This is roughly calculation.

Customer requirements:

They need to virtual all their infrastructure. 100 Physical Server with each servers have the specification: 2CPU, 8GB RAM, 100GB Disk. All Microsoft licenses are OEM.

Total Requirements:

• 100 x 2CPU = 200 pCPU
• 100 x 8GB RAM = 800GB RAM
• 100 x 100GB Disk = 10TB Disk
• 100 Windows Server 2012R2 Licenses
• Monitoring Tools required
• High Availability supported

Assumption:

CPU based (Option 1):

• Low CPU utilization, 10% average. 200 pCPU x 20% = 40 pCPU.
• Server configures with 2×6 Cores/CPU = 12 pCPU.
• Total server required based on CPU = 40 pCPU / 12 pCPU = 4 (Round Up).
• With N+1 roles (HA), then total servers: 4 + 1 = 5 Servers

RAM based (Option 2):

• RAM Utilized 80%. 800GB RAM x 80% = 640GB RAM
• Server configured with 128GB RAM. Maximum RAM utilized 80% then 128GB x 80% = 103GB (Round up)
• Total server required: 640GB RAM / 103GB RAM = 7 Servers (Round Up)
• With N+1 roles (HA), then total servers: 7 + 1 = 8 Servers
• For Microsoft Hyper-V, assumption required 2GB RAM for hypervisor. 128GB RAM – 2GB RAM = 126GB RAM x 80% = 101GB (Round Up). 640GB RAM/101GB RAM = 7 Servers. Total Server (N+1): 7+1 = 8 Servers

Because the application is highly memory consumption then we choice Option 2 (based on assumption and roughly calculation). I recommended to use the sizing calculator such as VMware Capacity Planning.

Licenses Required:

With Microsoft:

1. 8 x Windows Server Datacenter 2012R2
2. 8 x System Center 2012R2
3. 1 x Microsoft SQL Server 2012 STD Edition -> For DB

TOTAL: $78,994*

*Web Price (Y2014), excluded support and CALs for MSFT products

With VMware:

1. 16 x vSphere with Operations Management Enterprise Plus 5.5
2. 1 x vCenter Server Standard 5.5
3. 8 x Windows Server Datacenter 2012R2 -> For Guest OS
4. 1 x Microsoft SQL Server 2012 STD Edition -> For DB

TOTAL: $123,053*

*Pricelist (Y2014), excluded SnS and CALs for MSFT products

In the end, all is your choices. Enjoy.

VMware introduced replication in vSphere 5.5. The biggest limitation is that it only provides a single restore point only. This is an immediate show stopper for most customers. Multiple restore points are absolutely essential, because just like "good" data, any corruption/virus/dataloss from the source VM is immediately replicated to target VM, and if you don't spot the problem and perform failover to replica fast enough (before the next replication cycle) - which is going to be impossible in most cases - then you are done.

Other limitations
• No failback
• No traffic compression
• No traffic throttling
• No swap exclusion
• No network customization (network mapping)
• No re-IP upon failover
• Minimum possible RPO is 15 minutes
• Basic VSS quiescing (no application-aware processing)
• Works within single vCenter only
• No ability to create container-based jobs (explicit VM selection only)
• Limited seeding options: cannot seed from backup, or using different VM as a seed (disk IDs have to match)
• Different ports for initial and incremental sync required
• No good reporting

Also, be aware that biggest marketing push around vSphere replication is technically incorrect statement!
“Unlike other solutions, enabling vSphere replication on a VM does not impact I/O load, because it does not use VM snapshots”

It is simply impossible to transfer specific state of running VM without some sort of snapshot even in theory! In reality, during each replication cycle they do create hidden snapshot to keep the replicated state intact, just different type of snapshot (exact same concept as Veeam reversed incremental).

PROS: No commit required, snapshot is simply discarded after replication cycle completes.
CONS: While replication runs, there is 3x I/O per each modified block that belongs to the replicated state. This is the I/O impact that got lost in marketing.

Unlike VMware replication Veeam takes advantage of multiple restore points.
For every replica, Veeam Backup & Replication creates and maintains a configurable number of restore points. If the original VM fails for any reason, you can temporary or permanently fail over to a replica and restore critical services with minimum downtime. If the latest state of a replica is not usable (for example, if corrupted data was replicated from source to target), you can select previous restore point to fail over to. Veeam Backup & Replication utilizes VMware ESX snapshot capabilities to create and manage replica restore points.

Replication of VMware VMs works similarly to forward incremental backup. During the first run of a replication job, Veeam Backup & Replication copies the original VM running on the source host and creates its full replica on the target host. You can also seed this initial copy at the target site. Unlike backup files, replica virtual disks are stored uncompressed in their native format. All subsequent replication job runs are incremental (that is, Veeam Backup & Replication copies only those data blocks that have changed since the last replication cycle).

Conclusion:
Veeam Replication really stands out on top of the feature lacking VMware Replication. The numerous missing features like taking advantage of multiple snapshot replications, to help insure data integrity, no failback, no traffic throttling and no traffic compression etc., translate to only using VMware replication for simple use cases.

So it’s finally here!
The long-awaited release of vSphere 6.0, has been released, and will ready for download medio March we’ve been told. I’ve done a small write-up of some of the new features in this release.

Release cycles
As seen at VMworld, where many customers thought that VMware would release vSphere 6.0, VMware has adopted a strategy of longer release cycles of the core component vSphere. So instead of a yearly release we are most likely to see roughly 18 months release cycles instead. This is because the hypervisor needs to be stable all the time, and not something you’d need to upgrade all the time. On the other hand products like vRealize Operations or vRealize Automation Center will see shorter release cycles. I’m really liking this approach, as the hypervisor really is in the center of your data center core, and as such we need the absolute most stable product here.

Multi-processor Fault Tolerance
We’ve seen multiprocessor Fault Tolerance demoed at a few VMworlds so far, but now finally it’s here. with vSphere 6.0 you can now have Fault tolerance on VM’s with up to 4 vCPU’s. This finally opens up for the useful Fault Tolerance VM’s. I haven’t seen many critical VM’s with only 1 vCPU, even vCenter Server needs more than 1, so the use cases for the old Fault Tolerance were few and far apart.
A lot of older applications, haven’t been built with High Availability in mind and for this FT comes into play, and with the new 4 vCPU limit a lot more of older applications can be protected by FT as well. I’m guessing a lot of costumers will use this feature in their data centers. However the Bandwidth requirements for this will be quite steep, so cross data center FT might not be feasible just yet :). As with the old FT this won’t save you if your application corrupts, then both instances will be corrupt. For this you really need applications that were built for High Availability in mind.

Inter vCenter vMotion
This I think is one of the biggest new features of vSphere 6.0. The ability to vMotion between 2 vCenters is one thing a lot of people have been looking for, for a looong time. Moving VM’s without downtime to a new vCenter with newer vSphere, wasnt that easy if you deployed distributed switches. But now that really should be a thing of the past. A whole new set of design architectures should be set up now because of this feature.

Long distance vMotion
Another really nice new feature is long distance vMotion, where before you were limited to 5ms latency or 10ms in Enterprise+, you can now vMotion across links with up to 100ms of latency. For us Europeans that means we should vMotion vm’s across borders to neighboring countries or at last across the country. This opens up quite a few new scenarios for highly available infrastructure. In Denmark fx. we could vMotion between Seeland and Jutland, which would solve some of the Power issues we have :).

Web client
The last thing I will write about is the client. The new Webclient is much improved over the previous ones, and both looks and feels more like the C# client, which still is available in vSphere 6.0. Unfortunately its still not in HTML5, which would have been preferred, so the webclient could work on OS’s