[libvirt] RFC: libvirt support for QEMU live patching

[Martin Kletzander]

On Mon, Sep 18, 2017 at 10:26:40AM +0200, Peter Krempa wrote:
>On Mon, Sep 18, 2017 at 09:37:14 +0200, Martin Kletzander wrote:
>> On Fri, Sep 15, 2017 at 09:18:18AM +0100, Daniel P. Berrange wrote:
>> > On Fri, Sep 15, 2017 at 01:27:31PM +0530, Madhu Pavan wrote:
>
>[...]
>
>> > It isn't possible to make it work correctly in the general case, because
>> > both QEMU processes want to own the same files on disk. eg both might want
>> > to listen on a UNIX socket /foo/bar, but only one can do this. If you let
>> > the new QEMU delete the original QEMU's sockets, then you either break or
>> > delay incoming connections during the migration time, and you make it
>> > impossible to roll back on failure, or both. This kind of thing is not
>> > something that's acceptable for the usage scenerio described, which would
>> > need to be bulletproof to be usable in production.
>> >
>>
>> Can't we utilize namespaces for this?  Lot of the things could be
>> separated, so we could fire up a new VM that's "containerized" like
>> this, migrate to it and then fire up a new one and migrate back.  If the
>> first migration fails then we can still fallback.  If it does not, then
>> the second one "should" not either.
>
>If you are willing to accept this kind of slow-down/overhead you can
>as well as save the VM to file and restore it. This works as the upgrade
>path even now.

That way you have no fallback option, though.  The above solution could
still support live upgrade.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170918/6d6b2fb1/attachment-0001.sig>