Dodgy Bug in 5.0 ?

jibbajabba

Noticed something scary today. When I created a new VM, I noticed that it created just fine, even though a VM with the same name existed in the inventory.

The VM was created on a different datastore but surely it can cause all sorts of issues when / if the VM needs to be (s)vmotioned. Not to mention when you try searching the inventory and end up going for the wrong server.

Has anyone seen this before ? I am pretty certain you weren't able to create a VM with the same name before, despite being on different datastore (clusters)...

I am confused ...

vNerd

This is consistent with what I have seen and confirms to a certain degree that they have relaxed datastore <--> VM name consistency requirements in 5.x. The frist thing that I noticed is that they took out the display name consistency when executing storage vMotions. In previous versions if you change the display, execute a SvMotion and the name was updated throughout the path on the datastore; that is not longer the case. I also noticed that it allows two VMs with the same name to exist on the same datastore; it just appends _*number* to the folder [ie TESTVM_1]. The only fix I found for it is in 5.0 U2; there is an advacned option you can set to enforce it, other versions you can't. This is pretty scary, to me.

Yellow-Bricks post on the fix: Renaming virtual machine files using SvMotion back in 5.0 U2

jibbajabba

I did notice the path issue as well ....In my case both VMs were shutdown and I needed to delete one .....I had to go by the possible datastore cluster and install date to find the right one ...

blargoe

This is a change that I really hate, for the record.