30分で論文流し読みシリーズ 8「Multi-hypervisor Virtual Machines: Enabling an Ecosystem of Hypervisor-level Services」

https://www.usenix.org/system/files/conference/atc17/atc17-gopalan.pdf

  • 実際の所要時間

    • 二時間

  • 課題

    • IaaSでは(仮想)ハードウェアを含め多種多様なサービスを組み合わせて使えるようになっているが、VMMレベルのサービスはそうではなく、通常はベンダ提供の単一のものを使う。
    • 多種多様なVMMレベルのサービスを同時に複数使いたいとすると、次のような方法を使う必要がある。
      • 必要なだけ機能を詰め込んだVMMを作る: VMMが大きすぎることがセキュリティリスクになる
      • メインVMMからモジュール形式でサービスを提供する方法: 実現できる機能に限りがある。ページマッピングやVCPUのスケジューリングなどの低レベルの機能を提供するのが難しい。
      • VMMを好きなだけネストする: ネストが深ければ深いほど性能劣化が激しい。それに加えて、あるVMMから見てguestまでのレイヤが厚ければ厚いほどguestから得られる情報が減る。たとえばメモリのコンテンツなど。

  • 解決方法概要

    • Span-virtualizationという新アーキテクチャを採用したVMMを使う
      • 無改変のguestに対して、より細かいVMMサービスを提供できる
      • 個々のguestに対して別のサービスを提供できる
  • 解決方法詳細
    • メインVMM(L0)を用意して、その上にguestおよび各種サービス用のVMM(L1)を任意の数だけ配置する
    • guestはL0上に直接乗っているので、L0から見えるguestのメモリはすべてL0を介してL1に見せられる
    • L1が制御できるリソースはメモリ、VCPU、I/Oデバイスの3つ 　 - メモリ: 各L1にguestの物理メモリ上の任意の領域を割り当てられる。guestの物理メモリに対して所定のイベントが発生すると、イベントが発生したメモリ領域に対応するL1にその旨通知する
      • VCPU: 全CPU上の全VCPUは単一のL1によって制御できる。VCPUのイベントが発生するとL0は対応するL1にその旨を通知する
      • I/Oデバイス: 個々のguest上の個々のI/Oデバイスはそれぞれ単一のL1によって制御できる。guestにI/Oイベントが発生するとL0は対応するL1にその旨を通知する
    • あるリソースを制御するL1はL0から自由に切り替えられる
  • 効果
    • ネットワークモニタリングとVM introspectionサービスを実現できた。それに加えてゲストミラーリングとVM introspectionが実現できた
    • 性能インパクト: 全体的にはCPU intensiveなワークロードでは性能劣化がそれほどないがI/O intensiveなものでは劣化が激しいという予想通りのもの。詳細は8節を参照
  • 感想
    • ハードウェアの機能を活かした曲芸のオンパレードで非常に面白かった。が、流し読み(実装詳細は見てない)にもかかわらず読むのにめちゃくちゃ時間がかかってしまった
    • 多種多様なサービスの組み合わせをspanとnestedで性能比較した結果が見たイ。とくに3個以上のサービスを提供する場合。
    • table2のspanについてのL2って明に書いてないけどguestのことと考えてよい?
    • 上記のメインVMMからモジュール形式でサービスを提供する方法についての論文が読みたくなった