virt-manager GUI を使わずにコマンドラインで仮想ドメインを操作したり情報を表示したりするコマンドを紹介する。また、仮想ブリッジのためのコマンドについても触れる。
ここで少しウンチクを垂れなければならない。Xen の世界では、まだ xm ユーティリティと virsh (ヴァーシュ) ユーティリティが共存している状態にある。当コーナーでも xm と virsh のコマンド織り交ぜて紹介するが、時代の先を見据えるなら virsh のコマンドに慣れておいたほうが得だと思う。なお、virsh を使用するには、xend の他に、libvirtd というデーモンが起動していなければならない。その辺りの概略は「Xen 用語集」にまとめた。
ここでは、通常使うであろう主な命令句やオプションだけを取り上げている。他のオプションや命令句などは各ユーティリティの manページなどで調べていただきたい。
dom0 のコンソールで、以下のいずれかをコマンドする。
root# virsh start GUEST_NAME root# virsh list --all <--確認
root# xm create GUEST_DEF_FILE -c または root# xm start GUEST_NAME -c
xm で -c オプションを付けると、dom0 が起動し次第その仮想ターミナルに接続する。-c を付けないと、`xm create' コマンドはすぐにリターンする。virsh には -c に相当するオプションがまだなく (※)、常にすぐにリターンしてしまうので、 `virsh list' などを何度か発行してで起動を確認しなければならない。なお、virsh には、XML形式のドメイン定義ファイルからドメインを起動する仕組みもある。
※ 最新の virsh では -c オプションが加わっている模様。
dom0 のコンソールで、以下のいずれかのコマンドを実行する。
完全仮想化の Windows に対して以下を行ってみると、明らかに OS が惨殺されており、Windows Server 2003 なら次回の起動時に「異常終了の理由」を尋ねるダイアログが登場することになる。Windows ゲストをシャットダウンやリブートするには、ゲスト自体の上で [スタートメニュー] から行ったほうがいいようだ。
root# virsh shutdown GUEST_NAME root# virsh list --all
root# xm shutdown GUEST_NAME -w
xm で -w (--wait) オプションを付けると、xm コマンドはドメインがシャットダウンするまでリターンしない。かたや virsh では、そのようなオプションはないので list 命令で何度か確認しなければならない。xm にはこの他に、すべてのドメインをシャットダウンする -a (--all) オプションもある。virsh, xm ともに、shutdown を reboot に換えると再起動となる。
ゲストOS自体の上で `shutdown -h' や `shutdown -r' を行った時も、裏では実はこれらと同じことが行われている。
※ ゲストドメインをシャットダウンしたつもりなのに、`xm list' や `virsh list --all' を見ると「停止処理中」や「状態なし」となり、管理上消えないままになっていることがある。これを通称 ゾンビ (zombie) と呼ぶ。そうなると、xend をリスタートするかホストOS自体をリブートしない限り、同じゲストドメインが起動できない。Xen のメーリングリストアーカイブを紐解くと、仮想リソース (ディスクや vif) が何らかの原因で開放されないことが主な原因のようだ。現象を精査するひとつの方法としては、`xenstore-ls' を実行して XenStore に残っている情報を画面に出力してみることが挙げられる。
ゲストドメインがフリーズのような状態となって上記の shutdown が効かない時や、デバグのためにゲストドメイン定義ファイルの on_poweroff パラメータを "preserve" にしてある時などにだけ使う。これは、喩えて言うなら、仮想マシンの電源コードをコンセントからブチ抜くようなものだ。
root# virsh destroy GUEST_NAME
root# xm destroy GUEST_NAME
save は現実世界の PC で言えばハイバネーションにあたり、メモリやネットワークソケットの状態をファイル (ステートファイル) に保存してすべてのリソースを開放する。それをステートファイルから復帰させるのが restore オペレーションだ。
root# virsh save GUEST_NAME STATE_FILE_PATH root# virsh restore STATE_FILE_PATH
root# xm save GUEST_NAME STATE_FILE_PATH root# xm save STATE_FILE_PATH
ゲストドメインへターミナル接続する。これによって開始されるものは、実は Xen によって提供されている仮想のシリアルコンソールで、完全仮想化の Windows に対しては使用できない。dom0 上のターミナルで行う。xm の manページでは「パラバーチャルなゲストドメインにしか使えない」とあるが、virsh がその点どうなのかはまだ試していない。また、「vi など複雑な動作をするものは上手く動かないことがある」ともあるが、筆者はこれまでそれほどの困難にぶつかったことはない。
root# virsh console GUEST_NAME
root# xm console GUEST_NAME
root# virsh list (--inactive|--all)
root# xm list
virsh では、オプションを何も付けないと、現在実行されているドメインだけがリスト表示される。--all を付けると、起動されていないドメインも含めて登録されているドメインが全て表示され、--inactive では、起動されていないドメインだけが表示される。xm の挙動はバージョンによって異なり、RHEL/CentOS 5.1~5.4 のもの (xen-3.0.3) では起動されているドメインだけ、Fedora Core 8 (xen-3.1.2) ではすべて表示された。
ドメイン定義を XMLファイルに書き出すには、
root# virsh dumpxml GUEST_NAME >/etc/xen/xml/GUEST_NAME.xml
dumpxml 命令句は、現在稼働中あるいは virt-manager によって XenStore や定義プールに登録済みのドメインを、 libvirt の XML形式で出力する。出力先は stdout なので、例のようにファイルへリダイレクトするのが通常の使い方。上記の書き出し先パスは単なる例。XMLファイルはたいてい定義修正のために一時的に使うだけなので、場所はどこでも構わない。また、最近の virsh では、`virsh edit GUEST_NAME ' コマンドが使用でき、ドメイン定義を直接修正することが可能になった。これは virsh が裏でテンポラリな XMLファイルへの書き出し -> 再define をやっているというだけのことなのだが、`virsh edit' の場合は編集後の記述チェックをしてくれるというメリットがある。
書き出したドメイン定義XMLファイルを使えば、
root# virsh create /etc/xen/xml/GUEST_NAME.xml
のようにしてそのドメインを起動することもできる。しかし、通常は、`virsh define' で定義プールに登録してから使用する。以下に、書き出してから再定義する場合の手順をまとめておく。なお、RHEL/CentOS 5.3 及び 5.4 では、dumpxml するより前にゲストドメインを終了させておかないと、<bootloader> ブロックが起動に適さない記述になるバージョンもあった。
root# virsh dumpxml GUEST_NAME >/etc/xen/xml/GUEST_NAME.xml <--書き出した XML ファイルをここで編集--> root# virsh shutdown GUEST_NAME <--ゲストドメインを前もって終了させておく root# virsh define /etc/xen/xml/GUEST_NAME.xml <--新しい定義をファイルから再登録
root# xen top
または、
root# xentop
通常の top コマンドのような様式でドメイン毎のリアルタイムモニタが表示される。
指定したゲストドメインについて、Xen組込VNCサーバのディスプレイナンバーを表示する。
root# virsh vncdisplay GUEST_NAME
なお、Xen組込VNCのディスプレイナンバーを固定する方法もあり、ゲストドメイン定義ファイルの説明の中で触れている。
ここで網羅していない net-define, net-undefine, net-autostart などは「Xenネットワークのカスタマイズ」の章で実例を示しながら説明している。
libvirt によって管理される仮想ブリッジや仮想ルータの稼働状態を表示。
root# virsh net-list
全ての仮想ブリッジの情報を表示。
root# brctl show
brctl は、 Linux カーネルの備えるイーサネットブリッジ機能をコントロールするインターフェイスで、対象は仮想のものに限らず、各ブリッジの設定を変更するための命令句も備えている。詳しくは man を。
root# virsh net-destroy VIRNET_NAME
libvirt によって管理される仮想ブリッジや仮想ルータのひとつを、現在の Xen環境から消去する。定義ファイルが削除されるわけではない。「まだリンクアップしているので停止できない」とのエラーメッセージが出る時は、そのブリッジを使用しているゲストドメインをシャットダウンしてあるかどうか確認する。それでもダメな時は、
root# ip link set VIRNET_NAME down
によって明示的にリンクダウンしてからやってみる。
root# virsh net-start VIRNET_NAME
libvirt によって管理される仮想ブリッジや仮想ルータのひとつを生成し稼働状態にする。xend 管轄の仮想ブリッジを brctl でダイナミックに操作することも可能ではあるが、あまりろくなことにはならないようだ。
virt-manager でインストールしたゲストOS のファイルシステムは、ひとつのパーティションをひとつのハードディスクと見立てて中にさらにパーティションを切ってある特殊な形態であるため、通常の mount やループバックマウントではマウントできない。では、ゲストOS 自体の問題でゲストが立ち上がらなくなり、修正する必要が生じた時、どうやってレスキューすればいいのだろうか。実は、これらをマウントするには 2つのツールが用意されている。Fedora Core 7 (FC7) Xen/KVM Guide - Accessing data on a guest disk image が参考になった。
RedHat系では Xen パッケージに含まれている特殊ループバックマウンター。ただし lomount には、巨大なディスクイメージや LVM ボリュームには使えないという制限があるそうだ。百聞は一見に如かず。ゲストOS を /dev/sda5 にインストールした場合の操作例を示す。当該のゲストOS はシャットダウンしておかないと危険。
[root@xentestdom0 ~]# lomount <--manがないのでヘルプを見てみる Usage: lomount [-verbose] [OPTIONS] -diskimage FILE -partition NUM [OPTIONS] All OPTIONS are passed through to 'mount'. ex. lomount -t fs-type -diskimage hda.img -partition 1 /mnt [root@xentestdom0 ~]# lomount -t ext3 -diskimage /dev/sda5 -partition 1 /mnt/image [root@xentestdom0 ~]# ls /mnt/image <--マウントされたか確かめてみる bin etc lib misc poweroff sbin sys usr boot home lost+found mnt proc selinux tftpboot var dev initrd media opt root srv tmp [root@xentestdom0 ~]# mount <--どんなマウント状態になっているだろう /dev/sda2 on / type ext3 (rw) <- 中略-> /dev/sda5 on /mnt/image type ext3 (rw,loop=/dev/loop0,offset=32256) [root@xentestdom0 ~]# umount /mnt/image <--アンマウントは普通に
こちらは kpartx という単独のパッケージで提供されている。kpartx はマウンターそのものではなく、指定のオブジェクトからパーティションテーブルを読み取ってデバイスマップを作成するツール。こちらのツールもちろん、当該のゲストOS はシャットダウンしておかないと危険。kpartx には manページもあるので見てみてほしい。
[root@xentestdom0 xen]# kpartx --help <--とりあえずヘルプを表示させてみる kpartx: invalid option -- - usage : kpartx [-a|-d|-l] [-v] wholedisk -a add partition devmappings -d del partition devmappings -l list partitions devmappings that would be added by -a -p set device name-partition number delimiter -v verbose [root@xentestdom0 ~]# kpartx -av /dev/sda5 <--デバイスマップを生成 add map sda5p1 : 0 40001787 linear /dev/sda5 63 [root@xentestdom0 ~]# ls -l /dev/mapper/ <--ここにブロックデバイスが作られる 合計 0 crw-rw---- 1 root root 10, 62 2008-04-01 15:21 control brw-rw---- 1 root disk 253, 0 2008-04-01 19:11 sda5p1 [root@xentestdom0 ~]# mount /dev/mapper/sda5p1 /mnt/image <--先ほどのブロックデバイスをマウント [root@xentestdom0 ~]# ls /mnt/image <--見えるかどうか bin etc lib misc poweroff sbin sys usr boot home lost+found mnt proc selinux tftpboot var dev initrd media opt root srv tmp [root@xentestdom0 ~]# umount /mnt/image <--アンマウントは普段と同じ [root@xentestdom0 ~]# kpartx -d /dev/sda5 <--システムが混乱するといけないので用が終わったらマップを削除 [root@xentestdom0 ~]# ls -l /dev/mapper/ <--当該のブロックデバイスがなくなったことを確認 合計 0 crw-rw---- 1 root root 10, 62 2008-04-01 15:21 control
基本的には、domU のクロックは、dom0 によって抽象化されたハードウェアクロック (RTC) として提供される。そのため、dom0 の時計が正確なら domU の時計は狂わない。逆に、Xen のデフォルトの挙動では、ゲストドメインが独自の時刻を持つことを許さない。何か特別な理由でゲストドメインのクロックをどうしても別個に管理したい場合には、proc パラメータ;
/proc/sys/xen/independent_wallclock
を 1 に設定する。デフォルトでは 0 だ。これをシステム起動時に必ず設定させたいのなら、/etc/syscrl.conf に下記の行を追加しておけばいい;
xen.independent_wallclock = 1
そうした変なことはしないとして、dom0 で ntpd を動かす場合の注意点を挙げておこう。
まず、万が一 dom0 が ntpd のバッファオーバーフロー等によって権限を略奪されたら、そいつは同物理マシン上の全ゲストドメインを自由にできる可能性があるということを肝に銘じておかなければならない。これを未然に防ぐ手段として、dom0 上の ntpd は chroot 環境で動かす。Xen を備えたディストリビューションなら、乗っている ntpd は -i オプションの使えるバージョンのはずなので、chroot 化は容易い。方法は ntpd のページ の「ntpd を chrootする」でかなり詳しく説明している。ただし Xen dom0 環境では 1点それとは変えたいところがある。それは /etc/sysconfig/ntpd のパラメータ OPTIONS の内容。下記のように -I オプションを加えて、仮想ブリッジインターフェイスをリッスンしないようにしておいたほうがいい。ただし、いつものことながら、ntpd は仕様が支離滅裂に変わるため、あなたのバージョンでは -I オプションが使えなかったり代わりに -L オプションだったりするかもしれない;
OPTIONS="-i /var/chroot/ntpd -u ntp:ntp -I eth0 -I lo -p /var/run/ntpd.pid"
もうひとつの注意点は domU 側にある。RedHat系の INITスクリプトのうち、システム終了時の最後に呼ばれる halt スクリプトは、カーネルクロックの時刻を RTC に反映させるということをやる。実際には、ゲストドメインがこれを行うのは矛盾を含んでおり、domU のシャットダウンの最後に必ずそれに伴うエラーメッセージが出る。やめさせるには、すべてのゲストドメインの /etc/init.d/halt ファイルの下記の行をコメントアウトしておく。
[ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
ホストドメインを非Xenカーネルでブートすると、
init: Id "co" respawning too fast: disabled for 5 minutes
という emerg なメッセージがターミナルに 5分おきに表示される。結論から言えば、これは当然であり、問題はない。 "co" というサービスの開始定義は、Xen をインストールすると /etc/inittab に追加されるのだが、システムが Xenカーネルで動いていないと、"co" の使用する /dev/xvc0 というデバイスファイルは存在しない。非Xenカーネルの時にエラーが出るのはそのためだ。xvc0 は仮想シリアルコンソールのためのキャラクターデバイスらしい。
筆者の好む、ゲストOS をパーティション毎にインストールするインストール方法では、domU のコールド・フルバックアップにちょっと工夫が要る。実際にやってみてバックアップと戻しに成功した方法を示しておく。以下のコマンドはもちろん dom0 上で行うものだ。対象ゲストドメインのインストールされているパーティションが /dev/sda5、バックアップ先を /mnt/backup/ だとする。
root# dd if=/dev/sda5 |gzip > /mnt/backup/centos51u.gz <--バックアップ root# zcat /mnt/backup/centos51u.gz |dd of=/dev/sda5 <--リストア
この時バックアップしたゲストOS は、ほぼインストール直後の標準的なパッケージ構成の CentOS 5.1 で、パーティションサイズは 30 GB。書き出された centos51u.gz ファイルは約 5 GB となった。これはあくまでもひとつの手法でしかなく、他にもっと効率的なやり方があるかもしれない。