Xen は、安全な分離、リソース制御、サービス品質の保証、および仮想マシンの移行を提供するハイパーバイザーです。
Xenプロジェクトの下で開発されているXCP-ngプラットフォームの開発者たちは、 XenソフトウェアスタックのいくつかのコンポーネントをRustで置き換える計画を発表した。
Xen ハイパーバイザー自体はまだ処理されておらず、作業は主にツールセットの個々のコンポーネントの修正に集中しています。
このプラットフォームは現在、C、Python、OCaml、Goのコンポーネントを使用していますが、その一部は古くなっており、メンテナンス上の問題を引き起こしています。Rustを使用しても、サポートされる言語の総数は増加しないことが指摘されています。なぜなら、Goで実装されているコンポーネントは1つだけであり、それもいずれ置き換えられる予定だからです。
最初の試みとして、Xen ハイパーバイザーと Rust のすべてを書き直すことを期待しないでください。 実際、ここでの目標は、言語自体を「成長」させ、プラットフォーム全体でブロックごとに置き換える方法を考えられるように、その周りの小さなコンポーネントのいくつかを置き換え始めることです。
Rustが選ばれた理由は、高性能なコードとメモリ安全性を兼ね備え、ガベージコレクタを必要とせず、低レベルと高レベルの両方のコンポーネント開発に適しており、借用チェッカーなどの潜在的なエラーを減らすための追加機能を提供しているためです。また、Rustは現在のXAPI OCaml言語よりも広く普及しているため、プロジェクトに新しい開発者を引き付けやすくなります。
第一段階では、いくつかのコンポーネントの置き換えを計画し、プロセスを解決し、ソフトウェアスタックの他の部分の置き換えに向けた準備を整えます。具体的には、現在Go言語を使用しているLinuxゲストツールをRustで書き直し、メトリクス収集のためのバックグラウンドプロセスをOCamlで記述します。
Rustは安全で高速なので、他に何が必要でしょうか？私たちは、スタックのさまざまなレベル（低レベルと高レベルの両方）で動作できるプログラミング言語も必要としています。XCP-ngで実行できる低レベルのタスクをGoやPythonで処理することは期待できませんし、同様に、高レベルのタスクをCで処理することも期待できません。Rustを使用することで、 XCP-ngスタックのあらゆる場所で利用できる可能性が広がります。
また、Rust はもはや「ニッチな」言語ではありません。 たとえば、OCaml (XAPI で使用される) は優れていてもあまり知られていないため、この言語の経験者を簡単に採用する機会が減ります。 これはまた、オープンソース コミュニティが貢献者を獲得する能力を低下させます。 私たちは、Rust がそれ (雇用と貢献の両方) の妨げになることはないと考えています。おそらくその逆でさえあります。Rust は「必要な」技術であるため、より多くの人々を引き付ける原動力です。
Linuxゲストツール（xe-guest-utilities）の再設計が必要になったのは、クラウドソフトウェアグループの管理下にあるXenプロジェクト外のコード品質と開発上の問題が原因であり、これがパッケージングやコミュニティによる開発への影響を妨げています。ツールセットの新しいバリアント（xen-guest-agent）が計画されており、可能な限りシンプルに保ち、エージェントロジックをライブラリから分離した、完全にゼロから作成されます。メトリクス収集のためのバックグラウンドプロセス（rrdd）はコンパクトで独立しているため、開発中に新しい言語を試しやすく、再設計することが決定されました。
来年、私たちはxenopsd-ngコンポーネントをRustで開発し始める予定です。これにより、ソフトウェアスタックのアーキテクチャを最適化できます。主なアイデアは、低レベルAPIに関する作業を1つのコンポーネントに集中させ、そのコンポーネントを通してスタックの残りの部分へのすべての高レベルAPIのプロビジョニングを整理することです。
最後に、さらに詳しく知りたい場合は、以下のリンクから詳細をご確認いただけます。