3rd party HA tools such as DxEnterprise allow for failover of a virtual host (VHOST) from one Server (virtual or physical) to another in the event something happens to the VHOST. In the failover process, it will pull all of the associated disks along with the VHOST to the new machine it is going to be hosted on. If RedGate SQL Monitor is configured to monitor the physical server, things work well until you need to fail over. Then you get alerts of disk changing from 20% free to 0 bytes free and the failed-over SQL instance(s) are no longer being monitored.
The alternate configuration is to set up redgate to monitor the VHOST. This works a lot better for monitoring the SQL instance after failover, but results in disk drives and SQL instances appearing in duplicate when more than 1 VHOST exists on a server. For example, if we have our reporting instance on VHOST reports and our SSIS on VHOST ssis both hosted on physical machine PM1 and we notice that the report server is using up a lot of memory and causing delayed with SSIS package execution, we may choose to fail ssis over during the busy reporting times to PM2. SQL Monitor will freak out if we do that though telling us that ALL of the VHOSTS on PM1 suddenly lost the associated disk for that and we will get alerts that are not valid.
While we could turn off the low disk alerts, having them off means we won't get ANY low disk alerts which is a problem as well.
The other problem is if ssis and reports are both on PM1 and ssis has a 20 GB S drive, because both vhosts have the same drive letter and GUID, the SQL Monitor reports show that the S drive has 40 GB which is not accurate.
I am not sure of a good solution to supporting a tool like DxEnterprise would be, but my initial thoughts are to have the configuration for the disk monitoring and instance monitoring be more configurable and selective. For example, I may only want to monitor disk S on ssis but not monitor disk S on reports. And some disks I don't want to monitor at all as they are managed by the IT department (C drive, page file drive, etc).

The short version of this suggestion is to have more user control over what SQL Monitor monitors.