DerekMac asked a question.
Is there a SQL query or something to find out why a particular Beacon is selected to run vCenter Introspection? We have many Beacons and sometimes a vCenter will try to execute on multiple Beacons, working on one and failing on another, but I don't see any pertinent Subnets pointing to the failed Beacon, only the good one.
You might get some insight by looking at the discovery.log generated when the rule runs on a beacon. The logging can be a little confusion to follow, but this logging generally contains information about the configuration that shows what is and is not targeted by that beacon.
Chris, sorry for the late response. Meant to reply before taking some time off.
The Discovery log didn't provide exactly what I was looking for, although I did notice listing of the "is in scope" named Targets, which helps for something else.
I do not see a Subnet that points to the extra Beacon. In the Discovery Log I see this message, but do not have a Subnet defined for this, so I assume the messages below come from the Target where we point to this IP.
2022-06-08 23:01:14,119 [ets.SubnetRangeBuilder|rules-50] [INFO ] Authorizing IP range '100.97.82.209/32'
2022-06-08 23:01:14,119 [ets.SubnetRangeBuilder|rules-50] [INFO ] Including IP range '100.97.82.209'
Below messages are specific to this extra discovery, but why this Beacon?
2022-06-08 23:02:12,120 [iscoveryActionExecuter|DNSLookup] [INFO ] Successfully performed DNS discovery for device 'mdcvenglabvc'.
2022-06-08 23:04:10,800 [iscoveryActionExecuter|IPScan] [INFO ] Device 'mdcvenglabvc' is in scope: All vCenters-Known vCenter or OVM Manager servers-Services Discovery - All Sites-vCenter Targets - East Coast
2022-06-08 23:04:10,800 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Skipping Device Property Scan discovery for device 'mdcvenglabvc': Device is not discovered in the current rule execution.
2022-06-08 23:04:10,800 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Performing VMware discovery for device 'mdcvenglabvc'
Here are some comments explaining what each line of logging indicates.
- 2022-06-08 23:01:14,119 [ets.SubnetRangeBuilder|rules-50] [INFO ] Authorizing IP range '100.97.82.209/32'
Identifies IP address ranges are configured as mapped to the beacon, indicating that the beacon should do operations (discovery & inventory gathering) on addresses in the identified range.
I see you noted you "do not have a Subnet defined for this", but I believe this logging suggests the system thinks otherwise and that it does think a (single address) subnet range is mapped to the beacon.
- 2022-06-08 23:01:14,119 [ets.SubnetRangeBuilder|rules-50] [INFO ] Including IP range '100.97.82.209'
Indicates that the IP address 100.97.82.209 has been configured in the target for the discovery operation that is being performed.
- 2022-06-08 23:02:12,120 [iscoveryActionExecuter|DNSLookup] [INFO ] Successfully performed DNS discovery for device 'mdcvenglabvc'.
Indicates that the network name "mdcvenglabvc" has been found by whatever previous steps are noted in the log.
- 2022-06-08 23:04:10,800 [iscoveryActionExecuter|IPScan] [INFO ] Device 'mdcvenglabvc' is in scope: All vCenters-Known vCenter or OVM Manager servers-Services Discovery - All Sites-vCenter Targets - East Coast
Indicates what targets you have configured that include the identified device.
- 2022-06-08 23:04:10,800 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Skipping Device Property Scan discovery for device 'mdcvenglabvc': Device is not discovered in the current rule execution.
I'm not sure about this one. This is a guess, but it might indicate that the discovery action that is running:
- 2022-06-08 23:04:10,800 [.DiscoveryTaskExecutor|PropertyDisco] [INFO ] Performing VMware discovery for device 'mdcvenglabvc'
Indicates that the process is about to connect to the device in an attempt to find a VMware service running on the device.
Do you see Beacons producing logs for that inventory rule or do they actually access those vCenters?
Not sure what you mean. I was troubleshooting messages found in the Rule Execution Details. This Summary message "VMware server has not been discovered on this device" (which is listed by filtering for "VMwareNotDiscovered") on multiple Beacons, but is successful on the Beacon we intended. So why is it running on other Beacons. I thought the Beacon was decided by the Beacon specified in Subnets. The logs confirm that vCenter was attempted.
All Beacons should have all rules and run them. They then just decide based on their assigned subnets what to do per machine. My understanding is that finding logs on all Beacons is normal, but most of them should say like "not my department".
I think it may be useful here to distinguish between the Discovery part and the Inventory part. Could it be that what you're describing is only the Discovery part of that rule?
I wrote a SQL query to do this. It was easy after I found FlexNet Function IPAddressFromStr last week. It converts IP address to an Integer, and I found the Integer Range was already in SiteSubnet.
DECLARE @ip nvarchar(15)
SET @ip = '100.116.99.27'
SELECT
CONCAT(ss.IPSubnet, '/', ss.IPSubnetBits) AS 'Subnet',
ss.IPSubnet, ss.IPSubnetBits,
s.Name AS 'Site',
b.BeaconName, b.BeaconLocation
FROM SiteSubnet ss
JOIN Site s ON s.SiteID = ss.SiteID
JOIN BeaconSiteSubnetMapping bsm ON bsm.SubnetID = ss.SubnetID
JOIN Beacon b ON b.BeaconID = bsm.BeaconID
WHERE dbo.IPAddressFromStr(@ip) >= ss.IPAddressRangeFrom
AND dbo.IPAddressFromStr(@ip) <= ss.IPAddressRangeTo
The above showed me we have 4 overlapping subnets that invoke 2 different Beacons, one of which is failing because of firewall rules.
This info is a little late though, as I had already figued out that 100.0.0.0/8 (100.*) and 100.64.0.0/10 subnets where to blame and that FNMS was doing vCenter Introspection on them even though they are Disabled. Flexera Engineering created bug IOK-997120 for that.
I wrote a SQL query to do this. It was easy after I found FlexNet Function IPAddressFromStr last week. It converts IP address to an Integer, and I found the Integer Range was already in SiteSubnet.
DECLARE @ip nvarchar(15)
SET @ip = '100.116.99.27'
SELECT
CONCAT(ss.IPSubnet, '/', ss.IPSubnetBits) AS 'Subnet',
ss.IPSubnet, ss.IPSubnetBits,
s.Name AS 'Site',
b.BeaconName, b.BeaconLocation
FROM SiteSubnet ss
JOIN Site s ON s.SiteID = ss.SiteID
JOIN BeaconSiteSubnetMapping bsm ON bsm.SubnetID = ss.SubnetID
JOIN Beacon b ON b.BeaconID = bsm.BeaconID
WHERE dbo.IPAddressFromStr(@ip) >= ss.IPAddressRangeFrom
AND dbo.IPAddressFromStr(@ip) <= ss.IPAddressRangeTo
The above showed me we have 4 overlapping subnets that invoke 2 different Beacons, one of which is failing because of firewall rules.
This info is a little late though, as I had already figued out that 100.0.0.0/8 (100.*) and 100.64.0.0/10 subnets where to blame and that FNMS was doing vCenter Introspection on them even though they are Disabled. Flexera Engineering created bug IOK-997120 for that.