Select importable volumes to copy. The backend auto-snapshots each volume before transfer.
Source Volume
Snapshot
Size
Status
Created
Select
Connect the source cloud to load volume snapshots.
-
0 snapshots selected
State:OS:
Instance
OS
Vols
Source
Imported
Converted
Launched
Actions
Connect the source cloud to list its instances.
-
DemoRegion│https://keystone.demo.example/v3
Connect Source Cloud
Authenticate to the source cloud that holds the source images you want to import.
Source credentials remain session-only.
Rescue An Instance
Initiates Nova rescue with a chosen rescue image.
The VM will reboot into the rescue image. The original boot disk attaches as a secondary device. Use Unrescue to revert.
Start Snapshot Import
Confirm the disks to copy to the target cloud.
Disk
Role
Size
Device
Transport
Note: this is a Windows guest. Automated virtio-win driver injection can fail on some
Windows builds; if conversion fails, check the worker log and retry.
Starting import
Each disk appears once the server creates its job. Safe to close — progress continues on Activity.
Snapshot or fresh copy
An earlier attempt left a snapshot of these volumes.
Re-Import Blocked
A target instance was launched from these images.
Milkshake will not delete instances. Delete the launched target instance in the target
cloud, then Re-Import. Only the target images are ever deleted here, and only once no
instance derives from them.
Re-Import: delete target images
This permanently deletes the target images below.
This deletes the following target-cloud images for this instance and cannot be undone.
Your source VM is never touched. After deletion the import restarts from scratch.
Source cloud leftovers
Scratch Milkshake built on the source cloud and did not manage to remove.
These are snapshots, temporary volumes and snapshot images Milkshake created
for a migration. Nothing you or your users made is listed here, and nothing
is deleted until you confirm. Rows marked manual cannot be
proven to be ours, so Milkshake will not touch them; delete those yourself
in the source cloud if you are sure.
Migration
Left behind
Why
Action
Nothing left behind.
Delete source scratch
This deletes the resources below on the source cloud.
This deletes source-cloud resources and cannot be undone. Only resources
Milkshake created and can still prove it owns are deleted: each one is
re-read and its ownership marker checked first, and anything that does not
match is left alone. Your VMs, your volumes and your own snapshots are
never touched.
The Dirty Harry Milkshake Migration
Elapsed 00:00
"You've got to ask yourself one question..."Harry Callahan likes his milkshakes the way he likes his cloud migrations — cold, smooth, and finished before anyone realizes he pulled the trigger. So when it comes to moving VMs from one cloud to another, he doesn't negotiate with hypervisors — he just points Milkshake at the workload, squints once, and says, 'Go ahead, make my day... in your target region.'
Selected Source VM
Instance
-
UUID
-
Source
-
Source region
-
Target
-
Target region
-
Source flavor
-
Computed Target Choices
Disks To Bring Along 0 selected
Disk
Role
Size
Device
Transport
The root disk is converted and booted. Data disks are copied by source helpers in parallel and attached to the target VM; clear one to leave it behind.
Dirty Harry is a best-effort end-to-end migration attempt. Milkshake has taken a stab at the target selections above — adjust as needed, and review the result before treating the target VM as complete.
Source connection is stale or missing.Reconnect the source cloud, then reopen Dirty Harry to reload computed defaults.
Awaiting start
Elapsed 00:00
Waiting to start.
Active Log - append only
No run log yet.
Run Summary
SummaryRun not completed yet.
Console
No console log loaded yet.
Migration finished. Review the target VM before treating it as complete.
Ready to start
Welcome to Milkshake
Move your servers to the new cloud
Milkshake migrates running servers from your old cloud to the new one. You'll work through three stages, in order. This quick tour points out where each one happens.
1
Import
Copy a source disk into this project.
→
2
Convert
A worker runs virt-v2v / qemu-img.
→
3
Launch
Boot the converted image as a VM.
Before you migrate
Run through these first
01Lower DNS TTLDrop A-record TTLs at least 24 hours ahead so DNS changes propagate quickly.
02Confirm access nowVerify SSH or RDP works before you start. If you can't reach it now you won't reach it later.
03Know the passwordHave the administrator or root password recorded before you begin.
04Add SSH keysInclude extra public keys to work around post-migration auth issues.
05Plan for new IPsTarget IPs change. Update firewalls, configs, monitoring, and note current network settings.
06Open the portsEnsure target security groups allow the ingress you rely on (SSH 22 or RDP 3389).
07Quiesce writesStop or quiesce databases and write-heavy apps for a consistent snapshot.
08Back up firstMigration is not a backup. Keep the source VM until you validate the target.
When you're done: clean up to stop billing
A migration spins up billable resources on both clouds. Once a server is migrated and verified, delete what it no longer needs. On the target: the conversion worker and its scratch volume. On the source: the migration helper VM, snapshots, and temp/scratch volumes. Your migrated VM keeps running; that is the workload you moved.