Issue/Introduction

This article troubleshoots a UI that remains in the Migrating state after changing a host even though no underlying task exists. Do not attribute the symptom to a single product defect before completing the evidence checks.

Symptoms

After a host is changed in ZSphere 5.1.0, the UI displays the Migrating state for a long time, but domjobinfo finds no migration task. Restarting the management node does not clear the state, and the virtual machine cannot resume service normally.

Environment

• Product: ZVF ZSphere
• Version: 5.1.0 (recorded case)
• Components: ZSphere Change host, management-node task state, and libvirt VM state
• Deployment: After Change host is performed, the UI remains in the Migrating state and the business virtual machine is inaccessible

Possible causes

• Only a control-plane/data-plane state inconsistency is currently confirmed: the UI still shows a migration task, but libvirt domjobinfo no longer shows one.
• Restarting the management node did not clear the task state in the recorded case, indicating that it is not merely an in-process management-node cache.
• Because complete task UUIDs, logs, and state snapshots were not collected before recovery, the stage at which the migration state remained is unknown. This evidence cannot establish a product defect or stable reproduction conditions.

Resolution

1. Preserve control-plane task evidence before recovery

• Check: VM UUID, migration task/API UUID, start time, UI state, and management-node logs.
• Location: Save the task details/API response. Export the complete migration time window from the management-node logs by VM UUID and task UUID, and record whether the service is still accessible.
• Expected result: Determine whether the migration task is still actually running or only its control-plane state remains.
• Exception handling: If the task UUID and time window are missing, first preserve the current UI, API, and log evidence. Do not restart the management node first: the recorded case proves that a restart does not necessarily clear the state and can discard in-process evidence.

2. Check whether libvirt still has a migration task on the current host

• Check: The affected virtual machine's libvirt job and running state. Run the following on the host that the platform records as current:

  KB_VM_UUID='<affected-vm-uuid>'
  virsh domjobinfo "$KB_VM_UUID"
  virsh domstate "$KB_VM_UUID"

• Expected result: When the UI shows Migrating, domjobinfo should return the corresponding migration job, and the VM state should match the platform state.
• Exception handling: If domjobinfo clearly shows no task while the UI still shows Migrating, save the complete output and libvirt logs and follow the residual-control-plane-state branch. If a job still exists, troubleshoot the actual migration task and do not perform the forced recovery below.

3. Confirm all prerequisites for the site-specific forced recovery

• Check: No libvirt migration job, service is inaccessible, platform state cannot converge automatically, and the application owner accepts the data risk.
• Location: ZStack Technical Support and the business owner jointly confirm that pre-recovery evidence has been saved, the VM host is accurate, no migration/block job exists, the application accepts possible loss of unflushed data from forced power-off, and an application recovery or data-verification method is available.
• Expected result: Use the forced recovery from the recorded case only if every condition is met. Do not perform it if any condition is unmet.
• Exception handling: If a VM job still exists, the host is uncertain, or the business cannot accept forced power-off, stop and have support continue the analysis.

4. Have support force-stop the VM, correct its state, and start it

Workaround

• Support-assisted method: The recorded case restored service in the following order, but this method forcibly terminates the virtual machine and is not a general self-service operation. After confirming the exact host, support runs virsh destroy VM_UUID. Then use the supported method for the exact version to correct the platform VM state to Stopped, and start the VM from the UI. This article does not provide a command for directly modifying database state.
• Expected result: The VM starts normally from the UI, the platform no longer shows Migrating, virsh domstate VM_UUID matches the platform state, and the application completes file-system and business-data validation.
• Exception handling: Stop immediately if virsh destroy fails, the platform state cannot be corrected, or the VM fails to start. Preserve the output and have ZStack Technical Support continue. Do not repeat the forced stop or directly modify the database.

Additional information

• Support information must include the exact time window, resource and task UUIDs, complete error text, and relevant component logs.
• Do not extrapolate one site result to all versions. If the root cause remains open or an operation might affect services or data, stop self-service handling and submit the evidence listed in this article.