This section explains the 691XX message series.
Description
SNMP trap transmission failed.
The communication destination of the SNMP trap is displayed for host.
The SNMP trap transmission failure indicated by this message does not affect the event operation or its results.
For details of the event that is the target of the SNMP trap, refer to "A.2 Sending SNMP Traps" in the "Setup Guide VE".
Corrective Action
Refer to "A.2 Sending SNMP Traps" in the "Setup Guide VE", and check if there is a problem with the SNMP trap sending settings.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
[Virtual Edition]
Description
An error occurred during communication with the target target.
Corrective Action
When target is the admin IP address of the admin server, take the following corrective actions depending on the content of detail.
"configuration error"
For the correction method, refer to the corrective action of "Message number 67350".
"SSL certification error"
For the correction method, refer to the corrective action of "Message number 67351".
"connection timeout"
For the correction method, refer to the corrective action of "Message number 67352".
"read timeout"
For the correction method, refer to the corrective action of "Message number 67353".
"write timeout"
For the correction method, refer to the corrective action of "Message number 67354".
"connection error"
For the correction method, refer to the corrective action of "Message number 67355".
"no route to host"
For the correction method, refer to the corrective action of "Message number 67356".
"IO error"
For the correction method, refer to the corrective action of "Message number 67357".
"internal error"
For the correction method, refer to the corrective action of "Message number 67358".
When target is the IP address of a server management unit, take the following corrective actions depending on the content of detail.
"snmp communication error"
Use the following methods to check if SNMP communication with the server management unit is possible.
Use the ping command or another method to check if there is a problem with the network environment between the admin server and the server management unit.
If a cable is disconnected from the LAN connector, connect it.
Check whether connection to the admin UI of the server management unit (In the case of the PRIMERGY BX series, the Web UI or telnet) is possible.
Check that the SNMP community name set in the management blade has not been changed from the value specified in chassis registration.
Check that the values of the IP address, user name, and password set for the Remote Management Controller when registering the managed server have not been changed from their original values.
Check that Write (reference and updating) authority is possessed for the SNMP setting of the management blade.
Check the SNMP community name set from the ROR console.
If it was omitted, "public" will be specified.
Check that the server management unit of the managed server has Write (reference and updating) authority for the SNMP community name specified.
If the SNMP community name does not have Write (reference and updating) authority, change the authority settings.
For details of checks and the setup method, refer to the manual of the server being used.
When target is the IP address of a power monitoring device, take the following corrective actions depending on the content of detail.
"snmp communication error"
Use the following methods to check if SNMP communication with the power monitoring device is possible.
Check if there is a problem with the network environment between the admin server and the power monitoring device using the ping command or another method.
If a cable is disconnected from the LAN connector, connect it.
Check that connection to the power monitoring device is possible using Web UI or telnet.
Check that the SNMP community name set in the power monitoring device has not been changed from the value specified during registration.
Check that Read (reference) authority is possessed for the SNMP setting of the power monitoring device.
Check the SNMP community name set from the ROR console.
If it was omitted, "public" will be specified.
For details of checks and the setup method, refer to the manual of the power monitoring device.
"ping timeout"
Timeout has occurred during ping monitoring of the server target.
As the recovery process is performed automatically based on the configured monitoring information, there is no need to take corrective action.
For the method of configuring monitoring information, refer to "Chapter 8 Configuring Monitoring Information" in the "Setup Guide VE".
If the problem is still not resolved after performing the above actions, collect the corresponding message and troubleshooting data, and contact Fujitsu technical staff.
[Cloud Edition]
Description
An error occurred during communication with the target target.
Corrective Action
Perform the following corrective action depending on the value of target.
When target is the admin IP address of the admin server
Take the following corrective action for the content displayed for detail.
"configuration error"
For the correction method, refer to the corrective action of "Message number 67350".
"SSL certification error"
For the correction method, refer to the corrective action of "Message number 67351".
"connection timeout"
For the correction method, refer to the corrective action of "Message number 67352".
"read timeout"
For the correction method, refer to the corrective action of "Message number 67353".
"write timeout"
For the correction method, refer to the corrective action of "Message number 67354".
"connection error"
For the correction method, refer to the corrective action of "Message number 67355".
"no route to host"
For the correction method, refer to the corrective action of "Message number 67356".
"IO error"
For the correction method, refer to the corrective action of "Message number 67357".
"internal error"
For the correction method, refer to the corrective action of "Message number 67358".
When target is the IP address of a server management unit
Take the following corrective action for the content displayed for detail.
"snmp communication error"
Use the following methods to check if SNMP communication with the server management unit is possible.
Use the ping command or another method to check if there is a problem with the network environment between the admin server and the server management unit.
If a cable is disconnected from the LAN connector, connect it.
Check whether connection to the admin UI of the server management unit (In the case of the PRIMERGY BX series, the Web UI or telnet) is possible.
Check that the SNMP community name set in the management blade has not been changed from the value specified in chassis registration.
Check that the values of the IP address, user name, and password set for the Remote Management Controller when registering the managed server have not been changed from their original values.
Check that Write (reference and updating) authority is possessed for the SNMP setting of the management blade.
Check the SNMP community name set from the ROR console. If it was omitted, "public" will be specified.
Check that the server management unit of the managed server has Write (reference and updating) authority for the SNMP community name specified. If the SNMP community name does not have Write (reference and updating) authority, change the authority settings.
For details of checks and the setup method, refer to the manual of the server being used.
If the IP address of VM management software is displayed:
Check whether communication with the VM management software is possible.
Use a ping command, etc. to check whether there is a problem with the network environment between the admin server and the VM management software.
If a LAN cable has become disconnected, reconnect it.
If the VM management product has VM management software, check whether there is a problem with connecting to the VM management product from the VM management software.
If the IP address of VM management software is displayed:
Perform the following corrective action depending on the value of detail.
For "VMware vCenter Server communication error(Virtual_storage_resource_name)"
Check the status of the virtual storage resources registered in the storage pool.
When the status is something other than "unknown", corrective action is not necessary as a communication error has occurred but recovery is complete.
When the status is "unknown", update virtual storage resources.
If the status does not change, perform the following corrective action:
Check that "VMware vCenter Server" is operating correctly on the IP address output for target.
For details on the check method, refer to the manual of the "VMware vCenter Server".
Check that communication is possible with the IP address output for target.
For the recovery procedure, refer to "Message number 67192".
If a huge amount of these messages is output to the event log and makes it difficult to find the other messages, perform the following action:
Obtain the span of time when these messages were output.
The messages are output at about three-minute intervals for the number of virtual storage that are shown on the storage tree.
Each page of event logs has ten items. With this in mind, you can reach to the span of time quicker by specifying appropriate page number.
Retrieve the messages that were output during the span of time which was obtained by step 1. from the system logs and the event logs of ROR console.
The system logs do not contain all messages.
Refer to "Appendix A System Log Messages" to check which kind of messages are output.
Up to the latest 20,000 messages are stored in the ROR console event log.
a) System log
Select the messages of the product that are output during the span of time which was obtained by step 1. The messages of this product can be identified by event types of "application" and source names that start with "JSE_SWRC_FJSVRCX".
b) Event log of the ROR console
Display the event logs whose status are "Error" only.
Sort the logs by event ID.
Make a rough estimate of the number of messages that were output by dividing the span of time which is retrieved by step 1. by three minutes. Also make a rough estimate of the number of pages which contain messages other than this message.
Lastly, extract messages other than this message which were output during the span of time which was retrieved in step 1.
For "VMware vCenter Server communication error"
Check that VMware vCenter Server is operating correctly on the IP address output for target.
For details on the check and configuration method, refer to the VMware vCenter Server manual.
Check that communication is possible with the IP address output for target.
For the recovery procedure, refer to "Message number 67192".
For "System Center Virtual Machine Manager communication error(Virtual_storage_resource_name)"
Check the status of the virtual storage resources registered in the storage pool.
When the status is something other than "unknown", corrective action is not necessary as a communication error has occurred but recovery is complete.
When the status is "unknown", update virtual storage resources. If the status does not change, take the following corrective action.
Check that SCVMM is operating correctly on the IP address output for target.
For details on the check method, refer to the SCVMM manual.
Check that communication is possible with the IP address output for target.
For the recovery procedure, refer to "Message number 67192".
For "System Center Virtual Machine Manager communication error"
Perform the following corrective actions:
Check that SCVMM is operating correctly on the IP address output for target.
For details on the check method, refer to the SCVMM manual.
Check that communication is possible with the IP address output for target.
For the recovery procedure, refer to "Message number 67192".
For "Oracle VM Manager communication error(Virtual_storage_resource_name)"
Check the status of the virtual storage resources registered in the storage pool.
When the status is something other than "unknown", corrective action is not necessary as a communication error has occurred but recovery is complete.
When the status is "unknown", update virtual storage resources.
If the status does not change, perform the following corrective action:
Check that Oracle VM Manager is operating correctly on the IP address output for target.
For details on the check and configuration method, refer to the Oracle VM Manager manual.
Check that communication is possible with the IP address output for target.
For the recovery procedure, refer to "Message number 67192".
For "Oracle VM Manager communication error"
Check that Oracle VM Manager is operating correctly on the IP address output for target.
For details on the check and configuration method, refer to the Oracle VM Manager manual.
Check that communication is possible with the IP address output for target.
For the recovery procedure, refer to "Message number 67192".
If the IP address of storage management software is displayed:
Perform the following corrective actions:
The necessary settings for the storage management software may not have been completed. For details, refer to "D.3 Storage Environment Preparation" in the "Design Guide CE".
Check that communication is possible with the IP address output for target.
For the recovery procedure, refer to "Message number 67192".
When target is the IP address of a power monitoring device
Take the following corrective action for the content displayed for detail.
"snmp communication error"
Use the following methods to check if SNMP communication with the power monitoring device is possible.
Check if there is a problem with the network environment between the admin server and the power monitoring device using the ping command or another method.
If a cable is disconnected from the LAN connector, connect it.
Check that connection to the power monitoring device is possible using Web UI or telnet.
Check that the SNMP community name set in the power monitoring device has not been changed from the value specified during registration.
Check that Read (reference) authority is possessed for the SNMP setting of the power monitoring device.
Check the SNMP community name set from the ROR console. If it was omitted, "public" will be specified.
For details of checks and the setup method, refer to the manual of the power monitoring device.
"ping timeout"
Timeout has occurred during ping monitoring of the server target.
As the recovery process is performed automatically based on the configured monitoring information, there is no need to take corrective action.
For the method of configuring monitoring information, refer to "Chapter 8 Configuring Monitoring Information" in the "Setup Guide VE".
When target is the IP address of NS appliance or the physical L-Server on which NS appliance is deployed.
When the rcxnetworkservice setup command has not been executed
Restart after executing the rcxnetworkservice setup command.
When the rcxnetworkservice setup command has been executed
Confirm that there is no error in target login information.
When there are no errors in login information, confirm that the network configuration is one that allows communication between the manager and the physical L-Server corresponding to target or the NS Appliance.
If the problem is still not resolved after performing the above actions, collect the corresponding message and troubleshooting data, and contact Fujitsu technical staff.
Description
SNMP communication with target failed.
If the basic or registration information of the following hardware has been changed, the specified value may differ from the value set on the device.
Chassis
Managed servers
In cases other than the above, there are the following possibilities:
The SNMP community name settings are incorrect
The server is not powered on
The ServerView Agents have not been started
Corrective Action
If a chassis has been registered, check the following and take corrective action.
The SNMP community name settings of the chassis
Check that the SNMP community name specified matches the one set on the management board and managed servers.
If the basic information of the chassis or managed server has been changed, check the following and take corrective action.
If the chassis is powered on
Power on the chassis.
For how to check the power status and power on a chassis, refer to the manual of the server being used.
When the IP address of the chassis has been changed
Check that the specified IP address matches the one set on the management blade.
When the SNMP community name of the chassis has been changed
Check that the SNMP community name specified matches the one set for the management blade and managed servers.
When the IP address of a managed server has been changed
Check that the specified IP address matches the one set on the managed server.
In cases other than the above, check the following and take corrective action.
Network cable checks
How to Check
Check if the network cable between the admin server and the server management unit is correctly connected.
Corrective Action
If the network cable is damaged
Replace the cable.
If the network cable is connected incorrectly
Reconnect the cable.
Check the settings of network devices (e.g. LAN switch) being used
How to Check
Check that the duplex mode configurations of the admin LAN composed of the following admin server and managed servers are correct.
Between the NIC of the admin server and the switch port
Between the NIC of the server management unit and the switch port
Corrective Action
If the settings used for duplex mode configuration are incorrect, correct them.
For checks and setup of the admin LAN between the admin server and the server management unit, refer to the manuals of the OS and network switches being used.
Check the Network Environment
How to Check
Execute the ping command on the server where a manager is installed to check the network status.
Check if communication with the server management unit is possible.
[Windows Manager]
>ping the_IP_address_of_the_server_management_unit <RETURN> |
<Example: Normal communication>
Pinging ipaddr with 32 bytes of data: |
<Example: Abnormal communication>
Pinging ipaddr with 32 bytes of data: |
[Linux Manager]
# ping the_IP_address_of_the_server_management_unit <RETURN> |
<Example: Normal communication>
PING host name (ipaddr) 56(84) bytes of data. |
<Example: Abnormal communication>
PING host name (ipaddr) 56(84) bytes of data. |
Corrective Action
Check the following items:
For <Example: Normal communication>
"Port number checks"
For <Example: Abnormal communication>
"Network cable checks"
Port number checks
How to Check
Refer to "Appendix A Port List" in the "Design Guide VE" or "Design Guide CE", and check the port numbers of the admin server based on the following.
If port numbers are set
If the same port number or service name is being used
Corrective Action
If the port number is incorrect, change it to a suitable number.
For how to change port numbers, refer to the following:
For Virtual Edition, refer to "8.2 Changing Port Numbers" or "9.1.6 Changing Port Numbers" in the "User's Guide VE".
For Cloud Edition, refer to "6.2 Changing Port Numbers" or "7.1.6 Changing Port Numbers" in the "User's Guide for Infrastructure Administrators (Resource Management) CE".
Power status checks
How to Check
Check the power status of the managed server.
Corrective Action
If the status is OFF, power on the managed server.
ServerView Agents checks
How to Check
Check that the ServerView Agents of the managed server have been started.
Corrective Action
If they have not been started, refer to the ServerView Agents manual and start them.
SNMP service checks
How to Check
Check that the SNMP service of managed server has been started.
Corrective Action
If it has not been started, start SNMP service.
[Windows] [Hyper-V]
Log in to the managed server using OS administrator authority.
Open [Services] from [Administrative Tools] on the Windows Control Panel, and check that the status of the SNMP Service is "Started" on the [Services] window.
When the service is stopped, start the service.
[Linux] [VMware] [Xen]
Log in to the admin server using OS administrator authority.
Execute the following command, and check that the SNMP daemon is operating.
# /etc/init.d/snmpd status <RETURN> |
When SNMP daemon is stopped, execute the following command and start the daemon.
# /etc/init.d/snmpd start <RETURN> |
ServerView Agents SNMP community name checks
Check that the SNMP community name set for the ServerView Agents matches the one set in the management blade.
Server SNMP community name checks
Check that the SNMP community name specified during server registration matches the one set for the ServerView Agents.
Admin LAN IP address checks
Check that the admin LAN IP address specified during server registration matches the one that has been set on the managed server.
Write (reference and updating) checks
Check that Write (reference and updating) authority is possessed for the SNMP setting of the management blade.
Admin LAN network load checks
How to Check
Check the network load of the admin LAN.
The load may be high when image operations (such as backup and restoration of system images, or collection and deployment of cloning images) are being performed for other managed servers connected to the same admin LAN as the server management unit.
Corrective Action
After the process that is causing the high network load finishes, perform the operation again.
BIOS/firmware checks
How to Check
The BIOS/firmware of the managed server may not be the newest.
Corrective Action
Contact Fujitsu technical staff to obtain the newest BIOS/firmware for the managed server.
Admin server load checks
How to Check
Check if the load on the admin server is high.
Obtaining the power status may fail due to an increase in the load of the admin server.
Corrective Action
After completing any other high-load processes other than those of Resource Orchestrator, perform the operation again.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
Description
The managed server is a model for which LED operation cannot be performed.
Corrective Action
Refer to "2.5 Hardware Environment" in the "Design Guide VE" or "Design Guide CE", and check that the server meets the requirements.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
Description
A blade has not been mounted in slot slot_number.
Corrective Action
Mount a blade in the slot.
When a blade is mounted in the relevant slot, check the following:
If the MAC address of the blade is recognized correctly on the management blade Web UI
If the MAC address of the blade is not recognized correctly, mount the blade again, and power it on.
When slave slot information of multi-slot servers has been set in the system configuration file, has the file been imported
If slave slot information of multi-slot servers has been set in the system configuration file, delete the configuration information.
On differing types of servers, if hardware re-configuration has not been performed, or the blade type differs before and after replacing servers, delete the registered server, replace hardware and then perform server registration again.
If the blade type after server replacement differs that of before replacement, delete the registered server, replace the hardware and then perform server registration again.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
Description
Obtaining the information from the server management unit failed.
Corrective Action
Check whether communication with the server management unit is possible.
If the chassis is powered on
Power on the chassis.
For how to check the power status and power on a chassis, refer to the manual of the server being used.
Network cable checks
How to Check
Check if the network cable between the admin server and the server management unit is correctly connected.
Corrective Action
If the network cable is damaged
Replace the cable.
If the network cable is connected incorrectly
Reconnect the cable.
Server management unit connection checks
How to Check
Use the Web UI or telnet to check that connection to the server management unit is possible.
Corrective Action
Check that the SNMP community name set in the management blade has not been changed from the value specified in chassis registration.
Write (reference and updating) checks
Check that Write (reference and updating) authority is possessed for the SNMP setting of the management blade.
Check the type of the Remote Management Controller
Check if the type of the Remote Management Controller has been correctly specified.
Remote Management Controller IP address, user name, and password checks
Check that the values of the IP address, user name, and password set for the Remote Management Controller when registering the managed server have not been changed from their original values.
Also, check that the user of the Remote Management Controller has administrator authority.
Check the settings of network devices (e.g. LAN switch) being used
How to Check
Check that the duplex mode configurations of the admin LAN composed of the following admin server and managed servers are correct.
Between the NIC of the admin server and the switch port
Between the NIC of the server management unit and the switch port
Corrective Action
If the settings used for duplex mode configuration are incorrect, correct them.
For checks and setup of the admin LAN between the admin server and the server management unit, refer to the manuals of the OS and network switches being used.
Check the Network Environment
How to Check
Execute the ping command on the server where a manager is installed to check the network status.
Check if communication with the server management unit is possible.
[Windows Manager]
>ping the_IP_address_of_the_server_management_unit <RETURN> |
<Example: Normal communication>
Pinging ipaddr with 32 bytes of data: |
<Example: Abnormal communication>
Pinging ipaddr with 32 bytes of data: |
[Linux Manager]
# ping the_IP_address_of_the_server_management_unit <RETURN> |
<Example: Normal communication>
PING host name (ipaddr) 56(84) bytes of data. |
<Example: Abnormal communication>
PING host name (ipaddr) 56(84) bytes of data. |
Corrective Action
Check the following items:
For <Example: Normal communication>
"Port number checks"
For <Example: Abnormal communication>
"Network cable checks"
Port number checks
How to Check
Refer to "Appendix A Port List" in the "Design Guide VE" or "Design Guide CE", and check the port numbers of the admin server based on the following.
If port numbers are set
If the same port number or service name is being used
Corrective Action
If the port number is incorrect, change it to a suitable number.
For how to change port numbers, refer to the following:
For Virtual Edition, refer to "8.2 Changing Port Numbers" or "9.1.6 Changing Port Numbers" in the "User's Guide VE".
For Cloud Edition, refer to "6.2 Changing Port Numbers" or "7.1.6 Changing Port Numbers" in the "User's Guide for Infrastructure Administrators (Resource Management) CE".
Admin LAN network load checks
How to Check
Check the network load of the admin LAN.
The load may be high when image operations (such as backup and restoration of system images, or collection and deployment of cloning images) are being performed for other managed servers connected to the same admin LAN as the server management unit.
Corrective Action
After the process that is causing the high network load finishes, perform the operation again.
BIOS/firmware checks
How to Check
The BIOS/firmware of the managed server may not be the newest.
Corrective Action
Contact Fujitsu technical staff to obtain the newest BIOS/firmware for the managed server.
Admin server load checks
How to Check
Check if the load on the admin server is high.
Obtaining the power status may fail due to an increase in the load of the admin server.
Corrective Action
After completing any other high-load processes other than those of Resource Orchestrator, perform the operation again.
If this message is displayed during execution of any of the following operations, check that the specified IP address matches that of the server management unit.
Chassis registration
Changing of a chassis admin IP address
Chassis remote server management information checks
Managed server registration
Changing of a managed server's Remote Management Controller information
If no problems are found, a temporary loss of communication may have occurred due to rebooting of the server management unit, etc.
Wait for 2 or 3 minutes and then repeat the failed operation.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
Description
There is no server in the number of type.
Corrective Action
Take corrective action for the content displayed for type.
When type is "partition"
The number partition may have been deleted.
After configuring the number partition, perform the action again.
Description
The server may not exist or an incorrect name might have been specified.
Corrective Action
Update the information of the ROR console, and check if the relevant server exists.
To update the information, right-click the chassis on the ROR console server resource tree and select [Update] from the displayed menu.
Updating of the information may take around 30 seconds. Check in the resource details that information for the server has changed.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
Description
The server is a model which does not support forced power off.
Corrective Action
Refer to "2.5 Hardware Environment" in the "Design Guide VE" or "Design Guide CE", and check that the server meets the requirements.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
Description
The server is a model which does not support power operations.
Corrective Action
Refer to "2.5 Hardware Environment" in the "Design Guide VE" or "Design Guide CE", and check that the server meets the requirements.
If this does not resolve the problem, collect troubleshooting information and contact Fujitsu technical staff.
Description
Timeout has occurred during the execution of the internal command command.
Corrective Action
Collect troubleshooting information and contact Fujitsu technical staff.
Description
Power operation has been executed normally, but timeout has occurred during obtaining the information for the status of post-power off.
Corrective Action
The server may have not been powered off.
Check the power status of the server.
[Virtual Edition]
Description
Timeout has occurred during the execution of the power control module.
Corrective Action
Power operation may have been performed directly on the hardware of the managed server or the chassis while it was being started or stopped.
In that case, perform the operation again.
If power operation has not been performed directly, take the following corrective actions.
When deploying cloning images
There may be a mistake in the SNMP community name settings.
When this occurs on PRIMERGY BX series servers
When the following blade server is mounted in a different chassis, check that the SNMP community names of the chassis are the same.
The blade server the cloning image was collected from
The blade server the cloning image is being deployed to
When this occurs on rack mount servers or tower servers
Check that the SNMP community names of the server the cloning image was collected from and the server the cloning image was deployed to are the same.
When a managed server with an agent registered has been powered on
The settings of the OS may be incorrect.
Log in, check the following, and take corrective action.
If the settings of the admin network interface are correct
Whether the network settings are valid, and if the admin server and managed server can communicate correctly.
Whether an agent has been started
Refer to "2.2 "unknown" Server Status" in "Troubleshooting", and take the relevant corrective action.
When a managed server using HBA address rename does not start
Refer to "2.1 OS Startup Issues (with I/O Virtualization)" in "Troubleshooting", and take the relevant corrective action.
When server switchover or failback has been performed
Check the resource name of the event log, determine whether the primary server or spare server has been affected and then take the following corrective action.
When the primary server has been affected (the spare server in the case of failback)
Check if the primary server has been powered off. If it has not been powered off, directly (physically) power off the server hardware and then perform the operation again.
When the spare server has been affected (the primary server in the case of failback)
Whether the BIOS settings are correct
Check if the BIOS settings of the spare server correspond with those of the operational environment. After changing any necessary settings, perform the operation again.
For details of BIOS settings, refer to "6.2 Configuring the Server Environment" in the "Design Guide VE".
Whether an HBA has been mounted
When using HBA address rename, check if the server has an HBA mounted, and if there is no HBA mounted, mount one. Then perform the operation again.
Whether communication is possible using the admin LAN
Check that the settings of network devices (LAN switches, ports, etc.) enable communication using the admin LAN.
If communication is not possible using the admin LAN, either replace the devices or change the settings, and the repeat the operation.
Alternatively, in an environment with a redundant admin LAN, for managed servers other than PRIMERGY BX series servers, check that the admin LAN MAC address set during managed server registration is correct. If there is an error in the settings, reconfigure the hardware information and specify the correct MAC address.
The MAC address can be checked in the resource details of the physical server.
For how to check, refer to "A.6 Resource Details" in the "User's Guide VE".
For details of the settings, "6.2.2 Reconfiguration of Hardware Properties" and "6.3.1 Reconfiguration of Hardware Properties" in the "Operation Guide VE".
If the LAN switch has been registered
If the subnets for the primary server and spare server are different, check if the LAN switch blades connecting to each server have been registered.
If the network settings can be changed for switchover
If the subnets for the primary server and spare server are different, check if the network settings have been configured to change during switchover.
When the settings have not been configured, configure them referring to "18.2 Server Switchover Settings" in the "User's Guide VE".
Whether preparatory settings were performed correctly
Check that the settings given in "Configuration File Check" in "2.2.1.1 Software Preparation and Checks" in the "Setup Guide VE" have been performed.
If the settings have not been performed, perform them and then perform the operation again.
In cases other than the above, manually perform server switchover or failback again, and check the console of the spare server.
If the OS of the spare server boots, the settings of the OS may be incorrect. Log in, check the following, and take corrective action. If the status of the agent is not normal after a given length of time, it will automatically return to its previous state. After it does, perform the operation again.
Whether the SNMP community name settings of the chassis are correct
When the primary server and spare server are mounted in different chassis, ensure that the SNMP community names of both chassis are the same.
Whether the SNMP community name settings of the server are correct
When this occurs on rack mount servers or tower servers, check that the SNMP community name settings of the primary server and the spare server are the same.
Whether an agent has been started
Refer to "2.2 "unknown" Server Status" in "Troubleshooting", and take the relevant corrective action.
If the settings of the admin network interface are correct
When the settings to bind admin network interfaces to MAC addresses have been performed, change the settings so as not to bind them.
When chassis power operations have been performed
There may be a mistake in the SNMP settings. Check that the SNMP community name set in the management blade has not been changed from the value specified in chassis registration.
If an operation to stop the chassis is performed while the OS of the server blade is starting, the server blade will not shut down and stopping of the chassis will fail. In such cases, perform the operation to stop the chassis again.
When managed servers are PRIMERGY BX series servers
There is a chance that the correct settings have not been configured for the SNMP agent on the management blade. For details of the settings, refer to "6.2 Configuring the Server Environment" in the "Design Guide VE".
When the managed server is SPARC Enterprise
Automatic starting settings may not be correctly configured. Configure the following settings so that the OS automatically starts when the power is turned on.
For M series servers
Set the mode switch of operator panel to "Locked"
Configure the domain automatic boot as valid
Set "true" in OpenBoot auto-boot?
For T series servers
Set "true" in OpenBoot auto-boot?
There is a chance that the WWN information (WWPN of the HBA, target CA) configured is not correct. Use the storageadm zone info command of ESC to check that the WWPN of the HBA and the target CA are correct.
If WWN information is not correct, change the information to the correct values.
For details on how to use the storageadm zone command, refer to the "ETERNUS SF Storage Cruiser User's Guide".
If the problem is still not resolved after performing the above actions, collect the corresponding message and troubleshooting data, and contact Fujitsu technical staff.
[Cloud Edition]
Description
Timeout has occurred during the execution of the power control module.
Corrective Action
Power operation may have been performed directly on the hardware of the managed server or the chassis while it was being started or stopped.
In that case, perform the operation again.
If power operation has not been performed directly, take the following corrective actions.
If an L-Server has been stopped
Timeout occurs because shutdown of the OS running on the L-Server takes a long time.
Use the following procedure to change the wait time for stopping the L-Server.
Change the wait time.
Change the parameter value given in the following file, according to your environment.
Specify the parameter value in seconds. Do not change other parameters.
The target file
[Windows Manager]
Installation_folder\SVROR\Manager\rails\config\rcx\vm_guest_params.rb
[Linux Manager]
/opt/FJSVrcvmr/rails/config/rcx/vm_guest_params.rb
Parameter
SHUTDOWN_TIMEOUT
Example
When you change the wait time from 5 minutes to 15 minutes
Before changing: SHUTDOWN_TIMEOUT = 300
After changing: SHUTDOWN_TIMEOUT = 900
Restart the Manager.
The changed value is enabled.
[Windows Manager]
>Installation_folder\SVROR\Manager\bin\rcxadm mgrctl stop <RETURN> |
[Linux Manager]
# /opt/FJSVrcvmr/bin/rcxadm mgrctl stop <RETURN> |
If a physical L-Server has been deleted:
There may be an error in the HBA BIOS settings.
Perform the following check and corrective action:
Check whether spin up delay has been set
If spin up delay has been set in HBA BIOS settings, cancel the setting and perform the operation again.
When deploying cloning images
There may be a mistake in the SNMP community name settings.
When this occurs on PRIMERGY BX series servers
When the following blade server is mounted in a different chassis, check that the SNMP community names of the chassis are the same.
The blade server the cloning image was collected from
The blade server the cloning image is being deployed to
When this occurs on rack mount servers or tower servers
Check that the SNMP community names of the server the cloning image was collected from and the server the cloning image was deployed to are the same.
When a managed server with an agent registered has been powered on
The settings of the OS may be incorrect.
Log in, check the following, and take corrective action.
If the settings of the admin network interface are correct
Whether the network settings are valid, and if the admin server and managed server can communicate correctly.
Whether an agent has been started
Refer to "2.2 "unknown" Server Status" in "Troubleshooting", and take the relevant corrective action.
When a managed server using HBA address rename does not start
Refer to "2.1 OS Startup Issues (with I/O Virtualization)" in "Troubleshooting", and take the relevant corrective action.
When server switchover or failback has been performed
Check the resource name of the event log, determine whether the primary server or spare server has been affected and then take the following corrective action.
When the primary server has been affected (the spare server in the case of failback)
Check if the primary server has been powered off. If it has not been powered off, directly (physically) power off the server hardware and then perform the operation again.
When the spare server has been affected (the primary server in the case of failback)
Whether the BIOS settings are correct
Check if the BIOS settings of the spare server correspond with those of the operational environment. After changing any necessary settings, perform the operation again.
For details of BIOS settings, refer to "8.2 Configure the Server Environment" in the "Design Guide CE".
Whether an HBA has been mounted
When using HBA address rename, check if the server has an HBA mounted, and if there is no HBA mounted, mount one. Then perform the operation again.
Whether communication is possible using the admin LAN
Check that the settings of network devices (LAN switches, ports, etc.) enable communication using the admin LAN.
If communication is not possible using the admin LAN, either replace the devices or change the settings, and the repeat the operation.
Alternatively, in an environment with a redundant admin LAN, for managed servers other than PRIMERGY BX series servers, check that the admin LAN MAC address set during managed server registration is correct. If there is an error in the settings, reconfigure the hardware information and specify the correct MAC address.
The MAC address can be checked in the resource details of the physical server.
For how to check, "A.6 [Resource Details] Tab" in the "User's Guide for Infrastructure Administrators (Resource Management) CE".
For reconfiguration of hardware properties, refer to "9.2.2 Re-configuring Hardware Properties" and "9.3.1 Reconfiguration of Hardware Properties" in the "Operation Guide CE".
If the LAN switch has been registered
If the subnets for the primary server and spare server are different, check if the LAN switch blades connecting to each server have been registered.
If the network settings can be changed for switchover
If the subnets for the primary server and spare server are different, check if the network settings have been configured to change during switchover.
When the settings have not been configured, configure them referring to "18.2 Server Switchover Settings" in the "User's Guide VE".
Whether preparatory settings were performed correctly
Check that the settings given in "Configuration File Check" in "2.2.1.1 Software Preparation and Checks" in the "Setup Guide CE" have been performed.
If the settings have not been performed, perform them and then perform the operation again.
In cases other than the above, manually perform server switchover or failback again, and check the console of the spare server.
If the OS of the spare server boots, the settings of the OS may be incorrect. Log in, check the following, and take corrective action. If the status of the agent is not normal after a given length of time, it will automatically return to its previous state. After it does, perform the operation again.
Whether the SNMP community name settings of the chassis are correct
When the primary server and spare server are mounted in different chassis, ensure that the SNMP community names of both chassis are the same.
Whether the SNMP community name settings of the server are correct
When this occurs on rack mount servers or tower servers, check that the SNMP community name settings of the primary server and the spare server are the same.
Whether an agent has been started
Refer to "2.2 "unknown" Server Status" in "Troubleshooting", and take the relevant corrective action.
If the settings of the admin network interface are correct
When the settings to bind admin network interfaces to MAC addresses have been performed, change the settings so as not to bind them.
When chassis power operations have been performed
There may be a mistake in the SNMP settings. Check that the SNMP community name set in the management blade has not been changed from the value specified in chassis registration.
If an operation to stop the chassis is performed while the OS of the server blade is starting, the server blade will not shut down and stopping of the chassis will fail. In such cases, perform the operation to stop the chassis again.
When managed servers are PRIMERGY BX series servers
There is a chance that the correct settings have not been configured for the SNMP agent on the management blade. For details of the settings, refer to "8.2 Configure the Server Environment" in the "Design Guide CE".
When the managed server is SPARC Enterprise
Automatic starting settings may not be correctly configured. Configure the following settings so that the OS automatically starts when the power is turned on.
For M series servers
Set the mode switch of operator panel to "Locked"
Configure the domain automatic boot as valid
Set "true" in OpenBoot auto-boot?
For T series servers
Set "true" in OpenBoot auto-boot?
There is a chance that the WWN information (WWPN of the HBA, target CA) configured is not correct. Use the storageadm zone info command of ESC to check that the WWPN of the HBA and the target CA are correct.
If WWN information is not correct, change the information to the correct values.
For details on how to use the storageadm zone command, refer to the "ETERNUS SF Storage Cruiser User's Guide".
Description
An internal command for obtaining server information may be being executed in another process.
Corrective Action
Wait a couple of minutes and then execute the command again.
Description
The operation of the server management unit failed.
Corrective Action
Check the following and take corrective action.
Whether communication with the management blade is possible
Check if there is a problem with the network environment between the admin server and the management blade using the ping command or another method.
If a cable is disconnected from the LAN connector, connect it.
Whether Write (reference and updating) authority is possessed for the SNMP setting of the management blade
Check the SNMP community name set from the ROR console.
If it was omitted, "public" will be specified.
Check that the management blade of the managed server has Write (reference and updating) authority for the SNMP community name specified.
If the SNMP community name does not have Write (reference and updating) authority, change the authority settings.
For details of checks and the setup method, refer to the management blade manual.
Whether the hardware status is correct
When the server blade has not been inserted into chassis correctly, re-insert it and perform the operation again.
If the problem is still not resolved after performing the above actions, collect the corresponding message and troubleshooting data, and contact Fujitsu technical staff.
Description
Powering on of the maintenance LED failed because of the error displayed in the detailed information error_number.
Corrective Action
Check the error number displayed in the detailed information error_number and take the corrective action indicated for that message.
Description
Powering off of the maintenance LED failed because of the error displayed in the detailed information error_number.
Corrective Action
Check the error number displayed in the detailed information error_number and take the corrective action indicated for that message.
Description
Powering off of the managed server failed because of the error displayed in the detailed information error_number.
Corrective Action
Check the error number displayed in the detailed information error_number and take the corrective action indicated for that message.
Description
The managed server is not in maintenance mode.
Corrective Action
Place the server into maintenance mode.
Description
Power control failed because the power status is OFF.
Corrective Action
This message is displayed when the server for power control operation is powered OFF. Check that the correct server is the target of the operation.
When the server for operation is correct, turn ON the power and perform the operation again.
When this message is displayed during the setting of HBA address rename, restarting the server enables HBA address rename setup.
Description
Chassis power control failed.
When detail is "rc manager found in chassis"
As there is a manager installed on a server blade mounted in the chassis that is the target of power operation, it is not possible to stop the chassis.
Corrective Action
Take corrective action for the content displayed for detail.
When detail is "rc manager found in chassis"
When stopping the chassis, please do so without using Resource Orchestrator.
Description
An internal error has occurred.
Corrective Action
Collect troubleshooting information and contact Fujitsu technical staff.
