Xen 3.4ソースコード、構造紹介 | エンタープライズ | マイコミジャーナル
Xen - hypervisor, the powerful open source industry standard for virtualization. Stephen Spector氏がXen 3.4 Source Code Overview - blog.xen.orgにおいて最近リリースされたXen 3.4のソースコードオーバービューファイルXen Source 3.4 Guide (ODT)を公開した。データはODT形式で、閲覧にはOpenOffice.orgなどのアプリケーションが必要。Xen Source 3.4 Guideの内容はその名前のとおり、配布物のディレクトリ構造とファイルがリストアップされ、そのファイルがなにをするものなのかが簡単に説明されている、というものになっている。どのファイルにどの機能が実装されているのかが把握しやすい。 Xen 3.4 Source
ベンチマーク：ESX対Hyper-V対XenServer（20090313-1） | virtualization.info
どれだけ一生懸命探しても「Citrix XenServer」対「Microsoft Hyper-V」対「VMware ESX」のパフォーマンス比較を見つけることはほぼ不可能だろう。 VMware End User License Agreement（EULA）には、採用された手法の審査と承認が終わるまで第三者によるパフォーマンステストはいかなるものも認めないという具体的な記述がある。 （2006年6月以前の状況はさらに悪く、VMware社はベンチマーク比較の公開を一切認めていなかった。） これらの条件においては、VMware社がパフォーマンスで競合各社の後塵を拝するようなベンチマークが登場する可能性はない。 にもかかわらず、Virtualization Review社の勇敢なレポーターたちは先週、VMware社に挑戦状をたたきつけ、無許可で独自分析を公開した。 テスト結果の有効性とテスト環
Stray Penguin - Linux Memo (Xen)
1台のマシン上で Linux や別の OS を複数稼働させることのできる仮想化技術。最近は VMWare もかなりパフォーマンスが改善されたが (※)、Xen は OS上のOS だということをほとんど意識させないオーバーヘッドの少なさが売りだ。また、ひとつの基幹サービス (たとえば Webサービス) を OSごと根こそぎ分離するという用途においては、Xen は chroot の究極のカタチであるとも言える。Xen では、ゲストOS (子供) とホストOS (親) はカーネルもライブラリもそれぞれで持ち、ゲストは他のゲストやホストのリソースにほとんど影響を与えられないようにできているからだ。 また、例えば Apache HTTPSサービスと NFSサービスを提供したい時、ゲストOS 1 は Apache 専用にして CPU を 2個割り当ててメモリ割り当ても多めに、ゲストOS 2 は NFS
XenSummitTokyo2008Libvirt - mizzy.org - Trac
Xen Summit 2008 Tokyo で発表した、「Operating Xen domains through LL(Perl/Python) with libvirt」の資料を SlideShare にアップしました。 libvirt という仮想化システムを操作するためのライブラリがあるんですが、それをつかって Perl/Python で Xen を管理するプログラムを書く、ということにフォーカスした内容です。 Perl/Python での libvirt プログラミングだけではなく、libvirt そのものの概要やアーキテクチャ、Avahi という mDNS 実装との連携で、libvirtd が動いているホストを自動で発見する Perl コードのサンプル、Func の virt モジュールは裏で libvirt を使ってる、といったような内容が含まれています。 Xen Summi
ドメインの切り替え【後編】
コンテキスト切り替え処理の大枠 この部分は、複数のドメイン（ゲストOS）を切り替える心臓部です。ドメイン切り替え処理の大部分は割り込み禁止状態で行います（リスト1のA3、A6、A8）。まず、スーパーバイザースタックの底に置かれているcurrent変数が、次に動作する仮想CPU nextを指すようにします（A4）。 このとき、もし同じ仮想CPU同士で切り替えを指定された場合は（つまり、prevとnextが同じ場合は）、当然コンテキストを切り替える必要がありません（A5）。さらに、次に動作する仮想CPUがアイドルドメインのものである場合も、ここではコンテキストの切り替えを行いません（A5）。先ほど説明したように、実際の切り替え処理を遅延させます。 ドメイン同士の場合、通常はコンテキストの切り替えを行います。コンテキスト切り替えの大部分は、__context_switch関数（A7）で行います（
ドメインの切り替え【前編】
domain構造体とvcpu構造体 Xenは、各ドメインをdomain構造体で管理し、仮想CPUをvcpu構造体で管理します。それぞれのドメイン（domain構造体）には、複数の仮想CPU（vcpu構造体）が対応付けられています。 仮想CPUは、各CPUごとに用意されたRUNキュー（実行キュー）に登録されます。それぞれのRUNキュー上の仮想CPUの1つが、実CPUと対応付けられ、その仮想CPUを含むドメイン内のゲストOSが実行されます（図3）。 ハイパーバイザースタック Xenは、ハイパーバイザースタックを1つだけ持っています（正確には実CPUごとに1つのハイパーバイザースタックを用意しています）。Linuxカーネルが、プロセスごとにカーネルスタックを用意していたのと対照的です。これは何を意味するのでしょうか？ Linux上のプロセスは、システムコールやページフォルトの途中で処理を中断し、
[ThinkIT] 第4回：Xen上のVMにおけるネットワーク性能 (1/4)
第1回〜第3回では、どちらかというとドメインU単体での使用を想定して検証を行ってきました。しかし、よほどのことがない限りは、スタンドアロンでVM（VirtualMachine）を使うということはあまりないでしょう。そこで第4回では、VMから見たネットワークの性能を測定します。 今回の環境もまた、XenでドメインUが動作している環境が必要になります。基本はドメインUが動作している環境なので、今回も前回までの環境をそのまま使います。前回までのドメインU環境は、普通にネットワークが利用できるので、そのまま使って差し支えありません。 なおI/Oは、/dev/nullに向けて発生させます。こうすることで、物理的なI/Oは発生せず、純粋にネットワーク単体の性能に近い結果を得ることが可能になります。 また物理的な構成ですが、Xenが動作しているコンピュータと、それ以外のコンピュータを100MbaseTで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Xen_and_Rails_deployment
[ThinkIT] 第3回：プログラムコンパイル時のパフォーマンスは？ (1/3)
[ThinkIT] 第2回：ドメインUのI/Oパフォーマンスチェック (1/3)
[ThinkIT] 第1回：CPUのパフォーマンスチェック (1/3)