Best Practice for Naming Virtual Servers

[OpsMan]

My organization is currently enforcing naming conventions across the enterprise in an effort to standardize processes and operational procedures. Does anyone have any information on:

1. What naming standards are promoted by VMware?

2. What benefits does a common standard provide in the virtual environment?

[chandlm]

I've had that discussion a few times and made the decision to not name them any differently from any other machine for a couple of reasons.

First off if you are planning on doing any P2V conversions if you rename the server you are losing part of the advantage because you will need to repoint users/applications anyway.

Second, when you are getting to the point where quite a few of your servers are VMs it just becomes unneeded or almost redundant.

I'm looking at using other methods to locate them in AD by either using the description or using a security group in case there is ever a need for a VM specific GPO...

Recent article:

http://searchservervirtualization.techtarget.com/tip/0,289483,sid94_gci1264524,00.html

Message was edited by:

chandlm

[grasshopper]

Personally, I like to add a 'v' somewhere in the name to denote it's virtual. However, on P2V's I always keep the original hostname. This way, when troubleshooting an issue a year down the road, I will know that it was a P2V and not a fresh VM from scratch.

I also like to use the operating system's hostname as the VM name, and I also name the .vmdk's with hostname_0 and hostname_1 for each disk added. This numbering correlates directly to what you see in diskmgmt.msc. If the VMs are created by VCenter then I may be lazy and use the default name for the guest's boot disk, but additional disks will have the hostname_x naming.

Another standard that I once liked but after several consolidations have come to appreciate alternatives, is including the city or airport code in the naming standard (i.e. USCHIxxxxxx) for Chicago. While it's nice to instantly know where a server physically resides, these locations change.

I also like denoting the function of the server in the name (such as app, web, db, man, etc).

[OpsMan]

The concept I am coming from is from a global operations perspective.

Example: If there are a number of virtual servers located in different geographic areas, and services are architected to dynamically switch locations depending on capacity needs, what method using VMware will show me where a specific application service resides, on what virtual server, at that specific moment?

Will a naming convention give you this ability? Or do I have to rely on using the association of the application service to the IP Address or UUID of the server?

[jswano]

Hi,

Are they any limitation on the length of the server name or FQDN ?

Thx

[Erik_Zandboer]

I would say... Just the same as for your physical machines. One should make no difference between physical and virtual machines. Makes it simpler to do P2V, V2P with no hassle. The hostname stating physical of virtual does not add any usefull info (I think).

just my 2 cts

[caciolli]

I use the same naming convention as physical.

I like to break the barrier between physical and virtual....

[jswano]

I use 15 letters for physical server name's.

You said that they are no difference between physical and virtual naming ?

[caciolli]

Yes, all my virtual machines are using the same naming convention as physical.

Usually I have 50-100 servers per site, and 50-60% are virtual. Naming does not take care of virtual/physical

[jswano]

What is the length of your FQDN ?

[Erik_Zandboer]

We are only referring to naming CONVENTION, not physical limitations of number of chars.

You can make the names as long as you want (uhhh there is a maximum offcourse but I have never seen that limitation apply). However, when you create a VM, the name is used as a folder name on your VMFS. So I always like to keep it short, use only the name of the server, no special chars.

After creation feel free to change the name of the VM by adding info. Lets say you add an exchange server, you could use the name using your naming convention, for example:

exchange-location-number

and change it afterwards to:

exchange-location-number - This is the first exchange server within ESX

The folder name will now "only" contain the initial name.

[caciolli]

I agree with you Erik,

and I would like to add that if there is a limit...stay under that!

Yes use short names, they are lovely...

[dpomeroy]

Our naming convention for VMs is basically the same as physical servers except we add VM at the end. Part of our convention is a designation to site location (of where the server is), an OS designation for Unix/Linux or Windows, and a number. sounds complicated but comes out something like this: uschdux123vm

We use a description field in VirtualCenter to provide more info about the VM, i.e. CRM Test Node 1.

[bflynn0]

When it comes to VM's I personally think they should follow the same convention as physical servers. If you P2V or V2P something it'll keep it's name anyway. Knowing whether a system is a VM or not should be kept in your inventory system (whatever you use for that), and once you know it's a VM seaching VC is easy enough to find it and it's physical host. I also always name the actual VM the same as the OS host name.

Most places I've been have a convention something like SiteFunctionUniqueNumber. So the physical hosts could be something like Site[/i][b]VI[/b]## or Site[/i][b]ESX[/b]## (eg NYCVI01 or NYCESX01)

I like doing something like that so when I get an alert for it I know its an ESX Host in New York.

I guess one thing to ask yourself is "how can I use the naming convention being enforced in my virtual infrastructure?" If you really can't use the naming convention it's probably worth while to go back to the group making the standards and see what can be worked out (they may add rules to the convention for virtual systems) so you can follow the convention and still know what things are. After all, what good is a naming convention if you have no clue what the name means.

[petedr]

We have used the same approach, keeping the same name as the physical. For new Vms the company physical naming convention was also followed.

[kripes]

We've been naming servers with the prefix VM since we started dabbling in it and I don't plan to change that but on the other hand I have to agree that to a degree it becomes unnecessary to prefix with VM.

Generally, we use:

[Fabio_Pitzolu]

Just a few little tips:

1) Don't use different names for the Display Name and the name inside the OS (example: DN - Host 1, OS Name - srvHost1)

2) Don't use special characters and spaces in the Display name, because they will turn into the names of the files and the folder of your virtual machine (you can change them later manually, but it's kind of bothering doing that)

There are no naming convenctions, in my case i use camel notation for display names (example: hostDominoServer)

Bye!

Fabio

[c_g-hills]

The problem using the same convention as physical servers for us is that we use the badge number as part of the name, for example, SV-294823. Naturally virtual machines do not have asset tags, so I decided to just go with a sequence, for example, VM-000123. I have not yet decided whether it is worth the effort to give servers, be they physical or virtual, friendly names. Our last convention was based around big cats. As our DNS is served by ISC named, manually updating zones using nsupdate is a bit of a hassle, and I am sure would not be kept up to date.

[Erik_Zandboer]

@c_g-hills: If I understand correctly, you add the hardware[/b] tag in the hostname? Lets say a physical server is replaced by other hardware, do you then have to change the hostname? It appears to me you would never[/b] want any hardware-related items in your naming convention (for both physical and virtual systems; no asset tags and no "-vm" additions at all)

[c_g-hills]

That is correct, we use the badge number as the name. Of course, using a friendly name (ie DNS CNAME) mitigates the problem of changing physical servers, which only happens rarely. We already do this in some cases.