SAN Migration Caused VM's not to Power On

[AngelC2]

We have finished a SAN Migration project and was able to move 2 ESX 3.5 host and their VM's to the new SAN. However, although the VM's on one server gave me the same problem...those VM's powered on successfully the next day. The other ESX server's VM's did not. Each ESX 3.5 host has 5 VM's in it. These are running Standard edition and it's for our DEV/TEST environment and VMotion is not being used...each host stands on its own.

The error message I'm getting is: Virtual disk 'Hard Disk 2' is not accessible on the host: Unable to access file.

When I look at the VM's from the 1st one that was successful on 3 of those 5 VM's it shows that the "Hard Disk 2" is unavailable and grayed out within the VM Properties, but when I log into the VM the drives show up just fine within the Windows 2003 Server Guest OS. I got the same error message on these as above yet the next morning when I attempted to power then on they worked but now these are the weird settings they have. The other 2 VM's have both Hard Disk 1 and 2 properties show up correctly within the VM and Guest OS.

The 2nd ESX host server is similar...1 out of the 5 VM's have the VM properties show the correct Hard Disk info that the Guest OS shows but the other 4 continue to give me the same error message when I try to power them on and they have not fixed themselves so to speak.

I would like to not only fix the VM's that won't power on correctly, but also fix the ones that are on yet display incorrect info in their VM properties.

Any help would be greatly appreciated.

Thanks in advance!

[Texiwill]

Hello,

I would remove from the VM then readd the appropriate Virtual Disk to the VM. It looks like the VMFS UUID may be incorrectly referenced within the VM.

Alternatively look in the 'vmware.log' for the VM you are trying to power on for the actual problem you are facing. It sounds like a path issue.

Best regards,

Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

[anujmodi1]

The hard disk 2 is not able to access the vmdk file from the datastore. It happend when you move the vmdk from one datastore to another datastore but vmx file will not update the latest datastore info and you get the message file is inaccessible. Firstly browse the datastore and verify if you have all the vmdk intact. Then remove the problematic hardisk and then add the disk again to VM.

Anuj Modi,

If you found my answer to be useful, feel free to mark it as Helpful or Correct.

The latest blogs and articles on Virtulization:

http://communities.vmware.com/blogs/amodi

[AngelC2]

Texiwill,

Thanks for your reply and yes you were partially correct...the issue was due to the UUID being incorrect but removing the bad hard disk from the VM itself caused an additional error message which I forgot to post. The end result was that I had to get VMware support on the phone and remote control my computer and walk me through editing the VMX files directly in the datastore in order to fix the problem.

So, the UUID path was the problem but it had to be corrected differently that's all.

Thanks for your input! Overall, my problem has been resolved. VMware Support for HP and VMware Communities ROCK!!!

[AngelC2]

Anuj Modi,

Again, as I said in my latest post...the problem was dealing wtih what you're referring to but it wasn't a simple process such as removing the file from the datastore and re-adding it as I continued to get error messages when I tried this.

I actually had to log into the ESX host server using Putty SSH connectivity in my case and edit the VM's vmx file to remove the incorrect UUID path pointing to the second .vmdx file.

Thanks for your input anyway!

[AngelC2]

The resolve this issue I had to login directly to the ESX host and edit the .vmx file of each of the VM's in question in order to remove the incorrect UUID path of the .vmdx file for the 2nd Hard Disk drive.

[anujmodi1]

Thats ture, playing with vmx file through putty session and replacing the uuid is not easy task. It require correct parameter which can identify the actual uuid of the datastore.

But, service console give you much more flexibility to manager your VM in a better way.

Regards,

Anuj