While I have traditionally only used physical servers in my organization, it recently got to the point where this...
was no longer an option. I found that I was running out of space for additional servers. I was also concerned that there was not enough electricity going to my data center to support many more devices. Besides that, though, the cost of maintaining all of those servers was becoming astronomical.
As a result, I decided to try consolidating some of my physical servers by bringing in some high-end servers that could host multiple virtual machines. In order to avoid any unexpected complications that might result in downtime, I initially opted to migrate only lab servers and leave my production servers running on dedicated hardware. As you might expect, the migration process was a little bit tricky, but eventually I got through it. Still, I found that keeping track of individual virtual servers was far more difficult than I expected.
When I was running only physical servers, it was relatively easy to keep track of which server was running on which box. I simply used a label maker to create labels containing the server's name, operating system, IP address and purpose. When I switched to a virtual environment, though, this technique no longer worked. That meant I had to find a new way of keeping track of my virtual servers.
After considering several different techniques, I decided to use the name of each individual virtual server as a means of identifying that server and its purpose. Obviously, a lot of information that I had previously included on labels was impractical to include as part of a server's name. Therefore, I had to make some decisions about what types of information were really important to me, and then come up with a naming scheme that would allow me to incorporate that information in a uniform way.
Now before I go on, remember that I am a technical writer. Since I need to have a lot of servers on hand to test the concepts I write about, my situation is obviously unique. Consequently, it's unlikely that my exact naming scheme will work the same for you. However, most of these naming principals will apply. Also, remember that the most important thing is to be consistent in your naming conventions so that there is never any doubt as to the virtual server's location and purpose.
Creating a naming scheme
Here are the criteria that I determined to be important:
- Whether the virtual server is intended to be permanent or temporary
- Which physical machine is hosting the virtual server
- What operating system the virtual server is running
- What the virtual machine's purpose is
Obviously, this is a lot of information to include in a computer name. Windows Server 2008 allows you to create some pretty long names. In my case, occasionally I have to work with legacy operating systems. Therefore I needed the names to be 16 characters or less so that older versions of Windows could connect to the virtual servers if necessary.
The way that I got around this was by initially creating another label to place on the physical servers that were hosting the virtual machines. These labels simply contained numbers 1, 2, 3 and so on. I'd use these numbers as the first character of the virtual server's name. That way, one glance at the virtual server's name would tell me which physical server it was hosted on.
I made the next character in the name either a "T" or a "P." I used the letter "T" to designate a temporary lab server and "P" to designate a permanent lab server.
Unfortunately, with the naming scheme that I came up with, it was theoretically possible for two virtual servers to end up having the same name, which of course is a no-no. So, I decided to make the third character of the virtual server name a numeric identifier. If the virtual server was the first virtual machine that I installed on the physical server, then its identifier would be "1." If the virtual server was the second virtual machine that I installed on the host server, then its identifier would be "2." The order in which the virtual machines were created doesn't actually matter. I only used the sequence identifier as a mechanism to ensure that no two virtual machines would accidentally end up with the same name.
I then finished by using either the name of the editor or the name of the website or publication for which the virtual server is going to be primarily used, followed by the operating system that the virtual server is running.
To give you an idea of how this process really works, the editor of this website's name is Brendan Cournoyer. I recently set up a virtual server that is running Windows Server 2008 that I intend to use when writing Windows Server 2008-related articles for this site. That server's name is 2P3Cournoyer2008.
By looking at this name, I can tell that the virtual machine is running on host server number 2, it's a permanent virtual server, it was the third virtual machine installed on the host server and that the machine is used for this website and is running Windows 2008.
Again, while my situation is unique, it is clear that virtual servers can be more difficult to keep track of than physical machines and that you can convey a lot of important information in a short computer name. Just remember this: The most important aspect of a naming convention is to be consistent in order to avoid any doubt about the virtual server's location and purpose.
In addition, keep in mind that you might occasionally have to rename a virtual server. For example, I have some virtual servers that are running Windows Server 2003. If I were to upgrade them to Windows Server 2008, then I would need to rename those machines in order to reflect the change or else my naming scheme would be meaningless.
Recognize that renaming a server can cause problems for any machine that maps a network drive to that server by using the server name, so be sure to document network drive mappings or base your drive mappings on IP addresses rather than computer names.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.