Rename vms?

Hey guys
I want to rename some of our vms from inside and rename the actual server and to rename the vm so in the inventory it matches the new
name of the server. Yeah in WIndows 2003 AD it renames it fine
in there when you change it but what about in the Esxi itself and in the
infrastructure client I have hear it messes things up?

Any advice on doing this or dontdo it at all?? thank you!

Find more posts tagged with

Comments

Forsaken_GA

I've renamed things quite often, and it's never caused a problem. The one thing to realize is that it will not change the name in the datastore, it'll be whatever you initially added it as, and that name will be the default if you ever import it back into inventory. right click and rename the client in the vsphere client all you want, don't try renaming anything on the datastore.

RTmarc

Just to follow up on what he said, throw a note on the VM in the VIC like "aka OLDNAME" so you have another visual cue.

DigitalZeroOne

If you change the VM name and migrate it to another datastore, the files associated with that VM will reflect the new name.

Forsaken_GA

DigitalZeroOne wrote: »

If you change the VM name and migrate it to another datastore, the files associated with that VM will reflect the new name.

This is true, but migrating storage just for vanity is not what I'd consider the hallmark of a good admin.

blargoe

Forsaken_GA wrote: »

This is true, but migrating storage just for vanity is not what I'd consider the hallmark of a good admin.

So, you'd consider that the hallmark of a bad admin? I don't get that... as long as you're doing your due diligence regarding storage performance while you execute the migration, why wouldn't you want to keep your VM folders and file names consistently named, so that you know what the heck you're actually looking at when you browse the datastore?

Forsaken_GA

blargoe wrote: »

So, you'd consider that the hallmark of a bad admin? I don't get that... as long as you're doing your due diligence regarding storage performance while you execute the migration, why wouldn't you want to keep your VM folders and file names consistently named, so that you know what the heck you're actually looking at when you browse the datastore?

Call it a difference of opinion if you want, but after someone does a routine storage migration that didn't need to be done and manages to lose the LUN's in the process, necessitating a rebuild, and folk get a mite bit twitchy about doing something without a really good reason.

Since this happened on a server that was fairly important to me, and without any heads up whatsoever, let's just say my decibel level rose a bit. Now you can argue that's a bit of a process breakdown (and you'd be right, but that's another subject entirely), but the bottom line is that things can go wrong during supposedly safe operations.

I'd have much rather they just cloned the damn thing instead of actually trying to migrate it, and then forced a cutover. Would have saved about 10 hours of additional work.

jibbajabba

Forsaken_GA wrote: »

Call it a difference of opinion if you want, but after someone does a routine storage migration that didn't need to be done and manages to lose the LUN's in the process, necessitating a rebuild, and folk get a mite bit twitchy about doing something without a really good reason.

If that happens then something's wrong with your setup to start with ... Storage vMotion is a crucial part of vSphere and if you followed best practise then doing a Storage vMotion should not cause any issues whatsoever .. we do occasional storage vmotions just so we can convert a vm from thick to thin for example ..

Forsaken_GA

Gomjaba wrote: »

If that happens then something's wrong with your setup to start with ... Storage vMotion is a crucial part of vSphere and if you followed best practise then doing a Storage vMotion should not cause any issues whatsoever .. we do occasional storage vmotions just so we can convert a vm from thick to thin for example ..

What was wrong was the human element, and that part has long since been rectified.

And please, please pay attention to what I'm saying - I'm not saying never migrate storage! Obviously there are good reasons to (and you just listed one of them), all I'm saying is make sure you actually *have* a good reason. I happen to consider changing the names of the folders on the datastore to not be a good reason

jibbajabba

Forsaken_GA wrote: »

What was wrong was the human element, and that part has long since been rectified.

And please, please pay attention to what I'm saying - I'm not saying never migrate storage! Obviously there are good reasons to (and you just listed one of them), all I'm saying is make sure you actually *have* a good reason. I happen to consider changing the names of the folders on the datastore to not be a good reason

Oh, I read what you said but you used "losing a LUN" as a reason why you shouldn't do "unnecessary" migrations and all "I" am saying is, that this shouldn't be an issue / concern

Forsaken_GA

Gomjaba wrote: »

Oh, I read what you said but you used "losing a LUN" as a reason why you shouldn't do "unnecessary" migrations and all "I" am saying is, that this shouldn't be an issue / concern

Yeah, I know, my point is that due to the human factor, even simple routine things can be screwed up. I've always found that I make my biggest mistakes when I'm on autopilot (in this case, it wasn't me, but I've done things like cut off connectivity to an entire datacenter by making a typo, so...)

itdaddy

what you are trying to say is "if it ant broke dont fix iti"
ahahha

I do understand..but I want to rename the NETBIOS name in the server as well as rename the inventory name. So I can rename the inventory name
and the netbios name from within the machine but the sname in the datastorage willl remain the old name is that correct?

just to make sure I have it correctly.