VMware vSAN Reviews

The storage policies allow the administrator to define which VMs have specific storage requirements. For example: Our critical VMs have an increased flash read cache percentage enabled. This improves the overall performance of these machines. The ability to specify policies for every kind of VM in your data center improves storage efficiency, as well as improving performance, redundancy, and so on for specific VMs. With traditional SANs, configuring this was only possible on a LUN level. With vSAN, we can do this on the VM objects themselves.

One of the things that surprised me was the way vSAN handles a disk failure. It auto-rebuilds the vSAN objects when a failure has been detected. (Note: There are two kinds of failures, and this has a different effect on the rebuild timer.) But, in the end, the cluster is self-healing without any user input needed. The only thing that is affected is purely the raw storage that is lost with the drive.

The ease of managing and configuring vSAN. This means that all our VMware administrators are now able to do the daily maintenance and operations. Previously, only a couple of IT administrators were responsible for maintaining our previous storage solution and the complex tasks that came with it.

• The daily maintenance can be high, especially due to the lack of documentation and reporting in vCenter, and only on the vSAN health page.
• If the vSAN cluster can’t self-heal due to an internal error, we can’t repair the vSAN cluster ourselves.
• A case with VMware is always needed to fix the issue, resulting in an increased time to resolve. This can be very time-consuming.
• I would like to see more documentation on the errors, impact, and solutions. This could improve the product knowledge.
• Some essential storage features (deduplication/compression) are only available on all-flash vSAN clusters. These limitations need to be taken into account when sizing and designing your environment.

We have been using this solution for a year.

Keep a close eye on the vSAN HCL. As vSAN is continuously in development, the HCL changes as well and so the HCL gets updates.

When you are planning to upgrade the vSAN version, all other components (ESX version, server firmware, server BIOS) need to be checked to see if they are all on that version’s HCL.

Scalability on vSAN is extremely easy. If the host is compliant with the prerequisites (one SSD and one spinning disk), it will be accepted by the cluster instantaneously. All raw storage will be committed to the vSAN data store and directly available for usage.

In terms of sizing the cluster, as deduplication and compression are only available on all-flash arrays, this can heavily impact the storage capacity of the vSAN cluster.

Since we chose a hybrid-configuration, the lack of deduplication and compression caused a storage growth that exceeded the limits quite rapidly. We had to scale up and address the issue in other ways.

Technical support is good. When encountering issues with vSAN, 99% of the time a VMware support case needs to be opened. All of the standard steps of a support case are run through. In the end, a VMware engineer will solve the issue with you and bring the cluster back to a fully healthy state.

Our previous hyper-converged system broke down due to a power failure. A new system was needed. vSAN was the logical choice, as we are a VMware Partner.

The way VMware integrated the vSAN hyper-converged storage functionalities in their vSphere Kernel is really revolutionary.

It allows the environment to scale out on storage resources when the business needs it. You no longer have to buy those expensive traditional SAN setups scaled for the “future requirements” that you had in mind at the time.

Even an IT administrator with some basic VMware experience would be able to set up vSAN in just a couple of minutes. This is one of the easiest setups I have had in a while.

We had previous solutions, but vSAN was the logical choice.

I would definitely recommend vSAN to others. The old, cumbersome, and traditional storage environments are done and belong to the past. Hyper-converged is the next big thing. It is more cost effective, easier to manage, and scaling up can be done almost on the fly.

I recommend going for an all-flash vSAN setup, if the budget allows it. Some vSAN features like deduplication/compression are only available on an all-flash configuration.

With the falling GB/$, an all-flash is becoming the evident choice. The benefits are there (more features and all-flash performance for all VMs).

Centered on the VMs, it provides simple and centralized management from a single console. VMware vSAN is focused on the virtual machine and not on a datastore or mon. This allows it to adapt to the workload faster with specific storage policies for virtual machines, without needing to change the storage as in a traditional environment.

Having a single data store for virtual machines, the production of IT administrators has improved because they do not need to work with many LUNs and storage.

The web console, VMware vSphere Web Client, is not based on HTML5, which makes it difficult to manage. It slows down and page refresh is not fast; time is wasted. I know that vSphere 6.5 is already based on HTML5.

I have used it for one year.

I did not encounter any stability issues, as long as it complies with the compatibility matrix.

I have not encountered any scalability issues; very easy to scale.

I have not encountered any problems; no calls to support, but support is very good.

We previously used a traditional environment. We switched because the hyperconverged systems is very easy to deploy, it can scale and provides performance.

If you do not know about this technology, you cannot put it into production easily, but I know about vSAN, so it was very easy to deploy a vSAN environment.

It's a bit pricey. Indeed, there is hardly any price difference with a traditional setting, but it makes that up with the management and ease of use.

Before choosing this product, we also evaluated HPE VSA, Nutanix, and DataCore.

Both vSAN and Nutanix give very good performance, but the support when the infrastructure works with VMware is a simple support; with Nutanix, you have two support vendors if the hypervisor is VMware. Nutanix has a proprietary hypervisor based on KVM.

We have a traditional, multi-host cluster with SAN and a small (three host) vSAN cluster alongside it. I built the vSAN cluster mostly to experiment with the platform. 

As a VAR, it has been about gaining expertise in the platform. Additionally, it has allowed us to benchmark against traditional systems. We are now in a good position to help our clients decide when and where to deploy this solution.

The ability to have an HA cluster in the absence of a shared storage device or SAN. Not having to retain SAN expertise and the cost of a storage area network (SAN) warranty are big pluses, too.

Perhaps a bundle, like Essentials, would allow more businesses to make the leap to the product.

I would like to see this technology be made available to smaller businesses, who might benefit from high availability but struggle with the entry fee.

Coming from the early networking days when storage was software-defined, and seeing the announcement of this product caught my interest. The platform has been improved much over the first version. Today, we are comfortable running any of our mission critical apps on it.

We use vSAN as our server virtualization solution for Dell install of our customer base, and vSAN is our primary solution.

vSAN can help customers save on storage system costs, and also save on the human cost. For an SI (like us), vSAN can save tech service time and easily deploy for maintenance.

VMware vSphere with vSAN HCI system: It is easy to train customers to operate the system even if they have or do not have a VMware operator KB. Most customers can save tech service time via vSAN. vSAN is easy for deploying and maintenance, so some customers can do service themselves.

Simple manager with only one datastore. vSAN has just one datastore. so customers do not need to think where to put their VMs, how to design the physical disk RAID, the LUN size, the LUN mapping, etc. when they use NetApp/EMC/HDS or other storage systems.

• Online dedupe
• VM disk size limitations

vSAN does not have online dedup. When opening the inline dedupe, the performance will be lower than off inline.

Virtual machines disk size cannot cap more than a single node. For a VDI user, it may not save enough to hold a file server or exchange server on a single node storage space.

Simple to set up, manage, and integrate it with tools you’re already familiar (vCenter, vClient) with.

It also gives us a policy-based storage on a per-VM level.

Also if you can apply redundancies to machines, they’re all different.

• All built within hypervisor
• Easily stood up with hardware you already have
• Truly virtualized storage
• Get rid of all hardware, and you get a much smaller footprint
• Nodes can be in different datacenter, and so can stretch cluster

• Good job integrating with vRealize, vCOPS, etc.
• Needs complete integration with vRealize for GUI for drill down analysis
• Would be nice to see features like dedupe because it wastes a lot of mass when striping across multiple nodes and vSphere hosts.

Some difficulty finding compatible hardware, but if you follow the HCL provided by VMware. and make sure you're buying the correct nodes, storage devices, and SSD’s that are all supported, then it’s a stable product. Even if you have problems, it's still only one phonecall.

It supports up to 64 nodes so huge scalability.

As a VMware customer for many years, sometimes it takes a few calls, but they have some brilliant people who can solve difficult technical problems.

• Setup just a few clicks after hardware all connected, “pretty stupid easy”.
• Customers can test and validate without going out and buying vSAN ready nodes.

It loses points because it lacks lots of performance and deduplication abilities that competitors have.

• It's easy to implement.
• It performs very well.

The total cost of ownership, as it's really cheap for us and we have budgetary constraints. Plus, as we're a hospital, doctors need to access their patient data quickly, which VSAN allows them to do.

We haven’t had an issue and we've been using it for about six months now.

I find it’s easy to scale, so if you need 100 more VMs, you know the amount of users per node, and you know exactly how much it’s going to cost you to scale up.

Never had an issue.

The only thing is that as we were early adopters, we found tech support was difficult to deal with because our hardware was Cisco, and they didn’t know what we were talking about.

We had one issue with an MTU, but it didn't take me even a day to set up.

Basically we're a one man shop – we like to keep our list short and simple: VMWare and Cisco.

Try it out. It’s worth it.

I am a system integrator, and this is one of the products that we implement for our customers.

VMware vSAN is used in the deployment of OpenShift Containers.

It is simple to manage without the need for configuration which is the feature that I like the most. The simplicity, as well as the integration with virtualization.

On the troubleshooting front, it was occasionally difficult for me to perform some troubleshooting. We are currently working in a demo environment, so we are not encountering many issues. However, when you reach production with a heavy load, troubleshooting the vSAN may become difficult. 

Troubleshooting with vSAN is an area that needs improvement.

Based on my testing, I would like to expand deduplication to include hybrid deployments and not just for all-flash deployments.

I have been working with VMware vSAN for four years.

I use version 6.7 ESXi with vSAN

So far the stability has been good. We have not had any problems with the stability of VMware vSAN.

The scalability appears to be good. I have not tested it that much, but it seems fine similar to clusters in VMware. 

At the moment, we have approximately 300 users who use this solution.

In reality, we haven't used technical support yet. I don't have an opinion on the support at this time.

I have experience with Cisco HyperFlex solutions.

The initial setup was straightforward. We did not have any problems with it at all.

The deployment did not take more than two or three days. It was very fast.

We have two people to deploy this solution.

We completed the deployment ourselves.

As an architect, I am not involved in the negotiating process and don't have many details about the cost and licensing.

I would rate VMware vSAN an eight out of ten.

The valuable feature of the solution is the total hyperconverged facility. And that either it's hyperconverged, or it's standalone with storage arrays.

From the implementer side, the solution is very comparable to Nutanix. The only difference is that VMware requires more initial nodes.

I've been working with VMware for fifteen years.

Regarding the scalability of the solution, you've got 64 nodes into a stretched cluster for VMware. Nutanix goes a little bit above. The only problem is that due to licensing things, such as when you have Oracle and other things, what you tend to do is multiple clusters in order to avoid licensing costs.

The biggest network I have implemented was 16 nodes.

My advice to others looking into implementing VMware vSAN is to stick to the rules. That's where the problem is. If you don't stick to the rules and prerequisites, you end up having a nightmare.

People have a tendency to take hyper-converged solutions for granted. They function as the marketing says, as long as you follow certain rules. If those rules are not followed, you end up with a slower infrastructure than you ever had before.

I would rate this solution an eight out of ten because it lacks flexibility. Those rules I'm talking to you about, how you have to follow the prerequisites, that is well hidden, is that you can't do what you want. You don't have total freedom. You have to respect the rules and that's why respecting the rules sometimes is a burden.

They always recommend that nodes are the same type, have the same disk structure, and if you change some disk structures, you have to change them on all the nodes. Although somewhere it's understandable, it's a burden. It should not happen.