Issue/Introduction

This article troubleshoots No host available during cross-cluster migration of a virtual machine created from a template. Do not attribute the symptom to a single product defect before completing the evidence checks.

Symptoms

During cross-cluster/storage migration of a virtual machine created from a template, no destination host is found and No host available for block live migration is reported. A virtual machine created from an ordinary image might migrate normally.

Environment

• Product: ZVF ZSphere
• Version: 5.0.3 (recorded case)
• Components: ZSphere cross-cluster storage migration, resource binding, and Host Allocator
• Deployment: A virtual machine migrates from the source cluster to data storage accessible only to the destination cluster

Possible causes

The virtual machine was confirmed to have the resourceBindings::Cluster:SOURCE_CLUSTER_UUID system tag when it was created. Hosts in the source cluster are filtered out by HostPrimaryStorageAllocatorFlow because they cannot access the destination data storage. Hosts in the destination cluster are then filtered out by ResourceBindingAllocatorFlow as not bound resource, leaving no host that meets both conditions. The failure occurs before the migration data plane starts; it is not a SharedBlock Agent or data-copy failure.

Resolution

1. Find the allocator flow that reduces candidate hosts to 0

• Check: The failed migration API/LongJob, source and destination clusters, and destination data storage.
• Location: Search management-server.log for rejected candidate host by API ID, and organize candidate-host counts and rejection reasons in allocator-flow execution order.
• Expected result: At least one host can both access the destination data storage and satisfy the VM resource binding.
• Exception handling: If ResourceBindingAllocatorFlow is the last flow to reduce the candidate count to 0 because of not bound resource, follow the binding-tag branch. If a capacity, CPU, or storage flow reduces it to 0, troubleshoot that condition instead.

2. Query the cluster-binding tag on the virtual machine

• Check: The failed virtual machine's system tags and creation request.
• Location: Use a supported query to check for resourceBindings::Cluster:SOURCE_CLUSTER_UUID, verify whether the UUID is the virtual machine's current source cluster, and compare virtual machines created from templates with those created from ordinary images.
• Expected result: A virtual machine that must migrate across clusters must not remain bound to its source cluster.
• Exception handling: If the tag exists and the destination host belongs to another cluster, it explains not bound resource. Do not continue troubleshooting data copy or force migration.

3. Remove the binding through a VM-level policy

Workaround

• Applicability: The allocator log proves that the source-cluster binding caused ResourceBindingAllocatorFlow to reduce destination candidates to 0, and the business accepts the broader HA/DRS scheduling scope after unbinding. This does not apply when a capacity or storage flow reduces candidates to 0.
• Verified self-service method: First have the business owner confirm that the virtual machine may be scheduled across clusters. Then enable the VM-level Cross-cluster HA policy. Query again and confirm that resourceBindings::Cluster:* was removed through the product workflow.
• Expected result: Hosts in the destination cluster are no longer rejected by ResourceBindingAllocatorFlow and can still access the destination data storage.
• Exception handling: Changing only cluster/global settings does not take effect while the VM tag remains. Do not directly modify the database or manually delete the system tag; ask ZStack Technical Support to verify the version behavior.

4. Migrate and recheck the isolation boundary

• Check: A new migration task for the same virtual machine, destination-host selection, and HA/DRS scope.
• Location: First migrate one test or low-risk virtual machine. Confirm that host allocation succeeds and data migration completes before expanding to other virtual machines.
• Expected result: Migration succeeds, the destination host can access the data storage, and the business accepts the broader HA/DRS scheduling scope after unbinding.
• Exception handling: If no host is available after the tag is removed, inspect the new last failing flow. Do not assume that resource binding is still the cause.

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.