Live migration moves a running Droplet from one physical machine to another in its datacenter without requiring a reboot. We use live migration to minimize disruption and downtime during events like normal infrastructure and network maintenance, software upgrades, and hardware failures.
Live migrating a Droplet follows this general process:
When the migration is triggered, the system uses a scoring algorithm to find an available physical host in the same datacenter based on the Droplet’s size (CPU, memory, disk).
The system prepares the target hardware and begins copying the Droplet to its new location. This is more complicated than it may seem; because the Droplet is still running, its disk and memory may change during the migration.
To account for this, the system monitors the disk to track modified blocks. Once the initial copy is complete, it re-copies the modified blocks and repeats the process until all blocks are moved, at which point new writes will take place on the new hardware. If a Droplet is writing rapidly to disk during a migration, the system applies a temporary throttle when there are only a smaller number of modified blocks remaining so the migration can complete.
A very similar process occurs for memory pages, though automatic throttling in this case is significantly shorter than with disk throttling, and should be unnoticeable.
The system updates the Droplet’s records to point to its new location.
Once the migration is complete, we can access the original hardware for maintenance or other events without any effect on the Droplets that were originally running there.
Whenever possible, we give advance notification of live migrations to users, even though we expect minimal impact to Droplets. We also typically schedule planned live migrations outside of business hours.
Live migration doesn’t change a Droplet’s data or configuration, like its software or network settings. This means that its IP address and all other internal Droplet data will remain the same after a migration. Migrations are run at the block-level, so there is also no risk that any files will be lost or corrupted during the process.
In some cases, live migrations fail, but this does not affect the source Droplets. After a failure, we either attempt the live migration again or send a notification that we need to briefly shut down the Droplet to migrate it.
There may be a momentary slowdown in the read/write performance of the Droplet’s disk while the transfer is in its final stages. If you’re concerned about disk throttling, or if you prefer offline migration, you can choose to shut down the Droplet before its migration window. Shutting down or otherwise reducing the load of a Droplet during its migration window isn’t necessary, but it will not negatively impact the migration.