VM Migration or Shutdown on UPS: Choose a Policy the Site Can Complete

Migration and shutdown are worth comparing only when the virtualization platform supports both and the operating objective allows either. The two actions have different prerequisites and different time requirements. A UPS reports a power state and can raise events or run scripts through its management interface. Migration is a separate function that the virtualization platform and its orchestration perform. This guide turns that distinction into a decision the site can complete, with a worked scenario and the inputs NexPro-Link needs for a defined equipment proposal.

Start by naming the actions on the table. Migration, shutdown, and continue-on-UPS are three separate choices, each with its own prerequisites. Comparing them makes sense when the platform supports migration, the operating objective permits it, and the destination can hold the workload. When one of those is missing, the comparison collapses and the question becomes how to stop cleanly.

The UPS reports the power state and raises the event. The platform decides what to do next. Attributing migration to the UPS overstates what the equipment provides and skips the integration work that delivers it.

The three rows answer different questions. Continue tests stored energy. Migrate tests destination independence and orchestration. Stop tests the ordered shutdown path. A site can pass one row and fail another, so the table keeps them separate.

A destination is only useful if it stays available while the source loses power. It needs enough spare capacity, its own power path, a reachable network, and access to the same storage or a replicated copy. If the target sits in the same rack on the same UPS, moving a VM to it survives nothing. The event takes both hosts down together.

Record these conditions before presenting migration as the recovery strategy. Otherwise the plan looks complete on paper and fails during the first real outage.

The first row is the kind of destination that supports migration. The second row has spare capacity but no independence, so it helps with host-level faults while doing nothing for a building power loss.

Migration does not run by itself. A management component has to receive the event, authenticate, and issue the command. The storage and network paths have to stay up long enough for the data to move. If the controller loses power before it can act, the surviving hosts sit idle, and the policy never runs.

Protect the power path of every component in the chain through the required interval, including the hosts.

The table is a control chain. Walk it from event to storage and mark which item is on the UPS. A gap anywhere in the chain turns a complete policy into a partial one.

Every action needs a time budget and a fallback that runs when the budget is spent. Without both, a stalled migration can hold the reserve open while the battery drains, and the site ends up with neither a migrated workload nor a clean shutdown.

Use the platform's supported, approved fallback policy with explicit timing. Do not let a stalled action consume the entire energy reserve without a decision.

The times are teaching inputs for this article, not measured product performance. The sequence is serial for the worked example; real deployments may run some steps in parallel when dependencies allow it.

!Functional diagram connecting separate the candidate actions with include orchestration dependencies, using separate power and information paths.

A policy that works when the destination is available says nothing about the other cases. Test the intended success, an unavailable destination, a lost management link, and a migration that runs past its budget. Run each one in an authorized environment and record what happened.

A demonstration on one host does not prove the policy for every cluster or platform version. Record the tested scope so a later platform change triggers a re-test instead of an assumption.

When the decision reaches equipment selection, hand NexPro-Link the inputs that define the integration. Platform versions, power loads, destination conditions, and the signaling interface tell the supplier what has to stay powered and how the event arrives. Migration and shutdown support come from the specified integration, so the brief names the signaling interface explicitly.

The example entries are placeholders that show the shape of the brief. Replace them with the site's real versions and loads before the supplier discussion.