hasegaw blog

フラッシュメモリのストライピングは善か悪か？

hasegaw — 2012-02-20T02:24:29+09:00

SSDなど、フラッシュメモリを用いたストレージデバイスは非常に高速です。このようなデバイスをストライピングするとさらに上を目指せる、、、ように感じられますが、実はストライピングで常にアプリケーションの性能が上がるわけではありません。

デバイス単体、２台ストライプのレイテンシ特性

以下のグラフは、フラッシュメモリデバイスへのランダム4KB書き込み時のレイテンシ分布（ドライブ単体および２台をストライプ）を示したものです。

グラフ１

左側がいちばんレイテンシが低い状態、右にいけばいくほどレンテンシが増えていった状態を示していおり、線が左に寄っているのは、すなわち高速に応答していることを示しています。

デバイス単体の場合（赤）、レイテンシ分布は非常に高速な状態（１）に偏っており良好な状態です。ストライプした場合（青）、先と比べると（２）の値が高くなっていて、つまりレイテンシが大きくなっていると言うことになります。この状態であれば間違いなく赤、つまりデバイス単体の性能のほうが応答が早いことになります。

この結果ですが、すこし条件を変えて測定してみると —— 以下のようになります。

グラフ２

このグラフでは、ストライプ構成（青）のほうがデバイス単体（赤）よりよいレイテンシ性能を示しています。

条件の違いは？

この先の２つのグラフ、一体何を変えたと思いますか？　　答えはI/Oスレッド数です。

グラフ１ …… 1スレッド
グラフ２ …… 64スレッド

つまりグラフ１の場合よりグラフ２の場合のほうが大きなワークロードがかかっています。つまりワークロード次第でレイテンシ分布は変化します。

さて。
デバイス単体で使ったほうがお得でしょうか？
それとも、ストライピングしておいたほうがお得でしょうか？

ヒント

複数デバイスにストライプすると、各デバイスからの応答を待ち合わせる必要があるため、レイテンシが幾らか悪化する。
転送するデータのサイズに比例して、フラッシュメモリのレイテンシは変化する。

フラッシュメモリデバイスのレイテンシ差がアプリケーションに与える影響

hasegaw — 2012-02-19T02:14:53+09:00

たまにはブログを書こうかと。今日はこのブログではじめてフラッシュメモリの話題を扱うことにしましょう。

個人的に大好きなプレゼンテーションがあります。タイトルは Mythbusting Flash Performance 、元Sun（現Oracle）の Solaris プラットフォームエンジニアリングのバイスプレジデント Bill Neshim 氏が Flash Memory Summit 2011 のキーノートとして講演した際のスライドのようです。

このプレゼンテーションには衝撃的なグラフが入っていて、これを見たとき衝撃を受けました。それ以来このプレゼンテーションはお気に入りとして常にマシンの中に入っています:)

予期可能なレイテンシ性能のフラッシュメモリデバイス、そうでないフラッシュメモリデバイス

フラッシュメモリデバイスは、使用されているNANDフラッシュメモリのパッケージごとの性能もありますが、それを管理・制御するコントローラにより、最終的なデバイスの仕上がりが大きく変わることが知られています。

フラッシュメモリデバイスの性能は IOPS (単位時間あたりのIO回数)と帯域幅で語られがちですが、さらにレイテンシという軸で探ってみると、デバイスの本当の性能がよく見えてきます。

IOPSの比較

以下は、先のプレゼンテーションからの引用です。具体的なデバイスの機種名は明かされていませんが、2つのフラッシュメモリデバイスのIOPS性能を比較しています。

Device A

Device B

このふたつの違いは明白です。前者は書き込みスレッド数により IOPS 性能が決まってくる、つまり性能が予期できることがわかります。後者は、もちろんスレッド数が少ない方がIOPS数が多いもののおよそランダムな状態です。これが、性能が予期できないフラッシュメモリデバイスの特性です。

レイテンシの比較

続いて、次のスライドは2つのデバイスのレイテンシ性能を比較しています。

縦軸は頻度、横軸はIO時に発生したレイテンシの大きさです。つまりグラフが左側に寄っていればそれだけ応答が速いデバイスである、と見ることができます。

このグラフで登場している2つのデバイスは、実際に Oracle の本番環境で利用されており、非常にレイテンシ特性が似ています。しかし、 OLTP ワークロードをかけた際のグラフを見ると、 Dev1 はレイテンシが大きくなる頻度が Dev2 より大きい —— つまり、実際のアプリケーション負荷をかけるとレイテンシがより悪化するデバイスである、ということです。

これについて Bill 氏は「I/Oのうち最も遅い 1% がデバイスの性能を決める。しかし、多くのデバイスベンダはこの部分の軽く見がちだ」と述べています。

どうして氏が 1% に拘るのか……それは次のスライドに答えがあります。

このスライドは、さきほどの「最も遅い1%」がデータベースの OLTP に性能にどのような影響をもたらすかを示しています。縦軸はデバイスのレスポンスタイムタイム、横軸は時間です。このグラフでは、 Dev 2 が非常に安定したレスポンスタイムで応答しているのに対し Dev 1 のレスポンスタイムは明らかにムラがあります。

Dev 2 を使ったデータベースでは一定の間隔で応答してきますが、 Dev 1 は、まるで混雑した道路で渋滞にハマっているかのように動いたり止まったり……を繰り返しているのです。この結果、データベースの実行速度には大きな差が現れるのです。

まとめ

フラッシュメモリデバイスの性能は IOPS (単位時間あたりのIO回数)と帯域幅で語られがちです。しかし、それだけでなく、レイテンシが安定しているか、という観点での評価もとても重要です。それも一定時間の平均値ではなく、レスポンスタイムの分布まで含めてはじめて、アプリケーション性能への影響がわかります。

p.s. @yoshikaw さんにエントリ中のバグをご指摘いただき修正しました。ありがとうございます！

変なファイル名によるイタズラ

hasegaw — 2012-01-12T22:38:08+09:00

へぇぇぇぇ。

[sandbox@proliant2 work]$ touch -- '-rf' '~' [sandbox@proliant2 work]$ strace rm * execve("/bin/rm", ["rm", "-rf", "~"], [/* 23 vars */]) = 0 brk(0) = 0x87c000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a966000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=94094, ...}) = 0 mmap(NULL, 94094, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f840a94f000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\357\1n?\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1995840, ...}) = 0 mmap(0x3f6e000000, 3814616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3f6e000000 mprotect(0x3f6e19a000, 2093056, PROT_NONE) = 0 mmap(0x3f6e399000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x199000) = 0x3f6e399000 mmap(0x3f6e39e000, 21720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3f6e39e000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a94e000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a94c000 arch_prctl(ARCH_SET_FS, 0x7f840a94c720) = 0 mprotect(0x3f6e399000, 16384, PROT_READ) = 0 mprotect(0x3f6de20000, 4096, PROT_READ) = 0 munmap(0x7f840a94f000, 94094) = 0 brk(0) = 0x87c000 brk(0x89d000) = 0x89d000 brk(0) = 0x89d000 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=99154656, ...}) = 0 mmap(NULL, 99154656, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8404abc000 close(3) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0 lstat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 newfstatat(AT_FDCWD, "~", {st_mode=S_IFREG|0664, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0 unlinkat(AT_FDCWD, "~", 0) = 0 close(0) = 0 close(1) = 0 close(2) = 0 exit_group(0) = ? [sandbox@proliant2 work]$

シェルによりワイルドカード指定で見つかったファイルの ~ カレントディレクトリパスに置き換えられないため問題ないのね。

しかし意図的にファイルを置いておくことで -i を迂回できるね。怖い……！

※Fedora 14 の環境でためしました。

Tabキーでウインドウ上のボタンにフォーカスをあてるには

hasegaw — 2012-01-10T00:36:28+09:00

「えっ、いまさら？」と言われそうなネタで自分への備忘録がてら一本。。。。

MacOS XのUIでボタンなどをフォーカスしたいときに Tab キーで反応してくれないのに割と困っていたんですが、設定ひとつで挙動が変えられるんですね。感動しました。。。。

たとえば次のウインドウの場合、このダイアログにはチェックボックスとボタン２つ、合計３つのコントロールがあります。 Windows であれば標準設定でもこの３コントロール間を Tab で行き来できるのですが、 Mac OS X ではデフォルトでは Tab によるコントロール移動が効きません。なおこの画像は実際に Cancel にフォーカスをあてている状態です。

これは、設定＞キーボードで変更できます。

教えてくださった @akisutesama さん、ありがとうございます _o_

FreeBSDで使うLinux KVM準仮想化タイマ

hasegaw — 2012-01-04T23:04:37+09:00

こんにちわ。@hasegawです。あけましておめでとうございます。今年もよろしくお願いします！

かなり久々のブログ更新となりますが、本日はカーネル／VM Advent Calendar にてまたまた私の当番！ってことで、今回は FreeBSD 8.1-RELEASE に Linux KVM 用のタイムカウンタを実装してみたというネタでお話しようかと思います。

昨年のネタ: FreeBSD VIMAGEを使ったTCP/IPのルーティングデモンストレーション

■ Linux KVM のタイマ機能

まずバックグラウンドについて説明しておきましょう。 FreeBSD のはじめとする殆どの OS では、以下の計算式でシステム時間（年月日・時分秒）を把握しています。

システム時間 = システム起動時の時間 + システム起動後の経過時間

このうち「システム起動時の時間」はRTC（リアルタイムクロック）の値で初期化し、「システム起動後の経過時間」はOSが定期的にカウンタをインクリメントしています。しかし、仮想化環境ではこの仕組みをそのまま適用すると時刻ズレの原因となりやすいことは、この記事を読むような方であればご存じのことでしょう。

そこで、タイマの仮想化です。 Linux KVM でもタイマの準仮想化機能があります。

KVM PVclock
http://www.linux-kvm.org/page/KVMClock

これは、ゲスト OS が「おいら時間情報がほしいから、メモリのここに定期的に書いておいてちょ」と仮想マシンモニタにお願いすると、適当な間隔で仮想マシンモニタが指定されたメモリ上に時刻情報を書いておいてくれる、という仕組みです。

ただ、 KVM のサイトを見るとこの機能は Linux guests only. と書いてあります。

どうして Linux でしか使えないの？
それは、ゲスト OS が KVM PV Clock に対応する必要があるからです。

しかし KVM の PV Clock は決して難しいものではありません。もともと Xen にインスパイアされて殆ど同じ汎用的なデータ構造を持っているので、すでに BSDL で Xen 対応のコードがある FreeBSD であれば私のヘナチョコがちょろちょろっとコピペして済むレベルです。対応するかしないかは仮想マシンモニタ開発側＆ゲスト OS 開発側のモチベーション次第なだけなのです！よっしゃ、私は最近 FreeBSD 使っていないけど、やってみるかー。

ってことでとりあえず動くモノを作ってみましたとさ。

■ FreeBSD 用 timecounter: kvmclock 失敗編

時は 2011 年 10 月。今回のモノは FreeBSD の timecounter として実装しました。 Linux で言う clocksource ですね。システム起動時には以下のイメージで初期化されます。

Timecounter "kvmclock" frequency 1800000536 Hz quality 900

このタイムカウンタは、 Linux KVM が定期的に TSC のカウンタをメモリに書いてくれるので、それを使って時を刻んでいます。

struct pvclock_vcpu_time_info {
      u32 version;
      u32 pad0;
      u64 tsc_timestamp;
      u64 system_time;
      u32 tsc_to_system_mul;
      s8 tsc_shift;
      u8 pad[3];
} __attribute__((__packed__)); /* 32 bytes */

とりあえず動いたのですが、しかし実際には問題が起きて使い物になりませんでした。理由は桁あふれです。1.8GHzでカウントアップされていくタイマだと、あっという間に32ビットのカウンタは一週してゼロに戻ります。この結果、アイドル時間が多いと時計が遅れるという最高にイケていないタイムカウンタになりました。なお while true; do date > /dev/null ; done とかしていると非常に精度が高いカウンタであったことは申し添えておきます！

■ FreeBSD用timecounter: kvmclock その２

時は２０１１年１２月２９日。年末年始はスノーボードに行くので今作らなかったら Advent Calendar のネタがありません。ってことで、とりあえずバージョンアップしました。

Timecounter "kvmclock" frequency 1000000 Hz quality 900

このタイマはゲストOSに対して仮想的にマイクロ秒精度のタイマ機能を提供します。

前回は Linux KVM がシャドウしてくれた TSC の値を使って時を刻んでいましたが、今回は Linux KVM がシャドウしてくれたシステム時間をベースに時を刻みます。

struct pvclock_wall_clock {
      u32 version;
      u32 sec;
      u32 nsec;
} __attribute__((__packed__));

このデータ自体はナノ秒オーダーのものですが、 t = sec * 1000 + nsec / 1000 としてマイクロ秒のオーダーに変換し、これの情報を OS 側に食わせます。この形であればカーネルが気づかないうちに桁あふれなんてことがそうそう起きません。

■ 評価

早速作ったタイムカウンタで仮想マシンを動かしてみました。素人ハックの結果としては割と良好かと思います。

これは while true; do date; sleep 1; done の結果をゲスト（上）とホスト（下）で実行しっぱなしにした結果です。

5時8分0秒が飛んでいるので不安定っぽく見えますが、 sleep 1 の待ち時間がフラついているという問題はあるもののホスト OS から 1 秒以上時間がずれることは無くなりました。 sleep の精度が低い問題はありつつも gettimeofday は安定しているようです。

また、vCPUがアイドルの場合も、負荷をかけた場合でも、システムの時刻がホストとゲストの間で大きくズレることはないようです。

12 月 29 日から 1 月 4 日までの 5 日間放置しても、システム時間のずれは生じなかった

■ もっと頑張らないといけないこと

とりあえず自覚している課題は以下の部分です。

実はまだ KVM のプローブをしていない。 MSR を一発たたけばいいので、いつでもできます。
vCPU != 1 の場合を想定していないし、評価していない。vCPU ごとにカウンタを進める必要がありますので、今のコードのままではまずい。このままでも動くかもしれないけど。
sleep 1 が不安定ﾟ+.(･ω･)ﾟ+.ﾟ　ヘボグラマなので細かい修正はエキスパートにお願いすればいいかなっと。

現時点のやるきのないコードの一部（試行錯誤の跡付き）

■ おわりに

というわけで、「タイマ作りました、動いてます」というとっても退屈な記事ですが、、こんな事してみましたよ、ってことで。私のようなヘボでもいじくれる所があるというのは有り難いものです。

Advent Calendar 参加者の皆さんの記事、楽しく読ませていただきました。今後ともよろしくお願いします。

退職のお知らせ

hasegaw — 2011-06-04T02:30:23+09:00

既にご存知の方も多いかと思いますが、株式会社SRAを退職いたしました。

SRAには2004年に新卒として入社、以後7年間に渡りIAサーバを中心に、システム構築および運用サービスに従事しておりました。サーバの構築には学生時代から興味をもって取り組んでいたものの、ビジネスとして取り組むITは非常に新鮮で、同社社員、およびお客様方から大変多くのことについて学ぶことができました。自分にとって忘れられない7年間になりました。ありがとうございました。

在籍期間中、職場の同僚やマネージャ陣には大変お世話になりました。直接の業務ではないXen徹底入門の執筆、また、昨年に公開した仮想マシンのしくみの解説スライドなどのプロジェクトに必要な時間をやりくりして来られたのは、職場や上司の理解があり、時には、少なからずのバックアップいただけたという事情もあり、同社の社員としてこれまで業務に取り組めた事をありがたく、大変誇りに思っております。

6/1からの三日間はLinuxCon JAPAN 2011にアテンドさせていただきました。日本中、世界中のエンジニアとまた新たなつながりができました。会期中に受けた刺激で充電し、これから自分がどのようにITインフラストラクチャに関わっていけるかを考えていきたいと思っております。

SRA在職中は、多くの方々に大変お世話になりました。今後も引き続きご指導のほど、よろしくお願いいたします。

Takeshi HASEGAWA aka hasegaw

#ssmjp に参加してきました。

hasegaw — 2011-05-30T01:23:35+09:00

5月26日(水)に開催されたささみの会(#ssmjp、新橋勉強会とか別の名前が色々あるようですが)にてプロジェクトマネジメント的観点からプレゼンテーションをさせていただきました。ちょっと私のスケジュールがテンパっていた都合、事実上私の都合に合わせて開催していただいたような感じで……。 @togakushi さんには大変ご迷惑おかけしました。

20110526ssmjp

View more presentations from Takeshi Hasegawa

さて、プロジェクトマネジメントというと、普通は限られた予算・時間・リソース内でいかに仕事を片付けるかという話が一般的にされるわけですが、今回はそれとはちょっと違います。本業における私の立場では、プロジェクトマネジメントというよりはプロジェクトをリードする立場で、いかにプロジェクトが円滑に回るように、最短で片付くように、という観点から支援していく立場にあります。この立場で仕事をしているうちに思ったことなどを資料にまとめて 30 分ほどお話しさせていただきました。

前日の夜、酔いつぶれた状態で資料を作り始め、途中でやめて寝てしまうという事件があったため（ｗあまり内容がまとまっていない、私の私見と独断ベースの「仲間と一緒に戦うための心得」みたいな感じになってしまいましたが……。

某社の新人さんも何名かいらっしゃっていたようで……もし、私の話を聞いて、今後、より主体的に仕事に取り組んでくれるような若手になってくれたら ——— この夜の目的としては達成と言えるのかな、とか、そんなことを思っています。

東京OpenSolaris勉強会 2011.05に参加してきました。

hasegaw — 2011-05-30T01:00:57+09:00

5月28日(土)に開催された、東京OpenSolaris勉強会 2011.05に参加してきました。

@nslope さんに「自宅ZFSで盛り上がろうず！」とお声がけをいただいたので、構成的にヘンタイな我が家のZFS環境について簡単に紹介させていただきました。

20110528東京OpenSolaris勉強会2011.05

View more presentations from Takeshi Hasegawa

OpenSolaris 界隈の方はマニアックな方々ばかりなので今頃私が ZFS 自体の話をしても全然面白くなりませんし、ということで、あくまでもZFS的に非一般的な我が家のZFS環境についての紹介とさせていただきました。

私の自宅では、 CentOS 5 の Xen 環境において OpenSolaris の開発版スナップショットが動いており、 ZFS ファイルサーバとして利用しています。こうしてある理由としてはファイルサーバとしてZFSの最新機能を活用しつつ Linux とのコンソリデーションを実現する、またOpenSolarisに対応できないような安価なハードウェアでもZFSの恩恵を得るために、そういった構成にしています。

ZFSのオイシイところは、信頼性と管理性だと思います。Linuxのmdraidなどは意図せぬ停電やカーネルパニックでアレイの不整合などが起きると大変です。しかし、ZFSの場合は書き込み操作がトランザクション保護されており、中途半端な書き込み操作が多少起きたぐらいではデグレードしません。仮にデグレードしても、 End-to-end checksum による確認が可能なので、デグレ中や復旧作業後にデータが維持できているかどうかを判断できる点も魅力です。また、（喩えれば水と油を１つのバケツに溜めておける、と私はZFSを紹介することが多いのですが）データの管理が非常にフレキシブルなのもポイントです。

私は基本的には「重要なデータは持たない」（データを持つと管理コストが生じるので）という方針にしていますので、仮に手元のデータがロスしても精々数日ヘコむぐらいで済むよう心の覚悟をいつもしている（つもりな）のですが、これまで３年以上の運用期間中に２回のデグレが発生しても、嬉しいことに、データロスにまでは至っていません。また、これまでの経験から、使い始めた当初は色々と罠があった ZFS ですが、だいたいイケるところが見えてきたので、これからも ZFS を使っていくつもりです。

青山のオラクルさんのビルにて Linux の上に乗った OpenSolaris の話をしたり、リプレース時のOS候補は FreeBSD-current だとか話をしたりとかなり KY でしたがニヤニヤしながら聞いてくださった参加者の皆さん、ありがとうございました。

qpstudy 06 の懇親会に参加してきました。

hasegaw — 2011-05-30T00:42:00+09:00

5月28日(土)に開催された qpstudy 06 の懇親会に参加してきました。 qpstudy は IT インフラストラクチャを扱うエンカイチックな勉強会で、 qpstudy 03 の頃から、都合がつけばできる限り参加するようにしています。これまで勉強会の参加記録などは blog には書いてなかったんですが、折角 trackback 企画があるのでチャレンジ！

（本当は本編にも参加したかったんだけど、東京 OpenSolaris 勉強会 2011.05でテーマとして ZFS を扱うということで、 @nslope さんに私の都合を考慮して（？？）日程を決めていただいていた事もあり……昼過ぎ〜夕方には東京 OpenSolaris 勉強会＠外苑前、それが終わってから割と急いで大森のニフティさんにハシゴするという感じに……）

本編では @sho7650 さんのリードにより、普段の宴会チックな qpstudy とは全く雰囲気が違う勉強会になっているなーというのを Twitter のタイムライン越しに感じていたのですが、残念ながらそれが終わった頃にやっとこ現地到着。あ、通用口まで迎えにきてくださった @ysaotome さん、ありがとうございます。

懇親会は例によってピザとビールを囲んでの LT 大会です。折角なので私も LT やらせていただきました。

20110528qpstudy06懇親会LT「雪山の話」

View more presentations from Takeshi Hasegawa

本当は別のネタを仕込んでいたのですが、このスライドのほうが、勉強会本編のテーマにも沿ってるかも知れなくてGoodかな？と思い、セレクト。簡単にご紹介すると、明治３５年に行われた八甲田山の雪中行軍のお話をベースに、プロジェクトを円滑を進めるためには以下のような点が重要だよね？という感じでまとめさせていただきました。

スコープを把握する
問題を見つけたら対策をとる。判断を先送りしない
主体的・積極的に問題に取り組む。他人まかせにしない

今あらためて見るとヘボいスライドだなぁ……

◇

後、もう一本。ちょっと時間が余っているということだったので、 LT で @masudaK さんが発表されていた「海外MLに積極的に出ようよ！」という内容に共感したので、全くの突然でしたが、カーネル／VM探検隊向けに作成した LT 資料でも簡単に発表させてもらいました。

20110522kernelvm xen+virtio

View more presentations from Takeshi Hasegawa

なお、 LT の発表時間実績が 5 分 0 秒ジャストだったのは、、、、、偶然ですｗ

Xen Meets virtio

hasegaw — 2011-04-28T03:40:05+09:00

開発版バージョンである xen-unstable と最新の qemu を組み合わせることによって virtio-net が Xen でも使えるようになってきたので紹介したいと思います。

■ 必要なもの

xen-unstable をレポジトリからひっぱってくる
qemu を git://xenbits.xen.org/people/aperard/qemu-dm.git から引っ張ってくる。ブランチ qemu-dm-v14 をチェックアウト。
QEMU のクラッシュを防ぐ vmport パッチ http://ysr.jp/~hasegaw/upstream-qemu_vmport.patch
(vmportにアクセスしてくるような最近のdistroを動かす際に必要)
virtio対応のゲストOS

■ 設定方法

ドメイン定義ファイルで vif 行を下記イメージで記述します。

vif = [ 'type=ioemu, bridge=br0,mac=00:16:3e:09:ac:cd,model=virtio' ]

またドメインの作成には xl コマンドを使ってください。 xm コマンドだと新しい QEMU に対応できない可能性があります。

■ ゲストOS側の留意事項

Xen と QEMU の割り込み関係の相性が悪いのか、 MSI(-X) による割り込み通知が正しく inject されないようです。現時点の回避策として、ゲスト OS として Linux を起動する際に下記のカーネルパラメータを付けると問題を回避できます。

pci=nomsi

■ 参考

QEMUUpstream - Xen Wiki