Dom0からDomUのイメージファイルをディスクデバイスとして扱う

DomUの/var/xen/rescue.imgをDom0側からマウントしたい、という場合がある。例えば、DomUの/boot/grub/grub.confを書き換えたり、rootのパスワードを忘れた場合などだ。

手順だが、簡単に言うと、(1)イメージファイルをループバックデバイスに割り当て、(2)これをパーティション毎にマップし、それをマウントすればOK。まずは、ループバックデバイスの空きを調査する。

# losetup -f
/dev/loop3
#

このループバックデバイス/dev/loop3に、イメージファイルを割当てる。

# losetup /dev/loop3 /var/xen/rescue.img
#

/dev/loop3をパーティション毎にマップする。

# ls /dev/mapper/
control  VolGroup00-LogVol00  VolGroup00-LogVol01  VolGroup00-LogVol02
# kpartx -a /dev/loop3
# ls /dev/mapper/
control  loop3p2  VolGroup00-LogVol00  VolGroup00-LogVol02
loop3p1  loop3p3  VolGroup00-LogVol01
#

/var/xen/rescue.imgの中のパーティションが、/dev/mapper/loog3p[1-3]に割当てられたのが解る。通常、これがそれぞれ、/boot、swapおよび/になっているので、適宜マウントする。もし、LVMを使っていれば、vgscanで再度マップし直す必要があるが、この手順については、以前述べた通り。

使用後は、この逆の手順で元に戻す。マウントを解除した後、

# kpartx -d /dev/loop3
# ls /dev/mapper/
control  VolGroup00-LogVol00  VolGroup00-LogVol01  VolGroup00-LogVol02
# losetup -d /dev/loop3
#

とする。

なお、kpartxは、以下のパッケージに含まれる。

# rpm -qf `which kpartx`
device-mapper-multipath-0.4.5-12.2

[Ctrl]+[Alt]+[Del]による再起動を無効にする

Runlevel 3で[Ctrl]+[Alt]+[Del]を押下すると再起動(reboot)してしまう。Runlevel5では基本的に安全だが、[Ctrl]+[Alt]+[F1]でTTY画面を出しているとRunlevel 3と同じ動作になる。止められないサーバでこれが有効になってると、誤操作による事故の元。無効にする。

この設定は、/etc/inittabにある。以下の部分がそれだ。

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

この部分をコメントアウトするか、以下のように書き換える。

ca::ctrlaltdel:/usr/bin/logger 'CTRL-ALT-DELETE trap is disabled'

再起動するか、telinit 3などで有効になる。TTYから[Ctrl]+[Alt]+[Del]を押すと、SYSLOG経由でメッセージが残る。
メッセージが必要ない場合は、/usr/bin/loggerの代わりに、/bin/trueなんかにしても構わない。TTYにメッセージを出すのであれば、/usr/bin/wallが使える。

GDMログイン画面からshutdownボタンを消す

FC5のRunlevel 5のGUIログイン画面には、電源を切ったり、再起動したりするためのボタンが表示されている。これはデスクトップ機だと気にならないが、ラックマウントしてKVMをつけて、普段はディスプレイの電源を切ってます、なんて状態だと、誤って電源を落としそうで怖い。なので、これを無効にする。

まず、このログイン画面は、GDMが表示している。

$ rpm -q gdm
gdm-2.14.9-1
$

この設定ファイルは、FC5だと/etc/gdm/custom.confにある。この中を

[greeter]
SystemMenu=false

の様に変更すればよい。後は、再起動するか、telinit 5を実行する。

LVMをXenを使ってサルベージする

Xenで遊んでいると、DomUが起動しなくなった。起動しなくなった原因は不明なのだが、とりあえずそのDomUのサービスを復活させねばならない。サービスの設定や内容(コンテンツ)は、そのDomUのディスクイメージファイルに入っている。なので、古いDomU(以下、旧DomU)から設定や内容をサルベージして、新しく構築したDomU(以下、新DomU)に突っ込んでやればいいわけだ。
ちなみに、旧DomUのサービスは、MediaWikiなので、ApacheとMySQL、それとMediaWiki自身の設定と内容を復活させることになるが、ここではその詳細は触れない。
普通に考えれば、

1. ディスクイメージをlosetupで/dev/loop1などのループバックデバイスに割付け、
2. kpartxを使い、ディスクイメージ内のパーティションを/dev/mapper/loop1p1などに割付け、
3. それぞれをmountで/mnt/oldにマウント

して、ディスクの内容を読み出せばOK。

だが、最近のLinuxは、これではうまく行かない。それはLVM(Logical Volume Management)を採用しているからだ。パーティションが直接ext3などでフォーマットしてあれば上の手順でOKなのだが、LVMで構成されている場合には、論理ボリュームを認識させる必要がある。これは、vgscanを使って、/dev以下のブロックデバイス(この中には、当然/dev/mapper以下のデバイスも含まれる)を探索し、認識させることができる。
さらに、Dom0もDomUもLVMで構成されていると、デフォルトボリュームグループ名であるVolGroup00が旧DomUのディスクイメージと、Dom0の物理ディスクとの間で衝突してしまうため、旧DomUのボリュームグループがDom0側で認識できない。正確には、不整合(inconsistent)が発生した、と言うようなメッセージが表示される。これを回避するためには、ボリュームグループ名をvgrenameで名前を変更すればいいのだが、一旦論理グループ名を認識させないことには、名前を変更することもできない。

で、解決編。Xenを使っているのが前提であるので、一旦、サルベージ用のDomUを作成する。これは、LVMを使用しないものを作る。具体的には、インストールの際に、デフォルトでは、VolGroup00にLogVol00、LogVol01が作られ、それぞれ/(ルート)とスワップ(swap)に割り当てられているが、これをVolGroup00ごと削除し、新たに二つパーティションを作って、それぞれ/とスワップに割り当て直す。
正常に起動するサルベージ用DomUが作成できたら、この設定ファイルを以下のように編集し、旧DomUのディスクイメージを、/dev/xvdbに割り当てる。

name = "rescue"
memory = "64"
disk = [ 'file:/var/xen/rescue.img,xvda,w','file:/var/xen/DomU-old.img,xvdb,w' ]
＜＜以下略＞＞

サルベージ用DomUを起動し、vgscanを実行すれば、VolGroup00が認識される。

[root@rescue ~]# vgscan
Reading all physical volumes.  This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
[root@rescue ~]#

ここでこのままサルベージ作業に入ってもいいのだが、折角だから、新DomUにマウントできるようvgrenameコマンドを使ってボリュームグループ名を変更する。

[root@rescue ~]# vgchange -an VolGroup00
0 logical volume(s) in volume group "VolGroup00" now active
[root@rescue ~]# vgrename VolGroup00 VolGroup00-old
Volume group "VolGroup00" successfully renamed to "VolGroup00-old"
[root@rescue ~]#

そうして、新DomUの設定ファイルをサルベージ用DomUの設定ファイルと同様に編集し、新DomUを起動すれば、新DomUから旧DomUのディスクが認識される。これをmountコマンドでマウントすれば、無事旧DomUと設定と内容をサルベージできる、というわけだ。

物理ハードディスクからサルベージするときにもこれと同じ手法が使える。サルベージ元ディスクと、サルベージ先システムのボリュームグループ名は普通、同一になるので、普通にはマウントできない。このとき、Xenを使ってサルベージ元ディスクのボリュームグループ名を変更して、マウントすることが可能になる。

XenのDomUで、仮想コンソールにログインプロンプトが出ない

Fedora Core 5でXenを使っていて、うまく動いていたDomUが、yum updateをした後、システムを再起動すると、仮想コンソールにログインプロンプトが表示されず、代わりに以下のようなSELinux(auditd)のメッセージが表示され続ける、という問題に出くわした。

audit(XXXXXXXXXX.XXX:X): avc:  denied  { getattr } for  pid=XXXX comm="agetty" name="xvc0" dev=tmpfs ino=XXXX scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

よくよく調べてみると、yum update以前は、仮想コンソールは、普通のマシンと同じく

1:2345:respawn:/sbin/mingetty tty1
＜＜略＞＞
6:2345:respawn:/sbin/mingetty tty6

のようになっていたが、yum update以後は、

co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

となっていて、デバイスが/dev/tty[1-6]から/dev/tty/xvc0に変更になっている。SELinux的にはどうなっているかというと、

# cd /dev
# ls -lZ xvc0 tty1
crw-rw----  root tty  system_u:object_r:tty_device_t   tty1
crw-------  root root system_u:object_r:device_t       xvc0
#

と、違っていることが解る。問題解決には、これを合わせてやればいいわけだ。

# chcon -t tty_device_t /dev/xvc0
#

この後、再起動するか、init 5などを実行する。

訂正記事を公開しました。