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
Thanks
This is awesome
Thank you
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:, , 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:, , 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:, , 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.
Additionally:
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. ..it 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.
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?
Sorry for the delayed response:
if you have not already gotten it- ToLocal(v.lastsync) will convert utc to your local web server time. If you read the SDK PDF it lists the correct syntax for date and time manipulation.
Love the idea, but I have an issue where sometimes the new volume is replacing the old just due to some change and not due to it being a new drive perse. Hence for historical reasons I need both drives merged so I can have one graph for history.
I created an idea: that would deal with this.
Any news on this?
The ability to automatically swap disks when failed over would be a god send.
However the historic data retention is still key.
Thank you for this. However the LAST SYNC date is current on KNOWN stale volumes. Does anybody know why that is? And what is a better indicator of a stale volume besides LAST SYNC?
Update: Next Poll is the best indicator of stale volumes.
The two columns are confusing. Last Sync is actually the last time Orion attempted an update on the volume (this will always be current time). Next Poll is actually the LAST poll a successful poll was made. The two column names should be swapped in my opinion.
I've requested just a different color of icon for volumes on rebuilt servers. It was long time ago 1-2 years but I see no improvement up to now. It is bit frustrating to see the same icon for volume which is doubled or tripled with different codes behind volume letter. If unused volumes exist with different icons then existing ones it would be much easier to remove outdated.
Hi there,
Just wondered if there was any variation of the above that will work in Database Manager? I have well over 1000 old volumes to delete and don't particularly want to do this manually.
Here is a SQL that I built to find Interfaces that are probably obsolete and need to be removed.
SELECT Nodes.NodeID, Nodes.Caption, Volumes.VolumeID, Volumes.LastSync, Volumes.VolumeIndex, Volumes.Caption, Volumes.StatusLED, Volumes.VolumeResponding, Volumes.NextPoll, Volumes.VolumeType FROM Volumes INNER JOIN Nodes ON Volumes.NodeID = Nodes.NodeID WHERE Volumes.VolumeIndex = 0 AND Volumes.VolumeResponding = 'N' AND Volumes.NextPoll < DATEADD(day, -15, getdate()) ORDER BY Volumes.NextPoll DESC
Here is the same query using SWQL:
SELECT n.NodeID, n.Caption, v.VolumeID, v.VolumeIndex, v.VolumeType, v.LastSync, v.Caption, v.StatusLED, v.VolumeResponding FROM Orion.Nodes as n INNER JOIN Orion.Volumes as v ON n.NodeID = v.NodeID WHERE v.VolumeIndex = 0 AND v.VolumeResponding = 'N' AND v.NextPoll < ADDDATE('day', -15, GETDATE()) ORDER BY v.NextPoll DESC
How do you remove these dead volumes?
We've had to remove and re-add the entire node. Painful.
Disregard - I found it - Manage Nodes. Delete dead volumes.
Fun times!
orioncrack please provide a screenshot so that I see exactly where you click the Delete dead volumes.
Yes please provide solutions!
Search for the node and expand the volume and select the one which you like to delete.
the old volume will show in color Red, since the volume is not in healthy state and not active.
We have SWQL scripts that delete stale volumes and then we have discoveries running on automatic intervals to discover nodes and new volumes. Not the most elegant but it works for us.
Care to share the SWQL script that deletes stale volumes?
