A key section to having a well tuned vSphere environment is consideration into the organization and general “tidiness” of the layout and hierarchies of objects, even though properly designing and configuring a vSphere environment for performance and growth is a topic I tend to focus on more. Intelligent effort should be made into the placement of objects and containers to aid with administration, both for yourself and delegation to other users or groups. As growth and change occur (every virtual environment experiences) the need for a well defined and thought-out organizational structure begins to materialize as a necessity. Below are some topics I tend to ponder over when setting up a virtual environment that have served me well.
Embrace Folders
Folders are a pillar of organization in the vSphere environment. You can use them to logically organize business or application groups into something that makes sense, while also using them to serve as points of delegation to other users or groups. Since a folder can span clusters, you can combine an application group’s VMs into a single folder and delegate out a low level role to a lead developer or 3rd shift administrator for handling power on / off / resets (although I would advise against giving production access). There is a lot of potential here.
I often put all of the virtual infrastructure management (VIM) guests, such as the vMA and vCenter, into a folder to ensure only specific personnel can manipulate theses entities, and have another folder to house templates. Keeping a few rules on both naming structure and nesting depth is advised; I tend to focus on 1 or 2 word naming (I’m okay with spaces on folders) while trying to go no deeper than 2 folders to find things. It’s not pleasant having to go 3 or more layers to find things, and it may force users to just use the search tool.
For those with Enterprise or higher licensing – Resource Pools (RP) are not organizational containers! Even if you create an RP with no limits or reservations, specifically for “organizational” purposes, you are abusing the reason for an RP and can limit the number of simultaneous vMotions in the same cluster below the maximum 4/8 (depending on NIC speed).
For more information on this, I highly recommend picking up Duncan Epping and Frank Denneman’s book “VMware vSphere 4.1 HA and DRS technical deepdive” which goes into much more detail on RPs.
Don’t Forget Datastores
While this technically is a folder strategy, I have highlighted it specifically because it deals with datastores. Yes, you can create folders in the datastores view – it’s a great way to accomplish two goals: logically dividing up datastores based on device, and handling alarms and permissions.
When you have several storage devices tied, the cluster(s) can become a bit messy and vertical to manage. I always divide off local storage (the ESX host storage) into a “Local Storage” folder. Realistically, you don’t need to care much about these disks, as there shouldn’t be much (if anything) going on here outside of logging (you’re using a vMA or Syslog server for ESXi, right?). The other folder I create is “Shared Storage”. Under this folder goes all of the SAN luns, such as a “VMAX-1” folder with all fiber luns, or a “NetApp-1” folder with iSCSI / NFS luns. It can help clean up the clutter.
Additionally, the folders are a great way to setup specific alarms. On a small solid state or flash drive, a local ESX disk may constantly sit at 85% utilization. Rather than having a yellow caution constantly hovering over the datastore, you can create a custom one specifically for local disks that has a higher utilization threshold alarm level. Additionally, you can set specific permissions on the folders. I’ll admit that I’ve never done this, but it’s still an option.
Networking
The final area I apply some housekeeping rules to is the Network layout. In a vSwitch environment, there is no “root” keeper like a vNetwork Distributed Switch (vDS) to automatically organize portgroups (PG). Because of this, I like to use folders, sort of like a vDS, when in a vS environment. I often use folders for the major network types: prod, non-prod, storage, and vim (virtual infrastructure management – vmotion, management, FT).
There isn’t as much use for folder organization in a vDS environment, so make sure to choose descriptive names and avoid spaces. I usually follow a VDS-ROLE format and use the subnet for the PG name (for VM traffic). Make sure to label your uplinks (Edit a vDS, Properties tab, “Edit dvUplink Port” button, then put in the names). This can make identifying a port in the port view much easier than the standard “dvUplink#” format.
Thoughts
There’s a certain, definable boost in productivity and pride in an environment that is clean looking, well labeled, and easy to navigate. Spend the time to discuss your VMware environment with those who have to work in it, come up with some organizational rules, and whip things into shape. Taking the time to do it now will save time over the long run when you’re not hunting around for objects in the vSphere Client. By creating and maintaining organization you also set the tone for other administrators to know where to put things without having to ask around.
