Storage VMotion - VM's visible on both Datastores

[Frans_P]

Hi,

We moved a lot of VM's to some new datastores using svmotion which went fine, except for some VM's that where moved from a SATA LUN: These VM's are visible in Virtual Center on the old datastore "STORE1" and the new datastore "STORE2". When opening an ssh connection to my esx server and view /vmfs/volumes/STORE1 all the VM's are moved to /vmfs/volumes/STORE2 perfectly! Still, when opening Virtual Center and selecting datastore STORE1, i see all the VM's listed!

Anyone here that can help me fix this problem without interfere the all the running VM's?

Thanks!

Joris

[riker82]

what display virtual center when you select a vm? on the right box? On which datastore resides?

If it's the new one, no problem. Just delete the old vms vmdk

[Frans_P]

Well,

When opening STORE1 in Datastores and press the Virtual Machines tab, i see all the VM's listed there. When i select one of those VM's and view the virtual harddisk properties, STORE2 is listed!

Any idea?

[kjb007]

Use datastore browser to view the actual vm folders on STORE1. See if there is anything in those folders. If the harddisk properties say STORE2, then the disks have moved. Check also under the virtual machine's properties, in the options tab, to see where your virtual machine config file lives. Hopefully that says STORE2 as well. If it does, then the folders from the old location were not cleaned up after the svmotion, and they should be harmless, as long as they are empty.

-KjB

[Frans_P]

Well...

When viewing /vmfs/volumes/STORE1 (the old store) everything is empy, everything has moved properly. The only thing that is strange is that when i list STORE1 in Virtual Center, all the VM's are still listed which should not happen....

I can safely delete the STORE1 i guess?

[kjb007]

Is this a SAN LUN? If it is, before I delete it or write over it, I'd just mask it away from the ESX host, and then rescan and make sure all is ok. It may be paranoid, but if the folders are empty, you should be fine, but better safe than sorry.

-KjB