Updated: XenServer Virtual Machine Error on Boot "The VDI is not available"

Last year, I had wrote about this issue in regards to particular case I was working on, which you can find here. I am updating the troubleshooting methods and techniques not based on a specific scenario. Hopefully this makes it more useful to others.

When trying to boot a VM (virtual machine) residing on XenServer, you may get the error "The VDI is not available". This error can present itself for different reasons, but there are 2 common reasons why this happens:

• The VDI (virtual disk image) is missing.
• The VDI is locked to a host where the VM was running.

1. Get basic startup error information - To help narrow down the cause of the issue, we need more information. We can do this by trying to start the VM from the CLI (command line interface). To start the VM from the CLI run the following command either through the console of the XenServer host or through a SSH session to the XenServer host:

xe vm-start vm='VM name' on='XenServer host name'

2. Get detailed startup error information - To get more detailed information about this error, review the log file. You can do this from the CLI by running the following command:

less /var/log/SMlog

3. Verify if the XAPI database thinks the VM is still running and if the VDI is locked - For more information, you can see if the XAPI database thinks the VM is still running. This can happen if a host goes down with the VM running on it and the XAPI database isn't updated accordingly. To view the power state of the VM, run the following command:

xe vm-list name-label='VM name'

To find out if the VDI is locked open in the XAPI database, run the following command:

xe vdi-list params=all uuid='VM uuid'

If the VDI is locked you will see something similar to sm-config (MRO): host_OpaqueRef:6685cde1-9f08-f16b-aecc-c4e13df9c772: RW. The OpaqueRef line is a host reference, so the uuid will be different for you.

4. If the VM is not running and the VDI is not locked - If the VM is not running and the VDI is not locked, one possibility is the VDI has been removed. You will need to verify the VDI location and files. The other possibility is if the LUN where the VDI resides is having issues. If you are not running StorageLink, you can try to create a VM using that same storage repository (SR) to verify if there are any issues. If you are using StorageLink, run the following to help determine the name of the LUN on the SAN:

xe vdi-param-list uuid='VM uuid'

Look for the line that starts with location (RO):. Look for the following number on your SAN for the LUN names, it may not be the whole number showing, but you will be able to perform a partial match with the number and also size of the LUN. For example, XenServer shows 6233ac13-1a4c-49a9-8041-1b2b9c16b579, and the SAN shows 6233ac131a4c49a980411b2 for the LUN name. Once you locate the LUN on the SAN verify if there are any issues on the SAN.

5. If the power state is running, but you know the VM is powered down - If the power state is running and the VM is powered down, try resetting the power state on the VM. First on each host that is still up, run the following command to verify the VM is not running on one of them:

list_domains | grep 'VM uuid'

If a result is returned, then the VM is running on that host. When you are sure that the VM is not running on a live host, run the following command to reset the power state:

xe vm-reset-powerstate uuid='VM uuid' --force

6. Power state is not running, VDI is accessible, but VDI is locked - If the VDI is locked and the VM is verified off, you can reset the lock on the VDI. To do this, you will need to forget the VDI. To start you will need the UUID of the VDI:

xe vdi-list name-label='VDI name'

Once you get the UUID of the VDI you want to forget, run the following command:

xe vdi-forget uuid='VDI uuid'

After the command finishes, re-scan the SR and locate the VDI. Once the VDI has been located, re-attach it to the VM and try to start the VM.

If you are running XenServer 6.1, you can run the resetvdis.py script which will perform the reset operation for you. For previous versions of XenServer, the script exists, but all VMs on the SR that you run the script against must be shut down. To run the script in a XenServer 6.1 environment (always double check to make sure if the VM is running somewhere else using the command list_domains | grep 'VM uuid' on each host):

/opt/xensource/sm/resetvdis.py single 'VDI uuid'

Hopefully the above steps will help you if you run into this particular error. If you have any comments, questions, or criticisms, please leave them below.

This post was written in reference to the following platforms and versions:

• XenServer 5.6 - 6.2