Hello,
When we work on ESXi servers that are in Maint.mode (done via vCenter), our vROPS 6.1 still creates alerts because we remove a physical NIC uplink for example. I'd actually expect vROPS to be totally silent about an ESXi server until we take it out of maintenance mode, but nope, it still generates alerts. Why?
Is this expected behaviour7by design or am I doing something wrong ?
If this is by design, would it help if I put the "host object" of that ESXi server inside vROPS (Inventory explorer etc.) in "vROPS maintenance mode". Does that shut up vROPS ?
Regardless, I really expect vROPS to be so clever as to simply ignore all the horrible things we do to an ESXi server in maintenance mode, until it is taken back into production.
In other words, It should be "vCenter maintenance mode = vROPS maintenance mode" so to say.
Example: we removed an Uplink from a dvSwitch and gave it to another dvSwitch while the host was in Maint.mode (via vCenter). Still, we get these kind of alerts.
_____________________________________________________________________________
Info:esxbs008.domain.local HostSystem is acting abnormally since Tue Oct 11 14:27:47 CEST 2016 and was last updated at Tue Oct 11 14:27:47 CEST 2016
Alert Definition Name: The host has lost redundant connectivity to a dvPort
Alert Definition Description: One or more portgroups in the host have lost the last redundant connectivity to the dvPort. The current working connection is a single point of failure for the reported port groups and might cause the services associated with the affected port groups to become unavailable.
Object Name : esxbs008.domain.local
Object Type : HostSystem
Alert Impact: health
Alert State : immediate
Alert Type : Network
Alert Sub-Type : Availability
Object Health State: immediate
Object Risk State: info
Object Efficiency State: info
Control State: Open
_____________________________________________________________________________
KInd regards,
Steven
This is the expected behavior. You can disable alerts for hosts in maintenance by using a custom group and policy. Create a custom group with the membership criteria set to include only hosts in maintenance:
Create a new policy off your default policy and disable all of the host alerts. Assign this policy to the group for hosts in maintenance. This should disable any host alerts while the host is in maintenance and move the host back to your default policy when it exits maintenance.
Putting the host object in vROps in maintenance mode will also stop the alerts, but I don't think it's as simple to automate. Alan has some nice functions in PowerCLI.
http://www.virtu-al.net/2016/08/10/working-maintenance-mode-vrops-via-powercli/
You'd have to call this from vCenter or vRO when the hosts enter and exit maintenance mode.
I did this the opposite way but both would work
I created several groups ( Production ESXi hosts, Non production ESXi Host) and so on And my group membership rules include a statement that the host must not be in maintenance mode. When we put a host into maintenance mode they drop out of the different policies assigned to the different groups into the default policy that does not alert.
Either way will work depending on how you use policies. My way works for me as i have 4 different policies for different environments that have different capacity thresholds and alerting. If you have one policy (default) then dtaliafe reply works great as you only need to create a sub policy off the default and assign to one group
Today, when vCenter places a host in maintenance mode, there is no connection to tell vROps that the host should be in maintenance mode there too. To showcase the versatility of vROps, here is yet another approach to maintenance mode.
Maintenance Mode in vRealize Operations - VMware Cloud Management
This blog explains two ways for utilizing maintence mode:
This solution, although appealing, it's not really useful to us because it only refreshes the hosts inside the custom group every 20 mins. So, by the time, vRops puts my host in this custom group, the maintenance will be probably over, or underway, and the alarms are already being notified to other team members.