Hello, fellow Citrites, Partners, Clients, and XenServer fans.

This evening I thought I would touch on an issue that, for completely understandable purposes, I have fielded technically and personally: the ever ambiguous “VDI Not Available”.

Trust me when I say that in my professional and personal use that this message alone has caused me to choke on the morning’s brew of coffee.  The response to starting, migrating, or working with a Virtual Machine that fails to start due to these few words can seem… quite ominous, deadly, and down-right frightening.

The purpose of this session is to highlight a few of the most extreme to the most benign reasons that an Administrator may find themselves faced with “VDI Not Available”!

The Most Extreme Situation

To cut to the chase and from experience, well, this error will appear when something has happened to Local Storage or the Storage Repository a VM’s virtual disks are stored on.  For example:

– Power Outage

– Corrupt SAN disk

– Corrupt NFS share

– NAS networking failures during production

… and the list can go on…

Without proper backups I am afraid this is the most extreme situation wherein I loathe being the messenger of bad news: especially where policies/procedures, hardware, or other infrastructure related to storage has failed.

On the positive side, most storage vendors offer a means of replicating storage and in this case a hot-swap can be achieved.  Still, if Storage is suspect, the following article offers some insight to make a determination:  http://support.citrix.com/article/CTX138234

External Expectations

For my colleagues and clients who utilize XenDesktop that find a VM will not start as the “VDI is Not Available” can be corrected quite easily.  How?  Most often there is a resource issue that has gone on for quite sometime.  A prime example is that of adding new (hundreds) of VMs to a random pool, etc without cross checking XenServer for DOM0 memory, network utilization, etc.

What ends up happening is that the VM loses connection with XenDesktop and as such has to be “forced shutdown”.  When the VM is attempted to be restarted from XenDesktop, well – POP!  The VM declares that its VDI is Not Available.

The work around is quite simple:

– Start the VM on XenServer (alone)

– Refresh VM connections from XenDesktop

Presto – XenDesktop now has control over its VM and after running ‘free -m’ on XenServer hosts it is discovered that increasing the DOM0 memory value is needed.  As an example, changing dom0_mem=752M to dom0_mem=2048M.  The following article, http://support.citrix.com/article/CTX126531, illustrates how to do this.  As 5.6 is no longer supported, the minimum dom0_mem setting should reflect 2048M (at least).

Internal Expectations

Finally, we bring the most benign causes of them all: shutting down a VM with force (in a pool)  OR trying to migrate a VM when an ISO image is attached to the VM’s virtual disk drive.

The former is usually indicative of another problem, but if a VM is running on XenServer04 (for example), and is shutdown with force or the destroy_domain command, it must be started back up on the same server in the pool.  Why?  Well, you have a pool, right?  The VM and its metadata were previously in control by XenServer04 (in this example).  By shutting down the VM with force or destroying the domain, the rest of the pool still considers XenServer04 to be in charge of this VM.

If you attempt to start this VM on XenServer01, 02, 03, or even 05 in this imaginary pool, it will not start and complain that the “VDI is Not Available”.

If you cannot remember the server that the VM was running on you can perform the following to quite simply refresh/reset the metadata about the VM that is being passed around the pool:

– From the primary server, find out the VM’s basic information:

uuid ( RO)           : 0d27658c-784b-77b0-9670-fcfb63899d1a
name-label ( RW): winxp32sp3
power-state ( RO): halted

– Now that we have the VM’s UUID, we should find the VDI’s associated with this VM:

xe vm-disk-list uuid=0d27658c-784b-77b0-9670-fcfb63899d1a
Disk 0 VBD:
uuid ( RO)             : aececca8-7deb-1ae3-90c7-6fe4cc03715b
vm-name-label ( RO): winxp32sp3
userdevice ( RW): 0

Disk 0 VDI:
uuid ( RO)             : 8d1268b9-9442-4f74-8b40-5337c73dc857
name-label ( RW): WINXP32SP3
sr-name-label ( RO): DEBNFS1
virtual-size ( RO): 64424509440

– Find the Storage Repository of the VDI in question by executing:

xe vdi-list uuid=8d1268b9-9442-4f74-8b40-5337c73dc857
uuid ( RO)                : 8d1268b9-9442-4f74-8b40-5337c73dc857
name-label ( RW): WINXP32SP3
name-description ( RW): WINXP32SP3
sr-uuid ( RO): bfb0eda9-6fb2-7778-ba0c-923c7a004f44
virtual-size ( RO): 64424509440
sharable ( RO): false
read-only ( RO): false

– We now want to forget the VDI and then rescan the storage repository:

xe vdi-forget uuid=8d1268b9-9442-4f74-8b40-5337c73dc857

xe sr-scan uuid=bfb0eda9-6fb2-7778-ba0c-923c7a004f44

We can then attach the VDI back to the VM in XenCenter by selecting the VM in question – WINXP32SP3 – and selecting “attach disk”.

Presto – you can now run the VM.

As for a VM where a migration to another server was preformed, it is most important to check the DVD Drive for the VM.  More often than not an ISO was mounted as a virtual DVD drive for the VM in question.  The result is that the VM was migrated and from the new host, there is no access to the same ISO image.  By selecting “empty” or “eject” from the Console Tab in XenCenter, you should be able to the start the VM.

And this is from my virtual desktop to you.