On Mon, 20.04.15 15:10, Jóhann B. Guðmundsson ([email protected]) wrote:
> 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 ? 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
