Re: [libvirt] Support QEMU Live Upgrade in Libvirt
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
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)