[systemd-devel] systemd and process migration

[Lennart Poettering]

On Mon, 20.04.15 14:43, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:

> >>I thought fancy enterprise features like this was on hold until networkd was
> >>"ready" ?
> >This is not an enterprise feature. It's a promise one cannot keep. We
> >will not add code to systemd that works often but not always, and CRIU
> >is certainly of that kind.
> 
> "We will not add code to systemd that works often but not always" you need
> to explain this a bit further since we might have different perception on
> this since from my perception such code has been added to systemd in more
> then one occasion anyway I was not advocating for the use/inclusion of CRIU
> but something built in.
> 
> We should be able to support non live migration out of the box if live
> migration is a pandora's box or are you opposed to that as well?

Well, sure, it would be nice, but I also believe it is not realistic
to support. For example, if you have network protocols you can
probably still live with their connections being severed during
migration, but this is really not the case for local IPC connections,
like bus connections. Restoring the state for that is an immense
amount of work, and I am pretty sure that it is not desirable to add
code for this to all IPC systems like this just because of CRIU.

Also, I doubt this really is such an important thing to have. I mean,
containers are not VMs, they are easily instantiated and shut
down. You can socket actviate them, and have them exit-on-idle. If you
accept that containers are a much more volatile, dynamic thing that
VMs then live migration becomes much less attractive.

I am pretty sure you can make CRIU work for a lot of cases. But it's
obvious that it will fail to save/restore a large number of cases,
including any that involve dbus or any other non-trivial IPC (X11, PA,
mysql connections, ...), hence it's really a promise you cannot keep,
and I will not support something with systemd that is pretty obviously
unsupportable.

Lennart

-- 
Lennart Poettering, Red Hat