No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


FusionCloud Troubleshooting Guide 02

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Pod Troubleshooting

Pod Troubleshooting


  • Pod is suspended and is in the CrashLoopBackOff state.
  • Pod functions are abnormal.

Possible Causes

The docker umount devicemapper exception occurs, causing devices mounted in Docker fail to be uninstalled and pod suspension.

Troubleshooting Method

  1. Use PuTTY to log in to the om_core1_ip node.

    The default username is paas, and the default password is QAZ2wsx@123!.

  2. Run the following command to check whether the pod is normal:

    kubectl get pods --all-namespaces|grep CrashLoopBackOff

    manage        alm-website-1825011304-c7v32                     0/1       CrashLoopBackOff   205        11h

    The preceding command output shows that alm-website-1825011304-c7v32 is abnormal.

  3. Run the following command to query the IP address of the node where the faulty component resides:

    kubectl get pods PODNAME -o yaml -n NAMESPACE|grep hostIP

    PODNAME indicates the name of the abnormal pod. NAMESPACE indicates the namespace of the abnormal pod.


    The preceding output shows that the IP address is

  4. Check whether the abnormality is caused by the docker umount devicemapper exception.

    Log in to the node where the abnormal pod locates as user paas, switch to user root, and run the following command:

    journalctl -n

    Check whether there is the umount docker-thinpool exception.

    • If there is no umount docker-thinpool exception, the CrashLoopBackOff state is not caused by the docker umount devicemapper exception.
    • If the exception occurs, record the file system ID of devicemapper that fails to be deleted and perform the subsequent steps.

  5. Run the following command to query the information about the device failed to be deleted:

    mount|grep file system ID

    file system ID indicates the file system ID you obtained in 4.

    Record the ID of the device failed to be deleted.

  6. Run the following command to uninstall the abnormal device:

    umount device ID

    device ID indicates the ID you recorded in 5.

  7. Run the following command to obtain the ID of the container in dead stat:

    docker ps -a|grep dead

  8. Run the following command to delete the container:

    docker rm -f container id

    container id indicates the container ID you obtained in 7.

  9. Run the command in 2 to check whether the pod is recovered.

    If no command output is displayed, the pod is normal.

    If the pod is abnormal, contact technical support for assistance.

Updated: 2019-06-10

Document ID: EDOC1100063248

Views: 23083

Downloads: 37

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Previous Next