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.
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
