[systemd-devel] systemd and process migration

[Lennart Poettering]

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

> On 04/20/2015 02:49 PM, Lennart Poettering wrote:
> >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.
> 
> There are valid migration cases beside live migration ones ( for example
> reallocation to a different host(s) due to resources etc )
>
> Think in terms of shutting down and disable container on host A, send
> relevant units ( including any network related ones ) along with the
> underlying filesystem snapshot, in the case of btrfs it would be using btrfs
> send/receive feature to host B and start it there.
> 
> What I'm wondering if you would be opposed to supporting those use cases ?

Well, but non-live migration is easy: you simply stop the container,
transfer the container tree to the destination, and start it there again.

We support migrating offline containers like that already to a certain degree
with "machinectl export-tar" and "machinectl import-tar". And we
probably could even add more support for this, for example I think a "machinectl
migrate" command would make a lot of sense that basically connects a
local "machinectl export-tar" with a "machinectl import-tar" on
another host via ssh. I'd be totally on board with adding more support
for things like that. It's really just the *live* migration part I
have issues with, because I don't trust we could deliver the promise
it makes.

Lennart

-- 
Lennart Poettering, Red Hat