Showing results for 
Show  only  | Search instead for 
Did you mean: 

IBM PVU Beacon issue

We are currently running in to issues with our beacons on our on-premise version of FNMS 2019R2 and have recent have upgraded to 2020R2. We have recently enabled IBM PVU discovery every 30 minutes. When we started the PVU scans our jobs started failing. We currently have 50 + beacons deployed to cover our network, multiple remote sites, attached and disconnected networks so the jobs won’t feed to them, or get responses back. All the Subnets we are trying to retrieve data from are assigned to a single beacon.  So every 30 minutes the task runs to inventory the Vcenters against all 50+ beacons. Is there any way to limit the beacons that it tries to reduce scan times or reorganize the beacons to a parent child configuration so that when the job runs it only hits the parent beacons? 

(1) Reply
By Community Manager Community Manager
Community Manager

I can't think of any way to feasibly achieve what you're looking for here sorry. The decisions about what needs to be done during a virtual inventory gathering job like this are highly distributed: each beacon makes its own decision about whether it needs to do something for the job, but the design of this system does require each beacon to know about the job in the first place and report status. Even if most beacons will end up determining they don't need to do something, that decision can't be made centrally in a way that would stop the job going to the beacon in the first place.

In your situation, given that you know all the inventory gathering will be done from a single beacon you can probably just monitor the status of the job for that beacon. Your administrators would need to understand that the overall job status will generally be shown as poorly due to the nature of your disconnected networks not allowing status to be broadly reported from all beacons.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)