Open Stack

> > - historically XenAPI had migrate, Libvirt had live migrate
> > - But by end of Folsom we should have both having both
> 
> Yes, but what is the difference between the two?
Got you. I think this is right:

Migration:
- shutdown the VM
- move current disk to the destination
- start VM
- user sees reboot, and sees downtime
- resize is very similar, just starts as different flavour

Live-migration:
- snapshot running state
- copy memory + CPU state to other machine
- start
- user sees VM pause for a small amount of time
- assumes VM is on shared storage, so disks are not moved

Block-migration and live-migration:
- as above, but disk needs to be copied

Live migration can only happen when the source and destination CPU matches

Hopefully my comments make more sense now?
 
> > - Live migration was originally only nova-manage controlled
> > - Migrate is useful, but requires things like passwordless ssh
> > - We could re-implement migrate as snapshot and restart
> 
> This seems entirely reasonable.
>
> > - Above is also true for Resize
> 
> That is actually how it already happens, with the CONFIRM_RESIZE state
> acting as the quiescence point for the operation.
I thought it just did a copy and left the old image on the previous machine, but that might just be XenAPI.
I was more thinking upload the snapshot into glance as a private image, rather than do a 'behind the scenes' copy between hypervisors.

> > - But live-migrate not always possible (miss matched CPUs, etc)
> > - Ideally we would have single migrate/live-migrate API
> 
> This would be my preference. The way it stands today is entirely confusing.
Cool