[libvirt] [PATCH 0/6] Post-copy live migration support

[Dr. David Alan Gilbert]

* Eric Blake (eblake at redhat.com) wrote:
> On 09/23/2014 08:09 AM, Cristian Klein wrote:
> > Qemu currently implements pre-copy live migration. VM memory pages are
> > first copied from the source hypervisor to the destination, potentially
> > multiple times as pages get dirtied during transfer, then VCPU state
> > is migrated. Unfortunately, if the VM dirties memory faster than the
> > network bandwidth, then pre-copy cannot finish. `virsh` currently
> > includes an option to suspend a VM after a timeout, so that migration
> > may finish, but at the expense of downtime.
> > 
> > A future version of qemu will implement post-copy live migration. The
> > VCPU state is first migrated to the destination hypervisor, then
> > memory pages are pulled from the source hypervisor. Post-copy has the
> > potential to do migration with zero-downtime, despite the VM dirtying
> > pages fast, with minimum performance impact. On the other hand, one
> > post-copy is in progress, any network failure would render the VM
> > unusable, as its memory is partitioned between the source and
> > destination hypervisor. Therefore, post-copy should only be used when
> > necessary.
> 
> Thanks for tackling the proof of concept patches.
> 
> > 
> > Post-copy migration in qemu will work as follows:
> > (1) The `x-postcopy-ram` migration capability needs to be set.
> 
> This right here is a problem.  Qemu has explicitly documented that
> anything beginning with x- may be subject to change or going away in a
> later release, so libvirt policy has been to delay any patches
> targetting an x- interface until upstream qemu renames it to drop the x-
> to signify that it is now stable.  So we can review your patches, but
> can't apply them yet.

It is a shame that libvirt doesn't have a similar mechanism which could
be used in conjunction with qemu.  My reason for currently leaving the x-
in place is that while I don't expect the QML side to change, it seemed
fair to put a new feature into QEMU without locking it down for the
first cut.   This seems to be normal practice in QEMU but invariably
means that libvirt support is delayed.

Dave

> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 


--
Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK