I'm fairly sure our environment is not unique. We have SQL clusters, lots of them, and in monitoring the volumes, we usually point SAM at the virtual name, and only monitor the volumes that are applicable for that cluster group/SQL cluster. The problem I'm finding is on the event of a failover of the cluster group to another node in the cluster, it then thinks the volumes are new volumes if you tell it to list resources. I discovered this when I'd added a new volume to a SQL cluster, and went to add it to SAM, it rediscovered volumes that it already knew about, and is successfully polling.
Pictures may make more sense:
Image may be NSFW.
Clik here to view.
As you can see from this image, SQL_004_T and SQL_005_T are unchecked, like they are newly discovered drives. Now lets take a quick look in the database at the current volumes.
Image may be NSFW.
Clik here to view.
Note that both SQL_004_T (VolumeID 2401) and SQL_005_T (VolumeID 2402) are listed as volumes in the DB, and are being polled. Now I'm going to check the boxes for 004 and 005, and add them to be polled (twice).
Image may be NSFW.
Clik here to view.
So now we see 2 copies of the same drive. Lets go back to the DB again...
Image may be NSFW.
Clik here to view.
So they now have VolumeID 3501 and 3502 respectively. What is interesting is that the fullname field prefixes the name with the System Name pulled from the WMI query (I assume Win32_Volume) rather than using the node caption. This results in listing inventory making the assumption they are new volumes, when in fact they are not (this is my assumption on how it's identifying volumes). Keen observers might also note that despite having SQL_001_T checked in the "list resources" dialog, it's not in either the DB, or the UI, even after submitting it (about 15 times for the purpose of tracking down this particular issue). What I don't understand is how the fullname got the node name in the past, but doesn't now.
Anybody else see similar issues? I've noticed from a quick search that there are people reporting volumes going missing after a rename, or not polling anymore, which I put inline with this bassed on the assumption that it's using one of the caption/volume/fullname fields to actually match up. From my perspective, there is a couple of bugs here:
1. SAM is using a calculated value based on a user changeable information to identify volumes (granted the chance of the volume names changing is slim, but you already have serial number, why not just use that).
2. SAM is using the SystemName returned from Win32_Volume instead of the node caption/name as part of the calculated values (based on my assumptions). If I move the cluster group to another box (not unheard of in clustered environments) then the volumes are "new". What's odd here is that it still polls successfully, which means that the polling engine that is fetching the data doesn't appear to be using the fullname field, but the "List Resources" appears to be.
3. Despite numerous attempts, it refuses to add the one volume that is checked.
EDIT: I didn't notice but the "volumedescription" field for 004 and 005 has a \ on the old ones, but not the new ones. So it might be using that field for the discovery comparison, rather than the fullname. For kicks, I updated the database, and removed the \ from the volumedescription on the end, and it made no difference, it still keeps seeing them as new disks. Also still cannot monitor 001.
EDIT 2: Even more unusual discoveries, not sure it's using description or caption at all, but some other mystery field. When I unchecked 001 and 000 from the "List Resources", the 2 top mount points (volume id 2401 and 2402) were removed. Not what I was expecting at all.