The Virtualization Room

Oct 20 2008   9:01AM GMT

Defining a nomenclature for storage allocations

Rick Vanover Rick Vanover Profile: Rick Vanover


The relationship between the virtualization administrator and storage administrator can sometimes be less than cordial. Yet it can become less contentious when approached in a certain manner. One way that administrators can work closer with storage teams is to identify a nomenclature for shared storage resources in the virtual environment. This is critical because as virtual environments grow, storage management becomes an extremely important part of a successful implementation.

In larger environments where the storage and virtualization server teams are separate groups, there are a number of ways to organize a standardized nomenclature of a logical unit number (LUN). For example, the virtualization admin may only care about the size of the LUN and possibly the tier of performance. The storage administrator is concerned about those factors and more. As I’ve mentioned in the past, the process of getting down to details in the storage environment is critically important as the infrastructure grows. As time goes on, we simply can’t refer to the “500 GB LUN” or “the last one you gave me” anymore.

Recently I had an opportunity to work with an entirely different storage environment than I’m used to. As can be expected, this situation arose, but I perceived it as a great time to hammer out a crude yet effective specification for a LUN nomenclature. The situation involved a VMware environment connected to a Fibre Channel storage area network (SAN) with a number of storage devices presenting disks to the VM environment. The basic objective of having a standardized nomenclature is so both parties can determine which LUNs are available and the basic information present on them. The figure below shows the end result of this ad-hoc policy:
LUN Name Format
Determining a nomenclature for storage allocations will vary widely for different environments. Designations such as which tier the storage lies upon, whether it is developmental or live system storage, or which virtualization cluster owns the storage can all be elements of the process. Furthermore, if you’re dealing with a storage management system, the requirements for the name of the storage system may be different than the directly attached storage system in the example above. The end result for all parties involved is a far more orderly process with a much better understanding of how the storage is allocated in the virtual environment. In addition, the virtualization team will be able to more clearly communicate with the storage team about specific resources in use.

2  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Janåke Rönnblom
    What happens if you move the LUN inside the SAN from one enclosure to another enclosure? Then you would need to rename the LUN on perhaps both the SAN and perhaps even in your VMware environment. For example EMC has the ability to migrate a LUN to new disks and/or enclosure and I suppose the EVA also have that ability. -J
    0 pointsBadges:
  • Rick Vanover
    I would rename the LUN if that was something that mattered to the VMware side. In cases where something like an IBM SAN Volume Controller is used - I may not. I may just make a name like SVC4-GOLD-1750 for a LUN on the gold SVC that is 1.75 TB. The renames of datastores is permitted in VI3.
    20 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: