* Eric Blake (eblake@xxxxxxxxxx) 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@xxxxxxxxxx / Manchester, UK -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list