> > - 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp