@victor said in Monitoring Hyper-V cluster on Windows Server 2008 R2 Enterprise ed.:
@jmp_3f8h said in Monitoring Hyper-V cluster on Windows Server 2008 R2 Enterprise ed.:
I forgot to mention that in this scenario the event source for the alarm should be the container and not a specific node. But I don't know if promoting a container to source for alamr has other side effects.
This can cause some side effects. For example, now you have $node variable in filtering scripts in event processing policy. If container and/or cluster objects can be event sources as well, you will have to check with what object class you are dealing with before accessing object properties for example. It will be quite complicated change, mostly because lot of places in the code will need to be checked.
Best regards,
Victor
I was thinking about a $container to be checked for events generated by those objects. Probably a superclass object $some_entity extended by $node and $container can be substituted to the current $node in most of the places. But even without considering the implementation effects (heavy, as far as I understood), the real problem is that I'm not totally convinced that a similar approach can be 100% semantically correct.
Marco
PS May be my comments are totally foolish since I don't know how it is currently implemented. Sorry in advance!