Issue/Introduction

This article troubleshoots No available host found or not enough capacity returned during VM HA or manual startup even though the host page appears to show available CPU and memory.

Symptoms

• A candidate host's page or logs show available CPU and memory, but startup is still rejected.
• Some virtual machines in an HA batch start successfully, while later large virtual machines fail.
• After the host recovers, DRS migrates some virtual machines back, and the available capacity shown on the page changes accordingly.

Environment

• Product: ZVF ZSphere
• Version: 4.10.19
• Components: ZSphere HA, DRS, and host-capacity scheduling
• Deployment: A multi-host cluster in which multiple virtual machines on a failed host trigger HA in one batch

Possible causes

• Scheduling first checks recorded available capacity, after which the reservation process deducts reservedMemory; these use different capacity calculations.
• Concurrent HA requests compete for the same hosts. After initial filtering succeeds, other virtual machines might have consumed capacity by the final reservation stage.
• The total memory of the virtual machines on the failed host exceeds the takeover capacity of the remaining hosts after reserved memory is deducted.

Resolution

1. Capture candidate-host capacity at the time of failure

• Check: The failed host, online candidate hosts, and the successful and failed virtual machines in the same HA batch.
• Location: From management-node logs for the failure window, record each candidate host's availableCpu and availableMemory, VM CPU and memory requirements, total HA requests, and success/failure counts. Do not substitute page values captured after host recovery or DRS migration.
• Expected result: The capacity snapshot at the time of failure explains which hosts were retained or excluded during initial filtering.
• Exception handling: If only a post-failure page screenshot exists and no failure-time logs are available, mark the capacity evidence as insufficient. Do not conclude that scheduling is incorrect from that screenshot.

2. Calculate actual allocatable memory after deducting reservedMemory

• Check: Reserved-memory settings at global, cluster, and host scopes.
• Location: Search for reservedMemory in the UI under Global settings, and check for overrides at a more specific scope. Record the value, unit, and effective time. Compare availableMemory - reservedMemory with the target VM's memory.
• Expected result: After reserved memory is deducted, the result is still greater than or equal to the target VM memory requirement.
• Exception handling: If the result is insufficient, not enough capacity is a capacity rejection. In a recorded case, P02 had 65.01 GiB of recorded available memory. After deducting 60 GiB of reserved memory, only 5.01 GiB remained, so it could not host a 64 GiB virtual machine. These values illustrate the calculation only and are not general thresholds.

3. Distinguish initial capacity shortage from concurrent reservation failure

• Check: StartVmOnHypervisorMsg, AllocateHostReply, and other HA requests during the same period as the failed request.
• Location: Order candidate-host filtering, capacity reservations, and successfully started virtual machines by time. Compare candidate-host remaining capacity after each success.
• Expected result: no enough memory can be explained by insufficient recorded memory during initial filtering. not enough capacity can be explained by insufficient capacity after reserved capacity is deducted or after final concurrent reservations.
• Exception handling: If capacity remains sufficient after deduction and no other request consumes capacity between candidate acceptance and final rejection, preserve the complete message chain and escalate it as a scheduling-specific issue.

4. Correct capacity planning and verify the next HA event

Workaround

• Verified self-service method: Adjust capacity planning or reduce the takeover batch size so that, after any one host fails, the remaining hosts can still host critical virtual machines after reserved capacity is deducted. Do not rely only on the page's available value at one point in time.
• Support-assisted method: If reservedMemory is confirmed to conflict with the current HA objective, the administrator may adjust it through the change process after evaluating overcommit and HA risks, recording the original value, and preparing a rollback. Do not temporarily set reserved memory to 0 merely to bypass one startup.
• Expected result: HA/manual startup succeeds when retried within planned capacity. If DRS migrates virtual machines back after the host recovers, changes in page capacity correspond to migration records and released capacity.
• Exception handling and rollback: If the rejection remains unexplained or unexpected scheduling occurs, immediately restore the recorded original reservedMemory value, stop further startup attempts, and provide ZStack Technical Support with the failure window, host-capacity snapshot, reservation settings, HA queue, and DRS migration records.

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.