[libvirt] Support QEMU Live Upgrade in Libvirt

[Eric Blake]

On 10/22/2013 09:25 AM, Eric Blake wrote:
> 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).

More precisely, libvirt _would_ deadlock if we didn't prevent
migration-to-self, so instead we actively reject that configuration at
the libvirt layer and fail early.  But we aren't about to remove that
safety valve just to allow qemu live upgrade through the libvirt
migration API.

>> 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/ee965acb/attachment-0001.sig>