This section explains how to troubleshoot a registered managed server whose status is "unknown" even though the managed server is still running.
When errors or warning messages are displayed in the event log, take the appropriate action referring to the "Messages". Check the following points and resolve the cause of any problems:
Communication between the admin server and the server management unit is not possible
Check if it is possible to connect to either the Web or the telnet interface of the server management unit (management blade or remote management controller).
Communication between the admin server and the managed server is not possible
Check that the admin LAN IP address is correctly set on the managed server.
Check LAN switch blade configurations to confirm that the same VLAN ID or the same port group (for switch blades operating in IBP mode) is set for the ports used by the managed server and the admin server on the admin LAN.
When using PRIMERGY BX600 servers and changing the VLAN ID used for the admin LAN, proceed as follows to preserve communication from the admin server to the LAN switch blade. First, change the VLAN ID set for the admin LAN port (on the LAN switch blade) connected to the admin server, as well as the VLAN ID set for the switch blade's own network interface. Then, change the VLAN ID for the admin LAN port connected to the managed server.
For the overview and the setup of the VLAN for the managed server, refer to "7.1 Network Configuration" in the "Design Guide VE" and "9.1.8 Changing the VLAN Settings of LAN Switch Blades" in the "User's Guide VE".
Communication is not allowed for the ports used by Resource Orchestrator
Allow communication for the ports described in "Appendix A Port List" in the "Design Guide VE".
The Resource Orchestrator agent is not running
Make sure that the agent is running on the managed server.
ServerView Agents is not running
For PRIMERGY servers, check whether ServerView Agents is running properly on the managed server.
[Windows] [Hyper-V]
From the Windows Control Panel, open "Administrative Tools" and then open the [Services] window. Check that the status of the Server Control Service and SNMP Service is shown as "Started".
[Linux] [VMware] [Xen] [KVM]
Execute the following commands to check if the ServerView Agents service is running.
# /etc/init.d/srvmagt status <RETURN> |
The above commands are not available if ServerView Agents is not installed. If they are not available, install ServerView Agent on the managed server.
If ServerView Agents is not running, refer to the ServerView Agent manual for how to start the ServerView Agents.
SNMP community settings are incorrect
Make sure that the SNMP community settings on the management blade, management board, and managed server match those set in Resource Orchestrator during chassis and server registration.
Hardware properties were not reconfigured after replacing the server
Identify the MAC address of the replacement server, and check if it is the same address as that set for the admin LAN (MAC address) in the [Resource Details] tab of the ROR console.
If the MAC address is different, reconfigure the hardware properties from the ROR console.
No information could be obtained from the server virtualization software running on the managed server
In environments where no VM management software was registered, or for VM hosts that are not managed by VM management software, the status of a VM guest is displayed as "unknown" if its information could not be obtained from the server virtualization software used to run that VM guest. Check whether the server virtualization software is operating correctly.
If it is operating correctly, its account information (user account name and password) may have changed. As a result, the settings no longer correspond to those registered in Resource Orchestrator. In that case, change the virtualization software's account settings registered in Resource Orchestrator.
Refer to "9.1.7 Changing VM Host Login Account Information" in the "User's Guide VE" for details.
No information could be obtained from VM management software
In environments where VM management software was registered, the status of a VM guest (on a VM host managed by this VM management software) is displayed as "unknown" if its information could not be obtained from the VM management software. Check whether the VM management software is operating correctly.
If it is operating correctly, its account information (user account name and password) may have changed. As a result, the settings no longer correspond to those registered in Resource Orchestrator. In that case, change the VM management software's account settings registered in Resource Orchestrator.
For details, refer to "9.6 Changing VM Management Software Settings" in the "User's Guide VE".
The remote management controller's IP address, user name, or password was changed after server registration
Change the IP address, user name and password settings registered for this remote management controller in Resource Orchestrator.
Refer to "9.1.5 Changing Server Management Unit Configuration Settings" in the "User's Guide VE" for details.
The remote server management IP address, user name, or password was changed after server registration
Change the IP address for remote server management, user name, and password settings registered in Resource Orchestrator.
Refer to "9.1 Changing Chassis and Managed Server Settings" in the "User's Guide VE" for details.
High load on the admin server, server management unit, or managed server
Resource statuses may be temporarily shown as "unknown".
Power control of partitions has been performed on PRIMEQUEST
Resource statuses may be temporarily shown as "unknown".
The chassis has been powered off on PRIMEQUEST
The statuses of the target chassis and servers are all shown as "unknown".
The routing settings of the router are not correctly configured
When using an admin server to manage managed servers belonging to other subnets, configure the router settings.
For details, refer to "7.6 Configuring the Network Environment" in the "Design Guide VE".
When even though the chassis is powered on, and the network connection has no errors, the unknown status continues
[Linux]
Collect and send the result (output) of the following command.
In ${COMMUNITY}, enter the management blade community name, and in ${MMB_IP}, enter the management blade IP address.
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.3.5.1
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.3.1.5
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.1.1.1.5
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.3.1.7
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.3.2.3
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.3.1.6
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.1.1
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.2.1.1.11
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.2.1.1.10
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.1.5
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.10.1.1.11
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.2.1.1.6
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.2.1.1.7
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.2.1.1.22
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.2.1.1.2
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.2.1.1.1
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.1.1.1.7
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.3.1.1.3
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.3.1.1.4
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.3.1.1.6
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.4.2.1.4
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.7.1.1.2
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.7.1.1.4
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.7.1.1.3
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.7.1.1.5
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.4.7.1.1.6
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.13.1.1.5
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.13.1.1.6
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.13.1.1.12
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.13.2.1.1
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.13.2.1.2
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.5.1.1.2
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.5.1.1.5
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.5.1.1.6
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.5.1.1.7
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.5.1.1.10
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.5.1.1.11
snmpwalk -v 1 -c ${COMMUNITY} ${MMB_IP} .1.3.6.1.4.1.7244.1.1.1.5.1.1.9 |
