About manual live migration
Sole-tenancy lets you create VMs on a specific sole-tenant node or in a group ofnodes. If you create a VM in a group of nodes, Compute Engine optimizes thespace available for VMs in the node group by using a bin-packing algorithm todetermine the node to place the VM on. For information about sole-tenancy, seeSole-tenancy overview.
As your workload runs, you might want to move VMs to a different node or nodegroup. To move sole-tenant VMs to a different node or node group, you canmanually initiate a live migration. You can also manually initiate a livemigration to move a multi-tenant VM into sole-tenancy.
Use cases for manual live migration
The following list shows some use cases for manually live migrating VMs:
Increase utilization and optimize costs. You might be able to consolidateVMs onto fewer sole-tenant nodes.
Logically reorganize VMs. Use different sole-tenant node groups or nodesto separate VMs based on their workload type.
Isolate workloads to meet compliance standards or improve performance.Manually live migrate multi-tenant workloads that require hardware isolationinto sole-tenancy to meet compliance standards or to improve performance.
Increase portability of VMs. You can't modify certain node templatesettings, such as the maintenance policy, the maintenance window, and settingsrelated to local SSD. By using manual live migration, you can migrate VMs to anode group with different settings.
- Improve performance by rebalancing oversubscribed sole-tenant nodes. Ifyou areovercommitting CPUs on sole-tenant VMs,you can manually live migrate any VMs that are underperforming to othersole-tenant nodes.
Examples
To understand how manual live migration supports the preceding use cases, reviewthe following examples.
Manual bin packing
To more efficiently arrange VMs in a node group to fit additional VMs, you canuse manual live migration to choose which nodes to put sole-tenant VMs on.
Consider a sole-tenant node group with the following initial state, on which youare trying to schedule an additional VM with 16 vCPUs:
| Initial state | Node 1 | Node 2 | Total |
|---|---|---|---|
| vCPU capacity | 80 | 80 | 160 |
| VM vCPUs | 72 | 64, 8 | 144 |
| Unused capacity | 8 | 8 | 16 |
There is not enough space on any node to schedule a VM with 16 vCPUs. However,there is enough aggregate space.
To make space for the 16 vCPU VM, initiate a live migration of the 8 vCPU VMfrom Node 2 to Node 1. The following table shows the new VM configuration:
| Final state | Node 1 | Node 2 | Total |
|---|---|---|---|
| vCPU capacity | 80 | 80 | 160 |
| VM vCPUs | 72, 8 | 64, 16 | 160 |
| Unused capacity | 0 | 0 | 0 |
The following figure summarizes this process:
Autoscale after bin packing
After bin packing, there might be sole-tenant nodes without any VMs. In thiscase, the sole-tenant node autoscaler can remove the empty node.
Consider a sole-tenant node group with the following initial state. If you movethe 8 vCPU VM, the node group autoscaler can remove a node:
| Initial state | Node 1 | Node 2 | Total |
|---|---|---|---|
| vCPU capacity | 80 | 80 | 160 |
| VM vCPUs | 8 | 72 | 80 |
| Unused capacity | 72 | 8 | 80 |
To notify the node group autoscaler of an empty node, initiate a live migrationof the 8 vCPU VM from Node 1 to Node 1. The following table shows the new VMconfiguration:
| Final state | Node 1 | Node 2 | Total |
|---|---|---|---|
| vCPU capacity | 80 | 80 | 160 |
| VM vCPUs | 0 | 72, 8 | 80 |
| Unused capacity | 80 | 0 | 80 |
Now that Node 1 is empty, the autoscaler can remove it from the node group. Thefollowing table shows the new VM configuration:
| Final state | Node 1 | Node 2 | Total |
|---|---|---|---|
| vCPU capacity | - | 80 | 80 |
| VM vCPUs | - | 72, 8 | 80 |
| Unused capacity | - | 0 | 80 |
The following figure summarizes this process:
Limitations
The following limitations apply when manually live migrating VMs:
Capacity limitations. During manual live migration of a VM withinsole-tenancy, the VM consumes capacity from both the source sole-tenant nodeand the destination sole-tenant node until live migration completes. If thereis not enough capacity on the destination host, Compute Engine doesnot move the VM.
General limitations. Manual live migration requests might fail if thereare incompatible scheduling properties or other competing live migrationrequests. For information about how to troubleshoot this, seeVM schedulingfailures.
Managed instance group (MIG) limitations. You cannot manually live migrateVMs that are in a MIG to another sole-tenant node.
VM instance lifecycle limitations. You cannot update some properties of aVM, such as the machine type, without restarting the VM. Also, you cannotupdate these properties at the same time as you update node affinities. Formore information about these properties, seeUpdating instanceproperties.
Pricing
There are no additional charges for manually live migrating VMs. For moreinformation about how you are billed for sole-tenant nodes, seeSole-tenantnode pricing.
If a sole-tenant node is empty after the migration and you haveenabled thesole-tenant node autoscaler,manually live migrating VMs might lower your charges.
What's next
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-12-15 UTC.