Something that I have noticed early on when working with VSAN is that the VSAN datastore name is automatically selected for you and will always default to vsanDatastore. This is not a bad thing as it simplifies the setup of VSAN which is already dead simple. To enable VSAN, it is simply checking a box in the configuration of your vSphere Cluster just like you would when enabling vSphere DRS or HA.

From an operational standpoint, I think this can be a potential issue. What happens when you have a multiple VSAN Clusters under the same vSphere Datacenter object or even across different vSphere Datacenter objects? I recently came across this while re-building one of my lab environments, can you spot the problem in the screenshot below?

Here we have two VSAN Datastores within the same vSphere Datacenter. Datastore names under a single vSphere Datacenter must be unique. I am sure some of you may have already experienced this with local datastore names using the default "datastore1". vSphere will automatically append "(n)" to the name where n is the number of instances seen in the environment.

In this next example, we have two VSAN Datastores but they are split across two vSphere Datacenters. Since unique name is enforced at the Dataenter boundary, it is even worse now because you have the same name used across both VSAN Clusters.

Even though a user will most likely drill down into a specific environment when provisioning a Virtual Machine, I think it is critical to have a good naming scheme for your infrastructure. What happens when you have someone run an audit of all your VMs and all they showed for their datastore name was "vsanDatastore" and you had multiple VSAN Clusters? Would it not be more useful to have a bit more details in the datastore name to help map it back to some logical/physical container that is a bit more meaningful? I personally would think so and would help in times of troubleshooting where time is of the essence. 

Luckily this can easily be remediated since a VSAN Datastore operates just like any other datastore in which you can rename it. VSAN itself does not use the name to uniquely identify the datastore, it implements a unique UUID for each of the VSAN datastores. Simply renaming the VSAN Datastore to something more appropriate such as including the name of the vSphere Cluster will come a long when you need to correlate a Virtual Machine back to a particular compute/storage resource. 

I wonder if it would be a useful to have a feature in VSAN to automatically append the vSphere Cluster name to the default VSAN Datastore name? What do you think? 

9 thoughts on “Why you should rename the default VSAN Datastore name

  1. Good post. This reminds me a lot of renaming the internal VMFS datastores on a host if present. I don’t think it needs to be automatic. Similar to renaming all the local datastores to match the hostname… its a one time effort and done. I agree on the importance of a good logical naming conventions but every company has their own standards or should…

  2. Perhaps just having an option to name the datastore when you enable VSAN. It populates the field with the default name but the user has the option to change it. Covers both bases.

  3. @Phillip – Agree that every organization will have a different standard and I think the suggestion from @Adm is fair comprise in which both use cases can be satisfied. I’ll relay this back to our product teams for an FR

  4. I think it would be great not only for the vsan datastore, but for some of the other objects too. Local datastore and dvSwitch could benefit as well.

    My thought and my naming for my own datastores is —-. So as an example for one of my iscsi vols: HOUSEHOLD-I-TN-R5-DATA1, and a local disk example is HOUSEN1-LOC-ARRAY1-DATA1.

    Surely everyone has their own methods, but since lots of information is available to vcenter and esxi, why not be more verbose when offering the user an option to name their objects more smartly?

Thanks for the comment!