【ハードウェア】

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)
ESXi監視で大ハマリ (6) - DELLツールで監視(B)

最終的にはRAIDの監視ができるようにはなったのだが、洗練された監視状態とは言えない。
元々は、以下のように構成する事を狙っていた。

監視対象サーバが追加されたら、Power Edge T310 (A) 上の監視サーバの監視対象を増やして対応していくつもりだった。

しかし、ESXi を監視するためには、BMC経由にする必要があり、BMC経由にすると、今度は自分自身を監視できないため、結局、以下のように相互監視をする形にせざるを得なかった。

この場合でも、監視対象サーバが追加されたら、Power Edge T310 (A) 上の監視サーバの監視対象を増やして対応していく事になるが、Power Edge T310 (B) 上の監視サーバは、Power Edge T310 (A) を監視するためだけに稼働させることになるため、あまりきれいな構成とは言えない。

ただ…今思うと、結局のところ、「ESXi上で監視を行う」事がひじょうに面倒なだったというだけであるので、たとえば、ストレージ・サーバを1台追加して、ESXi からはNFSマウントするようにすれば、もっと簡単に構成できたかもしれない。
この場合、2台の Power Edge T310 は、ハードディスクも何も装備せず、USBメモリから起動して動くだけになる。

ストレージ・サーバを Windows や CentOS で稼働させれば、玄人志向などの安価なRAIDカードでも普通に認識して動作するだろうし、今回苦労した、物理ドライブの状態の監視も簡単にできるであろう。

もちろん、RAIDカードの信頼性や、NFSマウントでアクセスする事による速度低下などもあるだろうから、必ずしも、この構成がいいとは言えないとは思うが、少なくとも、監視そのものはひじょうに楽になる。

苦労したけど、勉強になった。
今後、この勉強できた事が生かせる時が来るといいな。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)

OpenManage Essentials が反応しない理由がまったくわからない。

仕方がないので、DELLのサポートに電話をし、やろうとしている事を説明、解決策はないか聞いてみた。
回答は…。

何ですとぉ？
SNMP経由では監視できない？
回答に書かれていた詳細な手順に従って、BIOSの設定を変更し、ESXiを再起動。

OpenManage Essentials で、設定したBMCのIPアドレスを指定、IPMIでの検出を有効にし、検出を実行してみる。

が…まったく検出されない。
SNMPでの検出では、「？」が付きながらも「VMWare ESX Servers」として検出されたが、今度は検出すらされない。
指定したIPアドレスは生きているのだろうか？

~ # ping 192.168.XXX.XXX
PING 192.168.XXX.XXX (192.168.XXX.XXX): 56 data bytes

--- 192.168.XXX.XXX ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
~ #

へ？
pingが通らない？
サーバを再起動して、BIOSの画面を出し、BMCに設定したIPアドレスを確認してみる。
間違いはない。どういう事だ？

もしかして、と思い、もう1台の T310 から ping を打ってみる。

~ # ping 192.168.XXX.XXX
PING 192.168.224.111 (192.168.XXX.XXX): 56 data bytes
64 bytes from 192.168.XXX.XXX: icmp_seq=0 ttl=64 time=0.543 ms
64 bytes from 192.168.XXX.XXX: icmp_seq=1 ttl=64 time=0.726 ms
64 bytes from 192.168.XXX.XXX: icmp_seq=2 ttl=64 time=0.667 ms

--- 192.168.XXX.XXX ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.543/0.645/0.726 ms
~ #

通った。
えー、自分自身のBMCにアクセスできない状態って事？

ハードウェアの問題なのか、ESXi のネットワークの問題なのかわからないが、ともかくも、BMC経由では「自分自身を監視できない」事がわかった。
なんだかな。

仕方がないので、もう1台の T310 にインストールしてある ESXi 上に、Windows Server 2008 R2 をインストールして監視サーバとし、OpenManage Server Administrator と OpenManage Essentials をインストール。
検出を実行してみる。

検出できた。
ただし、「VMWare ESX Servers」としてではなく、RAC（Remote Access Controller）として検出された。
どのような検出であれ、エラーを監視できるのであれば問題は無いので、気にしない事にする。

ハードウェアの情報も取得できた。

エラーは検出できるだろうか。
筐体の蓋を開けてみる。

検出できた。
アラートメールも着信した。

BMC経由では、自分自身の監視ができないようなので、2台のサーバで相互監視の形を取らざるを得ないが、監視はできる状態になった。
やれやれ。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)

DELLから提供されている、OpenManage Server Administrator および OpenManage Essentials を使用して、ESXi のアラート監視をトライしてみる事にする。

まず、ESXiには、OpenManage Server Administrator 用のVIBをインストールする。

インストールの前に、ESXi をメンテナンス・モードに切り替える必要があり、インストール後は ESXi の再起動が必要になる。

~ # esxcli software vib install -d /(path)/OM-SrvAdmin-Dell-Web-7.4.0-876.VIB-ESX55i_A00.zip

続いて、ESXi 上に Windows Server 2008 R2 をインストールし、これを監視サーバとする。

DELLのサイトから、OpenManage Server Administrator を含むISOイメージをダウンロードし、監視サーバにインストール。

問題なくインストール完了。
物理ドライブの状態、シリアルナンバーなども表示された。

OpenManage Server Administrator は、サーバの状態を表示する事はできるが、エラーを検出したらメールを発信するなどの監視機能は無い。
そこで、監視機能を持つ OpenManage Essentials をインストールする。
DELLのサイトから OpenManage Essentials をダウンロードし、監視サーバにインストール。

チュートリアルに従ってSNMPなどを初期設定。
サーバの検出を実行してみる。
が…「VMWare ESX Servers」として認識はされたものの、「？」が付いている。

ハードウェアの情報も、ほとんど取得できていない。

これでエラーを検出できる状態なのか？

OpenManage Essentials で、「管理」→「アラート」で、アラート監視を追加、電子メールを送信するように設定する。

ESXi 上から、SNMPにテスト送信を実行してみる。

~ # esxcli system snmp test

OpenManage Essentials は、まったく反応しない。
もちろん、メールも飛んでこない。

OpenManage Server Administrator で、「温度」の警告のしきい値を変更し、強制的に警告が出る状態にしてみる。

設定を変更した OpenManage Server Administrator だけでなく、vSphere Client でもエラーが検出された。
OpenManage Essentials でも検出するはずだ。

しかし、OpenManage Essentials は、まったく反応しない。

サーバの筐体の蓋を開けてみる。
OpenManage Server Administrator、vSphere Client では、サーバの筐体の蓋が開いたことが検出された。

しかし、OpenManage Essentials は、まったく反応しない。

監視サーバに、SNMPマネージャーをインストールして、SNMPの受信状態を確認してみると、アクションを起こしたタイミングで、何かを受信しているのを確認できる。

(A)は、esxcliコマンドでのテスト送信したタイミング。
(B)は、温度のしきい値を変更して、エラー状態にしたタイミング。
(C)は、温度のしきい値を元に戻し、通常の状態に回復したタイミング。
(D)は、筐体の蓋を開けたタイミング。
(E)は、筐体の蓋を閉じたタイミング。

SMNPは間違いなく何かを受信しているが、OpenManage Essentials は、まったく動作しない。
何だこれ？

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)

ESXi上で動作するコマンドで物理ドライブの状態が取得できないなら、RAIDカードのメーカが出しているサポート・ソフトウェアなどは無いだろうか。
DELLのサイトで探してみたが、それらしいツールは見当たらない。

DELL PERC 6/i は、LSI の OEM だったはず。
そうであれば、MegaRAID のコマンドを使って、S.M.A.R.T. の状態を取得できないだろうか。
LSIのサイトから MegaCli のコマンドをダウンロードして試してみる。

Find Support by Product Results - MegaCli

このブログを書いている時点では、「MegaCLI 5.5 P2」が最新版で、「VMWareMN」に対応となっているが、実際にダウンロードしてみると、このパッケージには「VMWareMN」用のプログラムは含まれていないようだ。

仕方がないので、バージョンを遡ってダウンロードし、「VMWareMN」用のプログラムを探す。
「Archived」をクリックし、上から順にダウンロードして確認していく。

幸い、一番上の「Jun 18, 2013」公開のバージョンで見つかった。
さっそくESXi上に転送して実行してみる。
が、エラー。

~ # ./MegaCli -PDList -aALL

./libstorelib.so: cannot open shared object file: No such file or directory

Exit Code: 0x01
~ #

「libstorelib.soが無い」と言っている。
更にバージョンを遡ってみても、この共有ライブラリは同梱されていない。
どうやら、この共有ライブラリは、元々は ESXi に標準でインストールされていたものであるが、ESXi 5.5 などでは標準でインストールされていないようだ。

旧バージョンの ESXi をインストールしてみれば、この共有ライブラリを取り出せると思うのだが…ちょっとめんどくさい。
IBM、日立など、ESXi 対応のサーバを販売しているサイトを探してみたところ、この共有ライブラリを同梱しているパッケージがあったので、ダウンロードして解凍し、この共有ライブラリだけを抽出させてもらう事にした。

S.M.A.R.T. の状態を取得できるか試してみる。

~ # ./MegaCli -PDList -aALL | grep "S.M.A.R.T"
Drive has flagged a S.M.A.R.T alert : No
Drive has flagged a S.M.A.R.T alert : No
~ #

取得できた。

故障した物理ドライブを特定できるか試してみる。

~ # ./MegaCli -PDList -aALL | grep "Inquiry Data:"
Inquiry Data:      WD-WMC4M2030827WDC WD20EZRX-00D8PB0                    80.00A80
Inquiry Data:      WD-WMC4M2030891WDC WD20EZRX-00D8PB0                    80.00A80
~ #

特定できた。
物理ドライブのシリアルナンバーが表示された。

このコマンドを cron などで定期的に実行するようにすれば、物理ドライブの故障を検出する事ができそうだ。
では、検出したエラーを、どうやって通知するかだが…。

ESXiには、標準で python がインストールされているので、やろうと思えばできそうな気がするが、すべてのモジュールがインストールされているわけでもないらしく、メールを送信するには、少々気合が要りそうだ。

物理ドライブの状況を取得する事はできたのだが…もう少し簡単に取得して、メールなどで通知できないものだろうか。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視

ESXi上で動作するコマンドで、物理ドライブの状態を確認できないだろうか。

ESXi 5.5 では、esxcli コマンドでできる事が充実してきている。

VMware vSphere 5.5 ドキュメント センター ≫ vSphere Command-Line Interface Reference

ストレージ関連のコマンドとして「esxcli strage」がある。

VMware vSphere 5.5 ドキュメント センター ≫ esxcli strage

とりあえず、ドライブの一覧を表示させてみる。

~ # esxcli storage core device list | grep "Display Name: Local" | sort
   Display Name: Local ATA Disk (t10.ATA_____ST340014AS______________________________3JX9AZPZ____________)
   Display Name: Local ATA Disk (t10.ATA_____ST500NM0011_________________________________________Z1M0TLLX)
   Display Name: Local DELL Disk (naa.690b11c02520ba001af38d3c0962e329)
   Display Name: Local PLDS CD-ROM (mpx.vmhba1:C0:T0:L0)
   Display Name: Local USB Direct-Access (mpx.vmhba32:C0:T0:L0)
~ #

5つのドライブが一覧された。
上から、非RAIDのATAドライブ×2台、RAIDの仮想ドライブ×1台、光学ドライブ×1台、USBドライブ（ESXiがインストールされている起動ドライブ）×1台。

「esxcli strage」には、S.M.A.R.T. の状態を表示させるコマンドがあるので、状態を表示させてみる。
まず、非RAIDの物理ドライブの状態を表示させてみる。

~ # esxcli storage core device smart get -d t10.ATA_____ST340014AS______________________________3JX9AZPZ____________
Parameter                     Value  Threshold  Worst
----------------------------  -----  ---------  -----
Health Status                 OK     N/A        N/A
Media Wearout Indicator       N/A    N/A        N/A
Write Error Count             N/A    N/A        N/A
Read Error Count              56     6          48
Power-on Hours                50     0          50
Power Cycle Count             100    20         100
Reallocated Sector Count      100    36         100
Raw Read Error Rate           56     6          48
Drive Temperature             41     0          51
Driver Rated Max Temperature  N/A    N/A        N/A
Write Sectors TOT Count       200    0          200
Read Sectors TOT Count        100    0          253
Initial Bad Block Count       N/A    N/A        N/A
~ #

S.M.A.R.T.の状態が取れた。
続いて、RAIDの仮想ドライブの状態を表示させてみる。

~ # esxcli storage core device smart get -d naa.690b11c02520ba001af38d3c0962e329
Parameter                     Value  Threshold  Worst
----------------------------  -----  ---------  -----
Health Status                 N/A    N/A        N/A
Media Wearout Indicator       N/A    N/A        N/A
Write Error Count             N/A    N/A        N/A
Read Error Count              N/A    N/A        N/A
Power-on Hours                N/A    N/A        N/A
Power Cycle Count             N/A    N/A        N/A
Reallocated Sector Count      N/A    N/A        N/A
Raw Read Error Rate           N/A    N/A        N/A
Drive Temperature             N/A    N/A        N/A
Driver Rated Max Temperature  N/A    N/A        N/A
Write Sectors TOT Count       N/A    N/A        N/A
Read Sectors TOT Count        N/A    N/A        N/A
Initial Bad Block Count       N/A    N/A        N/A
~ #

くそー、全部「N/A」だ。
仮想ドライブ配下に接続されている物理ドライブの S.M.A.R.T. の情報を一覧してくれることを期待したのだが… esxcli コマンドでは、RAID配下の物理ドライブの情報は取れないようだ。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築

さて、どうやってRAIDの状態を監視するか。

まず、ハードウェアの各種警告ランプで監視する事を考えてみる。
DELL PowerEdge T310 は、フロントパネルに状態インジケーターが装備されている。

正常な状態では青色で点灯している。

 何らかのエラーを検出すると、オレンジに変わる。

何らかのエラーが発生した事はわかるし、簡単なエラーの内容はわかる。
しかし、故障が発生したことがわかるのみで、どの物理ドライブが故障したのかといった、エラーの詳細はわからない。

フロントベゼルを開ければ、故障したドライブにはランプが点いているであろうから、故障したドライブの特定はできる。

しかし、1台の T310 は、上の写真のような、ブラケットで挿入しているが、もう1台の T310 は、普通に筐体内に固定しているだけなので、ランプでは確認できない。

また、できる事なら、エラーを検出したら、できるだけ早くそれを知りたいので、やはり、ランプの点灯状態で確認するのではなく、メールなどで通知できるようにしたい。

うまい方法はないだろうか。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート

ESXi上でRAIDを構成したのだが、その監視で大ハマリしたのでメモ。

ESXiはRAIDカードの選定がシビアだ。

ESX/ESXi をインストールするための最小システム要件 (2052813)

この資料によると、以下のカードしか認識しない。

DELL PERC（Adaptec RAID または LSI MegaRAID）
HP Smart Array RAID
IBM ServeRAID

たとえば、玄人志向などの安価なRAIDカードは認識しない。
しかし、DELL PERC 6/i をまともに購入すると、4万円強の出費が必要になる。

Dell - PERC 6/i 内臓 SAS RAID コントローラカード

ビンボー人 ずんべ には、ちょっと買えない。
この金額でデータを保護できるなら安いものだとは言えなくはないが、やはり、何とか安く購入したい。
そんな時は、ヤフオク頼みだ。
ヤフオクで検索してみると、取り外し品などがけっこう出品されている。

ヤフオク! - 「DELL PERC 6/i」の検索結果

新品の1割くらいで買える。
と、いう事で、RAIDカードはヤフオクで調達。

さっそくRAIDカードを取り付け、RAIDを構築。
ESXiを起動すると、すんなりRAID上の仮想ドライブを認識した。

RAID上の仮想ドライブにゲストOSを作成してインストールしてみるが、特に問題はない。

ここまでは順調。

しかし、ここで問題が発生した。
どうやってRAIDの状態を監視するのだろう？

一連記事：

愛車カローラフィールダーのバッテリーがそろそろ限界。
仕方がない、交換するか。

さて、どんな形で購入しようか。

(1).オートバックスやイエローハットなどで購入する。

お手軽に購入できる。
また、古いバッテリーも回収してもらえるので面倒がない。
しかし、全般的に価格は高い。

(2).通販で購入する。

購入そのものはお手軽にできる。
しかし、問題は古いバッテリーをどうするかが問題となる。
自治体でもバッテリーはごみとして回収してくれないので、どうにかして廃棄する方法を考えなければならない。
有料であれば引き取ってくれるところもあると思うのだが、有料で引き取ってもらうと、結果としてオートバックスやイエローハットなどで買うのと大差なくなってしまう。
ただし、再生バッテリーを生成している工場などに持ち込めば、無料で引き取ってくれるところもあるようだが、郵送なら送料がかかるし、持ち込みなら、当然の事ながら、そこまで持っていかなければならない。

(3).古いバッテリーを回収してくれる再生バッテリーを購入する。

たいていは、購入した商品の送料が無料か、古いバッテリーの返送が無料かどちらかの場合が多いようであるが、結果的に、これが一番安そうだ。
それに、ずんべ の会社は名古屋市のエコ事業所認定を取得していることもあって、再生バッテリーというリサイクル商品を使う事は、ぜひ推進したい。

エコ事業所認定

と、いう事で、(3)を選択する事にした。

ただ、再生バッテリーで心配なのは、やはり「新品と比べて、どのくらい早く劣化するのか」である。
一般的にリサイクルした商品というのは新品よりも高価であることが多いが、幸いにしてバッテリーは、新品よりもリサイクル品の方が安い。しかし、安いからと言って、1年やそこらで使えなくなってしまうのでは意味がない。結果としてコストが高くなってしまっては、なんにもならない。
もちろん、エコやリサイクルには元来お金がかかるものである事は承知しているが、個人で購入するにしろ、会社で購入するにしろ、かかるコストを増大させてまで、無理にエコやリサイクルをするまでの気はない。
エコやリサイクルは推進しなければいけないと言っても、やはりコストは無視できない。

ざっと再生バッテリーを販売している通販サイトを見てみると、18ヶ月保証、24ヶ月保証を謳っているところが多い。
もちろん、この保証は、正しく自動車に取り付け、正常な使用状況において、という条件は付くであろうが、そもそも、特殊な条件で使う予定はないので問題ない。
再生バッテリーを販売している店舗はいくつかあるが、こちら選択してみた。

即日発送！充電済み！◎不要バッテリー完全無料引取り処分付き 価格：1,800円（税込、送料別）

商品はすぐに到着。

バッテリー液の補充口にはテープが貼られ、端子にもテープが巻かれている。
しかも、それらのテープはすべて、端が折られていて我々がテープを剥がしやすいようになっている。
なかなか丁寧な梱包だ。

さっそく交換。

エンジンを始動。

一発でかかった。（当たり前か）

どのくらいで使えなくなるかは、実際に使ってみないとわからないが、保証期間の通り、最低でも18ヶ月は使えてほしいところだ。

このエピソードの続き。

メモリ増設で大ハマリ

社内サーバ、DELL PowerEdge T310 のメモリ関連まとめ。

DELL PowerEdge T310

このサーバは、コストパフォーマンスがよく、悪くないと思うのだが、メモリに関して言えば問題が多く、製品としては落第だと思う。
よく「サーバ機はメモリの選択がシビア」と言われることがあるが、T310の場合はシビアという問題ではない。
「サーバがメモリを選ぶ」というような問題ではなく、「ハードウェアの設計が甘い」と言わざるを得ないのである。

(1).装着できるメモリの規格に制限がある。

「メモリ増設で大ハマリ」に書いた通り。
メモリの「デバイス幅」なる規格に制約があり、メモリ幅が「x4」「x16」のメモリを装着すると、T310は起動すらしない。
しかも、この事はWEBサイトにも、ハードウェア オーナーズマニュアルにも記載されておらず、後から公開されたアップデート情報にしか記載されていない。

PowerEdge 11G T310タワーサーバの製品詳細 | Dell 日本
[PDF] ハードウェア オーナーズマニュアル
[PDF] アップデート情報 – Dell

メモリの規格の情報は使用者にとって重要なので、WEBサイトにわかりやすく表記する、ハードウェアオーナーズマニュアルを訂正する必要があるのではないか、と、DELLには申し入れをしたのだが、これらが更新された様子はない。
おそらく世界中で、このサーバのメモリの増設で苦労している人がたくさんいると思うのだが、どうしてこんな重要な情報がわかりやすい形で公開されないのだろう？

ずんべの手元にあるメモリで、T310が認識したメモリを一覧しておく。

Transcend

TS1GKR72V1N

8GB

4R×8

PC3-8500 (DDR3-1066) ECC Registered

Hynix

HMT31GR7BFR8A-G7

8GB

4R×8

PC3L-8500 (DDR3-1066) ECC Registered

Micron

MT18KSF51272PDZ-1G4D1

4GB

2R×8

PC3L-10600 (DDR3-1333) ECC Registered

SAMSUNG

M392B5273CH0

4GB

2R×8

PC3-10600 (DDR3-1333) ECC Registered

(2).装着できるメモリの組み合わせに制限がある。

T310のメモリ・スロットは6本あるが、装着できる最大メモリは32GBと非常に中途半端だ。
32GBに到達させるためには少なくとも8GBが4本必要だが、6本は装着できない。
そして、8GBと4GBを混在させた場合、スロット6本を使って32GBにできそうだが、実際に装着してみると、この組み合わせではエラーになってしまう。

ずんべが試して認識できた組み合わせを一覧しておく。

8GB×4（計32GB）
8GB×2、4GB×2（計24GB）
4GB×4（計16GB）

以下の組み合わせはエラーになってしまい、メモリを正しく認識しない。

8GB×2、4GB×4（計32GB）

スロットが6本あっても、最大の32GBにするためには8GB×4しか選択肢がない。
なんとも中途半端な設計である。

本質的には悪くないサーバだけに、残念だ。

一連記事：

このエピソードの続き。

メモリ増設で小ハマリ（しそうだった）
VMWare vCenter Converter
EASEUS Disk Copy

ビデオ・カードで小ハマリしたのでメモ。

新しいOSは何にしようか。
順当な選択肢なら、Windows 7 (x86)。

とりあえず、現状のPCのハードウェアでインストールできるか実験してみる事にする。
SSDを取り外して別のハードディスクを取り付け、Windows 7 (x86) をインストール。
インストールそのものは、何の問題もなく終了。

ディスプレイ環境を設定してみる。
ずんべのPCには、ビデオカードが2枚刺してあって、トリプル・ディスプレイになっている。

NVIDIA GeForce FX5200 PCI
NVIDIA GeForce FX5700LE PCI

Windows 7 をインストールした後、Windowsがメインのディスプレイカードとして認識した、FX5200に接続されているディスプレイにWindowsの画面が表示されている。
デバイスマネージャで確認すると、ディスプレイ・アダプターのところにビデオカード2枚が表示されているが、デバイス名（FX5200、FX5700LE）とは表示されておらず、片方には黄色の「！」マークが付いている。
アクティブな方がFX5200で、非アクティブな方がFX5700LEだろう。

NVIDIAのサイトでドライバを検索してみる。
が…FX5200、FX5700LEとも、Windows 7用のドライバが無い。
がーん。
どうやら、PCIバスのビデオカードなんていう太古の製品は、サポートするに値しないという事らしい。
くー。

何とかならないものかと、WEBを漁ってみると、FX5200のドライバは、Windows Update で提供されるらしい。
デバイス・マネージャからFX5200のプロパティを表示し、ドライバの更新を実行してみると、ドライバがインストールされ、表示が「FX5200」に変わった。
よし、認識したぞ。

次はFX5700LEだ。
同様に、デバイス・マネージャからFX5700LEのプロパティを表示し、ドライバの更新を実行してみるが、ドライバは更新されない。黄色の「！」のままだ。
FX5700LEのドライバはないようだ。

そこで、FX5700LEを強制的に認識させてみようと、デバイス・マネージャでFX5200のデバイスを削除し、OSを再起動してみた。
すると、FX5700LEに接続しているディスプレイでWindowsが起動した。
Windowsは、一応ビデオカードとしては認識しているらしい。
デバイス・マネージャで確認すると、ディスプレイ・アダプターのところにビデオカード2枚が表示されているが、デバイス名（FX5200、FX5700LE）とは表示されておらず、片方には黄色の「！」マークが付いている状態。
最初の状態と違い、アクティブな方がFX5700LE、非アクティブな方がFX5200だろう。

非アクティブなFX5200のプロパティを表示し、ドライバの更新を実行してみる。
ドライバがインストールされ、表示が「FX5200」に変わるかと思ったら…変わらない。ドライバはインストールされず、アクティブにならない。

デバイス・マネージャでFX5700LEのデバイスを削除して再起動すると、最初の状態に戻った。
FX5200がアクティブ、FX5700LEは非アクティブ。
どちらか一方しかアクティブにならない。
どうやら、Windowsの標準ドライバは、ビデオカードを2枚刺しする事は考慮されていないようだ。
これでは、トリプル・ディスプレイの環境は作れない。

そこで、ドライバがインストールできないFX5700LEは諦めることにして、手元にストックしてある NVIDIA GeForce GT340に変え、GT340とFX5200でトリプル・ディスプレイの構成をトライしてみる。
PCI-ExpressのスロットにGT340を刺し、FX5700LEを取り外す。
つまり、FX5200とGT340の2枚刺し。
Windows 7 を起動し、GT340のドライバをインストール。デバイス・マネージャにはGT340が表示された。FX5200は黄色の「！」。
続いて、FX5200のプロパティを表示し、ドライバの更新を実行してみるが…ダメだ。やはりFX5200はアクティブにならない。
PCIバスのディスプレイ・カードは使うなって事か。

結局、FX5200とFX5700LEの両方を諦め、もう1枚ビデオカードを新調する事にした。
何にしようか迷っ他のだけれど、ずんべ のPCにはPCI-Expressのスロットが2本しかないので、PCI-Expressのビデオカードにすると、スロットが埋まってしまう。
そこで、USB接続のディスプレイ・アダプタを使ってみる事にした。
これ。

価格性能比を考えると、イマイチな感じはするのだけれど、「PCI-Expressのスロットを埋めない」と考えると、選択肢はそう多くないし、別にゲームをやろうというのでもないので、そう高性能である必要もない。
USBにUSB-RGB/D2を接続し、ドライバをインストール。
無事認識し、トリプル・ディスプレイの環境が完成。

はふぅ…。