Live migration
Live migration moves a running VM to another Host while keeping its operating system running. Use it to prepare Host maintenance or change placement. It is an infrastructure operation requiring an appropriate Fleet role, not merely Project collaboration rights. Before starting, verify destination capacity, CPU compatibility, Network reachability and access to the VM's storage.
Prepare the destination
The destination Host must be live and suitable for the VM. Shared storage must be attached where required; local storage does not become shared because two Hosts join a Pool. Check SR free space and PBDs. Confirm that the destination provides the VM's Networks and that migration traffic can cross the management path.
Assigned PCI, USB or other Host-bound devices can prevent migration. Missing PV drivers, incompatible CPUs, inadequate memory and unavailable SRs are reported as migration preconditions. The Edge appliance is explicitly pinned to its Host and has migration operations blocked. Do not use migration to move ownership of a physical public NIC.
Migrate the VM
For a Fleet role with migration permission, open the VM's Migrate sheet. Review Destination host and Live migration (keep the VM running). Check the source VM and destination before submitting.
The same-Pool CLI path is:
hv vm show VM --pool POOL
hv vm migrate VM --pool POOL --host DESTINATION_HOST --live
hv task list --pool POOLUse the production configuration or authenticated remote mode described in CLI and API. Follow the migration's Task and inspect the VM again when it finishes.
Cross-Pool migration adds --dest-pool DESTINATION_POOL. The CLI accepts repeated --network-map VIF=NETWORK mappings for that case. Disks use the destination Pool's default SR on this CLI path; verify it before starting. Network mappings are refused for same-Pool migration. Do not assume imported XenServer VM definitions imply ABI or cross-product live-migration compatibility.
Move web-01 before maintenance
Suppose web-01 runs on hv-01 in a Pool that also contains hv-02. The aim is to free hv-01 for maintenance while the application continues running. Before requesting the move, record the VM's current resident Host, disk attachments and Networks. Confirm that the Account performing the operation has the required Fleet permission; Project access alone does not authorize infrastructure placement changes.
Inspect hv-02 and verify available memory for this VM, rather than comparing only the two Hosts' installed memory. Check that each required SR is accessible there. If web-01 uses a VPC, check that its overlay reaches the destination Host. If it uses an external Network, check the destination's connection to that Network. A matching display name does not establish that an unrelated Network has the same upstream connectivity.
Open Migrate on web-01, choose hv-02 and review the live-migration option. Submit once and retain the Task identifier. While that Task runs, avoid issuing another migration for the same VM. A browser reconnect or delayed progress display is a reason to read the Task again, not a reason to assume the request was lost.
When it finishes, open the VM page and confirm that the resident Host is hv-02. Check the application from its normal client path as well as through the VM console. A working console confirms guest access, but does not test the application's Network or its external dependencies. Only after these checks should you count web-01 as evacuated from hv-01.
If the move fails, inspect the reported precondition and the VM's actual placement. For example, an unavailable SR on hv-02 needs a storage connection repair or another destination. Changing the VM's name or repeatedly resubmitting the move does not address that failure. Leave hv-01 available until you have confirmed where the VM is running.
Plan a move between pools
A cross-Pool move needs a review of destination ownership and infrastructure as well as the running guest. Identify the destination Pool explicitly and inspect its default SR before using the CLI path. Verify that the SR is suitable for all disks being moved and has enough free capacity. Do not infer the destination from whichever Pool your CLI last selected.
Prepare a mapping for each virtual NIC that needs a different destination Network. For example, distinguish web-01's application interface from a separate management interface; swapping them can leave a running guest inaccessible. Review identifiers and the intended connectivity for every mapping before submitting. The CLI reference describes the cross-Pool options and selector rules.
Arrange a way to reach the guest console after the move, and retain the original Network and disk information until the destination is verified. If you cannot establish compatible destination resources, postpone the move and plan a different recovery or maintenance procedure. A backup restore is a separate operation and should not be presented to application owners as an equivalent live move.
Verify completion
Confirm the VM's resident Host changed, its power state remains correct and its operating system and applications are reachable. Check disk and NIC attachments on the destination. Live migration is not a promise of zero application latency or uninterrupted sessions in every network configuration; validate the workload's behavior before using the procedure for maintenance.
A successful submission is not completion. Keep the Task identifier and inspect its final state. If the connection to hv drops during migration, reconnect and read the existing Task and VM placement before submitting another move.
Common problems
For VM_REQUIRES_SR or SR_NOT_ATTACHED, inspect destination SR connections. For VM_REQUIRES_NETWORK, inspect the selected Network and cross-Pool mapping. For HOST_NOT_ENOUGH_FREE_MEMORY, free capacity or select another Host. Device-assignment errors require a workload-specific decision about removing the device or scheduling downtime.
If maintenance evacuation stops, the Host may already be disabled while VMs remain resident. Resolve the specific migration failure before rebooting. A single-Host Pool needs planned VM shutdown for platform updates; it has no second Host to receive a migration.