それ以来、多くの作業が行われ、CRIUの機能は主な目標である Linuxコンテナの保存と復元に近づきました。 これまでのところ、標準のプロセスセットを持つ空のコンテナのみがサポートされているという事実にもかかわらず、プロジェクトが成功する運命にあると信じるあらゆる理由があります。
コンテナに興味がない場合は、別の新しい機会が必要になるかもしれません- スクリーンセッションが適している擬似端末の保存と復元のサポート。 まず、topやvimなどのいくつかのアプリケーションを実行し、セッションから切断する必要があります。 CRIUを使用してscreen-sessionおよび子プロセスを保存および復元した後、screen-sessionに再接続して、実行中のプロセスがその状態を保持していることを確認できます。 確信を深めるために、保存と復元の間に、コンピューターを再起動するか、別のマシンで画面セッションを復元できます。
ビデオクリップは、CRIUがクライアントが接続されているスクリーンセーバーでvncserverの状態を保存および復元する方法を示すリンクから入手できます。
この例は、サーバーステータスの保存と復元中に、クライアントとの接続も復元されるという事実が注目に値します。 つまり、クライアントにとっては、すべてが透過的に行われます（サービスの短い遅延を除く）。
CRIU開発のいくつかの機能。
プロジェクト開発プロセスの興味深い瞬間を使って、CRIUの新しいバージョンに関する記事を希釈することにしました。 今日は、テストとダンプファイル形式について説明します。
単体テスト
プロジェクトの成功のためには、品質テストなしではできないことは明らかです。 したがって、開発のごく初期の段階で自動テストを実装することを決定しました。 OpenVZプロジェクトで同じ機能をテストする開発に基づいています。 プロジェクトのフレームワーク内で洗練された後、単体テストのための包括的なシステムを作成しました。 各テストは個別に起動され、3つの段階を経ます。環境の準備、「デモ」、および信号の待機（テストの保存と復元後に外部から送信する必要がある）、結果の確認。 テストは条件付きで2つのグループに分けられます。 最初のグループは、ある種の一定の環境または状態を準備し、信号を見越して「眠りに落ちる」静的テストです。 2番目のグループはストリームテストであり、常に状態や環境を変更します（たとえば、データはTCP接続を介して送信されます）。
現在、CRIUユニットテストシステムには、約70の個別のテストプログラムがあります。 同時に、システムでは、現在のテストと分離されたネームスペース（つまり、実際にはコンテナ）の両方で各テストを実行できます。
データファイル形式
プログラムのアーキテクチャーの側面は、設計段階で慎重に検討する必要があります。その場合、何かを変更することは非常に困難です。 データ保存形式は、CRIUのそのようなアーキテクチャの側面の1つでした。 次の2つの主要なタスクを解決する必要がありました。
- この形式は、下位互換性を維持できるように拡張可能である必要があります。
- 他のアプリケーションのデータに簡単にアクセスできるように、形式は共通である必要があります。
最も一般的で人気のあるすべての形式を確認し、Googleが開発したprotobuf（Protocol Buffers）に決めました。さまざまなプログラミング言語のライブラリでサポートされており、その形式により下位互換性をサポートしながら新しいフィールドを追加できます。
残念ながら、新しいフィールドを追加するだけでなく、データ構造を変更する必要がある場合があります。 したがって、ダンプファイルはバージョン管理されます。
おわりに
ParallelsはCRIUプロジェクトを積極的に開発しています。次の主な目標は、OpenVZコンテナの状態を維持および復元する方法を学ぶことです。 これにより、カーネル内のOpenVZコンテナーの移行のサポートがなくなり、開発者のリソースが解放され、OpenVZプロジェクトの開発が加速されます。
habrahabr.ru/post/148413
en.wikipedia.org/wiki/CRIU
lwn.net/Articles/517079
criu.org/LXC