Saturday, April 9, 2011

'VMware Server cannot find the virtual disk' on VMware Server

Summary
When starting the VM on Blade 5, the following error appears:
    VMware Server cannot find the virtual disk "//disk3.vmdk". Please verify the path is valid and try again. Cannot open the disk '//disk3.vmdk' or one of the snapshot disks it depends on. Reason: The system cannot find the file specified.
You may find that the your file equivalent of "disk3.vmdk" may not be found. However, other files may be found:
    -r--r--r-- 1 root root 11 Dec 21 16:38 disk3.vmdk.RESLCK.WRITELOCK
    -rw------- 1 oracle dba 4096 Sep 25 17:52 disk3.vmdk.RESLCK
    -rw------- 1 oracle dba 437 Dec 12 13:41 disk4.vmdk
    -rw------- 1 oracle dba 437 Dec 12 13:41 disk5.vmdk
    -rw------- 1 oracle dba 437 Dec 12 13:41 disk6.vmdk
    -rw------- 1 oracle dba 434 Dec 12 13:34 disk7.vmdk
    -rw------- 1 oracle dba 434 Dec 12 13:37 disk8.vmdk
Deleting the disk3.vmdk.RESLCK.WRITELOCK file did not make a difference.

Details
1. Manually create the //disk3.vmdk file (copy any of the other ones, e.g. disk5.vmdk), and change the following two values:
CID=0187ef8f                   <-- this should be a random number
RW 20971520 FLAT "/dev/sdh" 0  <-- change this to /dev/sdh or equivalent to your environment

Explanation why I used "0187ef8f":
Per http://sanbarrow.com/vmdk/vmdk-basic-CID-chain-repair.html, CID was a number randomly assigned by VMware Server. I figured, why not use a random CID (I just used the one in the website), after confirming that it's not in any of the .vmdk files.

Explanation why I used /dev/sdh:
All the other .vmdk files were already pointing to various files under /dev:
    disk4.vmdk: RW 20971520 FLAT "/dev/sdi" 0 disk5.vmdk: RW 20971520 FLAT "/dev/sdj" 0 disk6.vmdk: RW 20971520 FLAT "/dev/sdk" 0 disk7.vmdk: RW 2097152 FLAT "/dev/sdl" 0 disk8.vmdk: RW 2097152 FLAT "/dev/sdm" 0
So that leaves the only available ones:
    /dev/sdg /dev/sdh
Since lun33.vmdk was the first file, I chose to use /dev/sdh which was the one immediately preceding /dev/sdi and used by lun34.vmdk. This was a risk, but what choice did I have?

2. The VM server started up!!!

No comments:

Post a Comment