Deleting Orphaned Disks in Citrix XenServer 5.5

November 24, 2009

Recently I ran out of storage space on a Citrix XenServer because a number of local virtual disks had become orphaned and deleting them proved to be a little difficult, so, I thought it might be useful to share what I found lest others suffer the same issue.

I think the problem occurred because I removed disks which were attached to some VMs which had been created from templates, because I was using them with Provisioning Server and had run the XenConvert stage to copy the hard disk to the vDisk. This was so I could test that they worked without local disks, but didn’t want to delete them in case there was a problem.

I found two methods – the “hard” way and the “easy” way.  Guess which I found first?! ;)

Method 1.

From a console shell prompt run the command:

xe vdi-list

Note that vdi is short for “virtual disk image” in this context. This should result in a display similar to the following with one entry per storage item so will include ISO images as well as virtual disks. Note that this will list all items, not just orphaned ones. Pipe the output to “more” or redirect to a file and use “vi” or similar on the file produced to find the oprhaned items.

uuid ( RO)                : cb5781e0-c6f9-4909-acd6-5fd4b509d117
          name-label ( RW): Vista master for UIA
    name-description ( RW): Created by template provisioner
             sr-uuid ( RO): 72cc0d44-bea7-6c15-cf8d-c2965ca495b2
        virtual-size ( RO): 25769803776
            sharable ( RO): false
           read-only ( RO): false

Fortunately, I knew the name of the disks that were orphaned so passed their uuid values as an argument to the “xe vdi-destroy” command thus:

xe vdi-destroy uuid=cb5781e0-c6f9-4909-acd6-5fd4b509d117

The storage space freed up by deleting the disks will eventually be realized but to force this, you can manually instigate a re-scan of the containing storage repository. For this, we need to know the uuid of the storage repository which we have in in the “sr-uuid” field in the original “xe vdi-list” command above:

xe sr-scan uuid=72cc0d44-bea7-6c15-cf8d-c2965ca495b2

Method 2.

Add the disk to an existing VM and then delete the disk from the “Storage” tab in XenCenter for the VM when it is powered down :)

I hope this is of use to someone?…

 

 


Some Citrix XenDesktop Troubleshooting Tips

September 23, 2009

I have recently had to build a new Citrix XenDesktop environment for some testing which included Citrix Provisioning Server and Citrix XenServer. Along the way, I had various issues and struggled to find a single, comprehensive, troubleshooting article so I am going to have a stab at it here since I had to go through various tests in order to sort my issues. Having said this, there are some very good technotes on the Citrix web site here – http://support.citrix.com/product/xd/v3.0/technote/

  1. Enable logging for the Workstation Agent and ensure that access to the C$ share of the master XenDesktop image is enabled, including a firewall exception for file sharing. This is so that you can get at the log file without having to log on interactively to the image. See this article for how to enable the logging by a simple edit to the WorkstationAgent.exe.config file:  http://support.citrix.com/article/CTX117452 

    Obviously ensure that the Workstation Agent (Citrix Desktop Service) is successfully starting, as are other Citrix services, and the log shows it registering with the DDC.

  2. The event logs are also obviously another place to look when things fail although this can be tricky if your VM has been connected enough to want to reboot when the connection attempt has failed.
  3. You can also enable logging for the Desktop Delivery Controller service which is detailed in the link above. Ensure that the DDC service and other Citrix ones start successfully.
  4. PortICA logging can be enabled – http://support.citrix.com/article/CTX118837 – which could show potential ICA problems. It didn’t for me but will stay enabled in my base image whilst I am still testing.
  5. Citrix tracing tool (CDF – Citrix Diagnostic Facility) – this didn’t help me as it only currently supports a small number of client side features such as USB. It can also be run on the machine running the Workstation Agent but I didn’t do this.  http://support.citrix.com/article/CTX120269
  6. I did have some errors when using the XenDesktop Setup Wizard so I followed the steps to get a log file for this. I couldn’t get the log produced via the command line so ended up modifying the .config file as described here: http://support.citrix.com/article/CTX118278 

    My issues actually turned out, I think, to do with the fact that the template I was specifying in the wizard had an 8GB disk attached (it was my Gold Build VM that was booting off the PvS disk but still had the original hard drive in case I needed to rebuild the PvS disk) so each new VM created by the wizard was creating a new 8GB disk and I simply didn’t have the storage for it (not that I got an error suggesting this). I therefore created a new VM in XenServer that had the memory, NIC and CPUs I wanted but had no hard disk so actually didn’t have an OS installed (it never even got booted). This doesn’t matter since the OS comes from the vdisk/vhd you specify, separately, in the wizard.

  7. Check that you can logon with the required accounts to the VMs in your XenCenter/XenServer console. This should show any domain joining or account issues, e.g. expiry or permissions. Also check network connectivity to/from them.
  8. Fire up your gold image VM, since it should be on a standard image disk so the changes will be lost when it shuts down, add it to a new desktop group without a hosting infrastructure so that you just use the name of the VM in the group. This should tell you if the problem was something funny about the desktop group or the VMs that comprised it.
  9. My issue was that I was launching the connection from Web Interface but I wasn’t getting a session, just a failure popup – “Unable to connect to the desktop. This may be a temporary problem. Click OK and then try starting the desktop again. If the problem persists, contact your system administrator”. Before acknowledging the failure popup, look in your %temp% folder for the ICA file that it dynamically created. It won’t be a .ica file but instead will most likely be a .tmp file although will probably start “ica*”– easily spotted by modification time, particularly if you sort on modification time. It is actually the argument to cdsbar.exe if you look in Task Manger on Vista or with SysInternals/Microsoft Process Explorer. Open the ica file in notepad and check that it makes sense – e.g. is connecting to the right thing (“Address=”) and that the entity can be resolved/contacted. Note that the ica file, in best Mission Impossible style, will self destruct, i.e. be deleted, when you ok the failure popup thanks to the “RemoveICAFile=On” line. Note also that there is little point in saving the ica file for later use since it has a logon ticket in there which most likely will have expired.
  10. This leads on to checking that port 1494 is accessible in the virtual desktop by telnetting to it. However, port 1494 is only alive for a brief while after the connection is initiated so wait a few seconds after you have clicked on the icon to launch the session in Web Interface, or Program Neighborhood, before trying the telnet. When accessing a pool, look at the temporary ICA file to figure out which machine to check or reduce the pool to a single machine. We are not really looking for anything here other than the connection succeeds although you will probably see the characters “ICA” displayed.
  11. As by this stage all logs were looking fine and port 1494 was working, I put on a network monitor, in this case SysInternals/Microsoft Process Monitor, on my client machine (the one accessing Web Interface) and filtered on wfica32.exe. This is when I found that some traffic was going through my proxy that I hadn’t allowed for – bingo, problem solved when the proxy was disabled. In my defence, I had tried accessing from a different client (this should probably be a separate line item in this troubleshooting “guide”) but that had also failed, albeit probably for different reasons as it wasn’t using a proxy.
  12. Watch for proxies! Obviously configure them as necessary or disable them.
  13. I did have some “funnies” with my XP VMs created by the XenDesktop Setup Wizard and running off PvS. I think they were because after creation I had switched the master disk away from Standard Image mode. My excuse is that you have to manually hit F5 to do a refresh after changing vDisk properties and I didn’t! I was actually getting the error described here: http://forums.citrix.com/message.jspa?messageID=1393521 

    Sometimes the streaming console (StreamConsole.exe) on the PvS box can help diagnose these kinds of issue. Unfortunately it didn’t in this case.

  14. I also got caught by my base image having miniscule event log sizes (64KB) so even though they weren’t up for long, it was enough for them to fill up and not to overwrite so it was back to the base image to set larger sizes and set them to overwrite as needed.