История изменений

Краткая выжимка из https://criu.org/Usage_scenarios

• Живая миграция контейнеров-то для чего это создавалось. Контейнер зачекпоинтился, образ перенесли на другую машину, там восстановили. Как я понимаю, при этом сценарии «без разрыва сетевых соединений» подразумевается, что между выключением старого контейнера и включением нового должно пройти совсем немного времени, тогда это взлетит (юзер заметит просто кратковременное зависание). Думаю, это киллер-фича и хотя она ещё не откатана, но такого нет ни у кого насколько я знаю.
• Ускорение загрузки сервисов, которые обычно загружаются не быстро. Например, мы делаем чекпоинт в точке, когда сервис уже стартанул, затем при необходимости просто запускаем сервис из чекпоинта вместо запуска его с нуля. Например, VNC сервер+эклипс удалось запустить за 1.5 секунды вместо 30, это грубая оценка и все цифры взяты с сайта разработчика.
• Бесшовное обновление ядра-тут я не осилил перевести, так как не знаю, что такое kexec

  When replacing a kernel on a box we can do it without stopping critical activity. Checkpoint it, then replace the kernel (e.g. using kexec) then restore services back. In a perfect world the applications memory shouldn't be put to disk image, but should rather be kept in RAM.
  

• Балансировка сетевой нагрузки. Кусок проекта, который отвечает за TCP repair можно использовать, чтобы перераспределить запросы на уровне приложения на другой сервер.
• High Performance Computing — опять-таки распределение нагрузки и своеобразные бэкапы
• Сохранение в играх, где сохранений нет.
• Дебаг продакшена без ущерба для продакшена (содрал процесс в другую виртуалку и насилуй его как хош)

Вроде как что-то и для иксов планируется, но будет делаться скорее всего в последнюю очередь, т.к. сложность Х-сервера и комерчески малоинтересно.

Краткая выжимка из https://criu.org/Usage_scenarios

• Живая миграция контейнеров-то для чего это создавалось. Контейнер зачекпоинтился, образ перенесли на другую машину, там восстановили. Как я понимаю, при этом сценарии «без разрыва сетевых соединений» подразумевается, что между выключением старого контейнера и включением нового должно пройти совсем немного времени, тогда это взлетит (юзер заметит просто кратковременное зависание). Думаю, это киллер-фича и хотя она ещё не откатана, но такого нет ни у кого насколько я знаю.
• Ускорение загрузки сервисов, которые обычно загружаются не быстро. Например, мы делаем чекпоинт в точке, когда сервис уже стартанул, затем при необходимости просто запускаем сервис из чекпоинта вместо запуска его с нуля. Например, VNC сервер+эклипс удалось запустить за 1.5 секунды вместо 30, это грубая оценка и все цифры взяты с сайта разработчика.
• Бесшовное обновление ядра-тут я не осилил перевести, так как не знаю, что такое kexec

  When replacing a kernel on a box we can do it without stopping critical activity. Checkpoint it, then replace the kernel (e.g. using kexec) then restore services back. In a perfect world the applications memory shouldn't be put to disk image, but should rather be kept in RAM.
  

• Балансировка сетевой нагрузки. Кусок проекта, который отвечает за TCP repair можно использовать, чтобы перераспределить запросы на уровне приложения на другой сервер.
• High Performance Computing — опять-таки распределение нагрузки и своеобразные бэкапы
• Сохранение в играх, где сохранений нет.
• Дебаг продакшена без ущерба для продакшена (содрал процесс в другую виртуалку и насилуй его как хош)

  Вроде как что-то и для иксов планируется, но будет делаться скорее всего в последнюю очередь, т.к. сложность Х-сервера и комерчески малоинтересно.