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.

Knowledge Base

Deleting a VM at the Cascading Layer Failed

Publication Date:  2019-05-27  |   Views:  408  |   Downloads:  0  |   Author:  zwx531734  |   Document ID:  EKB1100016502


Issue Description

A user fails to delete an ECS through the ManageOne operation plane. The user opens the logs collected by the g-ray service and finds that an error code shown in the figure below is displayed for the nova-proxy service.

The user clicks the error code. A dialog box is displayed, showing the message "Proxy failed to delete cascaded instance:a5d56f3d-6bcc-485a-9524-31aba87eff07 for instance:30c1a945-0da6-413a-b4ba-85d7535b56e5."

Alarm Information

·     The host storage link is interrupted.

Alarm name: Host Storage Link Failure

Alarm ID: 6023

Alarm source: ID of the host where the VM is located

Handling Process

The error information indicates that the nova-proxy service at the cascading layer invoking an interface at the cascaded layer has timed out. Perform the following operations to manually rectify the fault:

1.    1. Contact the administrator to log in to the Service OM web client and choose Services > ECS > Compute Instances. Then, select a OpenStack name at the cascaded layer.


1.   2.     In the Name search box, enter server@ID of the VM that fails to be deleted to search for the VM, as shown in the figure below.

·       If the VM cannot be found at the cascaded layer, the VM has been deleted from the cascaded layer. Contact the user to delete the VM again.

·       If the VM can be found at the cascaded layer and is in the Deleting state, the VM is being deleted at the cascaded layer. (The deletion may take about 12 hours in some cases.) In this case, contact the user to delete the VM again.

1.   3.     Log in to the MO operation plane, choose Alarms > Current Alarms, and check whether ALM-6023 Host Storage Link Failure exists.

·       If the alarm exists and the alarm source is the ID of the host where the VM is located, the deletion failure may be caused by the disconnection between the host and the data plane network of storage devices. Rectify the fault according to [Solution 1].

·       If the alarm does not exist, ask the contact person to rectify the fault.


1.       Clear the alarm as instructed in section "ALM-6023 Host Storage Link Failure" in the alarm help.


This g-ray service error is caused by the timeout of the cascading layer waiting for the operation at the cascaded layer. Therefore, you need to analyze the current service processing status based on the logs of the cascaded layer.