Jump to content


Photo

error: iqn/iscsi initialization failed: no management credentials could be found for storage system

Started by Mike Meyer , 11 July 2010 - 09:36 PM
6 replies to this topic

Mike Meyer Members

Mike Meyer
  • 136 posts

Posted 11 July 2010 - 09:36 PM

See attached photo. My SAN guys recently implemented a VIF on the storage system, causing my iSCSI connections on all XenServers to our NetApp to fail. I'm not sure why this is the case, because the IP address of the VIF is the same as the original IP used on the PIF, so from a IP/networking perspective - everything is the same. My Windows/iSCSI connections, for example - from PVS - were fine. It's just XenServer that was a problem.

It has been extremely difficult ever since to even remove the disabled SR from XenServer, and StorageLink seeing these old/invalid connections, with "invalid credentials" - was also unable to remove/change anything, causing me to be flooded with alert emails & high CPU utilization.

I tried to unplug, forget, detach, destroy PBDs, SRs, VDIs, to no avail. Processes finally seemed to run their course over the past 24 hours however, and I have been unable to forget/detach the old SR from the XenServer Pool, reboot StorageLink, and everything seems healthy. However, lost in this shuffle is an SR that I still would like to use if I could - problem is this:

1) It no longer is visible in storagelink as an SR
2) I get the attached error message (see attached photo) when I try to use it in my XenServer Pool (run a VM that uses it as a storage/drive)

The SR shows up as a valid SR in my pool (no red error/alert atop of it), so it's not like it's "unplugged".

Questions:

1) how do I re-attached an SR in StorageLink once it is lost
2) how do I remedy a management credentials error message when it exists in XenServer

Thanks for any advice!

Edited by: Mike on Jul 11, 2010 5:38 PM

Attached Files



Mike Meyer Members

Mike Meyer
  • 136 posts

Posted 11 July 2010 - 09:48 PM

To frame this StorageLink question in a different context - from within StorageLink / Virtual Machines view, I have a couple of virtual machines listed that list their child storage as "NetApp LUN (Unmanaged)" now due to the SR now being missing.

Question: How do I actively go out and "re-manage" this same SR - bring it back.

I know full well I can create a NEW SR, and add LUNs to it - but that won't help the original link in XenServer, as it will be a new unique object/UUID.

I want to re-build that original relationship.

Thanks for any help with this.



Tobias Kreidl Members

Tobias Kreidl
  • 13,080 posts

Posted 11 July 2010 - 11:09 PM

I think what you want is the "xe sr-introuduce uuid=(UUID)" command. The UUID should show up if the SR is recognized as present, but not attached, via "xe sr-list".

The sr-introduce will require also the parameters:
type=lvm (or whatever the appropriate type is for the SR)
name-label=”your choice of label”
content-type=user (or "shared" if pooled storage)

--Tobias



Mike Meyer Members

Mike Meyer
  • 136 posts

Posted 12 July 2010 - 07:25 PM

Hi Tobias,

Thanks for the command - I'll give that a try. I've actually worked past the issue right now, but I'll keep this handy, if it happens again I'll give that a try.

Thank you

Mike



Mike Meyer Members

Mike Meyer
  • 136 posts

Posted 12 July 2010 - 11:07 PM

Tobias,

Thanks for your input. OK, I've got the same/similar situation again. Trying to replicate this so we are prepared and documented.

1) Disconnected iSCSI SAN
2) XenServers can no longer connect VM's to required LUNs (cache drives for VMs) "VDI not available" error

I want to understand how I can make XenServer resilient.

Here's what I know:

1) I can see the NetApp volume where these LUNs are located on all my XenServers if I do a "xe sr-list"
2) Currently, this Volume/SR has no alerts on it from XenCenter, but I suspect it may if I reboot (not sure)

Based on the above, shouldn't there be a way to just do a re-scan of those SR's, or have the system re-attach to the same iSCSI IP as it was before the disconnect/reconnect? The same IP/config is in play on the SAN as it was before.

The reason I ask is because at some point, this system will have to run on it's own, without a constant flurry of Linux commands being typed into it. I want to find, document, and leave with in house admins, the easiest way to get a connect back between the XenServers and the SAN, in the event a future network disruption should occur - chances are - next time it happens, no Linux shell expertise will be available.

Thoughts?

Thanks for your time.



Mike Meyer Members

Mike Meyer
  • 136 posts

Posted 13 July 2010 - 01:25 AM

Tobias,

Am troubleshooting this again. In the same situation, somewhat by choice so I can figure out why this happens and how to go about it. So far no luck. "VDI not available" and now after much careful troubleshooting, "IQN/iSCSI initialisation failed (no storage credenetials could be found for storage system....)."

I wanted to detach and reattach but I forgot instead - now I have disconnected from my SAN storage. Once so it no longer shows up in xe sr-list. My question again is - (and this is what frustrates me about this darn StorageLink) is how do I re-connect and re-manage and completely valid data set (volumes, LUNs) once I get disconnected????

Thanks



Tobias Kreidl Members

Tobias Kreidl
  • 13,080 posts

Posted 13 July 2010 - 04:23 AM

Mike,
You may want to do a re-scan before the
"xe sr-introuduce uuid=(UUID)" command.
That would be "xe sr-scan" and then do an "xe sr-list" and
the UUID should show up if the SR is recognized as present.

As noted before:
The sr-introduce will require also the parameters:
type=lvm (or whatever the appropriate type is for the SR)
name-label=”your choice of label”
content-type=user (or "shared" if pooled storage)

So try "xe sr-scan" and see if it picks it up. Sometimes, especially with a pool, you can
look with one of the XenServers first via XenCenter and it'll show up there, but not necessarily
at the pool level. I've found if you go through and "discover" the SR in all the pool members, you
can then go back and look for the device at the pool level and it somehow seems to almost
always then appear there, as well. Weird.

--Tobias