Does it bug you when the registered names of your VM do not match the folder and file names on the datastore? It can be difficult to identify VMs when browsing the datastore if the folder and file names do not match the VM name. Or maybe the VM names generally match what’s on the datastore but there are some case sensitivity discrepancies. I for one an uncomfortable with these situations. While fixing the problem by bringing the datastore folder/file names into alignment with the VM name isn’t impossible, the process is painful when done manually and requires an outage of the VM.

Here’s a simple trick I’m sure many may already be aware of. I remember hearing about it quite a while ago (I don’t remember where) but had forgotten about it until today. Let VMware Storage VMotion take care of the problem for you. During the Storage VMotion process, the destination folder/file names are synchronized with the name of the VM on the fly with no outage.

For example, let’s say we create a VM with a registered name of “old_name”. The datastore backing folder has the name of “old_name” and the files inside are also prefixed with “old_name”.vmdk, .vmx, etc.

Now we go ahead and change the name of the VM to “new_name” in vCenter. The datastore backing folder and files still have the “old_name” and now obviously don’t match the registered VM name.

To bring the datastore backing folder and file names back in synchronization with the registered VM, we can perform a Storage VMotion. In doing so, the backing folder and files will be dynamically renamed as they land on the new datastore. In this case, they will be renamed to “new_name”.

This solution is a heck of a lot easier than powering down the VM and renaming all the files, as well as modifying the corresponding metadata in some of the files.

Update 9/27/11: As reported by Gary below and validated in my lab, this trick no longer works in vSphere 5.0 with respect to file names within the folder.  As an example, after renaming the VM in vCenter inventory and then subsequently Storage vMotioning the VM, the destination folder name will match the VM however the .vmx and .vmdk files inside will not.  This is unfortunate as I have used this trick method many times.

Update 11/7/12: Over a year later, vSphere 5.1 is shipping and this feature is still disabled.  VMware KB Article 2008877 has not been updated since the launch of vSphere 5.1 If I were a customer, I’d be upset.  As an avid user of the product, I’m upset as much about the carelessness and complacency of VMware as I am about the disabling of the feature.

Update 12/21/12: Duncan Epping reports Storage vMotion file renaming is back in vSphere 5.0 Update 2.  Read more about that here.  This is a wonderful birthday present for me.

Update 1/25/13: Duncan Epping further clarifies that Storage vMotion file renaming in vSphere 5.0 Update 2 requires an addition to the advanced setting in vCenter (Add the key “provisioning.relocate.enableRename” with value “true” and click “add”).  Read more about that here.  Duncan further hints that Storage vMotion file renaming may be coming to vSphere 5.1 Update 1.  No promises of course and this is all just speculation.

Update 4/30/13: Duncan’s prophecy came to realization late last week when VMware released vSphere 5.1 Update 1 which restores Storage vMotion file renaming.  As pointed out by Cormac here and similar to the update above, an advanced setting in vCenter is required (Add the key “provisioning.relocate.enableRename” with value “true” and click “add”).

• Previous Entry: 8 New ESX(i) 4.0 Patches Released; 7 Critical
• Next Entry: VCDX Design Exam: been there, done that!