『Red Hat Cluster: kernel-xenにバグか?』および『続・Red Hat Cluster: kernel-xenにバグか?』で報告したバグだが、どうも修正されたようだ。
によると、kmod-gfsにバグがあり、新バージョンで解決されるらしい。
検証して報告したい。
#最近「~したい」「~したい」ばかりで全然進んでない。申し訳ない。
追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』
2007/11/28
2007/11/22
VLANとXenを組合わせて使う・その5・仮想ブリッジが多い場合
以前、『VLANとXenを組合わせて使う』シリーズで、VLANとXenを組み合わせて使う方法を紹介した。
この中の『VLANとXenを組合わせて使う・その3・Xenネットワーク』で、
では、これを増やすにはどうすればよいか?CentOS 5では(ということは、RHEL 5でも(未確認))、
VLANとXenを組合わせて使う・その2・VLAN設定l
VLANとXenを組合わせて使う・その3・Xenネットワーク
VLANとXenを組合わせて使う・その4・DomUインストール
VLANとXenを組合わせて使う・その5・仮想ブリッジが多い場合
この中の『VLANとXenを組合わせて使う・その3・Xenネットワーク』で、
が、と書いた。この/etc/xen/scripts/network-bridge
の中に# vifnum Virtual device number to use (default 0). Numbers >=8
とあるように、カーネル変数の変更が必要らしいが、試していない。悪しからず。
# require the netback driver to have nloopbacks set to a
# higher value than its default of 8.
vifnum
とは、Xenドメイン間を接続する仮想ブリッジの番号で、これはデフォルトでは、最大で8までしか使用できない…と書いてあるが、実際にCentOS 5で試してみると、vifnum=4
までしかブリッジを作成できなかった。では、これを増やすにはどうすればよいか?CentOS 5では(ということは、RHEL 5でも(未確認))、
netback
ドライバは、カーネルモジュールとして組み込まれている(modprobe -lで確認できる)ので、/etc/modprobe.conf
に次の行を追加し、再起動する。
options netloop nloopbacks=32VLANとXenを組合わせて使う・その1
VLANとXenを組合わせて使う・その2・VLAN設定l
VLANとXenを組合わせて使う・その3・Xenネットワーク
VLANとXenを組合わせて使う・その4・DomUインストール
VLANとXenを組合わせて使う・その5・仮想ブリッジが多い場合
2007/11/14
Xen DomUインストールでAnaconda Kickstartを使う
RHELやCentOSをインストールしたことのある人は、インストーラAnacondaのお世話になっているはずだ。Anacondaによるインストールでは通常、対話的にインストールパラメータを指定していく。
これはこれでユーザに優しい仕組みだが、同じ設定で何台もOSをインストールしたり、少しづつインストールパラメータを変えながら繰り返しインストールしたりする場合には、かえって煩雑で不便だ。それを解消する方法がKickstartだ。
Kickstartのもっとも簡単な利用方法は、設定ファイル
さて、本題。では、XenのDomUをインストールするときにはどうすればいいのか?DomUのインストーラ、
さて、ここまでKickstartの設定ファイル
LVMを利用している場合には、
ちょっと予告: 上の例の中で利用したローカルレポジトリ環境(参考)や、これ利用してPXEインストールする環境(参考)の構築は結構手間なのだが、Cobblerというツールを利用すると簡単にできるようだ。検証でき次第、ここで報告したい。
これはこれでユーザに優しい仕組みだが、同じ設定で何台もOSをインストールしたり、少しづつインストールパラメータを変えながら繰り返しインストールしたりする場合には、かえって煩雑で不便だ。それを解消する方法がKickstartだ。
Kickstartのもっとも簡単な利用方法は、設定ファイル
ks.cfg
をフロッピーディスクに入れておき、これをインストールディスク起動時に読み込ませる方法だろう。インストールディスクからの起動時、boot:
プロンプトが表示されたら、次のように入力する(未検証)。boot: linux ks=floppy詳しくは、Stray Penguinの記事を参照して欲しい(先達はあらまほしきことなり。ありがたや)。
さて、本題。では、XenのDomUをインストールするときにはどうすればいいのか?DomUのインストーラ、
virt-install
プログラムのオプション--extra-args
オプションを使ってAnacondaにパラメータを渡せばよい。例えば、- ローカルレポジトリ:
http://centos.repository.localdomain/centos/5/os/i386
- Kickstart設定ファイル:
http://centos.repository.localdomain/centos/5/DomU-ks.cfg
# virt-install --name=node01 --uuid=`uuidgen` --ram=256 --vcpus=1 \
--file=/dev/VolGroup00/LogVolNode01 \
--nographics --paravirt \
--location=http://centos.repository.localdomain/centos/5/os/i386 \
--extra-args='ks=http://centos.repository.localdomain/centos/5/DomU-ks.cfg'
さて、ここまでKickstartの設定ファイル
ks.cfg
の内容については触れてこなかった。詳しくは、マニュアルを参照して欲しいが、実際に例を見てみるのが早い。普通にCentOSやFedora、RHELをインストールすると、そのときのインストールパラメータが、Kickstart設定ファイルの形式で、/root/anaconda-ks.cfg
に保存されている。自分が対話的に指定した内容とこれを照らし合わせながら眺めてみると、直感的に理解できるはずだ。LVMを利用している場合には、
# The following is the partition information you requestedの様なコメントアウトされた部分が見つかる。コメントを読むと、そのままでは動かないような記述だが、ディスク全体を初期化する(
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart --all --drives=xvda
#part /boot --fstype ext3 --size=100 --ondisk=xvda
#part pv.100000 --size=0 --grow --ondisk=xvda
#volgroup VolGroup00 --pesize=32768 pv.100000
#logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=272 --grow --maxsize=544
#logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
clearpart --all
)ような場合や、パーティションを変更しない場合は、問題なく動作する。必要な部分をコメントアウトして使う。ちょっと予告: 上の例の中で利用したローカルレポジトリ環境(参考)や、これ利用してPXEインストールする環境(参考)の構築は結構手間なのだが、Cobblerというツールを利用すると簡単にできるようだ。検証でき次第、ここで報告したい。
2007/11/12
続・Red Hat Cluster: kernel-xenにバグか?
『Red Hat Cluster: kernel-xenにバグか?』でクラスタ/DLM関連のバグを指摘した。これはどうも、CentOS Bug ID 0002416 と同じバグのようだ。#2416は、CentOS 4でのものだが、「kernel: Extra connection from node * attempted」というログが共通しているし、症状も似ているような気がする。
アカウントを取って報告してみるか…
追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』
アカウントを取って報告してみるか…
追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』
RHEL 5.1リリース! CentOS 5.1も近日中に
Red Hat Enterprise Linux 5.1 (RHEL 5.1)がリリースされた。
[rhelv5-announce] Red Hat Enterprise Linux 5.1 General Availability Announcement
と言うことは、われらがCentOSも一両週間中("in a couple of weeks")にリリースされるということ。
[CentOS] status of Centos 5.1?
今回のリリースは、仮想化関係の改良が盛り込まれているようなので、逐次ここでも検証していきたい。
他にも、このブログと関係のある更新がいくつか含まれている。
『CentOS 5.0からCentOS 5.1へアップグレードする』を公開した。
2007/12/10(月)追記:
『CentOS 5.0からCentOS 5.1へアップグレードする・補足』を公開した。
[rhelv5-announce] Red Hat Enterprise Linux 5.1 General Availability Announcement
と言うことは、われらがCentOSも一両週間中("in a couple of weeks")にリリースされるということ。
[CentOS] status of Centos 5.1?
今回のリリースは、仮想化関係の改良が盛り込まれているようなので、逐次ここでも検証していきたい。
他にも、このブログと関係のある更新がいくつか含まれている。
- device-mapper-multipathからのインストールと起動が可能(Support for installation to and boot from dm-multipath)
- IPMIとHPIの更新(IPMI and HPI updates)
- IPMIドライバの更新(Driver updates include: ipmi)
『CentOS 5.0からCentOS 5.1へアップグレードする』を公開した。
2007/12/10(月)追記:
『CentOS 5.0からCentOS 5.1へアップグレードする・補足』を公開した。
2007/11/07
Red Hat Cluster: kernel-xenにバグか?
『Red Hat Cluster: GNBD, CLVM and GFS』シリーズが全然進んでいない。その言い訳。どうも、現時点で最新のカーネルkernel-xen-2.6.18-8.1.15.el5にはバグがあるようだ。一世代前のkernel-xen-2.6.18-8.1.14.el5ならば問題ない。
#Xen対応でないバニラカーネルでどうなのかは未確認。
シリーズの続きを書くべく、作業を進めていたのだが、クラスタの動作が安定しなかった。クラスタメンバを一斉に起動するような場合には問題なくクラスタが開始されるのだが、この後、各クラスタメンバの再起動を行うと、OS起動時にクラスタ関連のサービスが正常に起動されなかったり、最悪、OS起動時に停止してしまい、ログインプロンプトすら出ない、という現象に遭遇した。
クラスタメンバを一斉に起動し、クラスタが正常に起動した後、何度かクラスタメンバの再起動を繰り返していると、OS起動時に、
この状態から、停止しているノードをフェンスしたり、強制再起動したりすると、今度は、
更にこの後、clvmdの起動に失敗する。
ここから、クラスタメンバを停止しようとすると、正常に停止できない。
これは、サービスrgmanagerを停止中に、デーモンclurgmgrdが「Uninterruptible sleep」状態(ps(1)参照)になっていて、シグナルに応答しなくなることが原因。追求できたのはここまで。
カーネルのバージョン2.6.18-8.1.15.el5に関しては、RHSA-2007:0940-7に更新情報が記載されていて、Distributed Lock Manager(DLM)に関する修正がなされたことが解る。この修正で虫が憑いたのではないだろうか。
当面、2.6.18-8.1.14.el5で検証を行う。しかし、2.6.18-8.1.15.el5への修正は、深刻度「重要(Important)」に分類されているのが頭の痛いところだ。
2007/11/12追記:
『続・Red Hat Cluster: kernel-xenにバグか?』に情報を追加した。
追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』
#Xen対応でないバニラカーネルでどうなのかは未確認。
シリーズの続きを書くべく、作業を進めていたのだが、クラスタの動作が安定しなかった。クラスタメンバを一斉に起動するような場合には問題なくクラスタが開始されるのだが、この後、各クラスタメンバの再起動を行うと、OS起動時にクラスタ関連のサービスが正常に起動されなかったり、最悪、OS起動時に停止してしまい、ログインプロンプトすら出ない、という現象に遭遇した。
クラスタメンバを一斉に起動し、クラスタが正常に起動した後、何度かクラスタメンバの再起動を繰り返していると、OS起動時に、
Welcome to CentOS release 5 (Final)
Red Hat Enterprise Linux Server release 5 (Tikanga)
Press 'I' to enter interactive startup.
Setting clock (localtime): Wed Nov 7 13:27:24 JST 2007 [ OK ]
Starting udev: [ OK ]
<<略>>
Starting RPC idmapd: [ OK ]
Starting cluster:
Loading modules... DLM (built Oct 22 2007 09:34:27) installed
GFS2 (built Oct 22 2007 09:34:51) installed
done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting daemons... done
Starting fencing... done
[ OK ]
Starting system message bus: [ OK ]
Starting clvmd: dlm: got connection from 2
dlm: connecting to 1
dlm: got connection from 1
dlm: connecting to 1
[ OK ]
の部分で停止してしまう。このとき、他のクラスタメンバ上では、dlm: connecting to 3
dlm: got connection from 3
Extra connection from node 3 attempted
dlm: got connection from 3
の様なメッセージが表示される。この状態から、停止しているノードをフェンスしたり、強制再起動したりすると、今度は、
Welcome to CentOS release 5 (Final)
Red Hat Enterprise Linux Server release 5 (Tikanga)
Press 'I' to enter interactive startup.
Setting clock (localtime): Wed Nov 7 13:37:28 JST 2007 [ OK ]
Starting udev: [ OK ]
<<略>>
Starting RPC idmapd: [ OK ]
Starting cluster:
Loading modules... DLM (built Oct 22 2007 09:34:27) installed
GFS2 (built Oct 22 2007 09:34:51) installed
done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting daemons... done
Starting fencing...
ここで五分程停止する。おそらく、fencedの起動でタイムアウトまで待っているのだと思われる(/etc/init.d/cman
中のFENCED_START_TIMEOUT
の既定値は300[秒])。更にこの後、clvmdの起動に失敗する。
[ OK ]
Starting system message bus: [ OK ]
Starting clvmd: clvmd startup timed out
[FAILED]
Mounting other filesystems: [ OK ]
<<略>>
Starting Cluster Module - cluster monitor: Setting verbosity level to LogBasic
[ OK ]
Starting Cluster Service Manager: [ OK ]
Starting ricci: [ OK ]
CentOS release 5 (Final)
Kernel 2.6.18-8.1.15.el5xen on an i686
ノード3 login:
このとき、別のクラスタメンバ上では、[root@ノード2 ~]# cman_tool services type level name id state fence 0 default 00010002 FAIL_ALL_STOPPED [1 2 3] dlm 1 clvmd 00010003 FAIL_STOP_WAIT [1 2 3] dlm 1 rgmanager 00020003 FAIL_STOP_WAIT [1 2] [root@ノード2 ~]#の様になっている。正常ならば、
[root@ノード2 ~]# cman_tool services type level name id state fence 0 default 00010002 none [1 2 3] dlm 1 clvmd 00010003 none [1 2 3] dlm 1 rgmanager 00020003 none [1 2 3] [root@ノード2 ~]#のようになるはずだ。
ここから、クラスタメンバを停止しようとすると、正常に停止できない。
[root@ノード3 ~]# shutdown -h now Broadcast message from root (xvc0) (Wed Nov 7 13:50:09 2007): The system is going down for system halt NOW! INIT: Switching to runlevel: 0 INIT: Sending processes the TERM signal [root@dノード3 ~]# Shutting down Cluster Module - cluster monitor: [ OK ] Shutting down Cluster Service Manager... Waiting for services to stop:この部分で停止したままになってしまう。これは、すべてのクラスタメンバで共通の現象だ。こうなると、すべてのノードを一斉に停止・起動するしかない。
これは、サービスrgmanagerを停止中に、デーモンclurgmgrdが「Uninterruptible sleep」状態(ps(1)参照)になっていて、シグナルに応答しなくなることが原因。追求できたのはここまで。
カーネルのバージョン2.6.18-8.1.15.el5に関しては、RHSA-2007:0940-7に更新情報が記載されていて、Distributed Lock Manager(DLM)に関する修正がなされたことが解る。この修正で虫が憑いたのではないだろうか。
当面、2.6.18-8.1.14.el5で検証を行う。しかし、2.6.18-8.1.15.el5への修正は、深刻度「重要(Important)」に分類されているのが頭の痛いところだ。
2007/11/12追記:
『続・Red Hat Cluster: kernel-xenにバグか?』に情報を追加した。
追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』
2007/11/06
Red Hat Cluster: 予告編+xの補足
『Red Hat Cluster: 予告編+x』に
これはこれでいいのだが、この状態で`
この状態でマシンを再起動すると、起動時のGRUB画面で、カーネルのバージョンが表示されない、という弊害が発生する(OSは問題なく起動できる)。以下は、XenのDomUを起動したときの例:
注意深く見れば、この画面より前に
これは、当該部分を適切に修正すれば解決できる。
なお、この修正を施した状態でも、OS起動時に、
RHEL 5のマニュアルを見ながら手順通りやっても、CentOSではエラーになってしまう。と書いた。この解決策として、
原因は、/etc/redhat-release。クラスタメンバ側でこれをRHEL5だ、と詐称しなければ上手く動作しないようだ。という方法を紹介した。
これはこれでいいのだが、この状態で`
yum update
'を実行するなどしてカーネルを更新すると、/boot/grub/grub.conf
のtitle行が以下の様に二行になってしまう。
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS Red Hat Enterprise Linux Server (2.6.18-8.1.15.el5xen) root (hd0,0) kernel /vmlinuz-2.6.18-8.1.15.el5xen ro root=/dev/VolGroup00/LogVol00 console=xvc0 rhgb
この状態でマシンを再起動すると、起動時のGRUB画面で、カーネルのバージョンが表示されない、という弊害が発生する(OSは問題なく起動できる)。以下は、XenのDomUを起動したときの例:
注意深く見れば、この画面より前に
WARNING:root:Unknown image directive Redというメッセージを発見できるかもしれない。
これは、当該部分を適切に修正すれば解決できる。
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-8.1.15.el5xen)
root (hd0,0)
kernel /vmlinuz-2.6.18-8.1.15.el5xen ro root=/dev/VolGroup00/LogVol00 console=xvc0 rhgb
なお、この修正を施した状態でも、OS起動時に、
INIT: version 2.86 booting SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Welcome to CentOS release 5 (Final) Red Hat Enterprise Linux Server release 5 (Tikanga) Press 'I' to enter interactive startup. Setting clock (localtime): Tue Nov 6 18:17:59 JST 2007 [ OK ] Starting udev: [ OK ]の様に、OSの名前が二行になってしまうが、これは我慢していただきたい。
`xm create -c'でコンソールに接続できない・解決(?)編
記事『`xm create -c'でコンソールに接続できない』の解決…になっているかな、一応…という方法を発見したので、メモしておく。前の記事に、
あるいは、手元でX Windowを動かして、適当なターミナルからログインするという手もあるだろう。
ターミナルタイプがVT100(環境変数TERM=vt100
の場合など)のとき、この不具合が起こる。
と書いたのだが、だったら、これを変更すればよい、というだけ。例えば、ターミナルタイプをxtermに偽装する。つまり、# TERM=xterm xm create -c DomU名の様に実行すればよい。ターミナルがVT100互換なら、これでも大きな問題にはならないはずだ。
あるいは、手元でX Windowを動かして、適当なターミナルからログインするという手もあるだろう。
登録:
投稿 (Atom)