05/14 に CentOS 5.5 がリリースされ、既に 2ヶ月が経過した。我が家の仮想マシン (以下 VM) の CentOS 5.x は比較的早い段階で 5.5 にアップグレードしているが、VMware Server 2.0.2 が稼動する VM 親機の CentOS は例の glibc 問題が依然として横たわっているため、glibc を 2.5-34.el5_3.1 にダウングレードした 5.4 のまま放置していた。
しかし永久にこのまま放置するわけにもいかんだろ、と言うことで、先日ついに VM 親機で yum update を敢行した。普段 glibc と nscd は yum.conf で exclude 指定してあるが、そのまま yum update してはせっかくの blog のネタがなくなるので、敢えて指定を外し、ひとまず 「普通の 5.5」 にアップグレードしている。
更新されるパッケージ数が多く、多少時間がかかったが、アップグレード自体は問題なく完了。OS を再起動後に vmware-config.pl を実行して VMware Server を起動し、テスト用の VM を 2台程起動してみる。とりあえずは普通に動いているように見えるが、この glibc 問題の症状は、正常に稼動していた VM が唐突に落ちるのだ。しばらく様子を見てみないと判断できない。
日常的に稼動するわけではない VM はサーバー監視ツール Zabbix に組み込まれていないので、適当なコマンド (例えば date) の結果を共有ストレージ上のファイルに吐くスクリプトを VM 上で毎分走らせ、VM 親機側で該当ファイルが一定時間更新されない場合に 「落ちた」 と判断するスクリプトを定期実行させる。いつ訪れるかわからない 「そのとき」 のため、ずっと管理画面 (VMware Incfastructure Client) を眺め続けるのはダルい。
VM の死亡通知は、その後 1時間程で届いた。事前にわかってはいたこととは言え少しショックを受けたが、ダメとわかれば、後はもういつもの作業だ。落ちた VM の残骸を処理後、他の VM を止めて glibc と nscd をダウングレードし、OS 再起動後に vmware-config.pl を実行する。glibc そのものは本来のバージョンを使い、VMware Server 用に古い glibc を別途用意する方法を紹介したサイトもあるが、昨年 11月の実施以来特に問題も起こっていないし、「僕は今回もこの方法でいくぜ」 と強行。
# ls
glibc-2.5-34.el5_3.1.i686.rpm
glibc-2.5-34.el5_3.1.x86_64.rpm
glibc-common-2.5-34.el5_3.1.x86_64.rpm
glibc-devel-2.5-34.el5_3.1.i386.rpm
glibc-devel-2.5-34.el5_3.1.x86_64.rpm
glibc-headers-2.5-34.el5_3.1.x86_64.rpm
nscd-2.5-34.el5_3.1.x86_64.rpm
・まとめてダウングレード
# rpm -Uvh --oldpackage *.rpm
尚、今回気が付いたが、以前 「CentOS 5.3 の最後の glibc 入手先」 として掲載した URL が、5.5 がリリースされたためか、現在は既に消滅していた。新たに RPM をダウンロードする必要がある場合は、別ページに追記したように、RPM Search で探せば見つかる。
今回 CentOS 5.x + VMware Server 2.0.x 環境における glibc 問題の再発を確認したことで、親機の都合で振り回されることがない VMware ESXi のメリットを改めて感じた。最近はまた VMware vSphere Hypervisor やら何やらの製品名と言うかサービス名と言うか、新しい名前がいくつか登場しているので、それぞれの関係と、「無償でできること」 を理解するのが大変だが・・・。
