# OSv Kivityらが開発したユニカーネル(単一アドレス空間OS)。動的ELFリンカがLinux ABI経由の標準Cライブラリ呼び出しをOSvカーネル実装へ動的に解決し、glibcラッパー経由のシステムコールを通常の関数呼び出しとして扱うことで、ユーザ・カーネルモード切り替えを回避する。アプリケーションとカーネル(OSvライブラリ)は両方とも特権リング0で実行される。ベースイメージとアプリケーションを`build.py`で融合(fuse)してユニカーネルイメージを構築し、[[QEMU]]や[[Firecracker]]などの既存ハイパーバイザー上で実行する。制約として、複数プロセス(`fork()`・`exec()`)をサポートせず、マルチスレッドアーキテクチャのアプリケーションに用途が限られる。 [[@2021__Middleware__A Fresh Look at the Architecture and Performance of Contemporary Isolation Platforms]] では、[[Firecracker]]がサポートするユニカーネルオプションとして実験対象に含まれた。カスタムスレッドスケジューラを持つため、ffmpegの複雑なCPUバウンドワークロードやMySQL Sysbenchのマルチスレッドワークロードで著しい性能劣化を示す一方、単純なCPUベンチマークでは他プラットフォームと同等、ネットワークスループットではネイティブに次ぐ好成績(QEMU上のプレーンゲストに対し25.7%優位)を記録した。拡張HAPメトリクスでは、ハイパーバイザーを使用するにもかかわらずホストカーネル関数の呼び出しが最も少なく、「ホストへ狭いインタフェースのみを露出する」という設計意図を裏付けた。メモリ性能・起動時間は使用するハイパーバイザー(QEMU vs Firecracker)に強く依存する。 [[Unikraft]] の評価では、QEMU/KVM 上の Unikraft が Redis で約 35%、nginx で約 25% OSv より高速だった。OSv のバイナリ互換性は移植作業を減らすが、実行時のシステムコール変換とモノリシックなカーネル構成が、Unikraft の静的リンク・マイクロライブラリ構成に対する不利として比較される。(Source: [[@2021__EuroSys__Unikraft - Fast, Specialized Unikernels the Easy Way]])