Re: [libvirt] RFC: libvirt support for QEMU live patching

On Fri, Sep 15, 2017 at 01:27:31PM +0530, Madhu Pavan wrote: > Hi, > QEMU live patching should be just a matter of updating the QEMU RPM package > and then live migrating the VMs to another QEMU instance on the same host > (which would point to the just installed new QEMU executable). > I think it will be useful to support it from libvirt side. After some > searching I found a > RFC patch posted in Nov 2013. Here is the link to it > https://www.redhat.com/archives/libvir-list/2013-November/msg00372.html > Approach followed in above mentioned link is as follows: > 1. newDef = deep copy oldVm definition > 2. newVm = create VM using newDef, start QEMU process with all vCPUs paused > 3. oldVm migrate to newVm using unix socket > 4. shutdown oldVm > 5. newPid = newVm->pid > 6. finalDef = live deep copy of newVm definition > 7. Drop the newVm from qemu domain table without shutting down QEMU process > 8. Assign finalDef to oldVm > 9. oldVm attaches to QEMU process newPid using finalDef > 10.resume all vCPUs in oldVm > > I can see it didn't get communities approval for having problems in handling > UUID > of the vm's. To fix the problem we need to teach libvirt to manage two qemu > processes > at once both tied to same UUID. I would like to know if there is any > interested approach > to get this done. I would like to send patches on this. > > Is there any specific reason why it is not been pursued for the last 4 year? 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.

Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list