Two months ago VMware introduced vSAN Max at VMware Explore. I wrote about it in this blog. Last week I had a conversation with Kalyan Krishnaswamy on the topic of vSAN Max, for which Kalyan is the Product Manager. I figured I would share the episode via my blog as well for those who are not subscribed to the Unexplored Territory podcast just yet. Note, you can either listen to it below, of just listen via Spotify, Apple, or anywhere else you get your podcasts.
hci
Using HCI Mesh with a stand-alone vSphere host?
Last week at the French VMUG we received a great question. The question was whether you can use HCI Mesh (datastore sharing) with a stand-alone vSphere Host. The answer is simple, no you cannot. VMware does not support enabling vSAN, and HCI Mesh, on a single stand-alone host. However, if you still want to mount a vSAN Datastore from a single vSphere host, there is a way around this limitation.
First, let’s list the requirements:
- The host needs to be managed by the same vCenter Server as the vSAN Cluster
- The host needs to be under the same virtual datacenter as the vSAN Cluster
- Low latency, high bandwidth connection between the host and the vSAN Cluster
If you meet these requirements, then what you can do to mount the vSAN Datastore to a single host is the following:
- Create a cluster without any services enabled
- Add the stand-alone host to the cluster
- Enable vSAN, select “vSAN HCI Mesh Compute Cluster”
- Mount the datastore
Note, when you create a cluster and add a host, vCenter/EAM will try to provision the vCLS VM. Of course this VM is not really needed as HA and DRS are not useful with a single host cluster. So what you can do is enable “retreat mode”. For those who don’t know how to do this, or those who want to know more about vCLS, read this article.
As I had to test the above in my lab, I also created a short video demonstrating the workflow, watch it below.
Introducing VMware vSAN 7.0 Update 2 (video)
As you may have seen, today VMware announced the release of VMware vSAN 7.0 Update 2 (and vSphere 7.0 U2 as well of course). I was planning on doing a post on the 7.0 U2 release, but then I figured that I would try to record a video discussing most of the new features and enhancements introduced. Note, I do not cover the full release, I picked the features which I felt deserved some attention. I uploaded the video to my Youtube Channel, make sure to visit it and subscribe, as I will be releasing demos on various features in the upcoming weeks with some more detail where needed. Hope you enjoy it, and again, make sure to like the video and subscribe to the channel!
What if the disk controller driver included in my vendor’s ESXi image is not on the vSAN HCL?
Sometimes unfortunately there are situations where a vendor’s ESXi image includes a disk controller driver that is not on the vSAN HCL/VCG (VMware Compatibility Guide). Typically it is a new version of the driver which is supported for vSphere, but not yet for vSAN. In that situation, what should you do? So far there are two approaches I have seen customers take:
- Keep running with the included driver and wait for the driver to be supported and listed on the vSAN HCL/VCG
- Downgrade the driver to the version which is listed on the vSAN HCL/VCG
Personally, I feel that option 2 is the correct way to go. The reason is simple, vSphere and vSAN have different certification requirements for disk controllers and the vSAN certification criteria are just more stringent than vSphere’s. Hence, sometimes you see vSAN skipping certain versions of drivers, this usually means a version did not pass the tests. Now, of course, you could keep running the driver and wait for it to appear on the vSAN HCL/VC. If however, you hit a problem, VMware Support will always ask you first to bring the environment to a fully supported state. Personally, I would not want the extra stress while troubleshooting. But that is my experience and preference. Just to be clear, from a VMware stance, there’s only one option, and that is option two, downgrade to the supported version!
Inspecting vSAN File Services share objects
Today I was looking at vSAN File Services a bit more and I had some challenges figuring out the details on the objects associated with a File Share. Somehow I had never noticed this, but fortunately, Cormac pointed it out. In the Virtual Objects section of the UI you have the ability to filter, and it now includes the option to filter for objects associated to File Shares and to Persistent Volumes for containers as well. If you click on the different categories in the top right you will only see those specific objects, which is what the screenshot below points out.
Something really simple, but useful to know. I created a quick youtube video going over it for those who prefer to see it “in action”. Note that at the end of the demo I also show how you can inspect the object using RVC, although it is not a tool I would recommend for most users, it is interesting to see that RVC does identify the object as “VDFS”.