Orphan SRs?

Standard

(Image from www.totalprosource.com)

Recently I had to kick some XenServer pool members out of my test pool.  Yes, the XenServer pool is named Dead.  As in the one, the only, the magnificent DEADPOOL.  We go way back, share many things in common, but differ on both sanity and regenerating factors.

Where was I?  Argh…

landing-pages-deadpool-brain-failure

Oh, yes.  SO, recently I had to kick some XenServer pool members out of my test pool.  It is a run of the mill, XenServer 6.5 SP1 pool that had four members.  Two had to go.  After removing these two members, XenCenter displayed six storage repositories (SRs) that were in a disconnected state.

leftoversrs

No big deal as these were once associated with the two XenServer hosts I removed from my pool.  However, XenCenter would not let me remove them, which is something I have supported quite often and as such, inspired me to write up how I clear these.

rightclicksr

See?  When I right-click on the SR, I can’t forget it, destroy it, or even punt it.  So, I went about doing what I do and am here to share it with you.  No doubt there are 10 different ways to do this, but I am merely providing the shortest path I use when this situation occurs.

One last item before we begin to remove these…

This situation is also specific to the fact that there are no other issues with XenServer in thinking: the SR physically exists and virtual resources are associated with these poor orphans.  I will blog about that scenario later.


 

How can I remove these?

“With extreme caution,” I respond with tenor and extreme bass in my voice.  With the SRs physically gone, XenServer’s XAPI (XenAPI) database needs to be updated… manually.  Yes, this means command line access and geeky Linux/XE commands will be required.

I’ve heard your sighs, now let’s move along.

Gain access to XenServer’s command line via XenCenter or SSH.  You can obtain a list of all SRs that aren’t present by executing:

# xe sr-list host="<not in database>" | less

uuid ( RO)                : f5ef4c26-b486-c73d-b07f-47201dc834ee
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): <not in database>
                type ( RO): ext
        content-type ( RO): user


uuid ( RO)                : 089abd9d-496b-668f-166d-517d5b0c7725
          name-label ( RW): Removable storage
    name-description ( RW): 
                host ( RO): <not in database>
                type ( RO): udev
        content-type ( RO): disk


uuid ( RO)                : 97213b8c-705a-aa5e-e619-902688300638
          name-label ( RW): DVD drives
    name-description ( RW): Physical DVD drives
                host ( RO): <not in database>
                type ( RO): udev
        content-type ( RO): iso


uuid ( RO)                : f70e0ce2-6b9d-2a25-2626-2ec62f5c99a7
          name-label ( RW): DVD drives
    name-description ( RW): Physical DVD drives
                host ( RO): <not in database>
                type ( RO): udev
        content-type ( RO): iso


uuid ( RO)                : 05a325c7-f0c1-a485-5de2-00961d883a16
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): <not in database>
                type ( RO): lvm
        content-type ( RO): user


uuid ( RO)                : 4a00cc3d-b4e5-f5cb-ac9f-ee72c987bc85
          name-label ( RW): Removable storage
    name-description ( RW): 
                host ( RO): <not in database>
                type ( RO): udev
        content-type ( RO): disk

As you can see, the output will show the UUID for each SR as well as name-label, type, and so forth.  I would suggest comparing the output, such as name-label and UUID, with those displayed in XenCenter.

checkuuid

Just an ounce of precaution, right?


 

What do I do with the command line?

The long approach is to take each UUID for each orphan SR and execute:

xe sr-forget uuid=<UUID of orphaned SR>

That’s a bit tedious and redundant, so you can remove all SRs that are not present in the XAPI database with this one-liner:

IFS=','; for srUUID in $(xe sr-list host='<not in database>' params=uuid --minimal);\
do xe sr-forget uuid=$srUUID; done

This basically looks for all SRs where the host is “not in database” and uses XE to forget the storage repository.  Silent, quiet, and quick.

cleanedup


 

Two Last Things…

If you want something pretty, you can copy-n-paste the following code.  It is a simple BASH file that you will have to upload/secure-copy to XenServer:

#!/bin/bash

# REMOVE LEFT OVER SRS
# USE AT YOUR OWN RISK

# Set comma delimiter
IFS=','

# Search for SRs where they are not listed in the XAPI database for any host
for srUUID in $(xe sr-list host='<not in database>' params=uuid --minimal); 
do
    srNAME=$(xe sr-list uuid=$srUUID params=name-label --minimal)
    
    echo "FORGETTING SR $srNAME..."
    
    xe sr-forget uuid=$srUUID
done

After saving this to, say orphansr.sh, you should copy the file to /root/ of your XenServer using WinSCP (or another secure copy utility).  You can then execute the shell script by executing:

sh orphansr.sh

And your orphan SRs are removed, just like the one-liner above except this time, it prints out what SRs are being forgotten.

If you are concerned or feel uncomfortable doing this, always reach out to Citrix Support!

–jkbs | @xenfomation | XenServer.org | My Blog

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s