On 04/20/2015 02:49 PM, Lennart Poettering wrote:
On Mon, 20.04.15 14:43, Jóhann B. Guðmundsson ([email protected]) 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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
