We have onCommand Balance v184.108.40.206 running in our lab and correctly monitoring physical servers and linux virtual machine guests but we are unable to monitor windows virtual machine running on the same vmware cluster despite having deployed the Balance proxy and making sure from the web Gui that nslookup is correctly resolving fqdn/ip of the virtual Windows guests.
We tried with different domain credentials and local accounts but still have error message : "server unreachable" and "unkown error".
We tried rediscovering virtual machine from the virtual center (vsphere 5.1) in Balance GUI but we the errors are still here.
Any help would be appreciated.
I don't know the cause of the issue off-hand, but have you tried searching the Knowledge base on the Support site - support.netapp.com? I know there are a lot of articles on troubleshooting collection issues.
I did check the knowledge base but was unable to find a specific KB related to my issue. Name resolution seems ok from the balance appliance and from the proxy.
Are the VMware tools installed? Also, what O/S platform. Windows 2k8, unix (linux, redhat solaris, AIX? ) kernal version (2.6 etc )
How Many Virtual centers are monitored? Did you successfully Discover the vcenter(s) Do the VM's show up under "unmonitored servers" list?
OCI S&A team
We have the vmware tools running inside the windows guest virtual machines. We are able to monitor, inside balance, Linux guest virtual machines (Suse and RedHat) running on the same VMware cluster. We have only one vCenter (v5.1) monitored inside Balance, the discovery went fine and we see virtual machines managed by the vCenter under "unmonitored servers".
Most likely this is related to a change in guest monitoring, made back in a 4.1 update. If you have any port filtering, or port 135 on the guests is closed, monitoring does not work fir those guests.
A not very good workaround is to open up port 135 on Windows (which exposes the Windows guest to other vulnerabilities). Or you can wait until Balance 4.1.1 is available on or out about August 16, we have re-engineered guest discovery to be more robust in the face of closed ports on the guest.
We don't have have any port filtering blocking access to the virtual guest on port 135 (no firewall in between or inside the host). I am able to telnet this port correctly.
Here is the extract of the jetty-service log on the Balance proxy showing an error :
INFO | jvm 1 | 2013/07/31 10:12:05 | 151167375 [btpool0-31] ERROR com.akorri.bp.collectionserver.communication.WMI - Proxy Output File Access Error occurred whilst executing command: cscript//nologo//t:900C:/Program Files (x86)/NetApp/Balance/work/collection-server/code/scripts/windows/WmiToXml.vbs. Description: Unable to determine IP address for Hostname/FQDN.
INFO | jvm 1 | 2013/07/31 10:12:05 | 151167407 [btpool0-31] WARN org.springframework.remoting.support.RemoteInvocationTraceInterceptor - Processing of HttpInvokerServiceExporter remote call resulted in fatal exception: com.akorri.bp.collectionserver.proxy.IProxyService.runCommands
INFO | jvm 1 | 2013/07/31 10:12:05 | com.akorri.bp.collectionserver.exception.DeviceCommException: Proxy Output File Access Error occurred whilst executing command: cscript//nologo//t:900C:/Program Files (x86)/NetApp/Balance/work/collection-server/code/scripts/windows/WmiToXml.vbs.
As a sidenote, the Balance proxy is correctly resolving IP address and able to ping the guest virtual machines.
Did you find a resolution? i have the exact same Errormessages on two different Customer sites.
What I don't understand is that I have installed the same Balance version 2 weeks ago and it worked just out of the box.
These errors are from WScript.Echo statements in WmiToXml.vbs. There is additional information logged to the collection log file for the Windows server that would give us the specific WMI error code.
Balance checks the server name to see if an IP or FQDN was used. If FQDN, it checks the output of "ping -n 1 -4 FQDN" to see if it can resolve the FQDN to an IP address. We specifically look for the phrase "Pinging FQDN [w.x.y.z]" and use a regular expression to pick out the IP address.
We then attempt to open a connection to the "root\cimv2" namespace using the (hopefully) IP address, username and password. Can you check the output of "ping -n 1 -4 FQDN" and report back whether or not the response matches the format above? We have found that WMI can be problematic when connecting using an FQDN instead of an IP address.
In my case, the output of the ping command looks good.
ping -n 1 -4 xyz.abc.de
Ping wird ausgeführt für xyz.abc.de [172.16.xx.xx] mit 32 Bytes Daten
Antwort von 172.16.xx.xx: Bytes=32 Zeit<1ms TTL=128
Ping-Statistik für 172.16.xx.xx:
Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
I see, the issue here then is that the output is in German and not in English. We could relax the regular expression to look for a phrase beginning with the letters "Ping" followed by some number of characters followed by [w.x.y.z] to get around this.
I have the same errormessages.
After the upgrade to Version 4.1.1, unfortunaly the Error still persists.
I altough tried to use dieffrent proxies to add the "Guest". With the same result.
Do you have any suggestions?
If needed i can provid further Infromations.
Please open a support case to get to the root cause of this problem. In general, Balance should have enough information to either 1) no fail, or 2) give you guidance on how to fix any configuration issues to resolve the problem.
Thanks for your patience.
I have resolved my issue.
At my Customer Site the host on which the balance proxy was installed is also the vcenter host.
When the vSphere WebClient is installed on the server it uses Port 9443 which is the same port that the balance proxy is using.
changing the port on the balance proxy setup resolved my issue.
Thanks for the replies.
I although changed the Port to 9999. But with no success.
We use a dedicated VM for proxy. I opened a Case at Netapp Support.
We are not able to add the Server manually, as long we use the FQN.
When we use the IP, everythings works like charm. Unfortunaly it is not recommended to add VMs manually.
The ping, nslookup and tracert tests were all successfull from the onbalance VA and from the Proxy.
Unfortunaly it is not recommended to add VMs manually.
There's something very important I forgot to tell you. Do not manually add VMs to Balance; it would be bad, like crossing the steams1. It will seem to work, then completely confound Balance, as it thinks the VM is a physical sever, not a VM. It will look like it is working, yet no analysis will run, because the topology is incorrect.
Important Safety Tip:
Adding VMs through vCenter discovery is the proper method.