[libvirt] Support QEMU Live Upgrade in Libvirt

[Eric Blake]

On 10/21/2013 08:16 AM, Zhou Zheng Sheng wrote:
> Hi all,
> 
> Recently QEMU developers are working on a feature to allow upgrading a
> live QEMU instance to a new version without restarting the VM. This is
> implemented as live migration between the old and new QEMU process on
> the same host [1]. Here is the the use case:
> 
> 1) Guests are running QEMU release 1.6.1.
> 2) Admin installs QEMU release 1.6.2 via RPM or deb.
> 3) Admin starts a new VM using the updated QEMU binary, and asks the old
> QEMU process to migrate the VM to the newly started VM.

This is NOT migration, but qemu upgrading.  Libvirt has a very strong
notion that migration is between two distinct hosts, and libvirt WILL
DEADLOCK if you attempt to migrate to the same host (because of
assumptions that libvirt makes about the control sequence of managing
the migration).

While live upgrade may use migration under the hood in qemu, we would
need to add a new API to libvirt to expose the functionality as a qemu
in-place upgrade, rather than trying to add it as a flag to the existing
libvirt migration, because it would be something we want done by a
single libvirtd rather than reusing the code paths of existing migration
which requires handshakes between two libvirtd.

> The problem is that it requires twice host memory as the original VM
> does during the upgrading. Thus comes the ongoing development of using
> the system call vmsplice() to move memory pages between two QEMU
> instances, so that the kernel can just perform page re-mapping from
> source QEMU process to destination QEMU process in a zero-copy manner.
> This is expected to reduce memory consumption and speedup the whole
> procedure. This mechanism is based on Unix domain socket, pipes and FD
> inter-process passing magic [2].

Yes, I would love to have libvirt expose this functionality; it's just
that I think we need a new libvirt API for it.

> 
> Solution #2 Adding New API virDomainHypervisorLiveUpgrade()
> 
> Another idea is to have a new API and new flow dedicated to this
> feature. In my opinion, I think it's good to have a API to do hypervisor
> live upgrade in general, and we implement it in QEMU driver using a
> special local migration procedure. We can also provide a default
> implementation for all the hypervisors using this local migration trick
> if possible. However the work to do is much more than solution #1. The
> basic functions such as ACL, XML parsing, front-end device creation,
> QEMU process handling and so on can be re-used, but it seems most of the
> code in qemu_migration.c can not be re-used without massive refactoring.
> The UUID problem discussed the solution #1 is also still need to be solved.

This is the only viable solution.  Are you interested in starting
patches along this direction?


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131022/08cddd25/attachment-0001.sig>