Why are dependencies taking so long to get paused and unpaused

If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop in that sensor which is likely why you are seeing this issue of device's not being paused or not coming out of a paused state.

The best way to set this up would be to make the VM devices dependent on the ping sensor of the host and not of their own ping sensor.

The other way that you could do this would be to setup a separate host with the VMware Virtual Machine (SOAP) sensor and set up a ping on that device that would then be the master object and would put the VM's into a pause state if it went down.

"If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop in that sensor which is likely why you are seeing this issue of device's not being paused or not coming out of a paused state." - Will this be the case even if I have explicitly set the dependency of the ping sensor to the ping sensor of the host machine? Is it that the device's dependency takes precedence over the sensor's dependency.

Also, when you say "If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop..", till now, I've always set a device's dependency as it's own ping sensor, and have seen that if the ping sensor goes into alarm state, all other sensors on that device get paused, BUT the ping sensor itself remains in alarm state, and does NOT GET PAUSED. It would get paused if a loop was being formed right?

"The best way to set this up would be to make the VM devices dependent on the ping sensor of the host and not of their own ping sensor." - I considered this, but if the VM (not the host) loses connectivity, it's ping sensor will go down, and the other sensors on that VM, being dependent on the ping of the host device, will not get paused, and I'll be getting alerts for all sensors on that device.

"The other way that you could do this would be to setup a separate host with the VMware Virtual Machine (SOAP) sensor and set up a ping on that device that would then be the master object and would put the VM's into a pause state if it went down." - This seems like a good idea, but my experience with VM sensors is that they take a lot of resources in terms of CPU/memory usage, and I would like to use this option only as a last resort, since we're already using almost 2400 sensors.

"If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop in that sensor which is likely why you are seeing this issue of device's not being paused or not coming out of a paused state."

- Will this be the case even if I have explicitly set the dependency of the ping sensor to the ping sensor of the host machine? Is it that the device's dependency takes precedence over the sensor's dependency.

When you set a device to be reliant on it's own ping sensor by making it the master object for the device, when ping goes down, the other sensors that are NOT the ping sensor will be paused. If you set it so that the entire device, including the ping sensor, is reliant on the ping sensor then when it goes down and the sensors get paused the Ping will be paused as well. To bring it out of being paused, the ping sensor would need to come back up but it will remain paused since the device is paused. Therein lies the loop. Making the Ping then reliant on another ping will still yield this problem because when the other ping is brought out of the pause or down state, the device cannot come out of pause because it itself is paused which still includes the ping sensor. It's not so much that the device takes precendence but the timing for it to get out of a pause state would have to be quite unique, which can happen but will cause the inconsistencies that you had mentioned

Also, when you say "If you have set up that the VM device is reliant on the ping sensor, that would also include the ping sensor being reliant on itself. This will create a loop..",

till now, I've always set a device's dependency as it's own ping sensor, and have seen that if the ping sensor goes into alarm state, all other sensors on that device get paused, BUT the ping sensor itself remains in alarm state, and does NOT GET PAUSED. It would get paused if a loop was being formed right?

When you set the device's master object as the ping, then it will show the down state and not be paused since it is the master object. The problem arises when you set the ping sensor to be dependent on another device and it can no longer be the Master Object, I think this is the difference in what you are seeing between other devices that are reliant on Ping

"The best way to set this up would be to make the VM devices dependent on the ping sensor of the host and not of their own ping sensor."

- I considered this, but if the VM (not the host) loses connectivity, it's ping sensor will go down, and the other sensors on that VM, being dependent on the ping of the host device, will not get paused, and I'll be getting alerts for all sensors on that device.

Yes this would be the case. If the VM's are dependent on another device's ping and the VM goes down, the other sensors on the VM would all report a failure. What you could do is to INDIVIDUALLY set the other sensors on the VM to be reliant on the ping for the VM then set the ping to be dependent on the Host's Ping, you just CAN'T SET THIS AT THE DEVICE LEVEL.

"The other way that you could do this would be to setup a separate host with the VMware Virtual Machine (SOAP) sensor and set up a ping on that device that would then be the master object and would put the VM's into a pause state if it went down."

- This seems like a good idea, but my experience with VM sensors is that they take a lot of resources in terms of CPU/memory usage, and I would like to use this option only as a last resort, since we're already using almost 2400 sensors.

If you create the host as a device then monitor the VM's through the host using a VMware Virtual Machine (SOAP) sensor, you would only have 1 sensor per VM but these sensors would not provide the same information as you would see from monitoring the VM's seperately.

Thanks Greg. I was hoping to avoid setting the dependency for each sensor of the device individually, but it seems this is the only way.

Is PRTG planning to rectify this in further versions (i'm currently using PRTG Network Monitor 13.2.3.2135), unless there's a specific reason to prevent this cascading dependency check. I'd think it would be a powerful feature that would save a lot of time, not to mention not having to remember to set this every time a new sensor was added to that device.

Since more often than not devices that are set up in PRTG are not reliant on other devices as in your case with the VM's this is not a change that we plan to make. With most devices, they are self reliant and when the ping goes down, the device is down.

As virtualization becomes more prevalent, it's possible that we will change this behavior but right now this setup is not common enough for us to change the way the dependencies are structured.