Best Practice - Datastore naming conventions

[bolsen]

All,

As VMware administrators we're always looking for new and better ways to optimize our environment. I'm investigating a way to give our Virtualization team more insight into the underlying storage infrastructure and one way to do this is to update our existing datastore naming conventions.

Today we use:

_LUN[#]_T[#]R[#]

Service = Service area name

LUN # = The LUN ID

T# = Storage tier level

R# = RAID configuration

While this naming convention works well for our smaller sites, it doesn't work for bigger sites with multiple storage targets which use the same LUN IDs.

How are other people doing this? I'm especially interested in hearing from people who work with bigger infrastructures.

[RParker]

I just make it a basic name, like ESXSanData01, 02, etc..

Then we have certain ESX servers owned by groups, and it makes it easy to identify what datastore belongs to a server like ESXSalesData01.

If it doesn't have SAN in the name it's assumed to be local storage.

That's how we do it.

Typically the LUN ID isn't useful, seldom do ID's correlate with the volume, since most people use names rather than numbers for naming.

[awong505]

We use a naming convention that begins with an identifier of whether it is for prod, test, or lab. Then a sequential number identifier. Then the hostname of the storage array it is on. Appending a service tier or RAID configuration to that. We have found through the implementation of some other tools it is becoming less of a need to provide greater detail in the naming convention as the other tools will do the datastore to back end disk mapping, but that it is still important to have a standard regardless for consistency purposes. For example some of EMC or NetApp's VC plugins or NetApp SANscreen provide visibility to the storage and vm admins for an end to end mapping.

[mittim12]

We utilize the connecting protocol in our datastore names. We also have a few datastores dedicated for particular VM's and in that case we incorporate the function of the VM into the name.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[mark_chuman]

This naming convention works well for us and gives virtual operations quick information for the storage team:

I've also thought about using folders to group datastores by cluster, so they appear more organized when in datastore view.

[schepp]

We just use names like <Storage Unit>_<Enclosure>_<LUN> and have a database providing more information about these LUNs.

All LUNs are set to have unique IDs to avoid the problem you mentioned.