Showing results for 
Search instead for 
Did you mean: 
Create Post

Remove old volumes

Remove old volumes

There is no mechanism that allows NPM to notice old volumes. What we want is to remove those old volumes and replace with the newly found ones automatically.


Voted up as this is a huge issue!

Engineers will see a drive letter under a node and assume all is fine, meanwhile it's reflecting it's old values and not that it's not responding unless you dig deeper. I have had to add a resource so these orphan volumes are more visible at the summary level (additional benefit is it catches network share volumes which are not responding - though you can remove Network Disk in the where clause)

Cut/paste into a custom query:

--begin code

--Query from volumes and nodes tables with icons and links

SELECT  v.Caption as VolumeName,'/Orion/NetPerfMon/VolumeDetails.aspx?NetObject=V%3a' + ToString(v.volumeid) AS [_LinkFor_VolumeName]

, '/NetPerfMon/images/Volumes/' + v.icon AS [_IconFor_VolumeName]

, VolumeResponding

, v.LastSync

, VolumeType

, n.caption as Node, '/Orion/NetPerfMon/NodeDetails.aspx?NetObject=N%3a' + ToString(n.nodeid) AS [_LinkFor_Node]

, '/Orion/images/StatusIcons/Small-' + n.StatusLED AS [_IconFor_Node]

FROM Orion.Volumes v

inner join orion.nodes n on v.nodeid=n.nodeid

--filter on not unmanaged and not responding and Fixed or Network disk

where n.status <> '9' and

volumeresponding = 'N' and

type in ('Fixed Disk', 'Network Disk')

--sort by age

order by v.lastsync desc

--end code


Level 14


Level 14

This is great! How would I go about excluding systems with Linux (since we use a custom script for partition and extents monitoring; the build-in disk monitoring doesn't take into account the 5% reservation that Linux uses) ?

Go to manage nodes and on the left group by Machine Type then select 'net-snmp - Linux' and confirm these are all your linux servers. If so then just replace this filter section or just add that last line. Add more for each type of machine type you want to filter.

--filter on not unmanaged, not responding, not Linux, and is Fixed or Network disk

where n.status <> '9'

and volumeresponding = 'N'

and type in ('Fixed Disk', 'Network Disk')

and MachineType <> 'net-snmp - Linux'

BTW - this is exactly the same syntax to filter on your Top 10 resources and make them much more useful:

Screen Shot 2014-02-13 at 9.39.32 AM.png

Level 14

This will save me a lot of time -- thank you!

Level 11

This is awesome

Thank you

Level 10

Removing old volumes is a no-brainer.  ...mucho goodness.

I think a setting that enables auto-importing of volumes should only be used if conditional filtering can be applied to the resulting automation within the product.

case in point:

Big thing for us is that when a windows cluster group is picked up in discovery, it picks all volumes currently active on the cluster node it is currently active on.   Lets say you have a cluster node called physical1, and the other cluster node is called physical2.  They both have local C: and 😧 drives.   Cluster group "ClusterGroupHostName1" has an IP address, name(ClusterGroupHostName1), and single logical disk "L:"(on SHARED storage) that could be active at any time on either physical node.   Cluster groups B, C, D, & E also have unique IP addresses, names, & logical volumes on the shared storage.

If everything that is discovered is always auto-imported without evaluation, the result after a few cluster group fail-overs and scheduled discoveries is:

1) physical1 will eventually show a C:, D:, M:, L:, S:, P:, & T: drives (some of which might need to be purged because any of their cluster groups have failed back over to physical2 since the discovery).

2) physical2 will eventually show a C:, D:, M:, L:, S:, P:, & T: drives (some of which might need to be purged because any of their cluster groups have failed back over to physical1 since the discovery).

3) ClusterGroupHostName1 will eventually show a C:, D:, M:, L:, S:, P:, & T: drives.....oh, what a mess.   Each of the other cluster group host names will also potentially contain all volumes.

There are only a total of 9 volumes(4 local & 5 shared), but Solarwinds could potentially "show" 49 volumes across the two physical and 5 cluster group nodes.... again... what a mess..  so many erroneous volumes.

It takes some attention to detail on our admins' part, when importing volumes, to pay attention to what "server" they are importing the node on, but right now, if I go to a node that is a cluster group object "ClusterGroupName15"(for example) in our environment in Solarwinds, the only volume it shows(appropriately) is L:.

and if I go to either of the physical nodes in Solarwinds, all I see is their C: and 😧 drives

Some might argue that if they visit a physical node's page in Solarwinds that they want to see all volumes that the OS on that server currently has access to write to or read from, but without the ability to "move" a logical volume from one physical cluster node to the other in SW when the cluster group fails over, we have had a better experience requiring that our users seek the actual cluster group name node in SW if they want to see the L: drive and not have so much misinformation on every cluster node.

Level 10


If an auto-remove solution is not immediatly doable, two smaller modifications would be hepful interim-updates:

1) ACCURATE reporting of volumes on node view.   Currently, I will see a green dot next to a volume that has not seen an update in months. is green because the last time it was polled four months ago, it was in good shape.    Have the icon next to the volume properly represent the data that is already available in the db... perhaps a green dot with a broken line overlaying it?   (I already have a custom query resource on a custom view that shows me, in list form, such volumes)

2) The ability to delete the volume manually.   Again, It is "easy" enough to just go to the volumes table in the database and whack them as they are encountered, but.... If we could "list resources" on a node, and have a clickable 'trash can' icon next to all the volumes that are associated with the node whose VolumeResponding=N, that would be nice too.

#1 agree 100%

#2 agree but you can delete volumes from the manage nodes location  - just seen as a grey icon volume under the node. That's the issue though - why not show it as unknown status on the node page and as you suggest allow unchecking it from the list resources. Just add a section to list resources for orphan elements.

Level 12

We are using this code, however v.LastSync is returning UTC time instead of our current timezone (EDT).

Is this a bug? Or can we modify the SWQL code to subtract 4 hours from the time v.lastsync returns?