Incorrect VM status after migration

Problem

A virtual machine (VM) has been successfully migrated to the target cluster node, but the platform still shows it on the source node.

The following symptoms are observed:

• one of the following VM states:
  
  • the VM shows as Active, but migration tasks show as Failed, are stuck in a pending state, or are missing entirely;
  • the VM is stuck in the Migrating state, while migration tasks are completed and show as Successfuly;
  • the VM shows as Stopped, while the migration task shows as Running.
• running virsh list --all|grep <VM_name> on the source node does not show the target VM;
• running virsh list --all|grep <VM_name> on the target node shows the VM in the running state.

Cause

The platform did not receive confirmation that the migration completed successfully due to a network failure or an error processing the request. As a result, the actual state of the VM does not match the state recorded in the platform's database.

Solution

To resolve the mismatch between the actual VM state and the state in the platform's database:

1. Find the migration task ID:
   
   1. In the right-hand menu, click Task list .
   2. Select the migration task for the affected VM.
   3. Note the value in the id column.
2. Connect to the server with the platform via SSH. For more information about connecting via SSH, see Workstation setup.
3. Connect to the database:
   

   There are potential risks involved in altering a database. We do not recommend making manual edits to the database, as it can disrupt the correct operation of the platform.

   Create a backup of the platform before performing any actions with the database.

   
   

   As the platform is in the process of transitioning to the PostgreSQL DBMS, different instances of VMmanager may use different DMBS.

   The platform uses PostgreSQL in all new installations starting with version 2026.03.1. In all other cases, the platform uses MySQL. The DBMS is not changed when the platform is updated.

   To determine the type of DBMS, run the following command on the platform server:

   docker ps --filter name=pgsql

   Example answer

   CONTAINER ID   IMAGE         COMMAND                  CREATED      STATUS      PORTS      NAMES
   3213c5dc94d0   postgres:12   "docker-entrypoint.s…"   5 days ago   Up 4 days   5432/tcp   pgsql

   If the command output contains information about the container, the platform uses PostgreSQL; if the response is empty, it uses MySQL.

   
   
   MySQL

   docker exec -it mysql bash -c "mysql isp -p\$MYSQL_ROOT_PASSWORD"

   PostgreSQL

   docker exec -it pgsql bash -c "psql -d isp"

4. Retrieve the consul_id for the problematic task:
   

   SELECT consul_id FROM vm_task_log WHERE id = [task_id];

   Comment:

   • [task_id] —  the value obtained in step 1.
   Example output

   SELECT consul_id FROM vm_task_log WHERE id = 2338;
   +-----------+
   | consul_id |
   +-----------+
   |     16980 |
   +-----------+

5. Retrieve the callback_params for the problematic task. These are the parameters that the system should have sent upon successful migration completion:
   

   SELECT callback_params FROM taskmgr_task WHERE id = [consul_id];

   Example output

   SELECT callback_params FROM taskmgr_task WHERE id = 16980
   *************************** 1. row ***************************
   callback_params: {"disks": [{"id": 64466, "storage": 34}], "host_id": 66687, "node_id": 397, "is_dummy": false, "interfaces": [{"id": 66689, "name": "eth0", "is_vxlan": false, "mac_address": "52:54:00:11:C1:0F", "node_interface": 337, "is_main_network": true, "node_interface_name": "vmbr0"}], "dst_node_id": 375}

   Comment:

   • [consul_id] — the value obtained in step 4.
6. Exit the database:
   

   exit

7. Inside the vm_box container, make an API request to manually complete the task:
   

   curl -X POST -H 'Instance-ID:1' -H 'internal-auth:on' -o- -D- \
   http://localhost:1500/vm/v3/task/[consul_id]/success?name=host_migrate \
   -d '{"output":{"content":"","type":"text"},"params":[callback_params]}'

   Comment:

   • [consul_id] — the value obtained in step 4;
   • [callback_params] — the value obtained in step 5. 
   Example request for consul_id = 16980

   curl -X POST -H 'Instance-ID:1' -H 'internal-auth:on' -o- -D- \
   http://localhost:1500/vm/v3/task/16980/success?name=host_migrate \
   -d '{"output":{"content":"","type":"text"},"params":{"disks": [{"id": 64466, "storage": 34}], "host_id": 66687, "node_id": 397, "is_dummy": false, "interfaces": [{"id": 66689, "name": "eth0", "is_vxlan": false, "mac_address": "52:54:00:11:C1:0F", "node_interface": 337, "is_main_network": true, "node_interface_name": "vmbr0"}], "dst_node_id": 375}}'

   Successful output example

   HTTP/1.1 200 OK
   Content-Type: application/json; charset=utf-8
   Content-Length: 4
   Connection: keep-alive

8. Verify in the web interface that the VM now appears on the target node.