 |
 |
|
 |
|
|
|---|---|---|
| このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 | ||
|
|
|
|
|
|
|---|---|---|
| このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 | ||
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 専用で CPU はひとつだけでメモリ割り当ても控えめだが多くのディスク容量を与えておく、というようにリソースを最適にコントロールして、サーバマシンの持つ CPU 能力とディスク I/O を余すところなく活用することができる。さらには、サービスの提供を続けたままゲストOS を物理的に別の Xenホストマシンへ移動すること (Live Migration) も可能 (じつはこれが Xen 開発の本来の目的らしい)。ハードウェアのアップグレードやハードウェア障害 (部分的か比較的軽症の障害に限られるが) への備えとしても心強いし、コールドバックアップならホストOS上の標準的なツールで簡単にゲストOS のバックアップがとれるというメリットもある。
※ VMware といえば、一昔前まではまさに Windows の上にインストールして仮想ハードウェアを提供するカタチのものだけだったが、今は 2種類あり、そのひとつ VMware ESX はほとんど Xen と同じ構造 (ハイパーバイザ方式) で動作し、仮想化OS のオーバーヘッドはかなり小さい。旧来の方式のものは VMware Server としてフリーで配布されている。
当ページは、Red Hat Enterprise Linux/CentOS 5.1 から 5.4, Fedora Core 7, Fedora Core 8, RedHat Enterprise Linux 4.5(ゲスト専用) を組み合わせて準仮想化 (paravirtualization = パラバーチャライゼーション) で動かした実験に基づく。
Xen ではホストOS を dom0 (Domain-0) と呼ぶので、ここからは主にそちらの呼び方を使うことにする。また、ゲストOS は ゲストドメイン あるいは domain-U, domU とも呼ぶ。
Xen の仕組みを理解する上でうってつけの記事として Xen特集 - VA Linux Systems Japan がある。IT系ポータルの記事はだいたい寸止め以下のスカスカなものばかりだが、これは珍しく役に立つ。
まず、dom0 となるホストOS をインストールする。RHEL/CentOS 5.1, 5.3, 5.4 と、 Fedora Core の 7 及び 8 を試した。この時の Xen のバージョンは、RHEL/CentOS 5.1～5.4 のものが 3.0.3、Fedora Core 7 と 8 では 3.1.2 だった。
幾つかコツや認識しておかなければならないことがある。
OS のインストーラが完了したら、土台がきちんと整うまでは Xenカーネルでブートしたくない。ところが、RHEL/CentOS 5.x では、仮想化 パッケージグループを選択すると、不親切なことにノーマルカーネルはインストールしてくれない (Fedora Core 8 でも同様。FC7 では...忘れた)。メンテナンス用にどうしても入れておきたいのだ (※)。そこで以下のような追加手順を踏む。こんな面倒くさいことをせずに、Xenカーネルデーブートした dom0 上から yum で install してもいい。
sh-# mount /dev/scd0 /mnt/source sh-# cd /mnt/source/CentOS sh-# cp kernel{,-devel,-doc}-2.6.*.rpm /mnt/sysimage/root sh-# umount /mnt/source
sh-# chroot /mnt/sysimage sh-# rpm -ivh --nosignature /root/*.rpm sh-# exit <--chrootから脱出 sh-# exit <--リブート
※ 非Xenカーネルなしでも運用は可能だが、dom0 のネットワークパラメータを変更する際にいちいち仮想ブリッジを実体状態に戻さなければならず煩わしい。また、dom0 に割り当てるメモリは絞り込むのが通例なので、dom0 自体の環境整備やパッケージアップデートなどにも時間がかかる。
非Xenカーネルでブートし、ホストOS の基本的な設定を済ませておく。
まずはともかく、実在のネットワークインターフェイスに呼応するデバイス (eth0 など) ができているかを確認する (ifconfig コマンドなど)。最新のマザーボードに搭載されているギガビットNIC は、OSディストリビューションがまだドライバを持っていないこともあるからだ。NIC を認識しないことにはこの先に進めないので、ここで整備を済ませておかなくてはならない。必要ならばドライバをインストールし、(現実の) IPアドレス、ゲートウェイ、ホスト名をしっかり設定しておく。これらの情報は Xen dom0 のものにもなる。ただし、ドライバつまりカーネルモジュールファイルは、/lib/modules/ 下のカーネルバージョン毎のディレクトリにインストールされるものなので、後ほど Xen版カーネル上でもインストールする必要がある。
また、ネットワークインターフェイスを bonding (冗長化) するなら、それもこの時点で済ませておく。
IPv6 は Xen ではまだ不安定らしいので、特段使う予定がないのであれば無効化することをお勧めしたい。無効化の方法は「よろず環境設定」を参照されたし。
非Xen版カーネルもインストールした場合には、安全のため、この段階ではまだ暫くはノーマルカーネルでブートし続けてほしいので、/boot/grub/grub.conf に変更を加える。非Xenカーネルでブートすればメモリを独り占めできるため様々な基礎構築作業がスピードアップできるという点も見逃せない。
default=0 <--xenカーネルでないほうのエントリ番号をデフォルトにする timeout=15 <--延ばしておくとよい splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu <--コメントアウトして必ずカーネルリストが出るようにする title CentOS (2.6.18-53.el5) root (hd0,0) kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.el5.img title CentOS (2.6.18-53.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-53.el5 dom0_mem=350M <--dom0への割り当てメモリ module /vmlinuz-2.6.18-53.el5xen ro root=LABEL=/ rhgb quiet module /initrd-2.6.18-53.el5xen.img
dom0 への割り当てメモリは、あまり欲張るとゲストドメインへ割り当てるメモリが逼迫してしまう。ゲストドメインのメモリは dom0 から分け与えられるのではない。dom0 とすべてのゲストドメインへの割り当てメモリが搭載物理メモリ量とちょうどイコールになるのが理想だ。
なお、次の段階でカーネルをアップデートすると、yum 及び rpm がまた Xenカーネルのほうをデフォルトにしてしまう。それを防ぐには /etc/sysconfig/kernel ファイルのパラメータを変更しておく；
UPDATEDEFAULT=kernel <--`-xen' を取る
ここで行った非Xenカーネル優先の起動設定は、この後の適当な段階で戻すといいだろう。
/etc/inittab を編集してデフォルトinitレベルを 3 にしておく。そうすれば、実運用に入る時に dom0 へのメモリ割り当てをもっと減らすこともできる。ただし、dom0 に対しても VNC でリモート操作したいなら initレベル 5 のままにする。
また、スタートアップで起動されるデーモンも極力減らしておく。ただし、この段階で完全に絞り込めなくても、あとでじっくり煮詰めていけばいい。
Xen は日進月歩の勢いで変わって行っているので、おかしなバグに捕まらないよう、この段階で少なくとも主要なコンポーネントだけはアップデートしておくことをお勧めする (yum などを使って)。Xen に何らかのカタチで関わるクリティカルなものとしては、だいたい以下のようなところか。CentOS 5.1 で kernel-xen をアップデートした時、前項「基本設定」で Xenカーネルのカーネルパラメータに足した dom0_mem の記述が新Xenカーネルのエントリに引き継がれなかったことがあるので注意しなければならない。残りの有象無象は後でじっくりアップデートすればいい。
| kernel | kernel-devel |
| kernel-xen | kernel-xen-devel |
| kernel-headers | dbus* |
| device-mapper-multipath | glibc* |
| hal | hal-gnome |
| kpartx | nscd |
| libvirt | dnsmasq |
| tzdata | util-linux |
| udev | autofs |
| xen* | virt-manager |
| python-virtinst |
※ Fedora Core 8 では、この他に、libvirt パッケージから分離された kvm, qemu パッケージも重要。
ここでは、主に、Linux を準仮想化でインストールすることについて述べる。Windows などを完全仮想化でインストールする場合の注意点は、メモとして添える程度にとどめる。
基本的には RedHat系 Linux に付属している GUI ツール virt-manager (仮想マシンマネージャ, Virtual Machine Manager) またはコマンドラインツール virt-install を利用してセットアップを行う。ただし、きめ細かな調整はできないので、その分は作成後に設定ファイル類を直接編集して調整を行う。
これらのインストールツールの面白いところは、パーティションなりイメージファイルなりを仮想的にひとつのディスクとしてゲストOS のインストーラに差し出し、一種の VNCウィンドウの上で、通常の OS のインストールとまるで変わらない要領でインストールが行えることだ。そのおかげで、ツールを使わずにゲストOS をインストールする際に必要となるゲストOS の Grub 設定ファイルの調整や initrd イメージの作り直しといった面倒な作業が要らない。ここでは、パフォーマンスに優れるという理由から、基本的に、各々のゲストOS にホストOS のハードディスク上に切った物理パーティション丸ごとひとつを使わせる方法を採る。また、インストール完了後に、そのゲストOS の使うスワップパーティションも加えてやることにする。
※ virt-manager や virt-install はゲストのインストールの時に面白いトリックを使っている。まず最初に、インストールメディアの /images/xen/ にあるカーネルイメージファイルと initrdイメージを dom0 の /var/lib/xen/ に一意な名前を付けてコピーする。そして、暫定のゲストドメイン定義を作成する。その定義は基本的には virt-manager や virt-install の設定画面やオプション引数で入力していったパラメータに基づいているのだが、ただ、起動定義部分 (<os>エレメント) には、カーネルと initrdイメージに先ほど /var/lib/xen/ へコピーしたものが指定され、カーネルへのコマンドラインパラメータ (<cmdline>エレメント) として、我々が普段インストールCD の boot: プロンプトに打ち込むパラメータ (例えば `method=nfs:192.168.122.1:/media/CentOS_5.1_Final') が指定されている。ゲストOS のインストールが完了すると、暫定だったゲスト定義が <os> 部および <bootloader> 部を本来の状態へと書き換えられた上で libvirt あるいは xm 経由で Xen環境に正式登録される。インストール最中のドメインに対して `virsh dumpxml' コマンドを発行してみた結果分かったことだ。参考にそのファイル (Fedora Core 8 ホストOS上で CentOS 5.1 をゲストインストールしていた時のもの) を置いておく。
なお、Windows Server 2003 を完全仮想化でインストールしている最中の定義は こうなっていた。
ここからの作業は Xen版カーネルでブートした dom0 上で行う。
Xen版カーネルでブートしたら、まず dom0 が正常に機能しているか確かめておく。OSディストリビューションがドライバを標準で持っておらずノーマルカーネルに手動で加えたドライバモジュールは、Xen版カーネル環境でも再度インストールしなければならないことを忘れずに。
筆者の環境では CentOS 5.1 をホストOS にした dom0 で度々この障害に遭遇した。ブート中の xend をロードしたあたりから、
"received packet with own address as source address"
という emerg なエラーメッセージがターミナルを埋め尽くすのだ。dom0 とゲストドメインとの通信も成り立たない。あれこれ調査した結果、これが起こる時には必ず、 eth0 の MACアドレスが FE:FF:FF:FF:FF:FF というものになっていることが分かった。これは xenbr0 や vifX など (後述) の持つ MACアドレスと同じだ。かたや、正常な時の eth0 の MAC は 00:1E:... といった NIC 本来のものになっていた。また、不思議なことに、Xenカーネルで問題の起こっていた時には、すぐに非Xenカーネルのほうでブートしなおしても、半永久的に FE:FF:FF:FF:FF:FF になっていて元に戻らない。どうやら、上記メッセージの "address" とはハードウェアアドレスのことのようだ。
Xen の不具合なのかマザーの BIOS が悪いのかオンボードの NICチップがボロなのかドライバがヘボなのか分からないが、筆者のところで功を奏した処置法を書いておくことにする。やや強引な方法ではあるが；
RHEL/CentOS 5.x, Fedora Core 7/8 のデフォルトの Xen 環境では、virbr0 という仮想ブリッジが dom0 とゲストOS とを結ぶメインの仮想ネットワークになっている。細かいことは「Xenネットワーク」の章に譲るが、virbr0 はブリッジというよりルータだ。 IPアドレスを持ち、DNSキャッシュ/DHCP サーバ機能と、dom0 の iptables を介した外部ネットワークへの NAT(マスカレード)機能を備えている。この既定の virbr0 は、実は Xenデーモン xend でなく libvirtd という別のサービスによって作られるもの。 /etc/libvirt/qemu/networks/default.xml で "デフォルト" (default) という定義名のブリッジとして定義されている。
慣れてきたら、先に仮想ネットワークを構築しておいてからゲストOS をインストールするほうが、後でゲスト定義ファイルを調整するなどの手間が省けるので仕事がきれい。ホストOS のネットワークインターフェイスを bonding (ボンディング) で冗長化したい場合はなおさらだ。デフォルトの virbr0 を利用してゲストをインストールする場合には、`ifconfig virbr0' してその IPアドレスを調べておこう。CentOS 5.1 と Fedora Core 7/8 ではいずれも 192.168.122.1/24 となっている。
ホストOS上で、ハードディスク上にゲスト用のパーティションを fdisk で追加する。この作業は、Xenカーネルで立ち上がっていてもノーマルカーネルで立ち上がっていても構わない。パーティション例を下に示す。 sda1 から sda3 までは、ホストOS構築の際に既にできているはずのもので、これと同じである必要はまったくない。その後からが肝心で、例えば第1ゲストOS にとっては、 /dev/sda5 が 1個のハードディスク、 /dev/sda6 がもう 1個のハードディスクに見えることになる。ひとつの仮想ハードディスク内には複数のパーティションを切らない (後述のゲストインストールの際) ほうが、インストールもうまくいき動作も安定するようだ。RHEL4.5 をゲストとしてインストールしようとした時に一度、複数に切ってみたが、フォーマット行程の次あたりで処理が止まって次へ進まなかった。乗せるアプリケーションや提供するサービスによっては、例よりもずっと大きなサイズが必要となるだろう。なお、ゲストにスワップ領域として提供するパーティションは、ナマで使うのでなく仮想的に 1台のディスクに見せかけて差し出すことになるので、パーティションタイプはデフォルトの 83 (Linux) のままでよい。Windows ゲストを完全仮想化でインストールする場合も同様だ。なお、IDE や SATA のディスクの場合、パーティションテーブルの反映にはマシンの再起動が必要なことが多い。
| デバイス | 説明 | FSタイプ |
| /dev/sda1 | dom0 の /boot | |
| /dev/sda2 | dom0 の / | |
| /dev/sda3 | dom0 の SWAP | |
| /dev/sda4 | 拡張領域全体 | |
| /dev/sda5 | domU#1 の / (20480MB) | Linux (83) |
| /dev/sda6 | domU#1 の SWAP (2047MB) | Linux (83) |
| /dev/sda7 | domU#2 の / (20480MB) | Linux (83) |
| /dev/sda8 | domU#2 の SWAP (2047MB) | Linux (83) |
準仮想化ゲストOS のインストールで、 RedHat系OS のインストーラにインストールメディアを提供する方法として最も簡単確実なのは、dom0 から NFSサーバで提供してやることだ。最近の CentOS や Fedora Core ではメディアが 1枚の DVD で提供されているので、下のような設定を /etc/exports ファイルに書いてやればいい。`/media/' の後ろは実際にメディアをマウントした時に udev のホットプラグによって作られる動的マウントポイント名なので、実際にメディアをマウントしてみないと分からない。別のゲストOSディストリビューションをインストールする時にはいちいちエクスポート定義を書き換えなければならないのが玉に瑕だ (※)。蛇足だが `*' と `(' の間にスペースを入れてはいけない。(NFS に関する詳しい解説はこちらで書いた)
/media/CentOS_5.1_Final *(ro,nohide,insecure,no_subtree_check)
※ いやいや、あとで気付いたが、CentOS/RHEL の 5 以降ではオートマウントの仕様が変わって、ファイルブラウザのツリーペインで CD/DVD のラベル名を敢えてクリックしない限り /media/ 下にマウントされなくなった。よって、それをやらずに手動で `mount /dev/scd0 /mnt/cdrom` して、その /mnt/cdrom を NFSで開放するのが一番簡単確実。autofs サービスを止めておけば (`chkconfig autofs off; service autofs stop') 勝手なマウントがされなくなり、さらに安全だ。
ついでに言っておきたいことがある - Red Hat Enterprise Linux 5 になってから (いや、もうちょっと前からか?)、馬鹿げたことに、RHEL のインストールCD/DVD はラベル名にスペースが含まれるようになった。おかげで、エクスポートする時に悩まなければならない。その解決策のひとつとして「別名マウント」の活用がある。既にマウントされているマウントポイントやその配下の一部を、別のパスでもアクセスできるようにマウントする機能だ。例えば、オートマウントによって "/media/RHEL_5.2 i386 DVD" にマウントされたとすると、/var/export/cdrom/ ディレクトリを mkdir しておいてから；
root# mount --bind /media/RHEL_5.2\ i386\ DVD /var/export/cdrom
とやってやると、/var/export/cdrom でもインストールCD にアクセスすることができるようになるので、exports ファイルにもそちらを書いておけばいい。RedHat よ、格好つけてないで何が大切なのかを考えていただきたい!!! Linux好きはそういう非論理的なことは嫌いなのだよ。
RedHat Enterprise Linux 4.x のように、DVD でなく複数の CD-ROM でしかメディアが提供されないディストリビューションの場合は、全CD の中身をひとつのディレクトリにまとめた上でそこを NFS共有するといい。手順的には rsync で追加コピーしていくのが簡単で確実だ。コピー先を /var/export/rhel4.5es/ に決めたとすると；
root# rsync -a /media/<Label>/ /var/export/rhel4.5es
<Label> の後の `/' を忘れないように。そして、CD を入れ替えてはコマンドを繰り返す。この方法を採った時に /etc/exports に加えるべき定義は；
/var/export *(ro,insecure,no_subtree_check)
となる。
exports の準備が整ったら、NFSサービスで開放；
root# service nfs start root# exportfs -v <--確認
なお、完全仮想化では、物理CD/DVDドライブをインストールソースにすることもできる。
GUI ウィザードの virt-manager を使う方法と、コマンドラインの virt-install がある。とっつきやすいのは前者 GUI ツールだが、自由度が高いのは virt-install のほうだ。ここでは説明の都合上 virt-manager を先に挙げるが、筆者のお勧めは断然 virt-install。例えば、virt-manager では今のところ、ゲストのインストール時点で複数の仮想ディスクや仮想NICを提供することはできないが、virt-install ならできるので 後からスワップ用ディスクを足したり NICを足したり する手間が要らない。
Gnomeデスクトップの アプリケーション メニューから virt-manager (仮想マシンマネージャ, Virtual Machine Manager) を起動する 。要点のみ解説しておく。
 |
なんらかの分かりやすい名称を付ける。左図のように指定した場合、このゲストドメインの定義は /etc/xen/centos51u というファイルに保存される。ただし、Fedora Core 7/8 に搭載の Xen-3.1 ではそこにファイルは作られない (詳しくは後述)。 |
 |
ゲストOS が Xen のことを知っている Linux なら、迷わず 準仮想化 を選択。完全仮想化 は、CPU とチップセットが x86仮想化に対応していない場合にはグレーアウトしていて選べない。 |
 |
dom0 の NFSサーバで開放しておいたパスに基づいて nfs:192.168.122.1:/PATH/TO/MEDIA のように書く。IPアドレス部には、仮想ブリッジ virbr0 の持つアドレスを指定する。eth0 のアドレスを打ち込んでもうまくいくのだがネットワーク経済的に無駄。 なお、完全仮想化 の場合には、インストールソースとして物理ドライブや ISOイメージファイルを選ぶこともできる。インストールの最中には、CDドライブはゲストOS のインストーラに QEMU 仮想ドライブとして提供される。 |
 |
通常のディスクパーティション を選び、先に作っておいたディスクパーティションを指定する。残念ながら、今の virt-manager でゲストに渡せるのはひとつのパーティションかイメージだけだ。複数渡すためには、インストール後にゲストの定義ファイルを細工して、ゲスト上で追加を行う (スワップ追加の例を参照)。 ちなみに、シンプルファイル はイメージファイルにインストールする方式で、その場合はファイルをあらかじめ作っておく必要はない。その際、オプション 今、仮想ディスク全体を割り当てますか？ には必ずチェックを入れる。チェックなしにすると、イメージファイルはいわゆる sparse file として作られる。スパースファイルとは、初期にはディスクに占める実サイズがほとんどゼロで、データ量に応じて外見のファイルサイズ上限まで膨らんでゆく穴あきファイル。一見便利そうだが、Xen のオフィシャルドキュメントでは、データ信頼性の面から非推奨とされている。 |
 |
仮想ネットワーク "default" を選択すると、そのゲストドメインは前にも述べた仮想ルータ virbr0 に接続される。共有物理デバイス は xend の作る xenbrX のことで、デフォルトでは単純なハブ。まだ仮想ネットワークを何もいじっていない状態なら、ここでは 仮想ネットワーク を選択しておき、必要に応じて後で構成を煮詰める。 ここに絵はないが、次の「メモリとCPUの割り当て」画面では、すべてのゲストドメインの「最大メモリ」の量と dom0 への割り当てメモリとの合計が搭載物理メモリとほぼ同量かそれ以下になるよう計画する。CPU数のほうは、物理CPUの数 (ハイパースレッドやデュアル/クアドコアの分も数える) と同じかそれ以下にするのが通例だが、メモリのような積み上げ算ではない。例えば全 4個の CPU を持つマシンで、ドメイン1 に 4個、ドメイン2 にも 4個提供することもできる。これらのリソースは各々のゲストドメイン上で動かすサービスの性質に応じて計画すべきだが、インストールした後からでも容易に変更できるので心配は要らない。 |
うまくインストールソースが提供できていれば、ここまで終わると virt-manager組込みの VNC画面が開き、ゲストの OS のインストーラが起動する。(※ Fedora Core 7 では問題発生。Windows完全仮想化ゲストでは別の問題が発生したが virt-install の項で述べる)。あとは；
※ Fedora Core 7 で発生した問題
Fedora Core 7 をホストOS にしてやってみた時には、自動的に開くはずの VNC コンソールは、画面に "connection refused or ..." が瞬くばかり。接続をリトライしている模様でいっこうにつながらない。その画面を閉じ、(ゲストプロセスはシャットダウンせずに) dom0 の VNC Viewer (VNCクライアント) で 127.0.0.1 へ接続するとインストーラ画面が現れた。インストール完了後も、 virt-manager から起動はできるものの、やはり virt-manager の VNC コンソールは使えず、 VNC Viewer で 127.0.0.1 へ接続しなければならなかった。FC7 を dom0 にするのはお勧めする気になれない。
なお、dom0 に手動でインストールしたハードウェアドライバがあっても、ゲストOS にはインストールする必要はない。ゲストは、Xen によって抽象化されたハードウェアを認識しているわけで、固有のドライバとの遣り取りは Xenハイパーバイザと dom0 が受け持つからだ。
お勧めと言っておきながら心苦しいのだが、こちらはコマンド例を示すだけに留めさせていただく。オプションの意味は前記の virt-manager と対比させればだいたい想像はつくだろう。詳しくは virt-install の man ページを参照していただきたい。なお、インストール先をイメージファイルにする場合には、スパースファイルにならないよう --nonsparse オプションを指定しているが、イメージファイルの確保には時間がかかるので、失敗や再インストールで同じイメージファイル再利用する時には --nonsparse は外しても構わない (CentOS 5.2 ホスト上で試したところ、virt-manager でゲストOS を 削除 してもイメージファイル自体は削除されなかった)。
virt-inst-lnx-partit.txt： このように、複数の仮想ブリッジに接続させることもできる。
root# virt-install \
--paravirt \
--name=centos51u \
--ram=800 \
--vcpus=2 \
--file=/dev/sda5 \
--network=network:default \
--network=bridge:xenbr0 \
--vnc \
--keymap=ja \
--location=nfs:192.168.122.1:/var/export/cdrom
virt-inst-lnx-img.txt： このように、virt-manager では不可能な、インストール時における複数仮想ディスクの提供も行うことができる。
root# virt-install \
--paravirt \
--name=centos51u \
--ram=800 \
--vcpus=2 \
--file=/var/lib/xen/images/centos51u.img \
--file-size=20 \
--file=/var/lib/xen/images/centos51u-swap.img \
--file-size=2 \
--nonsparse \
--network=network:default \
--network=bridge:xenbr0 \
--vnc \
--keymap=ja \
--location=nfs:192.168.122.1:/var/export/cdrom
上例のようにコマンドすれば、(すべてのパラメータがその環境で妥当であれば) 何も訊かれずにいきなり anaconda インストーラが立ち上がるが、そもそも virt-install は CLI とはいえ対話式のルーツなので、まったくの引数なしでもコール可能で、必須の引数が欠けていれば訊いてきてくれる。
キックスタートインストールを使いたい場合は、キックスタートファイルを dom0 のNFSサーバで公開するのが簡単で確実だ。dom0 の /var/local/ks/ にキックスタートファイル centos51u.cfg を置いたとすると、virt-install のオプションに下記の 1行を加えればいい。オプションの値はつまり、通常のインストール時に boot: プロンプトで渡す文字列だ；
--extra-args='ks=nfs:192.168.122.1:/var/local/ks/centos51u.cfg'
virt-inst-win.txt： CentOS 5.2 ホスト上でやった時の例だ。
root# virt-install \
--hvm \
--name=win2k3u \
--ram=2048 \
--vcpus=2 \
--file=/var/lib/xen/images/win2k3u.img \
--file-size=100 \
--nonsparse \
--network=network:default \
--network=bridge:xenbr0 \
--cdrom=/var/tmp/JapaneseWinServer2003R2StandardwithSP2DISC1.iso \
--os-type=windows \
--os-variant=win2k3 \
--vnc \
--keymap=ja
OSタイプは、ゲスト定義ファイルのデフォルトパラメータの決定 (インストール時の一時定義も含む) に使用される。これはゲストに見せる仮想プラットフォームの仮想ハードウェア構成やパワーマネージメント (ACPI, APIC) の決定に関わる。特に Windows の場合、Windows インストーラのインストールする HAL が変わってしまうので重要だ (※)。OS種別は、ゲストOSのインストーラの挙動 (例えば、インストール完了までに 1回リブートが入る等) の掌握に使われている様子。例えば Windows Server 2003 (非R2) では途中 2回リブートがかかるわけだが、その間は、正規のゲスト定義ファイル (/etc/xen/HOST ファイル) は使われず、XenStore に保持されている動的な設定が再利用されているように見える。
また、インストールソースにCDイメージファイルを使用指定場合で、Windows Server 2003 R2 のように 2枚目のCDが必要となるOSである時には、2回目のブート後にゲストドメイン定義ファイル (/etc/xen/HOST ) の CD-ROM定義部を目的のイメージファイル名に書き換えてからゲストを立ち上げ直してやる必要がある。
※ Windows の HAL 選択について
Windows Server 2003 のインストーラは、インストーラ初期画面 (最初の CLI 段階の青い画面) が出た時に間髪を入れずに F5 キーを叩くと HAL の手動選択ができる。RedHat 5.2 Virtualization Guide (PDF版) の Part II -> Chapter 6 -> 3. Installing a Windows 2003 SP1 Server Guest as a fully-virtualized guest には、そこで 「"Standard PC" を選択せよ」 と記述されているが、そうしてインストールした Windows は 90年代のPCのように電源ボタンを押さないと電源が切れないようなシロモノになってしまい、複数の仮想 CPU を与えたつもりでも 1つしか認識されないなど大いに問題がある。"ACPI MultiProcessor PC" か "ACPI UniProcessor PC" を選択するか、F5 を叩かずに Windows インストーラに自動認識させるのがいいようだ。
xm (xend) のフレームワークに基づいた形式のものと、libvirt に基づく XML形式の 2種類がある。RHEL/CentOS 5.x では前者、Fedora Core 8 では後者、Fedora Core 7 はどっちつかずの状態だがどちらかといえば libvirt 形式が中心。両者は形式がまったく異なるので、別々に説明しなければならない。
RHEL/CentOS 5.x では、作成したゲストドメインの定義ファイルは /etc/xen/ に作られ、ファイル名がゲストドメイン作成時に定義した定義名になっている。以下に述べることのあらかたは `man 5 xmdomain.cfg' で見られる。また、下記の参考文献も参考になる。ただし、xmdomain.cfg の man も含めていずれの文書も、更新が Xen自体の進化に追いついていないようなので (それとも man が先走っているのか)、小生の説明では CentOS 5.1 (Xen-3.0.3) で観察した実情を加味している。
ただし、RHEL 5.3 及び 5.4 で検証したところ、後に説明する libvirt 形式のやり方で定義を更新してもドメイン定義は正しく更新され、その際、/etc/xen/ 下の xm形式の定義ファイルも一緒に書き換わることが確認できた。よって、筆者としては、RHEL 5.3, 5.4 では libvirt 形式による調整をお勧めする。
参考文献：
ゲストドメイン定義パラメータ
| パラメータ | 説明 |
| name | そのドメインの定義名。他のゲストドメインと重複してはならない。 |
| bootloader | pygrub のパス (絶対パス) を指定しておくと、dom0 上にある pygrub (Pythonで書かれたブートローダー) が Grub の代わりをする。pygrub は、そのゲストドドメインに与えられている仮想ディスクの /boot ファイルシステムからカーネルと initrd イメージを読み出して、一旦 dom0 の /var/lib/xen/ にランダムな拡張子を付けてコピーし、そこからブートさせているようだ。この仕組みを使う場合には、下記の kernel, ramdisk, root, extra の指定は無用。つまり、ゲストドメインのカーネルパラメータなどは、実際のゲストドメインの /boot/grub/grub.conf でカスタマイズすればよい。 |
| builder | ゲストドメインを生成するためのビルダー。デフォルトは "linux"。 |
| kernel | カーネルイメージ。 |
| ramdisk | initrdイメージ。 |
| root | ルートデバイス。 |
| extra | カーネルパラメータ。 |
| memory | ゲストドメインに初期値として与えるメモリ量 (MB)。 |
| maxmem | ゲストドメインの使用できる最大メモリ量 (MB)。 |
| vcpus | ゲストドメインに与える 仮想CPU の数。 |
| cpu | ゲストドメインの仮想CPU に割り付ける実CPU の指定。ひとつだけ指定する場合に使う。dom0 の最初の CPU は "0", 2番目のものなら "1" という具合。複数指定するには代わりに下記の cpus を使う。暗黙のデフォルトである "-1" は「どれでも」の意。 |
| cpus | ゲストドメインの仮想CPU 割り付ける実CPU の指定。複数指定する場合に使用する。"0,1,2" のような単純なカンマ区切りの他に、範囲の `-' と否定の `^' が使用できる。例えば "0-3,5,^1" と指定すると CPU#0, #2, #3, #5 がそのゲストの仮想CPU として提供されることになる。 |
| nics | 使用させる物理NIC の数。暗黙のデフォルトは 1。 |
| disk | 提供するディスクの定義。[ "<ディスク定義セット1>", "<ディスク定義セット2>"... ] という書式で、ひとつのディスク定義セットは ""<提供方式>:<dom0から見たdevパス>,<ゲストから見えるdev名>,{r|w}"" というカタチ。提供方式は、実パーティション丸ごとなら "phy:"、ディスクイメージの場合は "tap:aio:"(古いXenで "file:" だったもの)。 |
| nfs_server | ルートデバイスを NFS で提供する場合に、NFSサーバの IPアドレスを指定。 |
| nfs_root | 上記のルートデバイス (絶対パス)。 |
| vif | ゲストドメインに与える仮想ネットワークインターフェイスの指定。[ "<VIF定義セット1>", "<VIF定義セット2>"... ] という書式で、ひとつのVIF定義セットは ""mac=<付けるMAC>,bridge=<接続先仮想ブリッジ>"" という形式。詳しくは「Xenネットワーク」の章、特に「ゲストドメインへの仮想ネットワークインターフェイス追加と接続先の指定」が参考になるだろう。 |
| vfb | [準仮想化のみ] 仮想フレームバッファ (Xen内蔵VNCサーバ) に関する設定。中身で使用するパラメータは下表参照。完全仮想化では、幾つかのパラメータを vfb ブロックの中でなく独立したディレクティブとして書く (完全仮想化の定義記述例 参照)。 |
| pae | (完全仮想化専用？) ゲストに与える仮想プラットフォームの PAE (Physical Addressing Extentions) 機能を有効にする。32ビットのゲストOSに 4GB超のメモリを認識させるには 1 (有効) にする必要がある。 |
| acpi apic |
(完全仮想化専用？) ゲストに与える仮想プラットフォームのパワーマネージメント機能、ACPI, APIC の有無を決める。 |
| localtime | ゲストOSのハードウェアクロック (RTC) は即ちホストOSのカーネルクロックなのだが、localtime=0 (デフォルト) では、ホストOSのクロックがとくに補正なしでゲストに提供されるのに対し、localtime=1 にすると、ゲストOSから見たハードウェアクロックはホストOSのタイムゾーンに応じて補正された時刻を示す。例えば、ホストOSのタイムゾーンが -0900 (JST) なら、ゲストに与えられる仮想BIOSのRTCはホストOS上の時刻よりさらに 9時間前を示すものとなる。 |
| on_poweroff | `xm shutdown' コマンドまたは、ゲストドメイン内部でシャットダウンコマンドを発行した時など、礼儀正しくシャットダウンする時にトリガーされる動作。このパラメータ名は Xen のバージョンによっては on_shutdown。指定可能な値は； *"destroy": 停止し、環境のクリーンナップ (uuidやリソースの開放など) を行う。 *"restart": 停止し、同じゲストドメインを再び起動する。domID はたいてい変わる。 *"preserve": 停止するがクリーンナップは行わない。デバグ用。その後完全に停止させるには `xm destroy' を行う必要がある。 *"rename-restart": 使用したことがないので xmdomain.cfg.5 からその部分を和訳するだけにとどめる： 「停止するがクリーンナップは行わず、そのドメインをリネーム (-1 や -2 を付ける) して uuid も付け替えた上で、以前のドメイン名と uuid で新しいゲストドメインインスタンスを開始する。ただし前のドメインのリソースは開放される」 |
| on_reboot | `xm reboot' コマンドまたは、ゲストドメイン内部でリブートコマンドを発行した時にトリガーされる動作。値のバリエーションは on_poweroff と同じ。 |
| on_crash | 何らかの理由でゲストドメインがクラッシュ状態に陥った時にトリガーされる動作。値のバリエーションは上と同じ。 |
vfb (Xen内蔵VNCサーバ) のパラメータ (準仮想化の場合)
| パラメータ | 説明 |
| type | "sdl" にすると Xen組込の VNCクライアントでしか VNC接続できない。"vnc" にすると外部VNCクライアントアプリケーション (virt-manager のものも含む) から接続できるようになる。 |
| vnclisten | 内蔵VNCサーバのリッスンする IPアドレス。暗黙のデフォルトである 127.0.0.1 ならば、その Xen物理マシン上からしか接続できない。0.0.0.0 にすれば別のマシンからも接続可能となるが、当ページでは、Xen内蔵VNCサーバは緊急用と位置づけ、通常の利用では別途 vncserver をセッティングして使うことをお勧めするので、デフォルトのままにしておくのがよい。 |
| vncdisplay | 内蔵VNCサーバのディスプレイナンバーを固定したい時に定義。デフォルトではランダムに割り当てられる DomID と同一になるが、いちいち確認してからでないとつなげないため使いづらい。vncdisplay=3 のように指定する (`:' は不要)。下記の vncunused が書かれていると、この指定は有効にならない。内蔵VNCサーバの待ち受けポートは { 5900 + $vncdisplay } 番となる。下に示した記述例では dom0 の VNC Viewer で 127.0.0.1:11 を指定するとそのゲストドメインに接続できる。ただし、仮想ネットワークのトポロジーによるのか、vncdisplay を設定してもディスプレイナンバーが固定できないことがある。そんな時のために、自動的に振られたナンバーを調べるコマンドがある。 |
| vncunused | VNCのリッスンするポートを 5900番以上の空いているポート番号から自動的にチョイスする。これが指定してあると vncdisplay パラメータは効かない ("vncunused=0"でもダメ)。 |
| display | type パラメータを "sdl" にした時のディスプレイナンバー。デフォルトでは環境変数 DISPLAY の値が適用される。/var/log/xen/xend.log を見ると、デフォルト時には ":0.0" というものになっていた。通常、ドメイン毎のディスプレイナンバーを固定したければ vncdisplay さえ指定しておけばよく、こちらはあまり意味を持たないようだ。 |
| vncpasswd | 内蔵VNCサーバへクライアントから接続する時のパスワード。パスワードを掛けたいなら定義する。 |
| xauthority | type パラメータを "sdl" にした時の、X authority ファイルの指定。デフォルトでは環境変数 XAUTHORITY の値が適用される。/var/log/xen/xend.log を観察してみたところ、デフォルト時には "/root/.Xauthority" になっていた。 |
| keymap | man にもどこにも書いてないが、キーボードマップらしい。下の記述例参照。 |
name = "centos51u" uuid = "e5562feb-1ad2-bf5b-75e3-698f707b52be" maxmem = 512 memory = 512 vcpus = 2 bootloader = "/usr/bin/pygrub" on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" vfb = [ "type=vnc,vnclisten=127.0.0.1,vncdisplay=11,vncpasswd=myroot,keymap=ja" ] disk = [ "phy:/dev/sda5,xvda,w","phy:/dev/sda6,xvdb,w" ] vif = [ "mac=00:16:3e:66:24:3e,bridge=virbr0","mac=00:16:3e:66:24:3f,bridge=xenbr1" ]
name = "win2k3svu" uuid = "643a28c9-ccfe-8aaf-310d-5a890b625709" maxmem = 2048 memory = 2048 vcpus = 2 builder = "hvm" kernel = "/usr/lib/xen/boot/hvmloader" boot = "c" pae = 1 acpi = 1 apic = 1 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib/xen/bin/qemu-dm" usbdevice = "tablet" sdl = 0 vnc = 1 vncdisplay = 11 vncunused = 0 keymap = "ja" disk = [ "phy:/dev/sda9,hda,w","phy:/dev/cdrom,hdc:cdrom,r" ] vif = [ "mac=00:16:3e:3e:73:0e,bridge=virbr0,type=ioemu", "mac=00:16:3e:3e:73:0f,bridge=xenbr0,type=ioemu" ] serial = "pty"
完全仮想化のドメイン記述例についての補足：
こちらは仮想化の仕組みとして HVM (QEMU) が使われるため、内蔵VNC の定義は準仮想化の時とは異なり、vfb ブロック内ではなく sdl, vnc, vncdisplay, vncunused, keymap という独立した定義として記述する。パラバーチャライぜーションとは逆に、vncdisplay 設定は vncunused=0 を書かないと効かなかった。
また、Windows インストーラの最初の再起動時あるいはインストール完了時に、disk 定義ブロックの CD-ROM に関する記述部分が、"phy:..." が空になったり (CDイメージをインストールソースにした場合に発生)、定義自体根こそぎ削除されていたりするため、上記のように "phy:/dev/cdrom,..." を手動で訂正してやらなければならない。
そしてもうひとつ注意しなければならないのが localtime パラメータだ。virt-install や virt-manager で os-type=windows を指定して Windowsゲストをインストールすると、生成されるゲストドメイン定義ファイルは localtime=1 で書かれる。ホストOS で時刻管理を UTC にしている場合はそれで辻褄が合うのだろうが、ホストOS自体をローカルタイムで管理している (こちらのほうが多いのではなかろうか) と、日本の場合、ゲストの時計は {UTC - 9 時間 - 更に 9時間} となってしまう。よって、後者の場合には上例のように localtime=0 に修正してやる必要がある。
Fedora Core 7/8 (Xen-3.1) では、/etc/xen/ にファイルができない。RHEL/CentOS 5.1 の virt-manager が xm ユーティリティをコントロールの核にしていたのに対して、Fedora Core 7/8 のものは、より virsh (libvirt) 寄りに作られているためだと思われる。virt-manager は、ゲストドメインの OSインストーラーを開始させる時点で (virsh を使って？) ドメイン定義プール に定義を登録している。RHEL/CentOS 5.3 及び 5.4 では、当節に述べる方法を使ってもドメイン定義を更新することができ、/etc/xen/ 下の xm形式ファイルの方も同時に書き換わってくれる。
定義に変更を加えるには、まず virsh を使ってファイルに書き出してやらなければならない (※最近は `virsh edit' コマンドで編集可能)。出力されるのは XMLファイルだ。書き出し先はどこでも構わないので、作業のしやすいディレクトリに出力させればいい。例えば centos51u というドメインの定義を書き出すには下記のようにコマンドする (コマンドラインツールの章も参照のこと)。Fedora Core 7/8 では、そのドメインがアクティブな時でないと、完全な定義が出力に反映されなかった (アクティブな時は XenStore から読んでいる？)。逆に、RHEL/CentOS 5.3, 5.4 では、そのドメインをシャットダウンした状態でないと一部のパラメータ (bootloader ブロック) が不適切なものになってしまうバージョンが見受けられた。
root# virsh dumpxml centos51u >centos51u.xml
参考までに Fedora Core 8 (xen-3.1.2 + libvirt-0.4.1) でのサンプルを置いておく。
使用できるエレメントや属性を表にまとめてみた。libvirt - XML Format (libvirt.org) でもあらかたは書かれているが、実情とは異なるところもあるようなので、libvirt-0.4.1-2 のソースに付属していた libvirt.rng という資料を解析した。HTMLページには向かない巨大な表になってしまったため PDFファイルにしてある。各パラメータの説明は前述の xm形式 も参考にしてほしい。
XMLダンプしたファイルを適宜書き換えたら、必ずまずそのゲストドメインを shutdown してから、`virsh define' コマンドで定義を更新する。下記では念のためいちど登録を抹消 (`virsh undefine') してから再登録しているが、抹消しなくても定義は上書きされる。
root# virsh shutdown centos51u root# virsh undefine centos51u root# virsh define /PATH/TO/centos51u.xml
※ 最近の virsh では、`virsh edit <DOM_NAME> ' コマンドが使用できるようになり、一旦XMLファイルへ書き出さなくても、ドメイン定義を直接修正することが可能。virsh が裏で、テンポラリ XMLファイルへの書き出し -> 再define をやってくれているわけだ。
実際にゲストドメインを起動させて、まず、最低限の設定だけ行っておく。作業は、とりあえず virt-manager 作りつけの VNCコンソールで、当該ゲストドメインにログオンして行う。virt-manager の内蔵VNC機能に不具合があって使えない時 (例えば Fedora Core 7) は、VNC Viewer で 127.0.0.1 へ接続する (複数のゲストが起動している時の Xen内蔵VNC の ID を調べ方はこちら)。
ホスト名や IPアドレスなどが未設定だったら、ここで設定しておく。
ゲストOS のインストール時に `default' ブリッジへの接続を選択した場合には、IPアドレスは virbr0 (CentOS 5.1, Fedora Core 7/8 ではアドレス 192.168.122.1) から DHCP でもらうか、スタティックにするなら 192.168.122.2～254/255.255.255.0 の中から決める。VNC Viewer で接続する時に決め打ちできるようにするためにも、IP を固定で与えておく方がよい。その時の参照 DNSサーバとデフォルトゲートウェイはともに virbr0 のアドレスを指定する。
また、RedHat系の /etc/hosts ファイルは伝統的に書き方が悪く、このあとの VNCサーバの設定でエラーが出る。そこで、
127.0.0.1 localhost.localdomain localhost centos51u
のようになっているのを、
127.0.0.1 localhost.localdomain localhost
<eth0のIPアドレス> centos51u.my_domain.com centos51u
のように直しておく。
また、ホストOS で行った IPv6 の無効化を、ゲストOS にも施しておく。
VNCサーバを rcスクリプトで立ち上げるか xinetd 経由にするかで状況は異なるが、グラフィカルログオンだと不要なメモリを喰ってイヤだという人は /etc/inittab を編集してデフォルトinitレベルを 3 に変えておく。
かたや、VNCサーバを xinetd 経由で立ち上げるなら 5 のままにする。グラフィカルログインに必要となる gdm (prefdm) は inittab で定義され、ランレベル 5 でしか起動されないようになっているからだ。
Xen組込の VNCサーバと virt-manager 付属の VNCクライアントでもゲストの GUI 操作は可能だが、反応が鈍く、バッファサイズの制約から画面解像度も 800x600 を超えられないため実用に耐えない。そこで、単体の VNCサーバ (vnc-server パッケージで提供されるもの) を使えるよう整備する。別ページに独立させたので、そちらを参照いただきたい。
Windows 完全仮想化ドメインなら、無料の RealVNC Free Edition をインストールするか、物理的に別の Windows マシン (※) からリモートデスクトップすればいい。
※ CentOS 5/RHEL5 や Fedora Core 8/9 には rdesktop という Windows リモートデスクトップクライアントソフトウェアがあり、それをラップして使いやすくする tsclient を使えば、Windows機からやるのと同じくらい簡単にリモートデスクトップ接続ができる。
ゲスト定義名が centos51u だとして例を示す。まず、一旦、当該のゲストドメインを virt-manager からシャットダウンする。そして改めて起動させる。 virt-manager で起動させてもいいのだが、試しにコマンドラインで上げてみることにしよう。なお、Fedora Core 8 では構造上 `xm create' は使えない。(xm 及び virsh コマンドについては「コマンドラインツール」の章で解説)。dom0 上のターミナルで、
root# virsh start centos51u root# virsh console centos51u
または
root# xm create centos51u -c
ターミナル上に、ブートメニューが現れる (右図)。 Grub の画面に似ているが、これは Python で組まれたスクリプト pygrub がテキストを組み合わせて巧妙に描画している。Grub の備える様々な割り込みキーまで正確にエミュレートされていて面白い。
しばらくするとゲストOS が起動し、
centos51u login:
といったプロンプト状態になる。そこで直接、テキストモードでログインすることも可能だが、今はそのまま放っておく。
Gnomeデスクトップメニューから VNC Viewer を起動し、接続先指定ダイアログでゲストOS の IPアドレスと VNCディスプレイナンバーをタイプする。例えば `192.168.122.2:1' といった具合。 Gnome デスクトップ (rc起動の場合) か gdm のログイン画面 (xinetd経由起動の場合) が現れるはずだ。
VNCセッションを終了するには、rc起動の場合は VNCウィンドウを × ボタンで閉じる (ログオフ してはいけない)。xinetd 起動の場合はログオフでも × でも問題ない。
virt-manager を使ってゲストをインストールした場合には、インストール時に仮想ディスクをひとつしか指定できないため、「ゲスト用パーティションの作成」でSWAP用に用意しておいたパーティションを、ここで追加してやる。/dev/sda6 を使用する場合を例に手順を示す。当該のゲストドメインはシャットダウンしておく。
disk = [ "phy:/dev/sda5,xvda,w","phy:/dev/sda6,xvdb,w" ]
root# mkswap -L SWAP-sda6 /dev/xvdb1
root# swapon -v LABEL=SWAP-sda6 root# swapon -s <--確認
LABEL=SWAP-sda6 swap swap defaults 0 0
ゲストOS を再起動すれば、新しいスワップが有効になっているはずだ。
これも、 xm を基本としている RHEL/CentOS 5.x と libvirt を基本としている Fedora Core 7/8 とで別々に説明しなくてはならない。
dom0 の起動時に特定のゲストドメインを自動的に起動させるには、/etc/xen/auto/ 下へゲストドメイン定義ファイルのシンボリックリンクを作る (※ RHEL/CentOS 5.3 以降では virsh で可能)。元のゲストドメイン定義ファイルは所定の位置 /etc/xen/ になければならない。centos51u という定義名のドメインを自動起動させる場合；
root# cd /etc/xen/auto root# ln -s ../centos51u
上記同様のコマンドを繰り返して複数のドメインを起動させるようにすることも可能だ。
※ RHEL/CentOS 5.3 になってやっと、上記のリンクを張る作業が virsh コマンドでもできるようになった。`virsh autostart DOMAIN_NAME ' でリンク作成、`virsh autostart --disable DOMAIN_NAME ' でリンク解除となる。
ドメインの自動起動は xend の少し後に呼ばれる xendomains INITスクリプトによって行われる。自動起動サービスに登録されているか確認しておく；
root# chkconfig --list xendomains
期待した Runレベルに登録されていなかったら、`ckconfig xendomains on' などで登録しておかなければならない。このように準備しておくと、次回マシンが再起動して xend が起動された後に、それらのドメインが自動的に起動する。非Xenカーネルでマシンをブートした時には、Xenカーネルの時には存在するはずの /proc/xen がないため xendomains INITスクリプトはすぐさま `exit 0' し、ドメインの起動は発動されない。
デフォルトでは、dom0 のシャットダウン時にはすべての動作ドメインが save を試行され、save に失敗した場合には shutdown するようになっている。xendomains INITスクリプトのそれら動作を変えたい場合には、パラメータファイル /etc/sysconfig/xendomains を書き換える。例えば、dom0 のシャットダウン時にゲストドメインを save でなくシャットダウンしたい場合には、
XENDOMAINS_SAVE=""
にしておけばよい。
標準で提供されている /etc/init.d/xendomains スクリプトは作りが非常に雑だ (RHEL/CentOS 5.4 で少しはまともになったが)。下の virtdomains を作るついでに、こちらも改良版を書いてみた。
基本的にゲストドメイン定義ファイルを使わなくなった Fedora Core 7/8 の Xen実装では、自動スタートの仕組みがまだ正式には用意されていない。virsh で XenStore や定義プールから定義を書き出したとしてもそれは XML形式であり、xm をベースにしている今の xendomains スクリプトには扱うことができない。
そこで、Fedora Core 8 の xendomains 起動スクリプトを修正して virtdomains という起動スクリプトを作成した。ファイルをいじりはじめてつくづく思ったのだが、標準で付属している xendomains は非常に未完成なシロモノだ。そのへんの修正も加えた。
!!! 2008/4/26以前にこれらをダウンロードした方へ： 初期の virtdomains はゲストドメイン停止時 (saveなども含む) のゾンビプロセス検出条件にミスがあり、ホストOSのシャットダウン時にコールされた時に、ゲストドメインが完全に停止しないうちにホストマシンがシャットダウンしてしまう可能性があります。下記最新のものと入れ替えてください。
パッチ版を適用するには、 /etc/init.d/xendomains を作業ディレクトリへ virtdomains としてコピーし、作業ディレクトリで、
patch < /PATH/TO/virtdomains.diff
そうしてパッチの当たったものを /etc/init.d/ にコピーする (パーミション： root:root 755)。
起動させるゲストドメインがどれなのかは、/etc/xen/auto/ にあるファイルの名前で決まる。中身は見ないので空でいい。例えば、定義プールに登録済みの centos51u というドメインを自動起動/自動終了させるには、
root# touch /etc/xen/auto/centos51u
終了時に save するか shutdown するかなど、動作規定は /etc/sysconfig/virtdomains から読み込む。設定項目は元々の xendomains から変更していないので、オリジナルの /etc/sysconfig/xendomains ファイルを複製しておいてらえばいい。ただし、すべてデフォルトのままでいくとしても、このファイルがないとスクリプトは機能しない。
以上で準備は完了。`service virtdomains start' や `service virtdomains stop' できちんと動作することが確認できたら、`chkconfig --add virtdomains' でスタートアップ登録していただきたい。標準の xendomains はスタートアップから外しておいたほうがいいだろう (`chkconfig --del xendomains')。