エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)

Copyright(C) Software Research Associates, Inc. All Rights Reserved.

エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1a

hbstudy #17 (2010/11/26 ハロー会議室＠新宿)

ネットワークシステムサービス本部ネットワーク運用・構築部

長谷川猛 (hasegaw at sra.co.jp)

Twitter : @hasegaw

※本資料中の解説内容は、弊社としての統一的な見解を示すものではありません。

2

自己紹介

所属所属

興味分野興味分野

株式会社SRAネットワークシステムサービス本部ネットワーク運用・構築部

現在は提案支援業務に携わる

特にLinux や仮想化技術を得意とする、

雑食系システムエンジニア

主な著書主な著書『Xen 徹底入門』初版、第二版（2007、2009年翔泳社）共著

『LDAP Super Expert』（2006年技術評論社）寄稿

『萌え萌えうにっくす！ネットワーク管理ガイド』（2003年 MYCOM）

氏名氏名長谷川猛 (HASEGAWA Takeshi)

Twitter: @hasegaw

4

想定される参加者

• 想定される参加者– 仮想化技術に興味を持っている方

– Linux用仮想化技術『KVM』の仕組みを知りたい方

– KVMの内部構造を調査する”とっかかり”を掴みたい方

• 本セッションへのキャッチアップに必要なスキル※”参加条件”ではありません– IAシステムの基本知識

– C言語の読解能力

– オペレーティングシステム(OS)のしくみ

5

Agenda

• 現在のx86における仮想マシンの方向性– x86 仮想マシンの概要

– x86 仮想マシンにおけるon-goingなトピック

• いまさら聞けない仮想マシンのしくみ– 仮想CPU – 仮想マシンのメモリ管理

– 仮想ハードウェア– virtio 仮想デバイス

• FreeBSD virtio


現在のx86における

仮想マシンの方向性

7

そもそも「仮想マシン」とは何か(1/2)

ソフトウェアによって仮想的に構築されたコンピュータ。

仮想化技術における仮想マシンは、OSが動作する実際の

コンピュータをソフトウェアによって仮想的に構築したものである。

1台のコンピュータを複数の仮想マシンに分割することで、複数の利用者が同時に利用したり、異なるOSを並列に実

行させたりすることができる。

http://e-words.jp/w/E4BBAEE683B3E3839EE382B7E383B3.html （IT用語辞典, 仮想マシン）より引用

http://e-words.jp/w/E4BBAEE683B3E3839EE382B7E383B3.html

8

そもそも「仮想マシン」とは何か(2/2)

• 今日、対象とする「仮想マシン」 (System Virtual Machine)– x86ハードウェアの上で動くソフトウェア（ソリューション？）

– x86ハードウェアを再現する

– x86ハードウェア用のソフトウェア、OSが「そのまま」動く

– VMware, Hyper-V, Linux KVM, Xen各種, VirtualBox, QEMU, Parallels, …

• とりあえず思いつく「その他の仮想マシン」– 言語VM (Process Virtual Machine)

• Java, .NET Framework, YARV(Yet Another Ruby VM), …

– おもちゃのエミュレータ、古いコンピュータのエミュレータ• MAME, NES, ANEX86/T98, PC98E, …

9

ハイパーバイザー、仮想マシンモニタとは

• コンピュータで複数のオペレーティングシステム(OS)を実行する際に、調停するためのソフトウェア

• 仮想マシンモニタ(Virtual Machine Monitor, VMM)等とも呼ばれる

ハードウェアハードウェア

ゲストＯＳゲストＯＳ

–ゲスト

–仮想マシン, VM

ゲスト上のプロセスゲスト上のプロセス

–ハイパーバイザ

–仮想マシンモニタ(VMM)ハイパーバイザハイパーバイザ

ゲストＯＳゲストＯＳ

ゲスト上のプロセスゲスト上のプロセス

10

仮想化技術から見たx86の歴史

Intel 80861978

vSphere 4.1, RHEV 2.2, EL6デバイスSR-IOV対応製品2010

vSphere 4.0, Hyper-V 2.0, EL5(KVM)/RHEVオーバーヘッド削減の努力2009

Intel 803861985

|

Xen 2.02004

Hyper-V 1.0メモリ仮想化支援(EPT/NPT)2008

VMware設立1998

RHEL5 (Xen)IOMMU仮想化支援(VT-d)2007

VMware Server, Xen 3.0, KVM開発開始2006

Microsoft Virtual Server R2Intel VT(VT-x, VT-i)2005

x86ハードウェアの仮想化対応

仮想マシンの幕開けRobert P. Goldberg - Survey of Virtual Machine Research

1975

Xen 1.0, XenSource設立2003

x86仮想化ソフトウェア年

SRA創立(1967)

SRA, VAX-11導入(1980)

11

活性化してきたx86の仮想マシン技術

• Xen Hypervisorがもたらしたもの「Windowsが動く」オープンソースのハイパーバイザーのひとつ Intel VT, AMD-Vを使った代表的な仮想マシン実装

専用カーネルを使う「準仮想化」による高いパフォーマンスHyper-Vのアーキテクチャのベースにもなっている

• ハードウェアによる仮想化支援機能の充実 VT-x, VT-I, AMD-V … CPUの仮想化

• さらなる仮想化支援機能の強化 VT-x, VT-I, AMD-V … さらなるパフォーマンス向上 VT-d, AMD IOMMU… 仮想マシンからのPCIデバイスアクセス EPT/NPT … 仮想マシンのメモリアクセス高速化「カーネルはX86用OSを使用し、I/O部分のみを準仮想化」する方向へ

12

準仮想化 vs 完全仮想化


ハイパーバイザ(VMM)

（ハードウェア支援なし）


（ハードウェア支援なし）

仮想化専用

kernel

仮想化専用

kernel x86 H/W用

kernel

x86 H/W用

kernel


（ハードウェア支援あり）


（ハードウェア支援あり）

x86 H/W用

kernel

x86 H/W用

kernel

ハードウェアレベル仮想化支援機能ハードウェアレベル仮想化支援機能

KVM, VMware, …Xen

13

クラウドに求められる仮想マシンの特性

• クラウドコンピュータ – “規模”が実現するシステム運用ファシリティ →ラック、データセンタ、コンテナ単位での導入

インシデント駆けつけ型保守 → 計画的保守へ

システム全体としての可用性、各ノードの柔軟な構成・運用が必要

• 物理マシンと比べ魅力的な“仮想マシン”の特性導入後からの構成変更、レプリカの作成が容易

手元でなくとも“完全な管理” ← 管理対象の増化（OSインスタンス、物理数）

サービス提供用OSの起動・停止が容易

（ソフトウェアで実現でき、専用ハードウェアなどが不要）

仮想化によるパフォーマンス低下• 少なからずオーバヘッドが発生 → 運用と性能のどちらを取るか？

14

On-going なトピック

まだまだ解決すべき課題は山盛り

• “ゲストOS”としての各OSの仮想化サポート– 仮想環境むけデバイスドライバの標準装備化– 仮想環境における時間管理（Dynamic Tick、PV Timer）

• よりシームレスな統合管理– ノード管理ツールの強化– クラウドとしてのリソース管理ツールVMwareを買うエンドユーザ、内製するサービスベンダ

• 性能が求められる環境に対応するハードウェア– Device Passthrough– SR-IOV

• より安価・高速・高信頼なストレージシステム– 実は仮想マシンにとって一番大事


いまさら聞けない「仮想マシン」のしくみ

16

qemu-kvmqemu-kvm

そもそもKVMとは何か

Linuxのカーネルモジュールとして実装された仮想マシン技術おもに下記２コンポーネントにて構成される

Linux Kernel Linux Kernel

Virtual MachineImage

Device Emulator

HardwareHardware

System callsSystem callsernel-basedirtualachine

ernel-basedirtualachine

KVM Device DriversDevice Drivers

Kernel-based Virtual Machine (KVM)– カーネルモジュールとして実装– 仮想マシンのVirtual CPU実行

qemu-kvm– ユーザモードプロセスとして実装– VMのメモリイメージを保持

– IA-32システム周辺ハードウェアのエミュレーション

– I/O機能 (ディスク、ネットワーク等)

17

QEMUとqemu-kvm

• QEMU … オープンソースのPCエミュレータ– ソフトウェアによるCPUおよび関連チップを再現

• ソフトウェアCPU: x86 32bit/64bit, IA64, ARM, SPARC, PowerPC, MIPS

– Bochs由来のBIOSを搭載

– ユーザモードで動作するプログラム

• QEMU由来の仮想マシンソフトウェア群– qemu-kvm (KVMを用いてCPUの仮想化支援技術を利用するQEMU)– Xenに含まれるqemu-dm (Xen HVMドメイン用ハードウェアエミュレータ)– VirtualBox (Sunによる仮想マシンソフトウェア)– kqemu (カーネルモードを使用する、より高速なQEMU)

18

(参考) QEMUを使ったVMM

Type-1

hardware

Hypervisor

VM VM VM

Type-2

hardware

OS

VM

Hypervisor

VM 現Oracle VM(ブランド名)

Sun xVM (ブランド名)

Bochs (2 )

QEM U (2)

kQEM U

一部処理(CPU処理)

をkernel modeに持っ

ていって高速化した版

QEMU。KVM登場によ

りdiscon

各種CPUエミュレータ+デバイスエミュレー

タ。Bochsと比べ高速なのがウリ。デスク

トップ用、開発者用ともいえる

PC/AT互換機を再現できる、ほぼ最初の

CPUエミュレータ+デバイスエミュレータ

KV M (1)

V irtualBox (2 )

Sunが開発した

VMM+QEMUのハー

ドウェアエミュレータ

部分による仮想化ソ

フトウェア。とはいえ

H/Wエミュ部分に随

分Sunのコードが入っ

ているのが特徴的？

デスクトップ用

Xen 2 .x (1 )

PC/ATを再現するのではなく、OS側を

VMMにあわせる「準仮想化」を採用した

VM

Xen 3 .0 (1)

Xenの上でPC/ATを

再現できるように

なった最初のバー

ジョン

qemu-dm

Xen用にforkされ改造

されたもの

BIOSコード流用

fork→merge→

disconfork→merge

qemu-kvm

Linux上でIntel

VT(AMD-V)を利用

するためのカーネル

モジュール。CPU仮

想化、メモリ仮想化

の機能を提供。

QEMUのCPUエミュ

レータを使わずに

KVMを使う。KVMが

H/Wアクセスを検出

した際にqemu-kvm

がH/Wエミュレーショ

ンする仕組み

fork

Xen 4 .0 (1)

Oracle V MServer (1 )

XenServer (1 )

H/W emuコード

大量流用

xV MHypervisor (1 )

×

×コンフリクト

SunがOpenSolaris用

にパッケージした

オープンソース版

Xen。Oracle VM

Serverとコンフリクト

するためdiscon.

Oracleがオープン

ソース版Xenをベー

スに開発。

独自のWindows用ド

ライバ、管理ツール、

Oracle製品サポート

などの特徴を持つ

fork

一部mergeXen開発者達がXen

をベースに開発。独

自のWindows用ドラ

イバ、管理ツール、

Citrix製品との親和

性などの特徴を持つ

fork fork

19

KVMが必要とするハードウェアスペック

• 最低要求事項– CPU

• x86_64 or IA64 (64bit ほぼ必須)• 仮想化支援技術必須 (Intel VT or AMD-V)

– マザーボード、チップセット• BIOSレベルで仮想化支援技術が有効であること

– メモリ• ホストOS使用分: 512MB以上

• ゲストOS使用分: 512MB以上

– その他Linuxカーネルの動作要件を満たすこと

• 推奨スペック– Intel EPT (Extended Page Tables)/AMD NPT(Nested Page Tables)

20

Red HatのKVMによりサポートされるゲストOS

• virtioドライバ（ゲストOS用ドライバ）が提供されており、パフォーマンスが期待できるもの– EL3.9 (32bit, 64bit), EL4.7(32bit, 64bit), EL5.3 (32bit, 64bit)– Windows Server 2003 (32bit, 64bit), 2008 (32bit, 64bit)– Windows XP (32bit) – Network driver only– Windows 2000=NG Windows Vista, 7=?

• RHEL5により公式サポートされるもの– EL3(32bit), EL4(32bit or 64bit), EL5(32bit or 64bit)– Windows Server 2003 (32bit, 64bit), 2008 (32bit, 64bit)– Windows XP (32bit)

※公式なサポート状況はRed Hatにご確認ください

21

XenとKVMのざっくりした比較

• ハイパーバイザー(VMM)の機能– Xen: Hypervisorと管理OSの独立性が高い

• 管理OSへの攻撃が難しい?

• XSM (Xen Security Modules) – LSM (Linux Security Module) のXenバージョン

– 標準XSMモジュール： dummy, ACM, FLASK（どれか一つを排他利用）

– Linux: Hypervisorと管理OSが融合している

• 比較的コンテキストスイッチが少なく高速

• SELinuxを利用したMAC

• ゲストのサポート状況、サポート方法– Xen: Linux, NetBSD/FreeBSD, OpenSolaris, Windows

• Xen用カーネルを作成するアプローチ、PVドライバのみ移植するアプローチ

– KVM: Linux, Windows• virtioドライバを移植するアプローチ

• その他、virtioドライバが存在するOSの例: MonaOS(!), NetBSD

22

コンピュータを構成する３大コンポーネント

物理マシン、仮想マシンともに基本的な構成は同じ

I/ODevices

I/ODevices

CPU CPU

SystemMemory

SystemMemory

中央演算装置

プログラムを実行するための電子回路。演算処理の中心

主記憶装置

実行するプログラムや演算の結果を一時保存する為の領域

入出力装置

コンピュータに接続された周辺回路。キーボード／マウス、ビデオ、

外部記憶、その他I/F


CPUの仮想化

I/ODevices

I/ODevices

CPU CPU

SystemMemory

SystemMemory

24

x86のプロテクトモード基礎知識

• リアルモード(16bit)• 16ビットまでのデータ操作・メモリ操作、セグメント単位のメモリ管理

• プロテクトモード(32/64bit)• 32/64ビットの操作

• ページ単位のメモリ管理モード

• プロテクションリング

– X86 CPUに実装された権限機能

– Ring 0: 特権モード

– Ring 1～2: 使わないのが通例

– Ring 3: ユーザモード

Applications – Ring 3

Operating System Services – Ring 1, 2

Operating System – Ring 0

x86 Protection Rings

NTOSKRNL

linux-kernel

Apache

calc.exe

25

QEMUによるVMの動作原理

• QEMU の基本動作– VM上のコードを実行する前に、コードを確認する

• CPU上で直接実行できない命令（例：仮想メモリの設定、権限管理）

対応するルーチンを実行

• 通常の命令（例：仮想メモリに対する操作、演算など）

直接実行

– VM上のコードが実行された時にCPUで例外を捕捉する• VMの権限で直接実行できない命令（例：I/Oポート操作）

デバイスエミュレータで原因を解析、エミュレーションしVM実行を継続

• ゲストに未割り当てのページアクセスメモリを割り当て、VM実行を継続

26

Intel VT, AMD-Vの基礎知識

• 仮想マシン実行用モードの追加メモリ上の仮想マシン情報を基に、VMを実行する

必要に応じて制御をゲストから奪い、VMM(仮想マシンモニタ)へ戻す

linux-kernel

kvmGuest kernel

VMX root VMX nonroot

仮想マシンへの突入VMLAUNCH/VMRESUME (Intel)

VMRUN (AMD)

仮想マシンからの復帰特権命令、I/O操作等→VMEXIT

VMCS VMCB(AMD)

VMCS VMCB(AMD)

VMCS VMCB(AMD)

Apache

calc.exe

qemu-kvm

27

qemu-kvmによるVMの動作原理

• qemu-kvmの基本動作 (KVM使用時）KVMを使用してVMを実行 (VMRESUME/VMRUN)

通常の命令であれば直接実行される

VM内で特殊命令にあたると制御が戻る(VMEXIT)

qemu-kvm内のハンドラが必要な処理を行う

– I/Oポートの読み書き、MMIOなどハードウェアアクセス

– 一定時間オーバー（タイムスライスを使い切った）

– VM内からのVMM呼び出し

– VMの実行失敗、ほかエラーなど

28

qemu-kvmにおける制限事項

• 仮想化支援技術が必須– Intel VT(VT-x) もしくは AMD-V

従来x86 CPUの特権モードに加え「VMX root」「VMX nonroot」を提供

VM専用空間(VMX nonroot)でVM上の命令を実行

未実装命令・VMMによる処理が必要な命令にあたったら、VMM側(VMX root)に制御を戻す

• 仮想化支援技術にともなうゲストの制限– qemu-kvmは、基本的に実CPU上でVMを直接実行する

– 実CPUが実行可能なコード（OS, アプリケーション）のみ実行可能

– 実際に搭載したCPUができない事はVM内でも「できない」

• 非対応命令を例外などとしてトラップし、エミュレーションできる“場合”もある

29

KVM カーネルが提供するインターフェイス

• /dev/kvm … 特殊なデバイス– ioctl()で操作する

– 主な機能• 新しいVMの作成

• VMへのメモリ割り当てリクエスト

• vCPUのレジスタの読み書き

• vCPUへの割り込み挿入

• vCPUの実行開始

• I/Oハンドラの登録

• qemu-kvmが/dev/kvmを通してVMを制御する

30

599 int kvm_run(CPUState *env) 600 { 601 int r; 602 kvm_context_t kvm = &env->kvm_state->kvm_context; 603 struct kvm_run *run = env->kvm_run; 604 int fd = env->kvm_fd; 605 606 again: ……… 610 } 626 r = ioctl(fd, KVM_RUN, 0); 645 if (1) { 646 switch (run->exit_reason) { 647 case KVM_EXIT_UNKNOWN: 650 case KVM_EXIT_FAIL_ENTRY: 653 case KVM_EXIT_EXCEPTION: 660 case KVM_EXIT_IO: 661 r = kvm_handle_io(run->io.port, 662 (uint8_t *)run + run->io.data_offset, 663 run->io.direction, 664 run->io.size, 665 run->io.count); 666 r = 0; 667 break; 668 case KVM_EXIT_DEBUG: ……… 694 default: 701 } 702 }

kvm-main.c1370 static long kvm_vcpu_ioctl(struct file *filp,1371 unsigned int ioctl, unsigned long arg)1372 {1373 struct kvm_vcpu *vcpu = filp->private_data;1374 void __user *argp = (void __user *)arg;1375 int r;1376 struct kvm_fpu *fpu = NULL;1377 struct kvm_sregs *kvm_sregs = NULL;13781379 if (vcpu->kvm->mm != current->mm)1380 return -EIO;1381 switch (ioctl) {1382 case KVM_RUN:1383 r = -EINVAL;1384 if (arg)1385 goto out;1386 r = kvm_arch_vcpu_ioctl_run(vcpu, vcpu->run);1387 break;1388 case KVM_GET_REGS: { ….1404 break;1405 }

qemu-kvmからのKVMモジュール操作

VMを実行後何がおきたかを確認し、対処

仮想化支援機能を使用してVMを実行する

31

CPU仮想化のまとめ

CPUの仮想化支援機能 Intel VT-x/VT-I AMD-V x86のリングプロテクションに加え、さらにVMMをサポートするための

命令セットが追加されている

KVMカーネルモジュール CPUの仮想化支援機能を使用して、おもに以下の処理を行う

• VM起動

• VM停止

• ハードウェアI/Oが発生したときのディスパッチ

• メモリの管理

制御はioctl()を使って行う


仮想マシンのメモリ管理

I/ODevices

I/ODevices

CPU CPU

SystemMemory

SystemMemory

33

メモリ管理

• 非仮想化環境（ベアメタル + OS）では– OSが物理メモリすべてを認識し、管理する

– OSは、物理メモリの一部をカーネル用とし、

各プロセスの要求に応じてメモリを割り当てる

• 仮想化環境では– VMMが物理メモリすべてを認識し、管理する

– VMMがVMに対して指定容量のメモリを割り当てる

– VMは割り当てられたメモリが物理メモリ全体と信じ動作する

– ゲストOSは、VMに割り当てられたメモリからカーネル用、

各プロセス用のメモリ空間を確保する

34

メモリ管理、ちょっと寄り道(1/2)

現在一般的なシステムにおける、物理メモリ空間と仮想メモリ空間

0GiB -

OS Kernel

Process 2

Process2 から見える

メモリ空間物理メモリ

OS Kernel

Process 1

Process 2

Process 3

Process 4

64GiB -

OS Kernel

Process 1

Process1 から見える

メモリ空間

35

メモリ管理、ちょっと寄り道(2/2)

procedure CR3Read(var p : Pointer);asm

mov p, cr3end;

// エディットボックスEdit1の内容が変更されたら、その内容を// 文字列バッファbuffにコピーする。procedure TForm1.Edit1Change(Sender: TObject);begin

StrPCopy(@buff, Edit1.Text);end;

// Button1がクリックされたら、文字列バッファがどこにあるか// アドレスを表示し、また、バッファ上の文字列を表示する。procedure TForm1.Button1Click(Sender: TObject);var

s: String;begin

s := format('バッファは0x%pにあります。', [ @buff ]);memo1.lines.add(s);

s := format('このアドレスには文字列 %s が記録されています。',[ PChar(@buff) ] );

memo1.lines.add(s);end;

// Button2がクリックされたら CR3 を読み取り、表示する。// ※特権命令があるため、実際には成功しないprocedure TForm1.Button2Click(Sender: TObject);var

p: Pointer;s: String;

beginCR3Read(p);

s := format('このプロセスのCR3は %p を指しています。',[ p ] );

memo1.lines.add(s);end;

サンプルダウンロード先http://bit.ly/aPn3zm

http://bit.ly/aPn3zm

36

x86におけるメモリ管理の基本 #1

CSCS

System Registers

LDTRLDTR

TRTR

CR3CR3CR2CR2

CR1CR1CR0CR0

GDTRGDTR

IDTRIDTR

Controll Regiesters

System Address Registers

floating point number registers

・・・

Debug Registers

DR0DR0 ～ DR7DR7 TR3TR3 ～ TR7TR7

EAXEAX

EBPEBP

EBXEBX

ECXECX

EDXEDX

Main Registers

Base PointerESPESP

ESIESI

EDIEDI

Stack Pointer

EIPEIP

EFLAGSEFLAGS

Flag Register

Segment RegistersCSCS

DSDS

ESES

SSSS

FSFS

GSGS

Instruction Pointer

General Registers

（参考） 486プロセッサに実装されているレジスタセット

作成にあたっての参考資料: はじめて読む486 (1994年株式会社アスキー)

37


Page DirectoryPage Directory

Page TablePage Table

Page

（参考） x86プロセッサにおけるページングモードのしくみ

物理ページ

CR3

Page

Page

Page

…


メモリアクセス

要求

Page Directory

Page Table

仮想メモリアドレス空間（0～4GB）を1024等分し、各領域(4MB)のページ

割当を管理するページテーブルのポインタ、関連フラグを保持する。

（ＯＳが作成、管理）

各領域(4MB)をさらに1024等分し、各領域(4KB)がど

の物理ページに割当されているかを示すポインタや関連フラグを保持する。

（ＯＳが作成、管理）

Control Register 3

ＣＰＵが仮想メモリアクセスする際、ページウォークに使用すべきページディレクトリを設定する。

（ＯＳが設定）

38



要求 CR3

Page DirectoryPage Directory




10bits(2^10=1024)分のテーブル

PDE(32bits) × 1024 = 4KB (1page)

10bits(2^10=1024)分のテーブル

PTE(32bites) = 4KB (1page)

Page

プロセスが実際にアクセスすべきメモリ空間(12bits) 2^12=4KB

10+10+12=32bitのメモリ空間を2段のぺージテーブルで表現(64bit環境では4段のページテーブルで48bitアドレス空間を表現) Linux (or other OS) Kernel

process

PTPD PTPD PT PT

Page Page Page Page

process

PTPD PTPD PT PT

Page Page Page Page

process

PTPD PT PT PT

Page Page Page Page

qemu-kvm

PTPD PTPD PT PT

Page Page Page Page

CR3 IP …CR3 IP …CR3 IP …CR3 IP …process 4

プロセステーブルprocess 1process 2process 3

そのプロセスの仮想メモリ空間と物理メモリ空間の対応を定義する

Page Directoryのポインタ、他

39


出典: Intel® 64and IA-32 Architectures Software Developer’s Manual Volume 3A

64ビットモードの場合は4段のページテーブルでページング

64ビットモードの場合は4段のページテーブルでページング

40

仮想化環境におけるメモリ利用イメージ

非仮想化環境の場合

0GiB -

OS Kernel

Process 2

ユーザプロセスから見えるメモリ空間物理メモリ

Hypervisor

Guest OS 1

Guest OS 2

Guest OS 3

Guest OS 4

OS Kernel

Process 1

Process 2

Process 3

Process 4

ゲストOSの

メモリ空間

OS Kernel

Process 1

Process 2

Process 3

Process 4

64GiB -

仮想化環境の場合

物理メモリ

41

KVM, QEMUにおけるVMへのメモリ領域割当 #1

• VMのメモリ空間はqemu-kvm( QEMU)のデータ領域として確保される– 他の一般なプロセスと同じ扱い

• Linuxカーネルから見ればただのユーザスペースのデータ領域に過ぎない

• VM割り当てメモリサイズの上限– qemu-kvm + VM Imageの合計が

プロセス最大メモリサイズに収まる必要がある

– 32bit / 32bit PAE …… < 4GB– x86_64 …… 4GB以上可能

Linux Kernel

qemu-kvm (or QEMU)

VM Image

process

process

process

物理メモリ

42

514 void *kvm_create_phys_mem(kvm_context_t kvm, unsigned long phys_start, 515 unsigned long len, int log, int writable) 516 { 517 int r; 518 int prot = PROT_READ; 519 void *ptr; 520 struct kvm_userspace_memory_region memory = { 521 .memory_size = len, 522 .guest_phys_addr = phys_start, 523 .flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0, 524 }; 525 526 if (writable) 527 prot |= PROT_WRITE; 528 530 ptr = mmap(NULL, len, prot, MAP_ANONYMOUS | MAP_SHARED, -1, 0); 535 if (ptr == MAP_FAILED) { 536 fprintf(stderr, "%s: %s", __func__, strerror(errno)); 537 return 0; 538 } 539 540 memset(ptr, 0, len); 541 542 memory.userspace_addr = (unsigned long)ptr; 543 memory.slot = get_free_slot(kvm); 549 r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory); 550 if (r == -1) { 551 fprintf(stderr, "%s: %s", __func__, strerror(errno)); 552 return 0; 553 } 554 register_slot(memory.slot, memory.guest_phys_addr, memory.memory_size, 555 memory.userspace_addr, memory.flags); 556 557 return ptr; 558 }

KVM, QEMUにおけるVMへのメモリ領域割当 #2

プロセス内に仮想マシン用のメモリ領域を確保

VMのメモリ空間に、確保し

たメモリ領域を割り当て

43

VM上のページング① - ソフトウェア処理Shadow Page Table (SPT) #1

OS Kernel

Process 1

Process 2

Process 3

Process 4

ゲストOSの

メモリ空間

物理メモリ

PTPD PTPD PT PT

PTPD PTPD PT PT

VM上のは、ゲストOSが管理するページテーブル

である。ゲストOSはVMに割り当てられたメモリ空間を物理メモリ空間全体と

信じてページテーブルを作成する。

PTPD PTPD PT PT

VM上のコードを実行する際、CPUはVMのメモリ空間で動作しなければいけない。この際にCPUが参照すべきページテーブルは何か？

VM上のゲストOSが管理するをCPUが参照すると、物理メモリ空間が見えてしまい、本来ゲストOSが意図したページへ

アクセスされない。

PTPD PTPD PT PT

この問題を解決するため、ハイパーバイザはシャドウページテーブルを作成する。これは、VM上の仮想メモリ空間を

物理ページにマッピングする内容となるため、CR3レジスタにを設定することでCPUがVMのアドレス空間を解決可能となる。

PDVMへの割当ページ情報

PTPD PTPD PT PT

また、VM上のコード実行時、ページ読み書きの際にのAccess bit, Dirty bitがアップデートされる。これらは

へ、逆に同期する必要がある。

PTPD PTPD PT PT PTPD PTPD PT PTVMへの割当ページ情報＝＋

PTPD PTPD PT PT

PTPD PTPD PT PT

PD

sync

sync

①

②

③

④

⑤

44


VMMが、VM内で使われるページテーブルを基に Guest Virtual →Machine-Physicalのページ追跡に使用するページテーブルを作成

1. VM上からハイパーコールが実行される

2. VMMがvCR3を読み取りVMに制御を戻す

1. VMが管理するvCR3を読み取ろうとする

2. VMX non-rootからVMEXITする

3. VMMがVMEXITの原因を確認し、vCR3を読み取りを再現して再度VMENTERする

CR3参照

Intel VT / AMD-Vなしの場合Intel VT / AMD-V ありの場合

1. VM上からハイパーコールが実行される

2. VMMがvCR3を書き込んだことにする

3. Shadow Page Table を更新する

4. VMMがVMに制御を戻す

1. VMMが命令をスキャンし、CR3読み書き等の命令を洗い出す

2. 見つかった命令群をハイパーコールに書き換え

1. VMがメモリにアクセスする(この際、実CR3=SPT)

2. CPUがSPTを使用してゲストの仮想アドレスをホストの物理アドレス空間に解決通常ページへの読み書き


2. VMからSPT(VMMのメモリ空間)に書き込めないためページフォルトを引き起こす

3. VMMがVM中のページテーブルを更新

4. VMMがvCR3の示すページテーブルにあわせてSPTを更新

ページテーブル書込


2. VMからSPT(VMMのメモリ空間)を読めずページフォルトを引き起こす

3. VMMが、必要に応じてSPT上のAccess bit, Dirty bitをVM上のページテーブルへ転記

4. VMMが、VMのvCR3が示すページテーブルを返す

ページテーブル参照

1. VMがvCR3を書き込もうとする

2. VMX non-rootからVMEXITする

3. VMMがVMEXITの原因を確認し、vCR3を書き込みを再現する

4. VMMがShadow Page Table を更新する

5. VMMが再度VMENTERし、VMに制御を戻す

CR3書込

(前処理不要)（命令実行前）

実現のしくみVM内の操作

45

Linux + KVM Linux + KVM qemu-kvmqemu-kvm

Guest OS’s Page Table Shadow Page Table


VM内の4段ページテーブル(64bitの場合、32bitの場合は2段)

CR3

Page

Page

Page

PML4

PDPT

PD

PT

CR3

PML4

PDPT

PD

PT

VM内で見えるCR3

VM内で実際にCPUが使っている

CR3

TLB参照

TLB更新


要求

例外による操作検出内容の同期

毎回 Page Walk するのは大変なので、

最近参照したページテーブルの内容はCPUがキャッシュしている

(Tagged Look-aside Buffer)

46


Shadow Page Table(SPT)の問題点

• 必要メモリ量 (VM上のPT, VMM上の割当テーブル、さらにSPT)

• VMMコードのプロファイリングを行うと、約75%がSPT関連処理

It is estimated that for certain workloads shadow paging can account for up to 75% of overall hypervisor overhead.

- AMD-V™ Nested Paging, ©2008 Advanced Micro Devices, Inc.

KVMはShadow Page Tableのパフォーマンスが高くない

• 新CPUのVM用ページング支援機能の利用が前提

• SPTのサポートはあくまで互換性目的

• SPTの性能はXen > KVM

47

Linux + KVM Linux + KVM qemu-kvmqemu-kvm

Guest OS’s Page Table Shadow Page Table

VM内の4段ページテーブル(64bitの場合、32bitの場合は2段)


要求CR3

Page

Page

Page

PML4

PDPT

PD

PT

CR3

例外による操作検出内容の同期

Extended Page TablePML4

PDPT

PD

PT

PML4

PDPT

PD

PT

VM上のページング② - ハードウェア処理Extended Page Tables(EPT)/AMD Nested Page Tables(NPT) #1

VM実行時実際にCPUが使っている

CR3

VMMが作成した、VMへのメモリ割当を

示すテーブル

VM内で見えるCR3

48

VM上のページング③Extended Page Tables(EPT)/AMD Nested Page Tables(NPT) #2

• 非仮想化環境のページング– Memory Management Unit (MMU) ハードウェアが処理

– CR3レジスタで指定されたページテーブルにより、プロセッサが仮想メモリを実現

• これまでのソフトウェアによるページング(Shadow Page Table利用環境)– VMMが、VM向けのページングをソフトウェア的に再現

– VMMが、VM内仮想アドレス→物理アドレスのテーブルを追加作成、管理

• EPT/NPT有効時のページング– 仮想マシンの物理アドレス(Guest-Physical)を、実際の物理アドレス

(Machine-Physical)に変換する機能をプロセッサレベルで提供

– 仮想マシン実行時のメモリ仮想化はプロセッサが自動的に処理

– VMMは必要なメモリ割当テーブルをメモリ上に作成、CPUに設定する（だけ）

パフォーマンスの大幅向上（VMMによってはゲストの動作が約３０％高速化）

49

メモリ管理のまとめ

物理アドレスと仮想アドレス仮想アドレスを用いたアクセスにはページテーブルが必要

VM内ページングの手法ソフトウェアによるページング（Shadow Page Table）

• VM内仮想アドレスをマシン物理アドレスに変換するテーブル

ページング支援技術（Extend Page Tables, Nested Page Tables）• プロセッサがVM内仮想アドレスを物理アドレスに自動変換

CPUアーキテクチャに応じた仮想化技術の選択 Core i7, Xeon 5500(Nehalem) 未満 …. KVM ＜ Xen Core i7, Xeon 5500(Nehalem) 以後 …. KVM ≒ Xen(Intel製プロセッサの場合。AMD製プロセッサはBarcelona未満／以後)


デバイスのエミュレーション

I/ODevices

I/ODevices

CPU CPU

SystemMemory

SystemMemory

51

I/Oポート– プロセッサから外部に接続するためのデジタルインターフェイス– ON(1) もしくは OFF(0) を通信する– 1アドレス 8ビット×64K、アクセス単位が基本8ビットなので非常に低速

【使途】キーボードの押下状況確認、ディスクコントローラの状態設定、通知など

メモリマップドI/O (Memory Mapped I/O)– プロセッサの物理メモリ空間に、デバイス上のメモリ空間をマッピングする– ソフトウェアからデバイス上のメモリ空間に直接アクセスできる【使途】VGA, Sound, Disk Controller, Ethernet Controller など大量コピー

割り込み(Interrupt)– デバイスからCPUへイベントを通知するための信号【使途】タイマーの通知、キーボードの状態変化通知、データ転送完了通知(DMA,

MMIO)など

x86で使用される主なデバイスI/O方式

52

SerialPort

SerialPort

ParallelPort

ParallelPort

PIIX3 PCI IDEPIIX3 PCI IDE

PIIX3 PCI USBPIIX3 PCI USB

PCI SlotPCI SlotPCI SlotPCI Slot

LSI LogicLSI53c895a

LSI LogicLSI53c895a

System MemorySystem Memory

BochsFlash BIOS

BochsFlash BIOS

Real TimeClock

Real TimeClock

Cirrus LogicCL-GD5446

Cirrus LogicCL-GD5446

RealtekRTL8029

RealtekRTL8029

EnsoniqES1370

EnsoniqES1370

ISA

Bus

ISA

BusISA

I/O Interface

ISAI/O Interface

FloppyFloppy

PC SpeakerPC Speaker

PCI

Bus

PCI

Bus

Intel 82371 PIIX3(South-bridge)

Intel 82371 PIIX3(South-bridge)

CPUCPU

VGAVGA

EthernetEthernet

SpeakerSpeaker

SCSI HDDSCSI HDD

IDE HDDIDE HDD

CD-ROMCD-ROM

USBUSB

KeyboardKeyboard

MouseMousePS/2PS/2

QEMUによるx86ハードウェアエミュレーション

出典: KVM徹底入門 (2010年翔泳社)

Intel 82441FX(North-bridge)

Intel 82441FX(North-bridge)

53

KVMによるx86ハードウェアエミュレーション

• QEMU由来のデバイスエミュレータを使用– Xen, VirtualBox等オープンソースの仮想

マシンはほとんどQEMU由来のエミュレータを使用している

• 仮想デバイスの処理の流れ– VM内でハードウェアアクセスが発生！

– CPUがゲストOSからホストOSへ制御を返す

– KVMが例外をトラップし、QEMUのイベントハンドラに制御を移す（返す）

– QEMUのイベントハンドラがトラップの原因を確認し、適宜必要な処理を行う仮想デバイスに対するI/O なら

デバイスエミュレータを実行

– QEMUがKVMに、KVMがVMに制御を戻す

– VMはハードウェアアクセスが成功したと信じて実行を続ける

qemu-kvmqemu-kvm

Linux Kernel Linux Kernel

Virtual MachineImage

Device Emulator

HardwareHardware

System callsSystem callsKernel-basedVirtual

Machine

Kernel-basedVirtual

Machine Device DriversDevice Drivers

54

599 int kvm_run(CPUState *env) 600 { 601 int r; 602 kvm_context_t kvm = &env->kvm_state->kvm_context; 603 struct kvm_run *run = env->kvm_run; 604 int fd = env->kvm_fd; 605 606 again: ……… 610 } 626 r = ioctl(fd, KVM_RUN, 0); 645 if (1) { 646 switch (run->exit_reason) { 647 case KVM_EXIT_UNKNOWN: 650 case KVM_EXIT_FAIL_ENTRY: 653 case KVM_EXIT_EXCEPTION: 660 case KVM_EXIT_IO: 661 r = kvm_handle_io(run->io.port, 662 (uint8_t *)run + run->io.data_offset, 663 run->io.direction, 664 run->io.size, 665 run->io.count); 666 r = 0; 667 break; 668 case KVM_EXIT_DEBUG: ……… 694 default: 701 } 702 } 703 more: 704 if (!r) { 705 goto again; 706 } 707 return r; 708 }

733 static int kvm_handle_io(uint16_t port, void *data, int direction, int size, 734 uint32_t count) 735 { 736 int i; 737 uint8_t *ptr = data;738 739 for (i = 0; i < count; i++) { 740 if (direction == KVM_EXIT_IO_IN) { 741 switch (size) { 742 case 1: 743 stb_p(ptr, cpu_inb(port)); 744 break; 745 case 2: 746 stw_p(ptr, cpu_inw(port)); 747 break; 748 case 4: 749 stl_p(ptr, cpu_inl(port)); 750 break; 751 } 752 } else { 753 switch (size) { 754 case 1: 755 cpu_outb(port, ldub_p(ptr)); 756 break; 757 case 2: 758 cpu_outw(port, lduw_p(ptr)); 759 break; 760 case 4: 761 cpu_outl(port, ldl_p(ptr)); 762 break; 763 } 764 } 765 766 ptr += size; 767 } 768 769 return 1; 770 }

KVMによるx86 H/Wエミュレーション (ソース追跡編 #1)

qemu-kvm.ckvm_run関数 (VM実行部分)

VM実行

kvm-all.ckvm_handle_io関数 (I/Oイベントハンドラ)

I/Oポートの

読み取り

I/Oポートへの

書き込み

ioport.c201 void cpu_outw(pio_addr_t addr, uint16_t val)202 {203 LOG_IOPORT("outw: %04"FMT_pioaddr" %04"PRIx16"\n", addr, val);204 ioport_write(1, addr, val);205 }

ioport.c

70 static void ioport_write(int index, uint32_t address, uint32_t data) 71 { 72 static IOPortWriteFunc * const default_func[3] = { 73 default_ioport_writeb, 74 default_ioport_writew, 75 default_ioport_writel 76 }; 77 IOPortWriteFunc *func = ioport_write_table[index][address]; 78 if (!func) 79 func = default_func[index]; 80 func(ioport_opaque[address], address, data); 81 }

I/O発生 → QEMUの

イベントハンドラへ

I/Oポートに対応する

イベントハンドラへ

55

QEMUからの通知を受け取るイベントハンドラ 589 static uint32_t fdctrl_read_port (void *opaque, uint32_t reg) 590 { 591 return fdctrl_read(opaque, reg & 7); 592 } 593 594 static void fdctrl_write_port (void *opaque, uint32_t reg, uint32_t value) 595 { 596 fdctrl_write(opaque, reg & 7, value); 597 } 598 599 static uint32_t fdctrl_read_mem (void *opaque, target_phys_addr_t reg) 600 { 601 return fdctrl_read(opaque, (uint32_t)reg); 602 } 603 604 static void fdctrl_write_mem (void *opaque, 605 target_phys_addr_t reg, uint32_t value) 606 { 607 fdctrl_write(opaque, (uint32_t)reg, value); 608 }

529 static uint32_t fdctrl_read (void *opaque, uint32_t reg) 530 { 531 fdctrl_t *fdctrl = opaque; 532 uint32_t retval; 533 534 switch (reg) { 535 case FD_REG_SRA: 536 retval = fdctrl_read_statusA(fdctrl); 537 break; 538 case FD_REG_SRB: 539 retval = fdctrl_read_statusB(fdctrl); 540 break; 541 case FD_REG_DOR: 542 retval = fdctrl_read_dor(fdctrl); 543 break; … 556 default: 557 retval = (uint32_t)(-1); 558 break; 559 } 561 562 return retval; 563 }

フロッピーディスクコントローラをQEMUに登録1955 static int isabus_fdc_init1(ISADevice *dev)1956 {1957 fdctrl_isabus_t *isa = DO_UPCAST(fdctrl_isabus_t, busdev, dev);1958 fdctrl_t *fdctrl = &isa->state;1959 int iobase = 0x3f0;1960 int isairq = 6;1961 int dma_chann = 2;1962 int ret;19631964 register_ioport_read(iobase + 0x01, 5, 1,1965 &fdctrl_read_port, fdctrl);1966 register_ioport_read(iobase + 0x07, 1, 1,1967 &fdctrl_read_port, fdctrl);1968 register_ioport_write(iobase + 0x01, 5, 1,1969 &fdctrl_write_port, fdctrl);1970 register_ioport_write(iobase + 0x07, 1, 1,1971 &fdctrl_write_port, fdctrl);1972 isa_init_irq(&isa->busdev, &fdctrl->irq, isairq);1973 fdctrl->dma_chann = dma_chann;19741975 ret = fdctrl_init_common(fdctrl, iobase);19761977 return ret;1978 }

KVMによるx86 H/Wエミュレーション (ソース追跡編 #２)

I/Oポートアクセス

qemu-0.12.5/hw/fdc.c (仮想フロッピーディスクコントローラ)

QEMU I/Oポートテーブル

レジスタの読み取りエミュレーション 847 /* Status B register : 0x01 (read-only) */ 848 static uint32_t fdctrl_read_statusB (fdctrl_t *fdctrl) 849 { 850 uint32_t retval = fdctrl->srb; 854 return retval; 855 }

56

QEMUの仮想デバイスを選択する(1/3)

• QEMUには同種のデバイスエミュレータが複数実装されている

• いちばん気になる「仮想NIC」– rtl8139 (Realtek 8139)

– e1000 (Intel PRO/1000)

• 何が違うのか

– ゲストが認識するデバイス

– デバイスドライバ

エミュレーションの効率→ 全ゲストでシェアする”CPU”の利用効率

57


• どれぐらい効率が違うものか？

58.3Mbps 対 394Mbps (6.75倍)

C:¥>iperf -c 192.168.44.25 -w 4M

------------------------------------------------------------

Client connecting to 192.168.44.25, TCP port 5001

TCP window size: 4.00 MByte

------------------------------------------------------------

[1912] local 192.168.44.77 port 3334 connected with 192.168.44.25 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-10.1 sec 474 MBytes 394 Mbits/sec

C:¥>iperf -c 192.168.44.25 -w 4M

------------------------------------------------------------

Client connecting to 192.168.44.25, TCP port 5001

TCP window size: 4.00 MByte

------------------------------------------------------------

[1912] local 192.168.44.77 port 3334 connected with 192.168.44.25 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-10.1 sec 474 MBytes 394 Mbits/sec

e1000C:¥>iperf -c 192.168.44.75 -w 4M------------------------------------------------------------Client connecting to 192.168.44.75, TCP port 5001TCP window size: 4.00 MByte------------------------------------------------------------[1912] local 192.168.44.77 port 3318 connected with 192.168.44.75 port 5001[ ID] Interval Transfer Bandwidth[1912] 0.0-10.5 sec 73.1 MBytes 58.3 Mbits/sec

C:¥>iperf -c 192.168.44.75 -w 4M------------------------------------------------------------Client connecting to 192.168.44.75, TCP port 5001TCP window size: 4.00 MByte------------------------------------------------------------[1912] local 192.168.44.77 port 3318 connected with 192.168.44.75 port 5001[ ID] Interval Transfer Bandwidth[1912] 0.0-10.5 sec 73.1 MBytes 58.3 Mbits/sec

rtl8139

評価環境Machine: Intel DQ45CB + Core2 Quad Q8400 (2.6GHz)Host: Debian GNU/Linux (Lenny) + xen-unstable (Aug. 2010)Guest: Windows xp SP3, 1 vCPU

58


• rtl8139とe1000の差はどこに？– 「熱に消えた？」一概には言えないが

• rtl8139を使うということ有名チップをそのまま再現しているため、既存のドライバを利用できるCPU能力の無駄遣い

スループット制限はホストOSの機能を使うこと(tcコマンド)

• e1000ドライバを使うということQEMU由来VM用仮想NICの中では“かなりの高効率”

Windows XP SP3標準ドライバでは認識できない

Intel純正ドライバを使えば利用できる（が…）

59

デバイスのエミュレーションのまとめ

オープンソース系のVMMは、デバイスエミュレーションにQEMUを使用している– x86で使用される周辺チップがソフトウェア的実装されている

– 仮想マシン内でI/Oが発生したらエミュレータが処理し

結果を返す

エミュレーションするデバイスの選び方にも注意

– パフォーマンスが高い仮想デバイス、低い仮想デバイス


ここまでのまとめ

61

ここまでのまとめ

• コンピュータの３大要素: 中央演算装置,主記憶装置,入出力装置

• 仮想化の手法– CPU

• 仮想マシンはCPUが直接実行する

• 仮想化支援技術、例外などの仕組みを活用。必要時に制御をVMMに戻す

• 現行プロセッサのほとんどは仮想化支援技術に対応

– メモリ

• ゲストに一部メモリ領域を「全物理メモリ」だとと錯覚させる

• CPUはCR3レジスタに設定された内容に基づきページングする

• VMMが、ソフトウェア、もしくはハードウェアによるページング支援を行う

– I/Oデバイス

• 仮想マシン上で発生したI/O命令を例外としてトラップし、

デバイスエミュレータにて代替処理を行う


virtio 仮想デバイス

63

virtioの概要

• 『virtio』とはリングバッファを使用したHost –

Guest間のインターフェイスを定義

Host 、Guest OSの実装に非依存

• qemu-kvm, VirtualBox がサポート

各デバイスは１つ１つが独立し動作• virtio Block x2→ PCIデバイス x2

• 例外あり（ドライバ実装に依存）

非常に高速• 無駄なH/Wエミュレーションは不要

• 『virtio-pci』とは仮想PCIデバイス使用した

virtioインターフェイスの実装仕様

Host Host

Guest Guest


PCI BusPCI Bus

virtioBallon

virtioBallon

virtioBlock

virtioBlock

virtioBlock

virtioBlock

virtioNet

virtioNet

virtioBallon

virtioBallon

virtioBlock

virtioBlock

virtioBlock

virtioBlock

virtioNet

virtioNet

64

virtioの既知デバイスタイプ

iomemory69p transport9

乱数生成用ソースentropy source4ゲストが確保したメモリをできるだけ解放するよう促す

メモリバルーンmemory balloning5

仮想コンソールconsole3

仮想ネットワークインターフェイスnetwork card1仮想ディスク、SCSIパススル－仮想ブロックデバイスblock device2

参考デバイス機能Device TypeID

PCI Vendor ID, Device ID• Qumranet(現RedHat子会社)がPCIベンダ／デバイスIDを提供

• Vendor ID: 0x1AF4, Device ID: 0x1000～0x103F

Subsystem Device ID• そのvirtioデバイスが持つ機能を示す。USBのClassと同様

List of Subsystem Device ID – 出典：Virtio PCI Card Specification v0.8.9 DRAFT (Rusty Russell, 2010)qemu-kvmに実装されていないデバイスは灰色で表記した

65

virtioのリングバッファ

• リングバッファ Host – Guest 間のデータ交換は

共有メモリのリングバッファを使用

デバイスあたり1つ以上使用

リングの構成（数・長さ）はバックエンドドライバが指定

• virtio共通の初期化処理（フロントエンド視点）

– バックエンドドライバをプローブ

– Guest が自分のメモリ空間に

バッファを確保

– GuestがHost側にバッファの物理アドレス(Guest-Physical)を通知

Host Host

Guest Guest


PCI BusPCI Bus

virtioBallon

virtioBallon

virtioBlock

virtioBlock

virtioBlock

virtioBlock

virtioNet

virtioNet

virtioBalloon

virtioBalloon

virtioBlock

virtioBlock

virtioBlock

virtioBlock

virtioNet

virtioNet

66

virtio-netによるリングバッファ利用例

• キュー 0– 受信パケット用キュー

• キュー 1– 送信パケット用キュー

• キュー 2– ドライバ制御情報

Host Host

Guest Guest


PCI BusPCI Bus

virtio-net デバイスドライバvirtio-net デバイスドライバ

virtio-net PCIデバイスvirtio-net PCIデバイス

Queue 0 Queue 1 Queue 2

受信パケット

送信パケット

ドライバ制御情報

67

Guest 側Guest 側

virtioのリングバッファ構造(1/2)

キューの位置を示す2つのポインタ Guest側のバッファ終端位置

(vring.avail.idx) Hostが最後に処理したバッファ位置

(vring.used.idx) 互いに絶対追い抜いてはいけない Lock-Free

① Guestがキューにデータを追加する– キューにデータを書き込む;

vring.avail.idx++;

② Hostがキューからデータを読む– while (vring.used.idx <

vring.avail.idx) {キュー上のデータを処理;vring.used.idx++;

}

vring.avail.idx

vring.used.idx

Host 側Host 側

③ Guestがキューからデータを読む– while (last_used_idx < vring.used.idx) {

キュー上のデータを処理;last_used_idx ++;

}

• リングの仕組みは共有コード上に実装

– 各ドライバごとの実装は不要

68

virtioのリングバッファ構造(2/2)

• 従来モード– リング上にバッファのアドレス情報をおく– 1メモリ断片／1エントリ

• indirectモード– リング上にindirectテーブルのアドレス

情報をおき、実際のバッファを間接参照– 1以上のメモリ断片／1エントリ

• virtio-netの例– RX/TXのデータ構造の例

• TX(RX)パケット情報の構造体 × 1• Ethernetフレーム × 1

– リングの構造： 256エントリ/ring• 従来モード: 256 ÷ 2 = 128• indirectモード: 256 ÷ 1 = 256

indirectモードのほうが多数パケットをキューできる

従来モード（過去バージョンのvirtio互換)

indirectモード（現行virtioでサポートされる）

Indirectモードの構造を見ていると干し柿を食べたくなりますね

69

virtio-pciのリングバッファ更新通知

【Guest → Host】– H/Wエミュレータのハンドラをキック– 通知用I/Oポートにデータ書き込み

【Host → Guest】– ゲストの割り込みハンドラをキック– IRQ割り込み、MSI-X割り込み

【キックの抑制】– VRING_USED_F_NO_NOTIFY

(G→H I/Oポートキックの抑制)– VRING_AVAIL_NO_INTERRUPT

(H→G IRQ割り込みの抑制)– VIRTIO_F_NOTIFY_ON_EMPTY

（バッファが空になった場合のみ通知）

• VMX root/non-root切替が発生するため高コスト（回数を減らす工夫が必要)

Host Host

Guest Guest

Hardware Hardware

PCI BusPCI Bus

virtio フロントエンドデバイスドライバvirtio フロントエンドデバイスドライバ

virtio バックエンド PCIデバイスvirtio バックエンド PCIデバイス

IRQ, MSI-X割り込みでキック

I/Oポートを

通してキック

70

virtio-blkが遅い? - 原因を考えてみる

現状のvirtio-blkの実装は…– リングはひとつだけ使用– I/O要求は128個まで同時受付可能

SCSI, SATAのNCQ相当が効かない？– リングは“順番に処理”が原則– Host OS, Driver, Driveのレベルで

I/O要求の並べ替えが行われない

virtio-blkはI/Oの乱発が苦手？– マルチスレッドI/Oもきっと苦手

性能より実装容易化を重視した？今後、マルチキューサポートで改善？ Host Host

Guest Guest

PCI BusPCI Bus

virtio-blk デバイスドライバvirtio-blk デバイスドライバ

virtio-blk PCIデバイスvirtio-blk PCIデバイス

Queue 0

I/O要求

I/O結果

×

71

virtio関連ソースコードとライセンス形態

• Host側（バックエンド側）– qemu-kvmソースコードを参照

– Git

• Guest側（フロントエンド側）– Linuxソースコードを参照

– ファンクションドライバdrivers/net/virtio-net.c

drivers/block/virtio-blk.c ほか

– 共有ソースコード

drivers/virtio/virtio_pci.c （仮想PCIデバイス）

virtio_ring.c （リングバッファ）

Linux用コードのライセンス形態

アルゴリズム（関数定義、マクロ）

アルゴリズム（関数定義、マクロ）

データ構造、定数（構造体など）

データ構造、定数（構造体など）

BSDL

GPL

論文、仕様書の入手先http://ozlabs.org/~rusty/virtio-spec/

– virtio: Towards a De-Facto Standard For Virtual I/O Devices

– Virtio PCI Card Specification

http://ozlabs.org/~rusty/virtio-spec/

72

virtio-net for FreeBSD (1/2)

モチベーション

• virtioを理解するために開発中

Why on FreeBSD?

• FreeBSDなら実用価値もある？– さくらのVPS

• BSDL

現段階の実装状況

• リングバッファ（主要機能のみ）

• virtio-net

virtio-net for FreeBSD

テスト状況

• 2TiB TX, 1TiB RX以上の負荷試験

• 32bit OS未確認(AMD64にて開発)

パフォーマンス

• 1vCPU VM: TX 110Mbps

• 2vCPUs VM: TX 40Mbps

• 1vCPU VM+HW Emulation

TX 100MBps

73

virtio-net for FreeBSD (2/2)

$ ifconfig vn0

vn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

ether 52:54:00:1f:61:0e

inet 192.168.90.1 netmask 0xffffff00 broadcast 255.255.255.0

$

[root@proliant2 ~]# ifconfig vnet2

vnet2 Link encap:Ethernet HWaddr FE:54:00:1F:61:0E

inet6 addr: fe80::fc54:ff:fe1f:610e/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:2828598448 errors:0 dropped:0 overruns:0 frame:0

TX packets:1424299907 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:500

RX bytes:4267254392920 (3.8 TiB) TX bytes:93999838700 (87.5 GiB)

Guset OS (FreeBSD) から見ると

Host OS (Linux, Fedora 14) から見ると

74

virtio for FreeBSDRusty Russellにメールしてみた

• FreeBSD用virtioドライバと聞いて

– エキサイティング！

– 私もキミのコードを見てFreeBSDを勉強するよ。

• virtioドライバを開発する上でのアドバイス– Linux用virtioフロントエンドはLinux前提に書かれている。

– 他OS用virtioならその世界にあわせて開発したほうがいい。

– その成果はきっとvirtioに対し良いフィードバックになるよ！

75

virtio-blk for FreeBSD (1/3)

• FreeBSDユーザにとって一番重要なドライバ– QEMU上のFreeBSDはディスクアクセスが遅い（らしい）

たぶんストレージ部分のvirtio化は望まれている

「ドライバ２つ目はコレをやるしかない！」

• virtio-blkの実装作業– セクタのリード／ライトだけなら実装はシンプル、簡単

– デバイスの特性が違う

• Block … 要求に対して、必ず応答が戻る

• NIC … 送受信が完全に非同期

– 中途半端なコードだと、I/O完了までブロック！

• デバッグ中はちょっと大変だった

76


vm162# newfs /dev/vd0/dev/vd0: 8.0MB (16384 sectors) block size 16384, fragment size 2048

using 4 cylinder groups of 2.02MB, 129 blks, 320 inodes.super-block backups (for fsck -b #) at:160, 4288, 8416, 12544vm162# mount /dev/vd0 /mnt/vd0

vm162# mount | grep vd0

/dev/vd0 on /mnt/vd0 (ufs, local)

vm162# df -h | grep vd0

/dev/vd0 7.5M 4.0K 6.9M 0% /mnt/vd0

Guset OS (FreeBSD) から見ると

77


• 実装して判ってきた事– virtio-blkが完成しても、直接ディスク性能の劇的改善には結

びつかない可能性が高い

SCSIエミュレーションと比べ、性能は誤差の範囲

• virtio-blk, sym どちらでも約 6MB/sec （手元の開発環境にて）

• チューニングはまだ不十分とはいえ…

FreeBSDにはディスク書き込みのBarrierの仕組みがない？

（詳しい人教えてください）

78

virtioのまとめ

リングバッファを用いる仮想デバイス用インターフェイス– virtioデバイスはSystem VM（完全仮想化）では

仮想的なPCIデバイスとして認識される

– メジャーなフロントエンドドライバ• ネットワーク、ディスク、シリアルコンソール

• メモリバルーン（ゲストが確保するメモリ量を縮小させる）

virtioドライバを書けば、対応VMMで高効率I/Oができる– 現状qemu-kvmのほか、VirtualBoxもvirtioをサポート

– Linux用ドライバ（事実上のリファレンス）は GPL– FreeBSD用ドライバを鋭意開発中


Xen環境下におけるZFS障害体験

（おまけ）

80

（番外編）ZFSを正しく動かすのは難しい

• ZFSをPC, PCサーバ, 仮想マシンの上で正しく動かすのは難しい– ZFSの設計思想のひとつ：信頼性

– End to End Checksum

• 上記実現のために前提条件として要求されるもの

– 正しいエラー通知をするハードウェア、ドライバ– 必要なライト操作は同期I/Oで行われること

– “絶対に壊れないZFS Intent Log(ZIL)” ※ZIL利用時

• Xenの上で実行するにあたり– blktapの”tap:aio:…”もしくは”tap:sync:…”を使う

81

RAID-Z障害の例(1)

root@os200811:~# zpool status array1 pool: array1 state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. see: http://www.sun.com/msg/ZFS-8000-K4scrub: none requested config:

NAME STATE READ WRITE CKSUM array1 DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 c3d1p1 ONLINE 0 0 0 c3d2p1 FAULTED 8 7.56M 0 too many errors c3d3p1 ONLINE 0 0 0

http://www.sun.com/msg/ZFS-8000-K4

82


Sep 1 20:31:23 dom0 kernel: ata11: exception Emask 0x10 SAct 0x0 SErr

0x80000 action 0xe frozen （続く）

• 物理障害– HDDエンクロージャの物理障害により

– SATAコントローラ – HDD間のリンクが切断

• Dom0カーネルが障害を検出– Kernelメッセージ多数

– ブロックデバイス消滅

• OpenSolaris domUが障害を検出– blktapバックエンドがエラーを検出しVBDを強制デタッチ?– RAID-Zアレイの1デバイスが死亡しdegraded状態となる

83


• OpenSolarisを再起動したら

– インポートできなくなりました

– 『動いているものは安易に止めるな！』（本気で）

• 復旧までの道のり

– 当時の最新リリース(OpenSolaris 2009.06)では対処手段なし

– ZFSソース探検中に偶然「インポート失敗時、トランザクション

をロールバックしてインポートを試みる」オプションを発見

– レポジトリ最新のONにアップデート

– トランザクションをロールバックした上でインポート成功• ハードウェアレベルの問題を解決した後にスクラブを実施し復旧

84

いまは平和に動いています

toor@vm230:~$ pfexec zpool status array1

pool: array1

state: ONLINE

status: The pool is formatted using an older on-disk format. The pool can

still be used, but some features are unavailable.

action: Upgrade the pool using 'zpool upgrade'. Once this is done, the

pool will no longer be accessible on older software versions.

scrub: scrub completed after 3h40m with 0 errors on Fri Mar 12 01:20:10 2010

config:

NAME STATE READ WRITE CKSUM

array1 ONLINE 0 0 0

raidz1-0 ONLINE 0 0 0

c6t1d0p0 ONLINE 0 0 0



logs


errors: No known data errors


付録

86

外部リソース集 (1/3)

• KVM - Kernel Based Virtual Machinehttp://www.linux-kvm.org/page/

• QEMUhttp://wiki.qemu.org/

• virtiohttp://www.linux-kvm.org/page/virtio

• Rusty Russellによるvirtio関連ドキュメント(paper, specification)http://ozlabs.org/~rusty/virtio-spec/

• AMD-V™ Nested Paginghttp://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf

http://www.linux-kvm.org/page/

http://wiki.qemu.org/

http://www.linux-kvm.org/page/virtio

http://ozlabs.org/~rusty/virtio-spec/

http://developer.amd.com/assets/NPT-WP-1%201-final-TM.pdf

87


• Intel® 64 and IA-32 Architectures Software Developer’s ManualVolume 3A, 3B

– 書籍『KVM徹底入門』(翔泳社)http://www.seshop.com/product/detail/12214/

– 書籍『はじめて読む486』 (アスキー出版局)http://www.amazon.co.jp/dp/4756102131

– 書籍『すべてわかる仮想化大全』 – VMware/Virtual Server (日経BPムック)http://www.amazon.co.jp/dp/482223410X

– 書籍『30日でできる! OS自作入門』 (MYCOM)http://www.amazon.co.jp/dp/4839919844

http://www.seshop.com/product/detail/12214/

http://www.amazon.co.jp/dp/4756102131

http://www.amazon.co.jp/dp/482223410X

http://www.amazon.co.jp/dp/4839919844

88


– 書籍『Virtual Machines: Versatile Platforms for Systems and Processes(The Morgan Kaufmann Series in Computer Architecture and Design)』

http://www.amazon.com/dp/1558609105/※ハードカバー＆分厚いので amazon.com から Kindle 版の購入をお勧め！

http://www.amazon.com/dp/1558609105/

エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)

Technology

Transcript of エンジニアなら知っておきたい「仮想マシン」のしくみ v1.1 (hbstudy 17)