cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 8

Drives not updating after movement in SVC/change in serial number

Why didn't my drives update? I recently got called out because a server's E: drive was close to 100% and no alert was sent out on it. Looking at the node it had 2 E: drives and when I listed resources I added yet another E: drive. The drive I added is the one in use now. The drives stopped gathering data at the time that they where moved by SVC on the SAN. It looks like each time a drive was given more space or moved and got a different serial number SAM didn't add the new one and kept the old one even though it was not getting any data from it at all.

Tags (3)
0 Kudos
18 Replies
Level 12

This is probably the everlasting gobstopper of NPM (not SAM) bugs, whereby Orion stops updating a volume and marks it as "not responding" in the Volumes database table, but doesn't give an indication in the web UI that it's not being monitored any more. It happens whenever the volume name or serial# changes on the server.

I'm curious if this has been fixed in the newer versions of NPM - we're still on 10.4.1. There should be no need to have an alert for "unresponsive" volumes. One time I did manually update the Volumes database table and NPM subsequently resumed monitoring just fine - it's easy enough to write a script to run periodically to update the Volumes table, so it's something that SolarWinds should be able to do themselves very easily, but for some reason they have never done it.

0 Kudos

Do you know how to get rid of the drives that aren't responding? I'm in the process of adding the right drives, but now am left with a node with 2 C: drives and 3 E: drives when it only really has 1 of each...

0 Kudos

You can't delete it from the "list resources" screen - that just shows the stuff it found at that exact point in time.

"Manage Nodes", then expand the list of stuff for that server, tick the old drive (check you select the correct one!), delete it.

WMI is far more forgiving than SNMP. My recommendation would be to manage the node via WMI instead of SNMP and this should reduce or eliminate the phantom volume syndrome that you're seeing now when the SNMP volume index ID number changes on the host.

0 Kudos

aLTeReGo,

Unfortunately, this has not gone away. I have a Client right now who is suffering outage due to the Volumes changing Serial/Names and not being picked up by SolarWinds using WMI. With the introduction of AppStack this has become more visible, but doesn't resolve the underlying issue with Dynamic Storage Allocations, which change the Name/Serial number of the drive when it moves. This is also seen when the Applications are in Cluster Mode and volumes move from Cluster Member to Member when the Application moves.

Derik Pfeffer

Loop1 Systems: SolarWinds Training and Professional Services

0 Kudos

The WMI method is not tied to the same limitations o Index IDs that SNMP uses to identify volumes. Instead WMI uses the volume serial number as the unique identifier.

0 Kudos

aLTeReGo,

I understand the WMI using the Serial number, but that highlights the issue, as these volumes are being expanded or rebuilt get new Serial numbers. There needs to be a way to know that this systems had a C:\xxx and now it has c:\zzz and make that automated update to replace the existing volume to the new one, but able to keep the historical data for historical reporting.

Derik Pfeffer

Loop1 Systems: SolarWinds Training and Professional Services

I believe this is related to the following feature request.

aLTeReGo,

It is similar, so I voted for that feature as well. Thanks for pointing that one out to me.

Derik Pfeffer

Loop1 Systems: SolarWinds Training and Professional Services

0 Kudos

It does give you an idea that the drive is old or has been removed in the dashboard for that alert.  It will show a next poll time that occurs in the past and will never update because the volume has been removed.  You could potentially write an alert for any next poll times that occur in the past to easily find removed or modified volumes.

I'm on 10.6 and having this issue...so....don't think it's fixed.

0 Kudos
Level 11

Do you have auto discovery on?  The reason I ask is because we go through this quite a bit actually but we don't have auto-discovery on either.  I could be speaking out of line or on the wrong thing but it's the way SW tags the volume or drive and when it changes it doesn't see it unless you auto discover and accept or if you manually discover.  We run into this when hard drives are replaced and things like that.

0 Kudos

Not entirely sure. Where can I check for that? I know I've seen it, but I'm a little swamped going through and manually checking about 100 nodes to see if they have the correct drives...and it's not looking good.

0 Kudos

I also would recommend you using an alert called volume checking, again, there may be a much better way, but I have an alert that sends me a message and only shows up in active alerts when volumes are no longer avail and then at that point I check SNMP or WMI and if those are working, I then delete the old drives and edit node and look for the new volumes.Untitled.png

Halfway through checking nodes and taking a break to build this alert. Is this an alert you found on Thwack? Is that "Volume responding" a script?

Nevermind, didn't have "Type of Property to Monitor" set to volume instead of node! My bad!

0 Kudos

Thanks I'll set this up and test it! Now that I think about I'm not sure I can run the sonar everyday with the amount of nodes I have. 4 pollers with 3k-4k nodes...

0 Kudos

It's in settings on Orion Website Administration under Network Sonar Discovery, do add a discovery and I believe you can get it to run daily.  There may be a better way to do this as well.

0 Kudos

Give me a few and I will locate.  I know we have it turned off because at times volumes don't report when SNMP is jacked up or WMI isn't working.  I use the alert that will notify when volumes aren't seen and then manually check.  I'll get back to though on the auto discovery location.

0 Kudos