![[Pocketstudio.jp Linux Wiki]](image/icon.gif "[Pocketstudio.jp Linux Wiki]"){kind=icon}
Xen/Docs/ユーザーズマニュアル日本語版2.0
http://pocketstudio.jp/linux/?Xen%2FDocs%2F%A5%E6%A1%BC%A5%B6%A1%BC%A5%BA%A5%DE%A5%CB%A5%E5%A5%A2%A5%EB%C6%FC%CB%DC%B8%EC%C8%C72.0
|
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html Xen User's manual Xen v2.0 for x86 免責条項：このドキュメントは現在作成途中の段階にあるもので、誤記述や問題があるかもしれません。くれぐれもご注意下さい。もし何かあれば開発者メーリングリストに報告をお願い致します。あわせて、資料・提案・校正等の貢献は大歓迎です。 1. 導入とチュートリアル †Xen は x86 プロセッサ互換アーキテクチャに対する並行仮想化(paravirtualising)仮想マシンモニタ(VMM = Virtual Machine Monitor)、あるいは「ハイパーバイザー」(hypervisor) です。Xen は１つの物理的なシステム上で動作開始から終了まで性能を落とすことなく、安全にそれぞれが独自の OS で稼働する複数の仮想マシンを実行することができます。この仮想マシン技術は極めて先進的な機能性を以下のような技術によって実現しています：
並行仮想化(paravirtualising)により伝統的に仮想化が非常に困難だった x86 アーキテクチャに対しても、仮想化された環境下で非常に高い性能を発揮することを可能としました。Xen を用いる手法の欠点は、オペレーティング・システム上に Xen の機能を移植しなくてはいけない事です。Xen が移植された OS 上では新しいハードウェア基盤がサポートされているように見えます。ですが、実際には並行仮想化マシン・アーキテクチャが、本物のハードウェアに非常に類似した単純なプロセスが、そのように見えているだけなのです。オペレーティング・システムはカーネル上で必ず Xen を実装しなくてはいけなませんが、重要なのはユーザが利用するアプリケーションやライブラリに対しては一切の変更を必要しないという事です。 Xen は多数のオペレーティング・システムをサポートしています。現時点の Xen 2.0 では Linux 2.4・Linux 2.6・NetBSD が利用可能です。FreeBSD に対する移植作業はテスト段階にあり、まもなく正規リリースに取り込まれるようになるでしょう。Plan 9 等、その他の OS への移植作業も進行中です。私たちは arch-xen パッチが近いうちにこれらオペレーティング・システムの正規リリースに組み込まれれる事を（既に NetBSD で実施されているように）希望しています。 Xen は以下のような利用方法を想定しています：
1.1 Xen 基礎システムの構造 †Xen システムは複数の層(layers) から構築されており、最下層に特権を持つ Xen 自身が位置します。Xen は、それぞれが安全に完全独立している仮想マシン群（ Xen の専門用語でドメイン"domain" と呼びます）で複数のゲスト・オペレーティング・システムを動作させます。ドメインは Xen によって利用可能な物理 CPU を効率的に利用できるよう、計画的にリソース*1が分配されます。それぞれのゲスト OS は、自分自身のアプリケーションを管理します。また、管理の中には Xen によって仮想マシンにリソースが割り当てられた期間内に処理を実行するという責任も含まれています。 システムの起動時に、特権管理機能を持つ domain 0 という１番目のドメインが作成されます。また domain 0 は仮想マシンの停止・再開や移行といった管理機能も実装されています。 domain 0 には xend と呼ばれるシステム管理プロセスが動作しています。xend は仮想マシン群を管理する役割があり、それぞれのコンソール群にアクセスすることができます。コマンドは HTTP インターフェース経由やコマンドライン、ウェブ・ブラウザから xend に対して実行することができます。 1.2 ハードウェアのサポート †現時点で Xen でサポートしているのは x86 アーキテクチャのみです。そのなかでも "P6" 以上の新しいプロセッサを必用とします（この中には Intel 社製のものと、過去５年間に公開された AMD x86 互換 CPU も含みます）。マルチプロセッサ（複数 CPU ）マシンもサポートされていますが、ハイパー・スレッディング 機能(SHT)のうち基本的な部分のみサポートしておりますが、さらなる実装に向けて重要な課題として研究も進められています。x86/64 システムへの移植作業は進行中です。現時点で既に 32 ビットのレガシー・モード（下位互換）では動作を確認しています。付け加えておくと、IA64 アーキテクチャへの移植が完成に近づいています。可能であれば、 PPC といった他のアーキテクチャにも実装するこが出来ると見込んでいます。 Xen は現在 4GB のメモリを扱うことが可能です。x86 マシンでは 64GB まで物理メモリを確保することができますが、現時点で Xen システム上でサポートする予定はありません。x86/64 への移植に際してはメモリサイズの増大が出来るよう計画しています。 Xen は Domain 0 として動作しているゲスト OS に対して、かなり大部分のハードウェア利用を解放しています。Xen は自分自身の中に第二のプロセッサを検出・始動させ、割り込みルーチンをセットアップし、PCI バスのエミュレーションを行うためだけの単純な命令セットを要求します。デバイス・ドライバに関しては Xen の中でというよりも、むしろ特権を与えられたゲスト OS 上で動作します。この手法により、Linux によってサポートされているハードウェア装置に対しかなりの互換性を実現できるようになりました。標準の XenLinux? ビルドでは、比較的新しいサーバ・クラスのネットワークとハードウェア装置に関するサポートを行いますですが、XenLinux? のカーネル構成の調整次第では、その他のハードウェアのサポートを行わせることも可能です。 1.3 歴史 †Xen は元来、英国の EPSRC(The Engineering and Physical Sciences Research Council＝イギリス政府による技術と物理科学に関する研究助成機関)より資金提供を受けて開発が開始されました。当初はケンブリッジ大学のコンピュータ研究所に所属する XenoServers? 計画(ゼノ・サーバーズ)グループにより開発が進められました。XenoServers? は「広範囲にわたる分散計算の為に公開される基礎構造」の提供をめざしており、Xen は、多数の独立したクライアントの保護、リソースの隔離と確保を行う環境を、１つのマシン上で個々に独立したオペレーティング・システムを動作させてアプリケーションを効率的に分散動作させる為の中核となる技術です。プロジェクトのウェブページ内には詳細な情報や指針、関連する技術レポートを掲載しています：http://www.cl.cam.ac.uk/xeno Xen は元来、 CPU・メモリ・ディスク・ネットワークといったリソース(資源)を仮想化する為の理想的な手法を模索する事が研究目的でしたが、現在では完全な独自のプロジェクトへと成長しました。プロジェクトはケンブリッジのインテル研究所や HP 研究所による強力な支援により、共同研究体制が強化されつつあります。 当初 Xen は 2003 年の SOSP (Symposium on Operating System Principles = オペレーティング・システムに関するシンポジウム) において発表がなされ*2、10 月には公開版(バージョン 1.0)のリリースが行われました。それ以後、Xen は著しい成熟を遂げ、現在では多くのサイトで実運用されるまでに至っています。 Xen 2.0 の大きな特徴は、ハードウェアのサポートし、設定システムの柔軟性や操作性の向上、そして、多数のオペレーティング・システムをサポートするようになった事です。最新リリースに於いては、Xen がオープンソース・ソフトウェアを用いた仮想化のための決定的なな手法へと近づきつつあります。 2. インストール †Xen は主に３つのディストリビューションに組み込まれてます：Xen そのものが inux 2.4・Linxu 2.6・NetBSD に移植され、稼働する事が可能になっており、Xen を基本としたシステム管理をユーザ単位で行うことが出来るようになっています。この章ではどのように Xen 2.0 を配布されているソースを元にインストールするかについて述べます。インストールをしなくとも、ディストリビューション中のオペレーティング・システムしによっては、既にパッケージ群が利用可能な状態に移植済みの場合もあります。 2.1 必要条件 †以下に必要となる条件を述べます。項目の中で'†'と印が付いているものは、xned 管理ツールによって必要とされるものであり、仮想マシン環境を実行するためには必須となるものです。また'*'と印が付いている項目はソースから構築したい場合のみに必要とされます。 † ブートローダーに GRUB を用いる Linux ディストリビューションで、P6 クラス（あるいは、それ以上）の CPU を実装していること † iproute2 パッケージ † Linux bridge-utils*3 (例：/sbin/brctl) † Twisted バージョン 1.3*4 以上のインストール。ディストリビューションによってはバイナリのパッケージが利用可能な場合もあります。あるいは Xen のソース展開ディレクトリ内で `make install-twisted' としてインストールする事も可能です。
以上のような適切な必要条件を満たすことが出来れば、Xen のインストールあるいはソースコードからの Xen 構築が可能となります。 2.2 バイナリの Tar 形式(Tarball)からのインストール †ビルドされて構築済みの tar 形式の圧縮ファイルは、以下の Xen ダウンロード用ページから取得可能になっています。 tar 形式の圧縮ファイルを取得後は、単純に展開してインストールするだけです。 # tar zxvf xen-2.0-install.tgz # cd xen-2.0-install # sh ./install.sh あとはセクション 2.4 で記述されているように、インストールされた必要に応じてシステム構成に関する設定を行ってください。 2.3 ソースからのインストール †当セクションではどのように Xen のソースを取得・構築し、インストールするかを述べます。 2.3.1 ソースの入手 †Xen のソースコードは tar 圧縮形式、もしくは私たちの運営する BitKeeper? レポジトリより取得可能です。 tar 形式で圧縮されたソースの入手
BitKeeper? の使用
2.3.2 ソースからの構築 †カーネルのソースコードに対して Xen をトップレベルで読み込ませるために、make のターゲットは 'world' を指定します。次のように作業をすすめます：
ビルドが完了すると dist/ をトップレベルとするディレクトリ内に対象となるファイル群が構築されています。XenLinux? カーネルにとりわけ関係があるのは２つのカーネル・イメージが構築されます。１つは '-xen0' と付いている Xen 上で動作する仮想デバイス用のドライバ群と、ハードウェア装置のドライバ群が含まれています。もう１つは '-xenU' と付いている仮想デバイス自身が用いるためドライバ群です。これらは Xen を移植したカーネルやビルド時に用いた設定用ファイル群と共に dist/install/boot/ ディレクトリ内に置かれています。 NetBSD への移植は以下のようにして構築できます： # make netbsd20 NetBSD への移植は netbsd-2-0 csv ブランチで提供している最新のスナップショットを用います。スナップショットは NETBSD_SRC_PATH 検索パスを特に明示しなくとも構築時のプロセスに於いて自動でダウンロードされます。構築作業時にはは Linux カーネルで動作する際に必須となる NetBSD カーネルのためのツール群も同時にダウンロードされます。 構築されるカーネルに対して調整したい事項がある場合、トップレベルの Makefile を編集します。次の行を探してください。 KERNELS ?= mk.linux-2.6-xen0 mk.linux-2.6-xenU 必要に応じて buildconfig/ ディレクトリのトップレベルにあるオペレーティング・システムに関する設定ファイルを定義した行を編集してください。たとえば、mk.linux-2.4-xenU というのは Linux 2.4 カーネル向けに仮想デバイス・ドライバ群のみを構築するという意味になります。 2.3.3 XenLinux? 構築のカスタマイズ †カスタムされた XenLinux? カーネルを構築したい場合（例えばデバイスを追加したりディストリビューションによっては必要とされる機能を有効にしたい時）、xen 向けのアーキテクチャとして標準的な LInux 設定手法を用いる事ができます。例えば、 # cd linux-2.6.11-xen0 # make ARCH=xen xconfig # cd .. # make あるいは既存の Linux に対する設定情報（.config ファイル）を linux-2.6.11-xen0 に反映させるためには、次のように実行します： # make ARCH=xen oldconfig 必要に応じて Xen に関連したオプションを指定しなくてはいけない場合もあります。そのような場合、そのまま提示されるオプションを標準のものとして受け入れることを勧めます。 構築される２種類の Linux カーネルにおける唯一の違いは、それぞれのカーネルのために用いられている設定ファイルが違うだけだという事を覚えておいてください。"U" と付いている（特権のない）バージョンは物理的なハードウェア装置のサポートを行わないので、30% ほどカーネルのサイズが小さいです。そのため、特権を与えられていないドメインを使うよりは、むしろこちらを利用したほうが良い場合もあります。"0"と付いている特権を持つバージョンはシステムの起動時に必要とされるものであり、ドライバの管理は行うものの、特権を与えられていないドメインです。 2.3.4 バイナリのインストール †構築プロセスによって作成されたファイル群は dist/install/ ディレクトリ配下に置かれています。それらを標準の場所にインストールするには、次のようにします： # make install あるいは、ユーザによっては特殊なインストール方法をしたい場合もあるでしょう。その場合は、特定のファイルを対象とするディレクトリにコピーする事でもセットアップ可能です。 dist/install/boot ディレクトリには XenLinux? カーネルを構築する際に必要となる設定ファイル群も置かれています。また、Xen のバージョン情報と XenLinux? カーネルに含まれるデバッグ用のシンボル（xen-syms-2.0.6 と vmlinux-syms-2.6.11.11-xen0）はクラッシュ時にダンプするデータを解析する際に必要となるものです。何かメーリングリストに投稿する際には開発陣はこれら設定ファイルを必要とする場合もありますので、削除せずに保管しておいてください。 2.4 設定 †一旦 Xen を構築してインストールさえしてしまえば、マシンの起動時に Xen を実行させるのは単純な作業です。 2.4.1 GRUB の設定 †Xen/XenLinux? が起動できるよう grub.conf （通常は /boot/ か /boot/grub/ 配下です）に記述を書き加えます。特定のディストリビューションでは menu.lst とも呼ばれています。以下に表示されているような記入を行ってください： title Xen 2.0 / XenLinux 2.6 kernel /boot/xen-2.0.gz dom0_mem=131072 module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro console=tty0 kernel 行では GRUB に対して Xen 自身がどこにあるか、そして、起動時にどのようなパラメータを渡すのかを記述します（この場合は domain 0 が確保するメモリ容量をキロバイト単位で指定し、シリアル・ポートの設定を行っています）。Xen の 起動パラメータについてはセクション 8.2? をご覧下さい。 module 行では XenLinux? カーネルがどこに位置しているかを記述し、Xen が開始されるべき時に必要となるパラメータを指定しています（これらは標準的な Linux のパラメータ群です。root となるデバイスを指定し、Read-Only = 読み込み専用モードとして稼働し、画面上にコンソール出力を行うよう指示するものです）。SuSE などのディストリビューションによっては ro パラメータは不要です。 もし initrd を使いたい場合は、通常通り設定ファイルに module 行を追加してください。次のようにします： module /boot/my_initrd.gz 2.4.2 シリアル・コンソール（オプション） †Xen をシリアル・コンソール上へ出力したい場合には GRUB の boot オプションへ設定の追加が必要です：例えば上記の例で用いた kernel 行は次のように置き換えてください： kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1 この設定により Xen は COM1 に出力され、通信速度は 115,200 ボー(boud)、8 データ・ビット、１ストップ・ビット、パリティ無しという指定です。パラーメータは必要に応じて書き換えてください。 XenLinux? に対してシリアル・コンソールを共有させることも出来ます。このような場合はモジュール行に"console=ttyS0" を書き加えてください。 もし XenLinux? へシリアル・コンソール上からのログインをしたい場合には、/etc/inittab に通常の Linux の設定と同様にコンソールに関する記述を行ってください。次の行を加える単純なものです： c:2345:respawn:/sbin/mingetty ttyS0 これでログインできるようになります。root ユーザとしてログインしたい場合、最近のディストリビューションでは /etc/securetty ファイルの中に ttyS0 の記述が無いといけない事があります。ご注意下さい。 2.4.3 TLS ライブラリについて †XenLinux? 2.6 カーネルを使うユーザはローカル・ストレージに関するスレッドを無効にして XenLinux? カーネル*5を作動させるべきです（例：コマンド mv /lib/tls /lib/tls.disabled を実行します）。必要に応じてディレクトリを元にもどせば、いつでも TLS を利用可能にできます（例：コマンド mv /lib/tls.disabled /lib/tls を実行します）。 TLS が無効でなければ（有効な場合）、Xen はエミュレーション・モードを使用する必要がないため、エミュレーションによる大幅な性能低下を招くことはありません。私たちは、この TLS ライブラリの下位互換性に関する問題に関して、ディストリビューションの開発ベンダと協力しながら解決したいと考えています。 2.5 Xen の起動 †あとはシステムの再起動をおこなうことで Xen が利用可能となるでしょう。普通どおり起動させ Grub の画面が表示されたら Xen を選んでください。 その後の動作については通常の Linux 起動と全く変わらないように見えるでしょう。Xen によって出力される最初の部分では、マシンの動作に関する基底レベルの情報を提供します。Xen に関する情報は XenLinux? という表記の後に続きます。 XenLinux? のブート中には若干のエラーが表示される場合もありますが、気にしないでも大丈夫です。これは XenLinux? カーネルと本来の Linux カーネル間での何らかの設定の違いが原因となっている場合があるでしょう。 起動が完了すると、通常通りシステムにログインすることが出来るはずです。もし Xen を動作させることでシステムにログインすることが出来なくなるようであれば、再び再起動して通常の Linux カーネルを呼び出してみてください。必要に応じて設定を見直す必要もあるでしょう。 3. ドメインの追加をはじめましょう †新しいドメイン（Xen では仮想マシン環境の事を"ドメイン"と呼びます）を作成する手始めに、ブート可能であるルート・ファイルシステムを準備します。とりわけ、この作業は通常のパーティション作成や、 LVM ・その他のボリューム管理システムによるパーティション管理や NFS サーバなどのためのディスク領域の準備と似たようなものです。単純な方法としてはディストリビューションによって配布されているインストール用の CD-ROM を使って。ハードディスク上に別のパーティション領域を確保するというものです。 xend を起動するには、次のようにコマンドを実行します。
xend デーモンを自動的に起動させたい場合は、セクション 6.1 の指示をご覧下さい。デーモンが稼働さえしてしまえば、xm ツールを利用し、システム上で動作しているドメインの監視やメンテナンスを行うことが可能です。この章では非常に簡単なチュートリアル（導入編）を提供します。xm ツールを使った詳細については次の章で述べます。 3.1 ドメイン設定ファイルの作成 †ドメインの追加作業を行う前に、まずは設定ファイルの作成が必要です。まずは手始めとして利用できるよう２つのサンプルファイルを提供します。
これらのファイルをコピーして、適切に編集してください。ファイルの中には調整を行うための典型的な変数があります。
必要に応じて vif 変数を用い、自分自身の仮想イーサネット・インターフェースのために MAC アドレスを直接指定する事も出来ます。
vif 変数を設定しない場合、xend が使用されていない MAC アドレスを任意に作成し、自動で MAC アドレスを割り当てます。 3.2 ドメインの起動 †ツール xm はドメインを管理するための様々なコマンドを備えています。create というコマンドをは新しいドメインを開始します。サンプルファイル /etc/xen/xmexample2 を参考にして作られた myvmconf という設定ファイルをベースとし、domain 1 という仮想マシンを実行するには次のように実行します。 # xm create -c myvmconf vmid=1 オプション -c は xm を実行後に、コンソールをその作成したドメインに移動させるという意味があります。vmid=1 と設定しているのは設定ファイル myvmconf の中で用いる vmid 変数に対する指定です。 コマンドが正常に実行されると、コンソール上で新しいドメインが起動してきて、仮想端末が表示されるのを確認できるでしょう。 3.3 設定ファイル例：ttylinux †ttylinux は極めて少ないリソースしか必要としないように設計された、とても小さな Linux ディストリビューションです。Xen でドメインを使い始めるにあたり、この ttylinux をつかって具体的な手法を紹介します。基本的な部分を理解できるようになれば、ディストリビューションの完全版のインストールをしてみてもいいでしょう*6。 1. ttyplinux のディスクイメージを SourceForge サイト）（http://sf.net/projects/xen/ をご覧下さい）の File セクションからダウンロードして展開して下さい。 2. 次のような内容の設定ファイルを作成してください。 kernel = "/boot/vmlinuz-2.6-xenU" memory = 64 name = "ttylinux" nics = 1 ip = "1.2.3.4" disk = ['file:/path/to/ttylinux/rootfs,sda1,w'] root = "/dev/sda1 ro" 3. コンソール上から新規ドメインを作成します： xm create configfile -c 4. root として root パスワードを入力して下さい。 3.4 ドメインの自動起動・停止 †マシンの dom0 ドメイン起動時に自動的に各ドメインが開始されるようにしたり、システムの停止時に自動的にドメインも停止させる事が出来ます。 起動時に特定のドメインを開始したい場合、/etc/xen/auto/ ディレクトリ内に設定ファイルを置きます。 Sys-V 形式の init スクリプトを用いている RedHat や LSB 互換システムのために、自動起動スクリプトが /etc/init.d/ へインストール時にコピーされます。ディストリビューション毎に適切な方法で自動実行するようにできます。 例えば、Red Hat の場合は次のようにします：
標準では、起動時のドメインのランタイムは 3・4・5 のいずれかです。 また、service コマンドを使って手動でスクリプトを実行させることも可能です：
4. ドメイン管理ツール †前の章ではドメインの設置と、簡単な開始方法の例について記述しました。この章では実際に動作しているドメインを管理するために利用可能なツール群についてまとめてあります。 4.1 コマンドラインからの管理 †コマンドライン上での管理は xm ツールを使って行います。利用可能なコマンドを参照するためのオンライン・ヘルプがあります。次のように入力してください：
あるいは xm help <コマンド名> としてコマンドに関する詳細情報を読むこともできます。 4.1.1 基本管理コマンド †最も重要なコマンド群は以下のものです。
4.1.2 xm list †xm list による出力は次のようなフォーマット形式です。 name domid memory cpu state cputime console
xm list コマンドでは -l オプションを使うことで、より詳細な利用状況を出力することも出来ます。この出力には xend の SXP 設定フォーマットに基づく全ドメインの稼働状況の詳細が記述されます。 例えば、上記の例で用いた ttylinux ドメインを動作させるとします。list コマンドを使うと次のような出力を行うはずです： # xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 251 0 r---- 172.2 ttylinux 5 63 0 -b--- 3.0 9605 このように ttylinux に加えて domain 0 に対しても（もちろん domain 0 は常に稼働しています）詳細を見ることが出来ます。ttylinux ドメインに対してのコンソール背得俗ポートが 9605 番である事に注意を払ってください。これは TCP を用いる端末プログラムを使って接続可能な事を意味しています（telnet よりも xencons のほうが望ましいです）。xm console コマンドを使って特定のドメイン名やドメイン ID に接続する方法が最も単純な方法です。ttylinux ドメインに接続するためには、以下のコマンドのどれでも利用可能です。 # xm console ttylinux # xm console 5 # xencons localhost 9605 4.2 ドメインの保存と復帰 †Xen システムの管理者の中には、仮想マシンの状態を一時的にファイルへ保存し、あとから domain 0 を経由して状態の復帰をさせたい方もいるでしょう。 上記の例で用いた ttylinux ドメインを一時停止させディスクに情報を保存するには、次のようにコマンドを入力します： # xm save ttylinux ttylinux.xen このコマンドにより 'ttylinux' という名前のドメインは停止され、その時点での情報が ttylinux.xen というファイル内に保存されます。 ドメインの状況を復帰させるには xm restore コマンドを用います： # xm restore ttylinux.xen コマンドを実行することにより、ドメインを元通りの状況に復帰させ、動作可能な状態に移行させます。稼働したドメインに対しては以前同様に xm console コマンドを使ってコンソール画面に移行することも出来ます。 4.3 live migration (生データの移行) †ドメインが稼働し続けている状態のまま、物理的なホスト間でドメインを移行するために live migration 機能を用いることができます。この動作は一般ユーザーレベルでは移行を検知できないようなものです。 live migration 機能を用いるためには、両ホスト間で Xen の導入および xend の稼働を行っていなくてはいけません。そして、移行対象となるホストにはドメインを受け入れるための十分なリソース（例えばメモリ容量）を持っていなくてはいけません。付け加えると、現在の技術では、移行元ホストと移行先ホストが同じ Layer-2(L2) サブネット上に設置されている事が必要な条件です。 現時点では、ドメインの移行を行うにあたり、ローカルのディスク内に保存されているファイルシステム上のデータを、目的とする遠隔にあるホストへ自動転送させることはできません。管理者は目的地となるホストのノード上でもデータが利用可能である事が保証されるような、適切なストレージ方式をサポートするファイルシステムを選択すべきです（例えば SAN や NAS など）。GNBD は１つのマシン上のボリュームを他のマシンへ転送するのに適切な手法です。iSCSI も似たような動作を行うことができますが、設定が多少複雑です。 ドメインの移行は、MAC アドレスと IP アドレスの移行も伴うものです。つまり、同じ Layer-2 ネットワーク上の IP アドレスのサブネットマスクに配置されている仮想マシン間でのみ移行が可能となるのです。もし移行先のノードが異なったサブネット上にあるばあいは、管理者は遠隔にあるノード上の domain 0 において、手作業で IP アドレスを割り当てるか IP トンネルを設置する必要が出てきます。 ドメインの移行は xm migrate コマンドを用います。現状のドメインを他の仮想マシンに移行するためには、次のようなコマンドを用います： # xm migrate --live mydomain destination.ournetwork.com --live フラグがない場合には、xend は単純にドメインを停止した後に、メモリイメージを新しいノードにコピーしてドメインを再開します。ドメインによっては大きな容量を確保する場合もあるでしょうから、ギガビット・ネットワークを用いても非常に時間がかかる場合があり得ます。xend に対し --live フラグを使う場合、ドメインを稼働させながらデータの移行を行うことができます。ただし、データの移行が進行中は約 60 〜 300 ミリ秒という定期的な停止時間を必要とし、その間にデータを移行します。 作業が終わったあとは、新しい仮想マシン上で正しくデータが稼働しているかどうか確認するために xm console コマンドを用いてドメインのコンソールに接続する必要があるでしょう。もし、移行させられたドメインがネットワーク接続の設定が行われていた場合、それらも移行されますが、SSH 接続のセッションは維持されません。 4.4 ドメインのメモリ管理 †XenLinux? ドメイン上では、管理者や利用者の必要に応じて仮想マシンのメモリを増減させる機能が備わっています。 4.4.1 dom0 上におけるメモリ配置の設定 †マシンの管理者は必要があれば、ドメインに対して xm set-mem コマンドを用いることでメモリ配置の変更を行うことが出来ます。簡単な例として、例によって ttylinux ドメインのメモリを 32 メガバイトに再配置してみましょう。 # xm set-mem ttylinux 32 このコマンドの結果は xm list の出力より確認できます： # xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 251 0 r---- 172.2 ttylinux 5 31 0 -b--- 4.3 9605 ドメインは set-mem の命令に応じるため、Xen にメインメモリを返します。ドメインに対してはコマンドを実行さえしれば元通りのメモリ容量に戻すことも出来ます。コマンドは次の通りです： # xm set-mem ttylinux 64 4.4.2 ドメイン内でのメモリ配置の設定 †仮想ファイル /proc/xen/balloon を用いることで、ドメインの所有者が自分自身でメモリ設定を行うことが出来ます。ファイルを読み込んで表示された結果（例：cat /proc/xen/balloon）が、ドメインの現時点におけるメモリ配置です。ファイルへ書き込むことによって（例：echo 新しい容量 > /proc/xen/balloon）、ドメインに対し、カーネルが新しいメモリ値を割り当てます。 4.4.3 メモリ設定の制限 †Xen は各ドメインに対して利用可能なメモリ容量の上限を設定することができます。標準の設定では、ドメイン作成時に設定されたメモリ容量が上限であり、その容量を超えてメモリを確保するような事はできないよう制限がされてます。ドメインが当初割り当てられたメモリ容量を上回る確保を許可するため、あるいは、一度放棄したメモリ領域を復帰させたい場合には、コマンド xm maxmem を使って設定を行います。 5. ドメインが保存されるファイルシステムについて †dom0 から他のドメインを作成する際には、仮想マシンの / ファイルシステムが直接 Linux のブロック・デバイスを用いなくても構いません。一般的なネットワーク・プロトコル上（例：NBD・iSCSI・NFS 等）に仮想マシンを配置することもできます。この章では、これらの実現性について述べます。 5.1 物理デバイスを VBD として用いる †単純な設定を行うことにより、domain 0 から外部の独立したパーティションへ新規ドメインを作成することがきるでしょう。そのためには phy を用います。phy という特殊な指定をドメインの設定ファイル内で記述します。例えば以下のような行です：
この記述によって、パーティション /dev/hda3 にある domain 0 は、読み書き可能な状態で新しいドメインを /dev/sda1 に作成できます。同じように /dev/hda や /dev/sdb5 など、同様に作成可能です。 ローカルなディスクやパーティションだけでなく、Linux が 'ディスクである' と認識できるデバイスであれば同様な動作が可能です。例えば iSCSI ディスクや GNBD ボリュームに置かれている domain 0 からも、phy を指定することによって新規にドメインを作成させることも可能です。記述は次のようにします：
ブロック・デバイスをドメイン間で純粋に共有するために使うのであれば、各ドメインの Linux カーネルが用いるファイルシステムが混乱を引き起こすとがないように、read-only(読み込み専用)の属性を持たせて共有すべきです（ext3 形式のパーティションを読み書き可能な状態でマウントさせることにより、ファイルが修復不可能な状態に陥る危険性があります！）。xend は domain 0 、もしくは既に作成済みのドメインが読み書き可能な状態で共有されようとしたならば、事前に誤実行されないよう警告を行います。もし読み書き可能な状態で共有を行いたいのであれば、domain 0 から NFS のような他のディレクトリにドメインを作成するようにしてみてください（あるいは、GFS や ocfs2 といったクラスタ・ファイルシステムをご利用下さい）。 5.2 ファイル基盤の VBD を用いる †domain 0 のメイン記憶領域内に、仮想マシンの情報をファイルとして利用することも可能です。この手法は非常に都合が良く、仮想マシンが用いるデバイスとしての容量は純粋に割り当てられるファイル容量によって調整が可能であり、システムのリソースとしてもわずかな為です。ですので、もし仮想マシンがディスク容量の半分を使うのであれば、実際のディスク上でもその割り当てられている半分だけの容量が使用されているにすぎません。 例えば、2GB が割り当てられたファイル基盤の仮想デバイスを作成するとします（実際に使用するのはディスクの 1KB のみです）：
このディスク用のファイルに対してファイルシステムを構築します：
現在メインで使っている領域からファイルをコピーして、ファイル容量を増加させます： # mount -o loop vm1disk /mnt
# cp -ax /{root,dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{proc,sys,home,tmp}
ファイルシステムでは /etc/fstab や /etc/hostname など設定を行います（編集するのは domain 0 ではなく、マウントされている /mnt 配下のファイルシステムだという事を忘れないでください。例えば対象ファイルが /etc/fstab であれば、編集すべきは /mnt/etc/fstab です）。 あとは fstab に /dev/sda1 が / となるように記述してください。 その後、アンマウントします（非常に大事です！）：
設定ファイルには次のような記述を行います：
これで先のファイルが仮想マシンでは'ディスク'として認識されるようになります。たとえディスク容量が増えることがあっても、オリジナルの 2GB を超えることは決してありません。 デバイスに対する I/O が頻繁に行われるドメインでは、ファイル基礎を用いる事が不適切な場合もあるのでご注意下さい。ファイルを基礎とした VSD で非常に負荷となる I/O を行うことは、dom0 によって管理されているループバックデバイスに対する負担となり、システム全体の性能低下を招くことになります。LVM を用いた VBD（セクション 5.3?）や物理デバイスを用いた VBD（セクション 5.1?）を使用する方が優れた I/O 性能を発揮することができます。 標準の設定では Linux 環境上で最大８つのファイルを基礎とした VBD のドメインをサポートできます。この上限は dom0 カーネルのモジュールをコンパイルする時のパラメータ CONFIG_BLK_DEV_LOP にある max_loop の値を増やすか、CONFIG_BLK_DEV_LOOP オプションが dom0 カーネルコンパイル時に指定されていれば起動時の boot オプションで max_loop=n として指定ができます。 5.3 LVM 基礎の VBD を用いる †ドメインを管理するファイルシステムとして理想的なのが LVM ボリュームを用いることです。LVM によって作成されるボリュームは動的に増減が可能であり、スナップショットや、その他の機能が使えるからです。 LVM ボリュームをサポートするパーティションを初期化するには： # pvcreate /dev/sda10 物理パーティション上に 'vg' という名前のボリューム・グループを作成するには： # vgcreate vg /dev/sda10 'myvmdisk1'という 4GB の論理ボリュームを作成するには： # lvcreate -L4096M -n myvmdisk1 vg これで /dev/vg/myvmdisk1 というファイルシステムが作成され、マウントすることができます。容量を増やしてみましょう。例： # mkfs -t ext3 /dev/vg/myvmdisk1 # mount /dev/vg/myvmdisk1 /mnt # cp -ax / /mnt # umount /mnt 仮想マシンのディスクの項目は以下のように設定できます： disk = [ 'phy:vg/myvmdisk1,sda1,w' ] LVM を用いれば論理ボリュームを増やすことが可能ですが、同時に、領域を確保するためには新しくファイルシステム上の空き容量を必要とします。いくつかのファイルシステム（例えば ext3 ファイルシステム）ではオンラインでのサイズ変更が可能です。詳しい事については LVM マニュアルをご覧下さい。 補足しておきますと、LVM ボリュームのクローンを作成する機能を用いることも可能です（この作業の事を LVM の専門用語で、持続的な書き込みが出来るスナップショットと呼びます）。機能は Linux 2.6.8 より実装されましたが、まだあまり安定しているとはいえません。とりわけたくさんの LVM ディスクを用いることは domain 0 上において多くのメモリを消費し、ディスク領域はシステム上の負担となるためエラーを引き起こす場合もあります。とはいえ、将来的に、これら問題は改善されるでしょう。 上記の例で用いたファイルシステムをコピーした２つのクローンを作成するには、次のようなコマンドを入力してください： # lvcreate -s -L1024M -n myclonedisk1 /dev/vg/myvmdisk1 # lvcreate -s -L1024M -n myclonedisk2 /dev/vg/myvmdisk1 それぞれがマスター領域から作成されている 1GB づつの領域です。lvextend コマンドを使えば、必要に応じて領域を追加させることもできます。例： # lvextend +100M /dev/vg/myclonedisk1 LVM によって領域を確保する事とボリュームを増やす事は、全く意味あいが違うのでご注意下さい。dmsetup を待機させることで、ボリュームが溢れかえる事を検出し、lvexend によってボリュームを拡張するという事は自動化出来るかもしれません。 原則として、複製されたボリューム（変更を加えてもクローンとは見えないでしょう）に書き込みを続けることは可能です。ですが、これは推奨しません。複製されるドメインは、どの仮想マシンからも直接参照されることがなく「手が加えられていない」ファイルシステムに書き込まれるべきです。 5.4 NFS 階層を用いる †まずはじめに、NFS を用いることによって、現在のファイルシステム上に他のサーバ・マシンのディレクトリを加えることが可能です。NFS は物理的に異なるマシンや単純な仮想マシンのディレクトリも同一のノード上で扱えることが出来るのです。 たとえば今、ネットワーク越しにあるファイルシステムから接続を行うには、/etc/exports ファイルに設定行を追加します。例えば： /export/vm1root 1.2.3.4/24 (rw,sync,no_root_squash) 最終的にはドメインが NFS のルートを用いるように設定してください。標準的な変数の他に、出来ればドメインの設定には次のような設定をしておけば確実です： root = '/dev/nfs' nfs_server = '2.3.4.5' # NFS サーバの IP アドレス nfs_root = '/path/to/root' # サーバーのファイルシステム上にあるルート指定 ドメインによっては起動時にネットワークの亜kせすが必要になる場合もあるでしょう。その場合は静的な IP アドレスを用いるか（IP アドレス・ネットマスク・ゲートウェイ・ホスト名の設定）、DHCP を有効（dhcp='dhcp'）にしてください。 Linux 上で NFS をルート・ファイルシステムとして用いることは高負荷時に安定面での問題を抱えていることが分かっています（Xen に限った問題ではありません）。重要な役割を持つサーバ上で NFS を用いることは不適切です。どうか注意を払ってください。 ─────────────────────────────────────── 2 ユーザ参照ドキュメント 6. ソフトウェアの制御 †Xen の制御ソフトには xend ノード管理デーモン（必ず動作していなくてはいけません）や、xm コマンドライン・ツール、xensv というプロトタイプのウェブ・インターフェースの事を指します。 6.1 Xend (ノード管理デーモン) †Xen デーモン(Xend) は仮想マシンに関連するシステム管理機能を遂行します。仮想マシン群を管理する中心に位置する役割を持ち、HTTP を基本にしたプロトコルを用いた制御を行います。 Xend は仮想マシンの開始や維持のために、常に動作していなくてはいけません。また、Xend は特権を必要とするシステム管理機能も扱うため root ユーザ権限としても動作する必要があります。xned を簡単なオプションと一緒にコマンドライン上で用います。 # xend start start xend が起動していなければ起動する # xend stop stop xend が起動していれば停止する # xend restart xend が起動していれば再起動し、停止していれば起動する # xend status xend の状態をリターンコードで表示する xend という SysV 系起動スクリプトを用いることで、マシンの起動時に xend を稼働させることができます。ファイルは make install 時に /etc/init.d ディレクトリにコピーされています。自動起動を有効にするには、適切なランレベルのディレクトリにシンボリック・リンクを作成するか、もし利用可能であれば chkconfig ツールを使い設定することも可能です。 xend さえ稼働してしまえば、より洗練された管理ツールである xm (セクション 6.2?)と、実験的な Xensv ウェブ・インターフェース（セクション 6.3?）を用いることができるようになります。 また、xend に稼働中には各種のイベントが /var/log/xend.log に記録されます。移行補助デーモン（xfrd）が起動する時には /var/log/xfrd.log に記録がされます。何か問題が発生するときに、これらのログが役立つでしょう。 6.2 Xm （コマンドライン・インターフェース） †コンソール上から Xen を間記すための重要なツールが xm です。一般的な書式は次の通りです： # xm コマンド [スイッチ] [引数] [変数] 利用可能なスイッチや引数については使用するコマンドに依存します。変数を指定する場合には殆どが 変数=値 といったもので、コマンドライン上での宣言は、設定ファイルで予め標準値と規定されている変数や、あらゆる特別な変数よりも優先されます（例えば、xmdefconfig ファイルでは vmid 変数を使っています）。 使用可能なコマンドは以下の通りです：
スイッチ・引数・変数についての詳細を確認するには、help の引数としてコマンドを指定して下さい。 # xm help command 6.3 Xensv (ウェブ管理インターフェース) †Xensv は Xen 仮想マシン群を管理するための実験的なウェブ管理インターフェースです。これを利用することで xm ツールを使うよりも簡単に管理しやすくなるでしょう（まだ完全に機能するわけではありません）。 開始するには次のようにコマンドを実行します：
停止するには次のようにします：
標準設定では、ウェブ・インターフェース用にポート 8080 を確保します。ポート番号を変更したい場合は /usr/lib/python2.3/site-packages/xen/sv/params.py ファイルを編集してください。 Xensv が稼働中はウェブ・インターフェースを通してドメインの管理や作成に利用する事ができます。 7. ドメインの設定 †以下のセクションではドメイン設定ファイルに関わる構文や、どのようにネットワーク機能を利するか、ドメインの運用状況と一般的なスケジューリング機能について述べます。 7.1 設定ファイル †Xen 設定ファイルでは以下の標準的な変数が指定できます。設定ファイル上で指定される変数についてですが、それぞれの項目・値は " で囲むようにしてください。詳しくはサンプルファイルの /etc/xen/xmexample1 と /etc/xen/xmexample2 に記述されている構文を確認してください。
機能に柔軟性を持たせる為に、設定ファイル上で Python 言語で記述されたスクリプトをコマンドとして使用することが出来ます。記述例は xmexample2 ファイルの vmid 変数で用いられている Phthon コードをご覧下さい。 7.2 ネットワーク設定 †多くのユーザの為に、標準のインストールでは'難しい設定を一切しないで済む'ように設計を行いました。例えば、多数のイーサネット・インターフェースを実装したり、ネットワークのブリッジを設定するといった、複雑なネットワーク設定を行うための専用設定があります。 このセクションでは Xen の仮想ネットワークに柔軟性を与えるため、その役割を担う xend の仕組みについて述べる事を目的としています。 7.2.1 Xen 仮想ネットワーク技術 †dom0 の仮想ネットワーク・インターフェースには各ドメインのネットワーク・インターフェースに次から次へと接続する事ができます（事実上の '仮想クロス・ケーブル'です）。これらのデバイスには vif<domid>.<vifid> と名付けられています（例：domain 1 の１番目のインターフェースは vif1.0、domain 3 の２つめのインターフェースは vif3.1 となります ）。 これらの仮想インターフェースのトラフィックは domain 0 によって処理されます。処理内容は標準の Linux で用いられるブリッジ・ルーティング・トラフィック制限の仕組みと同じものです。xend はネットワーク設定を初期化する為と新しく仮想インターフェースを設定する為に、２つのシェルスクリプトを使って実行します。以下のセクションで任意のルーティングやブリッジ設定を行うスクリプトの調整方法について詳しく述べます。 7.2.2 Xen ネットワーク用スクリプト †Xen の仮想ネットワークの設定は２つのシェルスクリプトによって構成されています（標準のネットワーク設定とブリッジに関する設定です）。これらのスクリプトは、以下で述べる記述方法に従った引数を与えることで xend により自動実行されます。スクリプトを置く標準の場所は /etc/xen/scripts です。スクリプト名と場所は /etc/xen/xend-config.sxp ファイルで指定することができます。
より複雑なネットワーク構成を実現するために（例：eth0 ではなく既存の別ブリッジに対するルーティングを行う必要がある場合など）、これらのスクリプトは自分の運用するサイトに対し性能を発揮できるよう、適切に設定ファイルを変更することができます。 7.3 ドライバによるドメイン設定 †ドメインが直接 PCI デバイスにアクセスさせたい場合、 I/O 特権を与えることも出来ます。これはドメインがドライバを扱えるようにする為に使います。 バックエンド側での特権を設定できるのは、現時点では SXP 形式の設定ファイルだけをサポートしています。ドメインがその他の仮想エレメントに対してバックエンドとして機能するには、その設定ファイルは (backend (type)) として指定され、形式は netif か blkif のいずれかでなくてはならず、その種類に応じて仮想デバイスが動作します。 現時点では他のドメインから仮想ブロック・デバイスをブロック・バックエンドとして取り込むことは出来ないのでご注意下さい。それと、ネットワーク・バックエンドも他のドメインから仮想ネットワークデバイスとして読む込むことはできません。ですので、RAM ディスクやネットワーク・デバイスをバックエンドのドメインを呼び出す必要があるかもしれません（特に仮想ブロック・デバイスをルート・ファイルシステムとして読み込むことが出来ないようなブロック・バックエンドの場合）。 PCI デバイスへのアクセスですが、デバイス毎に設定ファイルが必要になるかもしれません。Xen はデバイスを管理するために必要とされる最小限の特権をドメインに対して割り当てます。これは以下のいずれかの設定ファイル形式で指定できます：
7.4 スケジューラ設定 †Xen は起動時に複数のスケジューラを選ぶことが出来ます。スケジューラを選ぶには Xen 起動時の変数で sched=ched_name として適切なスケジューラ名を指定してください。スケジューラやそれらの変数については以下で述べます：将来のバージョンで提供されるツールは、現行のものより高いレベルのインターフェースを備えているでしょう。 システムの管理者は自分のシステムに最も適切だと思うスケジュールを選択すると思われます。現時点では BVT スケジューラを選択することを推奨します。 7.4.1 仮想時間の借用 †sched=bvt（標準設定） BVT はCPU 時間を公平に釣り合って共有するようになっています。時々ブロックするドメイン（例えば I/O が頻繁なドメイン）に対してペナルティーを課すことができますので、公平に CPU リソースを利用できるように配慮されています。 * 7.4.1.1 グローバル・パラメータ †
* 7.4.1.2 ドメイン毎のパラメータ †
7.4.2 アトロポス(atrpos) †sched=atropos アトロポスはソフトなリアルタイム・スケジューラです。共有可能な CPU 時間の絶対量を元に、それぞれドメイン間で CPU 時間を共有する際に最も効率が良い手法を用います。そのため、あまり使われていないドメインに対しては CPU 時間の割り当てを減らします。 全てのドメインに対して期限(period)と期間(slice)が割り当てられます。ドメインは割り当てられた期間(slice)に指定された期限＝ナノ秒で指定(period)までリソースを利用可能です。これは管理者がドメインに対して割り当てる CPU 時間の絶対量と、共有される状況に応じて適切に割り当てます。 メモ：アトロポスを用いる場合は CPU に対して過度の負担を与えないようにしてください（つまり、必要以上に多くの CPU 時間を確保しないように注意してください。使用するときはマシン自身の動作を保証するために 100% よりやや少なめで設定されるべきです）。 * 7.4.2.1 ドメイン毎のパラメータ †
7.4.3 ラウンド・ロビン(Round Robin) †sched=rrobin ラウンド・ロビン・スケジューラは Xen 内部のスケジューラ API であり、実証用のシンプルなものです。現時点では実環境での運用を想定していません。 * 7.3.1 グローバル・パラメータ †
8. 構築(Build)・起動(Boot)とデバッグ(Debug)オプション †この章では Xen システムの構築時(Build)・起動時(Boot)に用いることが出来るオプションについて記述します。 8.1 Xen 構築オプション †Xen の構築時のオプションは環境変数やコマンドラインでの make 時に指定することが出来ます。
以下翻訳作業中（含む Developer's guide） 時間があれば Fedora Core 4 で「実際にどうよ？」というのも取り扱う予定です。 |
