Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Live migration moves a running instance from one compute host to another without shutting it down. Cold migration stops the instance, moves it, and restarts it on the target host. Both operations are administrator-only actions used for planned maintenance, load balancing, and hardware decommissioning.
Administrator Access Required — This operation requires the admin role. Contact your Xloud administrator if you do not have sufficient permissions.
Prerequisites
  • Administrator access to the Xloud Dashboard (admin view)
  • Shared storage between source and destination hosts (or block migration enabled)
  • Compatible CPU architecture between hosts

​
Migration Types

TypeInstance StatusDowntimeUse Case
Live MigrateActive or PausedNone (zero downtime)Planned maintenance, load balancing
Cold MigrateActive or ShutoffYes (reboot required)Hardware replacement, when live migration fails

​
Live Migrate an Instance

1

Open the Live Migrate dialog

Navigate to Compute > Instances in the admin sidebar. Click the More dropdown on the instance row and select Live Migrate.
Live Migrate is available for instances in Active or Paused status. It is not available for bare metal instances. This action appears only on the admin page.
2

Select a destination host (optional)

The dialog shows:
FieldDescription
InstanceInstance name (read-only)
Current HostThe compute host currently running the instance (read-only)
Destination HostSelect a target hypervisor, or leave empty for scheduler auto-selection
Block MigrateCheckbox — enable block migration for instances on local storage
The host table shows available hypervisors. The current host and disabled hosts are grayed out. Bare metal hypervisors are filtered from the list.
Leave the destination host empty to let the scheduler select the optimal target based on available resources. Manually selecting a host is useful when you need to place the instance on a specific node.
3

Start the migration

Click Confirm. The instance status changes to Migrating during the transfer and returns to Active on the new host when complete.
Instance is Active on the new host. Verify with the instance detail page.

​
Server Group Affinity Is Honored

Live migration respects the affinity / anti-affinity policy of any server group the instance belongs to. The scheduler treats migration the same way it treats a launch:
Policy on the instance’s server groupWhat live migration does
affinityPicks a destination host that already runs the other instances in the group. If no such host has capacity, the migration fails with NoValidHost
anti-affinityPicks a destination host that does not already run another instance in the group. If every other host already runs a group member, the migration fails with NoValidHost
soft-affinityPrefers a destination host that already runs other group members; falls back to any available host if none has capacity
soft-anti-affinityPrefers a destination host with no other group members; falls back to any available host if no separate host is free
This holds for both Dashboard-initiated migrations and CLI-initiated migrations, and for both single-instance Live Migrate and Bulk Live Migrate. If you want to override the policy for a specific move, remove the instance from its server group first, migrate, and re-add it (no platform-supported way to bypass the policy in-place).
When evacuating a host, use Bulk Live Migrate with the source host pre-set as the filter. The scheduler picks destinations one at a time and re-evaluates the server-group constraint for each move — so anti-affinity remains intact across the whole evacuation.

​
Cold Migrate an Instance

1

Open the Migrate dialog

Navigate to Compute > Instances in the admin sidebar. Click the More dropdown and select Migrate.
Cold Migrate is available for instances in Active or Shutoff status. Not available for bare metal instances. Admin-only action.
2

Select a destination host (optional)

FieldDescription
InstanceInstance name (read-only)
Current HostCurrent compute host (read-only)
Destination HostSelect a target, or leave empty for auto-selection
Click Confirm to start the migration.
3

Confirm the migration

After the cold migration completes, the instance enters Verify Resize status. You must confirm or revert:
  • Confirm Resize or Migrate — accept the migration
  • Revert Resize or Migrate — move the instance back
Instance returns to Active on the new host after confirmation.

​
Next Steps

Compute Hosts

Monitor hypervisor resources before and after migration

Availability Zones

Understand zone boundaries for migration targets

Live vCPU/RAM Scaling

Scale instance resources without migration

Troubleshooting

Resolve stuck or failed migrations