This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

hyper-v polling's side effects

Apparently enabling Hyper-V polling has a side effect of kicking the node out of a dynamically queried group and changing the way the node behaves and is managed in Solarwinds.

For instance, you can't edit node properties from the node page. It no longer being a member of a group affects the group's health status as well: the node can be down, the group still up.

Perhaps SW developers were thinking of VMWare when they were baking Hyper-V polling. Virtualization is the only thing VMWare does. Hyper-V: nuh-uh. I can quietly run a bunch of test VMs on a side in Hyper-V with other roles and apps still being mission critical. So perhaps re-think that a little bit? Until then, no Hyper-V management for me.

  • Hi akhasheni,

    Can you please post a screenshot of what you're seeing? I am able to "Edit Node" from the Hyper-V server's page. Also, can you elaborate on how your dynamic group was setup? The only thing I can think of is that the "Machine Type" value changed? If so, you can add "Machine Type"==Hyper-V to your Dyanmic Group to re-add it to your group.

  • Hi Balki 1429.

    Here is my node. Hyper-V polling not yet enabled. "Edit Node" is there.

    Screen Shot 2014-07-16 at 9.40.02 PM.png

    I do "List Resources", select "Hyper-V", and end up on "Virtualization Summary -> Hyper-V Host Details" now instead of "Node Details":

    Screen Shot 2014-07-16 at 9.48.20 PM.png

    I don't see "Edit Node" here any more, and can't get to it from "find node":

    Screen Shot 2014-07-16 at 9.49.56 PM.png

    Clicking on the node in the view above gets me to the same "Hyper-V Node Details" view.

    To sum up my experience thus far with enabling "Hyper-V Polling":

    1. Changes the default view of the node to "Hyper-V Node Details" as if Hyper-V was its only function now, rather than just a role. Unexpected and undesired behavior.
    2. Changes "machine type" as if... see (1), with unexpected and undesired results, such as breaking existing monitoring, logging and alerting - as it did in my case. That's potentially catastrophic if you unexpectedly lose alerts for something mission-critical just because you enabled a Hyper-V role and Hyper-V polling in Solarwinds.
    3. "List Resources", like "Edit Node" is no longer available in this view, i.e. one can't go back the same way one came. I enabled "Hyper-V polling" by using "List Resources", and now I have to dig into docs and google around to figure out how to disable it - as "List Resources" is nowhere to be found. This is unexpected, undesired and ... annoying, especially for someone new to SW (that'd be me).
  • Actually "Edit Node" and "List Resources" are there on the page in the "management" section, they just got pushed down outside of the viewable part of the UI (my monitor is 1680x1050 and the browser window - about 90% of that vertically). I.e. not visible. I know, would have found them if I just searched the page, but didn't occur to me at the moment.

    It's still befuddling: why would you dramatically alter the layout and UI elements of the page just because one added Hyper-V polling? Many VMWare Hypervisors (Fusion, Player, Workstation) are similar to Hyper-V roles: they do not change machine types logically or physically in the real world. Why does Solarwinds?

    Screen Shot 2014-07-16 at 10.08.04 PM.png

  • We did it that way based primarily on how other users told us they use Hyper-V and want to see it inside of SolarWinds. Given conversations with end users, I don't believe that the majority of customers are using Hyper-V this way; however, I can understand how this presentation might be confusing given your mixed use of your Hyper-V machines. If you want, you can drag the Management and Host Details resources back to the top of your view.

    So let me ask you this: If you could wave a magic wand and see your Hyper-V Hosts in an ideal view, what would that look like? Why? What are the primary use cases you are trying to solve with monitoring of your Hyper-V environment and how best could we represent that?

  • I don't have a wish list or ideas on how the management should look like, except that it doesn't mess with my existing monitoring, group membership, alerts - at least not without a clear warning. emoticons_happy.png

    I understand user wishes and desires, yet there is also this fairly standard rule: if any newly added functionality breaks existing one, warn the user. And I don't mean in a blog or release notes. It has to be in the UI, any time there's a possibility of a break.

  • These are completely different node detail pages - while I agree 100% on consistency across the UI- it's up to us to manage page views by machinetype anyway we want.

    Try adding Hyper-V resources to your normal node detail view, go to settings, custom views by node type and change for hyper-v to the standard view. Now you should have a unified view where everything you change or add looks the same for hyper-v.

  • Try adding Hyper-V resources to your normal node detail view, go to settings, custom views by node type and change for hyper-v to the standard view. Now you should have a unified view where everything you change or add looks the same for hyper-v.


    That's a good tip, thank you - gives me some ideas on how to adjust our SW settings.


    Other than that: I am a rookie and an unexpected view change threw me off, where for a user with a modicum of experience it's a non-issue. Agreed.


    That's the minor part though. The bigger one - the unexpected (for me) change of machine_type that breaks alerting and grouping. Is it fully expected for everyone else? Why? Again, from rookie's perspective: a role is just a role, it doesn't change the hardware or its core functionality. The system remains primarily a Windows Server system, and how big the Hyper-V part of it is - would user's choice, not Solarwinds'. Is that the wrong approach?


    Then there's the breaking part, the fact that the machine_type change breaks alerts, grouping and monitors that rely on it. How would a rookie (or any user who never dealt with SW approach to virtualization) know the machine_type would change?

  • I agree about more documentation around machinetypes. However I have found as I learned more about them that having more nuanced machinetypes is always preferred. So for me I would prefer a hyper-v and VMWare machinetype.

    This is not an easy method but you could set up a SQL UX monitor to query the Orion DB for machinetypes not in your list- then you would get a SAM alert anytime new ones are imported.

    Thanks,

    Christian