[systemd-devel] systemd and process migration

["Jóhann B. Guðmundsson"]

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 ?

JBG