I was spending some time thinking about one of the problems with keeping your virtual machines organized and memorably separate from your host machines.  Now, a week or two back I was reading an article on the topic (for some reason I can’t find it). And it harkened me back to the naming conventions I used in my previous job and for the resource centre I volunteered for. First, I’d just like to give a little back-story.

Back in 2002 when I started with my now previous employer, I hadn’t ever put much thought into really how people named computers, workgroups in the case of Windows, servers, devices, etc. My first encounter was with a Windows 2000 Server named “Big Red”. I remember the question I asked myself, “What the heck does that have to do with anything we do?” Oddly enough, with all of the server changes we did over the years, the implmentation of a Windows XP Pro-based web-server using Apache and PHP, I can’t remember those old server’s names. I do remember my first attempt at making sense of the chaos with ServerOne, ServerTwo and ServerThree. After that, I moved onto using organization abbreviations followed by an abbreviation of the software installed. So, eg. MBE-SBS. As time progressed, I did falter on the naming convention, but that was due to my lack of understanding and experience with Internet Security and Acceleration Server and the belief that I had to name my server a certain way for the web server forwarding to work (ah, in-experience). Then I took the leap into virtualization, moved my first physical machine to a VM and seriously started considering how to simplify naming of servers. Our virtualization server was named MBE-HV1 (HV1 for Hyper-V).

So far, the two best methods I could come up with are:

1. Name your virtual machine hosts after locations from a certain mythology, eg. Norse Mythology: Himinbjörg, Asgard and Midgard.  Then name your virtual machines after suitable gods.
   • Pros: Works with low numbers of servers, doesn’t run amok of copyright laws, depending on the mythology involved it can be flexible and memorable.
   • Cons: Depending on your total number of virtual machine hosts, VMs and/or physical machines you can run out of names quickly.   As well, if you’re dealing with a moderate number of servers it may be difficult to keep your names straight.
2. Name your virtual machine hosts and physical servers following one convention and name your VMs following a different scheme, eg. organization abbreviation (MM) dash (-), followed by a server number (002) gives you MM-002. Then you name your VMs first with the server name then a server number (MM-002-005)
   • Pros: Easy to follow and can handle a large number of servers.
   • Cons: not memorable, doesn’t describe the duties of the server
3. Follow the previous method, however choose a prefix number to describe the servers task before the servers id number MM-2-003, or in the case of a (VM MM-2-003-1-005)
   • Pros: Much more granular identification of servers by their task, so finding a server according to a job is easier.
   • Cons: Initially not easy to identify, can become confusing without pre-planning and documentation.

These are probably the most simple to utilize, it also forces network staff to think about what they’re doing before they implement a virtual machine.  Since VM sprawl is an actual issue to be seriously considered when utilizing virtual machines today.  Another method for helping to deal with sprawl is to simply implement a 2-stage system for the implementation of servers.

1. Force all Virtual Machines to be created in a “sand-box” server or cluster. This allows for a process by network administration staff to determine whether a VM is actually necessary, safe and functional before movement into the production server or cluster. This works well with the implementation of disaster recovery planning and ensures that plans are updated when new VMs are moved into production.
2. Once a servers function and usage is tried, tested and necessary, the server can be moved into production and plans can be updated and appropriately tested.

The biggest problem with managing sprawl and a network though always starts at the beginning. Before ever leaping into modifying an environment heavily, plan everything. Come up with a basic operations guide for the network and make sure to stick to it and document everything.

This information of course may not apply for really experienced network administrators, but for those who are taking their first leap with moving a small to mid-size business to new infrastructure or to overhaul an in-place LAN that was set up ad-hoc, these are serious considerations. If you’re dabbling, it always helps to get started with your own network and carry good practices with you. That way you leave your bad habits behind and ensure that you plan for the future when doing any sort of network setup projects.

Well, I think that’s it for now