2 Replies Latest reply on Oct 29, 2008 10:01 PM by Malcolm Stewart

    Bug in List of Virtual Machines detach resource

    Malcolm Stewart

      Found a possible bug in the URLs asociated with the List of Virtual Machines displayed on the ESX Server Details view.


      Where the guest server name is diplayed and link to click through appears (very nice), the URL is in the form:
      http://orionserver:8787/Orion/NetPerfMon/NodeDetails.aspx?NetObject=N:52


      If you click the List of Virtual Machines heading to detach the resouce and view in a new window the link for that same server becomes:
      http://orionserver:8787/Orion/NodeDetails.aspx?NetObject=N:52    ie; /NetPerfmon is missing from the URL, with the resulting error message when clicking on the link:


      Orion Website Error
      An error has occurred with the Orion website.


      Additional Information
      System.Web.HttpException: The file '/Orion/NodeDetails.aspx' does not exist.
         at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath)
         at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
         at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
         at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
         at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
         at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
         at System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
         at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)
         at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
         at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


       


      FYI other interesting behavior in this resource:
      Where a guest servername appears that is only monitored by ICMP because SNMP is not yet configured on the server (and no green LED so it's obvious), clicking the displayed servername link prompts Do you want to manage SERVERNAME with Orion?  I have not followed through with this dialog in case it screws up some existing config.  I note too that the ICMP monitored server IP address is not known or not found and would reply on DNS resolution of the name to continue.
      How is the resource checking the found VM guests against the nodes already known to orion?


      In the attached screen screenshot, servers x03, x04, xVM1 are snmp managed. Servers x34 and x40 are icmp pinged only.


      The Not Running servers are also offered to be managed. I can't imagine what happens there.


      Evaluating version 9.1 so cannot open a support ticket.


      cheers
      stewie

        • Re: Bug in List of Virtual Machines detach resource
          Karlo.Zatylny

          Hi,


          Thanks for these observations.  I will look into your first issue tomorrow with my testing team to see if we can duplicate it and will put the fix in SP2 (SP1 should be coming out soon).


          Moreover, nothing spectacular happens when you try to manage a server that is not running.  You are first taken to the Add Node page with the server name automatically populated.  Orion simply tries to resolve the name with DNS and then tries to ping the IP and then tries to contact it via SNMP (if requested to do so).  If any of these steps fail, then just tells you so.


          For your servers that do not have SNMP enabled yet, the best thing to do is enable it, manage those nodes and add the SNMP information and then the next polling cycle, your VM list will be updated properly (if that is indeed what you want to do).


          The ESX server tells us the MAC address of each VM.  We compare this to the interface list that we have of managed nodes and make the connection.  Thus you don't see the green LEDs on ICMP only boxes, since we don't know their MAC address and can't make the connection.


          Thanks for evaluating our product.  The ESX monitoring is new this release and has a couple kinks, but SP1 will address most of them and will be available soon.