This section provides steps to troubleshoot manual RDS deployment or RDS Auto-Deploy.
Troubleshooting manual RDS deployment
| |
|---|
After you deploy the OVF and power on the VM, you see an unexpected inconsistency when checking the file systems. | If you see this problem, perform the following steps. 
- Manually run the fsck command to fix the file system.
- Restart the operating system.
|
Database import does not work or fails. | Make sure that you create the database instance using the Unicode option (UTF-8).
 |
Troubleshooting RDS Auto-Deploy
If you see problems when you run the RDS Auto-Deploy script, use the following troubleshooting steps:
| |
|---|
VM unable to pick up IP from DHCP | Note: This is required only when VMs pick up the IP from DHCP. If IPs are statically allocated, it is your responsibility to fix the Network settings. If your VM does not pick up the IP from DHCP, you can resolve the issue in two different ways. Deleting the device from Network Connections: - Go the Network Connections settings of the VM.
- Remove the Auto eth0 device.
- Assign the IP.
- Restart the network service:
service network restart
Re-attaching the NIC to the VM: - Shut down the VM.
- Go to the settings of the VM using the Edit virtual machine settings link.
- Remove the NIC card.
- Re-add the NIC card.
- Start the VM and verify that IP is allocated using DHCP.
|
Cannot use agentinfo to connect deployed VM from RDS clm-autodeploy VM. | After the VM is deployed and the IP is assigned, the VM is not reachable using the hostname from the same host. For example, from the clm -ar VM, you cannot ping clm-ar. This is because, in the DNS, the IP is mapped to csm-ar if the DNS is available. If DNS is not available, the VM is not reachable using csm-*** as well as clm-***. This condition applies to all VMs. To resolve this issue: - Perform the IP Address hostname mapping for all the VMs.
- After you check the availability of DHCP and DNS and the VM is reachable from its own console using clm-*** as well as csm-*** and from other VMs using the hostname csm-***, restart the RSCD agent using the following commands:
#/etc/init.d/rscd stop
#/etc/init.d/rscd start Verify from the RDS Auto-Deploy VM that all the VMs respond to the agentinfo command from NSH. 
Until you can successfully agentinfo the VM from the RDS clm-autodeploys VM, the script cannot run Post Deployment Changes. |
| To resolve the issue if the script fails, execute only the failed and not executed part. - Modify the Deployment_details.txt and change the OVFLists parameter.
For example, if the clm-ar OVF deployment fails, let the script continue with all the remaining partd. After the OVF Deployment, DB Schema creation, and Post Install is completed (clm-ar post deploy would fail since clm-ar ovf deployment failed), edit the Deployment_details.txt and keep only clm-ar in the first ESX and run the scrip again with only OVF deployment and Post Deploy Changes. You do not need to run DB schema creation a second time.
 - In this example the script would have created the clm-ar.log and ear_post_deploy_chg.sh files in the /data1/scripts folder. As a result, delete those files before you running OVF deployment and Post Deploy Changes for clm-ar a second time.
- To re-run the script to deploy OVFs, create DB schema, or run post deploy again, delete all the logs and other files that are created by the script. For more information, see Cleaning up your environment after script failures.
|
