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