feat(vmop): explain why a migration is queued behind concurrency limits

[danilrwx]

Description

When a migration (a firmware update, a node drain, or a manual migrate) cannot start immediately because a concurrency limit is already taken, the operation used to sit in Pending for a long time with only a generic "queued, waiting for the queue to be processed" message — indistinguishable from a stuck one.

This surfaces the concrete reason on the pending operation for all three limits, naming the node and current counts:

• inbound (target node): node "worker-0" has no free inbound migration slot (1 in progress) — from the controller's own inbound limiter.
• cluster / per-node outbound: taken from a MigrationConcurrencyLimitReached condition that KubeVirt now sets on the migration, e.g. the cluster live migration limit is reached (3/3 running) or node "worker-0" has no free outbound migration slot (1/1 running).

The cluster/outbound limits are enforced by KubeVirt, so the reason is reported at the source (see the paired 3p-kubevirt change) and this controller only reads the resulting condition — no duplication of KubeVirt's limit algorithm. The inbound limit is enforced by this controller's own limiter and is reported here.

Why do we need it, and what problem does it solve?

Migrations queued behind a concurrency limit looked identical to stuck ones, so users waited and escalated with nothing actionable to look at. This makes the limit, the node, and the numbers visible directly on the operation, so a queued migration is recognizable at a glance without digging into controller logs.

What is the expected result?

Start a migration while a migration limit (inbound, cluster, or per-node outbound) is already taken:

1. The operation stays Pending (unchanged behavior).
2. Its message names the limit that is reached, the node, and the current counts, instead of the generic queued message.
3. Once a slot frees up, the migration proceeds as before.

Note: the cluster/outbound reason relies on the paired 3p-kubevirt change that sets the MigrationConcurrencyLimitReached condition; without it, those cases fall back to the generic queued message. The inbound reason works independently.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: vmop
type: feature
summary: "A migration waiting for a free concurrency slot now names the limit that is reached (inbound, cluster, or node outbound) with the node and current counts, instead of a generic pending message."