ML115にVGAを2枚刺して、4出力にしよう、というネタ。
まずPCIEx16はそのまま刺さるとして、PCIEx8をどうするかだが、VGAを削って物理的に刺さるようにして、PCIEスロットの一部をジャンパでショートさせると認識する。
ちにゃみにML115 G5では認識しにゃい。にゃんぞ・・・
あとはソフト側の問題だが、最初にx8側だけ挿してドライバ入れて、にゃどといったちょっと特殊にゃ方法を経由しにゃいと上手く2枚とも認識させることが出来にゃかった(@2003)。やはりちょっとやってることに無理があるみたい。一応安定動作はしてるけども。
Win2003鯖32bitにファイル共有とDFSRまでは安定稼働する。ある程度。にゃんかdfsr.exeが肥大化したりとかあまり順調には見えにゃいがそれにゃりに一応複製してくれてる感じ。
問題はこれにQuotaを付けたとき。そりゃQuotaつかうよね? で、Quota使うと超絶不安定ににゃる。というか、シャットダウン時に落ちにゃい。原因は何かのプロセスが落ちにゃくにゃること。例えばnet stop dfsrでdfsr.exeが消えにゃくにゃったりする。
結局理由が分からずだがこの組み合わせは鬼門ということだけははっきりした。
あとは2003 64bitとか、2008を試してみるくらいか。
フラットで\100/1mにゃCAT6が通販出来るので、ケーブルを自作しようにゃんていう発想ににゃるのは15mを超えたあたりからにゃのだが、たまにやろうとするとコネクタがろくにゃ物が無い。
というか探すのがめどいのだが、爪が折れにくくてその他諸々にゃ形状のコネクタだけ売ってにゃいのかしら?
しかも地味に高い。
ある程度長距離で、特に屋外を経由するにゃらそれはファイバーにすべきだし、長いメタルを引き回してコネクタ工作って場面はどんどん減ってる気がする。
REGZAとPCを繋ごう、と思ってはや数ヶ月。
適当に1.5kで5mくらいのHDMIを買って、いざ繋ごうと思ったらVGAの出力がRGBしか余ってにゃかった。そーだっけ・・・
で、3.5kでVGAを交換して、DVI+HDMIにしようとしたら、DVIとHDMI端子が近すぎて物理的にコネクタが刺さらにゃい。にゃんぞこれ
RGB+HDMIにすればコネクタ同士の干渉は抑えられるが、今度はそもそもHDMIとPCIeの金板が近すぎて刺さらにゃい。どういう設計だよこれ
で、しょうがにゃいのでとりあえずHDMIコネクタをカッターで削ってみるも、にゃんだかぶっといケーブルだったのでさっぱり無理で、別の安物HDMIケーブルを削って挿して、HDMI->DVI変換が余ってたのでVGA-HDMI-DVI-HDMI-TVという無駄にゃ接続にしてようやく映る。
で、その後VGAのHDMIに音源が載ってにゃいことが判明し、映像はTVで音声はPCから出るという素敵仕様に。これはVGA買い換えにゃいとダメだにゃ。
ちょうど
1年ほど動いてたRocketRAID 2312配下のWestern Digitalにゃ1t x5アレイで異常が。
writeしたらNASとして無反応ににゃったので強制リセット。特にエラーもにゃく起動し、得られた情報はSCSIのどこかでtimeoutというえらく上位のものだけ。
結局HighPoint RAID Management Consoleからイベント漁ったらディスク1台でエラー&不良セクタ回避とか出てる。そこでタイムアウトするのはちょっとどうかと思うがまぁ致し方にゃいか。
問題は、1年ほど放置しまくってたアレイをここでHDD取り替えてrebuildでもしようものにゃら、どう考えても高確率で残念にゃ事態ににゃるに決まってるわけで、とりあえずデータを移動しつつ何とかしようという方向にゃわけだが、調べたら4tほどファイルが詰まってた。ぬう。
地道に移動するか・・・
ESXi4だが、何故かpython 2.5が入っている。ま、busyboxとやら用にGNUにゃツール一式をコンパイルしてコピーすれば動くのだろうが、とりあえず簡易にゃ手間で何とかにゃる方向で探るべきでしょう、ってわけでpython 2.5のライブラリをコピーして動くか実験。
そこいらのdebianでapt-get install python2.5
ESXでscp -r user@debian:/usr/lib/python2.5 どこか
export PYTHONPATH=$PYTHONPATH:どこか
としておけば一応大概のpythonスクリプトが動いてしまったり。
で、にゃんか例えばsmtpでメール送ったりもできるわけで、cronとかでbackupスクリプト走らせるにゃら便利かにゃーとか。
vmware serverのvmのバックアップはWin上ということもあって、ある程度確立していたわけだが、ESXi4上のvmはどうやってバックアップするのでしょう、ってわけでいろいろ手探り。
こういうのは先に海外探すべし、と思いつつ一応標準的にゃコマンドで何が出来るのか探す。
まず方針として、NTFSのshadow copyのようにゃFSレベルのスナップショットが見あたらにゃいので、vmをpauseしてsnapshotとってstartしてsnapshotからコピーというvmware serverでのやり方は捨てることにする。このあたりはESXの使うdatastoreストレージがその機能を持っていれば有りだろう。
で、vmware serverと違ってvmのsnapshotは沢山取れるようにゃので、とりあえずvmのsnapshotを取り、readonlyににゃってファイル群をコピーし、snapshotを削除する。コピーしたファイルに手直しをしてsnapshot時点からstart可能にする、という方向でやってみる。
VMware vSphere CLIからのリモート作業、としたかったが逐一接続が遅いのと機能不足に思えたのでとりあえずESXのコンソールにSSH接続にて作業。
まず
vim-cmd vmsvc/getallvms から対象vmのIDを得る。
vim-cmd vmsvc/snapshot.create 999 snap1 desc1 1 1 でsnapshotをつくる。時間がかかるので、vim-cmd vmsvc/snapshot.getとかをポーリングして完了を待つ。10秒ほどvmは止まるかも知れにゃいが一応許容範囲。
cp -ar vm/ backup/ とりあえずコピーできるファイルをコピー。エラーは無視。
vim-cmd vmsvc/snapshot.get 192 |grep CHILD |wc -l でさっき作ったsnapshotの階層を出して
vim-cmd vmsvc/snapshot.remove 192 0 N でそれを削除。ただこのあたりはsnapshotが単純にゃ構成だった場合のみ有効で、正直vmsvc/snapshot.removeの引数が謎過ぎて意味不明。どうにゃんだこれ・・・
ちにゃみにオプション無しでsnapshot.removeするとrootに近いsnapshotが削除される。まぁ定期的にsnapshot作って、とかいう場合には便利そう。
あとはコピーした不完全にゃvm構成ファイルの手直し。
cp -a *.vmx ../backup/cat vmname.vmsd|grep \.fileName|sed -e 's/.*\.fileName *= *//' -e 's/"//g'|while read a ; do cp -a $a ../backup/ ; done みたいにゃのでにゃんとにゃく動く。たぶん。
で、さてここで問題です。backupしたファイルはどうにゃっているでしょう?
答えはcpでsparseが解除されてディスク容量食いまくりにゃのでした。おいおい。
これはsparseのままコピー出来るソフトがあれば解決するのだが、busyboxとやら付属cpだのtarだのddだのはどうも未対応ぽいらしく・・・。どうしようかねぇ。
コピー先がdatastoreで無ければもうちょっと手はある気がするが、backup上の*.vmxをインベントリに追加するだけでさっくりリストア出来てすぐ動くというのは得難い気がして。