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.
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.
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 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".
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.
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.
"Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light. Total Protonic Reversal."
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.