vSAN 7.0U1 – File Service SMB Support

One of the new, exciting features in vSAN 7.0U1 is the extension to vSAN File Service. As well as supporting NFS v3 & v4.1, we now also support SMB (Server Message Block) protocols v2 & v3. This protocol is commonly associated with Windows File Shares. In this post, I will go through the new configuration steps, and then we shall present the new created SMB file share to a Windows desktop. One of the new prerequisites, which wasn’t needed with NFS file shares, is that Active Directory integration is required for SMB. We will see this new step during the setup of vSAN File Service shortly.

Enable vSAN File Service

The configuration / enablement of vSAN File Service is much the same as before in vSAN 7.0, except for the additional step highlighted previously – you will now need to have Active Directory integration to allow SMB file shares to be created. Active Directory integration is also required if you wish to support NFS shares with Kerberos Security. This is another new feature in vSAN File Service 7.0U1. Let’s go through the enable process now.

In the vSphere client, select the vSAN cluster, then navigate to Configure > vSAN > Service, and click ENABLE next to File Service.

The first Introduction screen provides some information about vSAN File Service, and what additional information is needed to complete the enabling of the feature.

If this is the first time you have enabled vSAN File Service, you will be prompted to download an OVA which is the virtual machine that runs the Protocol Stack container. However, this only needs to be done once. After the first time, you will not be prompted to do the download again, no matter how many times you setup vSAN File Service.

Next we come to the domain information. Note that the first entry, the File service domain, is not related to the Active Directory (AD) domain, which is added later.

This is also the place where you add your DNS server(s) and DNS suffix(es). In my case, the DNS suffix and AD domain are the same. Yours may be slightly different.

In the last section, since we want to create SMB file shares, an Active Directory domain must be specified along with an AD username and password. This user is used for connecting and configuring the Active Directory service. The OU / Organization Unity is optional.

This brings us to the networking section where subnet mask and gateway are added.

Next we populate the information required by the Protocol Service / file server containers. There are two useful features here to make the life of an administrator easier. The first is the AUTOFILL option, so that you only need to provide the first IP address in a range for the IP Pool. By clicking AUTOFILL, the remainder of the IP address fields are automatically populated with incremental IP addresses. The second useful feature is LOOKUP DNS which resolves the IP address to DNS names. This really speeds up the configuration process.

Note that in this case, there are 4 Protocol Service containers to be configured. The containers are run inside of vSAN File Service node VMs. There are 4 VMs and 4 containers because there are 4 ESXi hosts in my vSAN cluster, and there is 1 per host. vSAN File Service v7.0U1 can have a maximum of 8 file servers.

The next screen is simply a review screen. If everything is correct, click FINISH and vSAN File Service is shortly enabled.

Once everything has deployed, the vSAN File Service view in the vSphere UI should now look something similar to the following:

And as File Service enables, we can see a number of new objects in the vSphere inventory, under ESX Agents. This is because the VMs are managed ESX Agent Manager (EAM). You are not expected to do anything with these VMs from a management perspective – EAM takes care of these VMs from a maintenance and availability perspective. These are the virtual machines which actually run the  Protocol Service / file server containers. Again, since this is a 4-node vSAN cluster, there are 4 file service node VMs, and thus 4 containers – by default there is one in each VM. A VM can run more than one container if necessary, for example a failure scenario. If you have a larger cluster, you may see more of these virtual machines instantiated.

Everything looks good. We’re ready to create a file share.

Skyline Health

Before creating our first SMB share, there is one additional feature that I want to highlight, and that is Skyline Health. There is a complete section for File Services now included  (you will find it at the bottom of the list of other vSAN checks). Since there is nothing untoward at the moment, it is not reporting any issues. The first set of checks are looking at the file service node VMs.

This second set of checks is looking at the Protocol Service / file server containers. All looks good here too.

Since we have not yet created a file share, there is no point in looking at the last set of health checks. We will return to this once we have built an SMB file share.

Create an SMB File Share

To create a file share, navigate to vSAN Cluster > Configure > vSAN > File Share. Click on the ADD link to create the share. The information required is very simple – provide a name for the share, and then set the protocol to SMB. Finally, select a storage policy. This is used to protect the objects created on the vSAN datastore. In my case, I am simply using the default vSAN storage policy. Optional features include enabling protocol encryption, storage space quotas and labels. I am not using any of these. Review the choices and complete the “create file share” operation.

The file share will now appear in the list of file shares. if you click on the button next to the share (shown below in red), you will get a bunch of additional information about the share. Note that you also have the ability to review the physical placement of the SMB file share across the hosts and disks in the vSAN cluster. However what we are interested in the moment are the SMB export path and the MMC command. We will look at those next.

Client File Share Access

Accessing the client from a Windows host is very straight-forward. From my Windows 10 Desktop, I open File Explorer, select the “This PC” icon, right click and select “Map Network Drive“. In the Folder: section, “I simply place the SMB export path copied from the previous screen.

And all going well, I should be able to successfully mount the SMB share from vSAN File Service to my Windows desktop. The share should now also be visible in Skyline Health (we skipped over this earlier).

Microsoft Management Console

One final feature to show you in the MMC  – Microsoft Management Console – integration. We provide a link to launch MMC from your client so that you can observe the status of the share from the Windows client. You can find the link to copy the MMC command from the file shares listing, shown below.

As the guidance states, if you run this command from the client, it will launch the MMC and you can get various detailed information about the share, including sessions and open files.

That completes the overview of the new feature to support SMB file shares in vSAN 7.0U1 File Service.

13 Replies to “vSAN 7.0U1 – File Service SMB Support”

  1. Hi Cormac, presumably the SMB and NFS services don’t support the same file namespace? I’m pretty sure that won’t work but if not it’s the kind of thing I’d love as it’d mean I could get rid of my NetApps!

    1. Hi Spencer – nice to hear from you.

      I’ve not looked into what you can and what you cannot do with APIs. But we do have plans to bubble up lots of metrics about file shares into the UI, so the assumption is that these API must exist somewhere.

      Stay safe

      1. That’s very interesting Cormac, and thanks for coming back to me.

        Hopefully we can grab a coffee at a VMUG when things become a little more ‘normal’. Until then, you stay safe too.

        Take care!

    1. Good point Riy. I’m not sure, but it is something I am planning to investigate shortly.

      Since the vSAN FS virtual machines are managed by EAM, the ESX Agent Manager, they will not appear as candidates for replication afaik. So we will have to investigate a bit further.

        1. Can you be more specific James? I’d be interested to hear any requirements or use-cases you might have for replication of vSAN File Service SMB file shares. What is the preferred way you would like to do it, and so on. Many thanks.

          1. Hi Cormac

            Thanks for the reply.

            We are looking to replicate the contents of the VSAN FS SMB share to another datacenter, for DR purposes.

            The idea is that if the customer had to failover, the files and folders within the SMB share would already be available in the DR location for use.

            If the DR SMB share its using a different host name, or IP address that would be fine.

            *Potentially we would use something like DFS namespace, with the second VSAN file share as a secondary target.)

            The key thing is getting the data across, we normally use something like Veeam or Zerto for replicating virtual machines. Although I appreciate these VSAN File Services VM’s aren’t exactly normal VMWare VMs, and don’t actually contain any data.

            If there was a mean to replicate the underlying VSAN blocks, and have VSAN file services nodes always running at the secondary location. I can imagine that could work, its more a question on whether its been done before?

            Incidentally, the primary use case for this is FSLogix profile disks. They are usually locked files, so replication at storage block level would be the preferred option, rather than SMB > SMB.

            Any input you have would be very much appreciated.



    1. Hi Mehmet,

      Any size stretched cluster is currently unsupported.

      The 2-node is a reference to the 2-node vSAN solution (sometimes referred to as ROBO), and is not a reference to the size of the stretched cluster.

Comments are closed.