Resolving VM evacuation failures during CubeCOS rolling upgrades
Summaryβ
During a rolling upgrade, the first master control node reboots. Then, the rest of the upgrade processes are carried out automatically. However, timing issues or temporary service unavailability may prevent virtual machines (VMs) from being evacuated from their original node. If VMs fail to evacuate a node, the upgrade process aborts and requires manual intervention to resolve the issue.
Detailsβ
Errors related to VM evacuation failures may occur during a rolling upgrade process due to temporary service unavailability of pertinent components or timing issues on the platform. In this case, the virtual machines must be evacuated manually, and the node must be rebooted before the automatic rolling upgrade process can continue.
Applicable versionsβ
CubeCOS 3.1.0 and above.
This article applies to environments running CubeCOS version 3.1.0 or higher.
Resolutionβ
Evacuate VM manually and reboot node to resume automatic rolling processβ
-
Open a terminal session.
-
Connect to the cluster VIP via SSH and log in as the
adminuser.ssh admin@<your-cluster-vip> -
In the admin CLI, enter the following command to resolve the host evacuation failure:
iaas compute pre_failure_host_evacuation -
Enter the index of the failed node when prompted to evacuate the failed host.
examplecubenode1> iaas compute pre_failure_host_evacuationEvacuate which compute node:1: examplecubenode12: examplecubenode23: examplecubenode3Enter index: 1 -
Verify the node and VM details, then type "YES" to confirm the evacuation.
The CLI will then display the status and relevant information for all the VMs on the host that will be evacuated. Verify that the host and VM information are correct before entering "yes" to execute the evacuation.
+------------------+----------------------+--------+--------------------------------+--------------------------+----------------+| ID | Name | Status | Networks | Image | Flavor |+------------------+----------------------+--------+--------------------------------+--------------------------+----------------+| some-id1 | cinder-volumes_nodeID| ACTIVE | \_internal-network=some-ip-info| N/A (booted from volume) | t2.diagnostics |+------------------+----------------------+--------+--------------------------------+--------------------------+----------------+Enter 'YES' to confirm: YES -
To continue the automatic rolling upgrade process, reboot the node after evacuation has been performed.
- Connect to the cluster VIP via SSH and log in as the
adminuser:ssh admin@<mgnt-ip-of-errored-node> - Enter
rebootinto the CLI to continue the automatic rolling-upgrade process and reboot the node.
- Connect to the cluster VIP via SSH and log in as the
-
Navigate to
Maintenance > Update. -
Verify that the automatic rolling upgrade continues without error and that the status of the failed node returns
Succeeded.