Lately I’ve been dealing very often with VMware environments, some of them fairly complex, so I spent a few hours testing the features of the most widespread VMware solutions. I don’t consider myself a VMware expert, but I’m not a complete beginner either. I can install and configure virtual environments based on ESXi and vCenter entirely on my own and tune their configurations so they work properly, and I don’t think I’d have too much trouble taking on the implementation of more complex solutions too (again, without claiming to be an expert).
Although my work is generally tied to the Citrix world, I like to keep up to date on other vendors’ solutions as well, so in my lab I’ve installed several VMware products and products from other vendors.
In particular, I’ve installed a 4-node ESXi cluster with vSAN and I’m comparing it with what NUTANIX offers in the hyperconvergence space. The comparisons between the two solutions you can find online are often biased, while I like to form my own opinion without being too influenced by others.
In this post I don’t want to get into a vSAN vs NUTANIX comparison, I just want to share what I like and what I don’t like about the VMware solution.
My impression of VMware solutions is almost always positive, and I rarely run into particularly serious malfunctions. Today I want to focus on vSAN. vSAN is another product that left me with a positive feeling, although maybe I was expecting a bit more.
How easy vSAN is to configure is somewhat offset by its weaker options for monitoring the product afterwards. I have to admit that my lab is based on ESXi 6.7 CU3, so I may be missing some of the new features in 7.0, but I’d hardly consider it wise to move environments to production on such a new and not yet battle-tested version of the product; so I think it’s fairer to evaluate the options that 6.7 CU3 offers today.
In the lab I have 4 hosts, each with 1 x 2TB HDD and 1 x 240GB SSD, connected to each other by 2 x 10Gbps Ethernet + 2 x 1Gbps Ethernet.
So I configured each host to use the 1 Gbps ports for VM traffic and host management (MGMT) traffic, and the two 10Gbps NICs for vSAN and vMotion traffic. This way the environment works well and performance is satisfactory. I’ve had a few cases of instability and corruption of some VMs (Linux ones in particular), but I believe that was caused by some wrong action on my part (which caused corruption on the vSAN datastore side) or a misconfiguration of the cluster. In particular, some Linux VMs stored on the vSAN datastore shut down after a snapshot and could no longer boot (because of file system corruption). This gave me quite a few headaches, but honestly I think the problem was due to some mistake of mine or to the instability of the lab (which obviously has no serious redundancy).
I also had cases of VMs whose files could no longer be removed from the vSAN Datastore; in those cases I had to use a procedure, linked below, which was the only method that let me remove the files locked in the datastore:
https://kb.vmware.com/s/article/2109034
All in all, I’m enjoying vSAN for what it is: a hyperconverged storage solution, part of a virtualization ecosystem that is undoubtedly the market leader.
In the future I’ll make a point of updating this post with any other impressions of VMware products I form along the way.
If you’d like to share your opinion in the comments too, I’ll really appreciate it.