ホーチミン市街地からハノイに向かう有料道路を車で移動中です。写真は9区の交差点。
相変わらずバイク凄いっすね。排気ガスも物凄い。
警察が交通整理してるけど、かえってそれが渋滞の元になってる気がする。(^_^;)
]]>NAVの時代から特定クライアントの更新が止まる現象というのは時折起きていたので、あぁSEPも同じか...なんて思いつつSEPMのコンソールを見てみたら、なんと全てのクライアントの更新が滞っているではないですか。
SEPM側の問題と直感的に思ったのですが、日付が12月31日というきっかり去年の末という点に直感でシステム上の問題ではないかと疑いを持ち、Symantecのサイトを漁ってみたら、ほらね、やっぱりありました。
SEP クライアントと SEPM のウイルス定義ファイルの日付が最新版に更新後も 2009/12/31 のままとなっている
http://service1.symantec.com/support/inter/entsecurityjapanesekb.nsf/jp_docid/20100105094746949?OpenDocument&dtype=corp
2009/12/31 11:59 PM より新しい日付のコンテンツが、古い定義ファイルと認識されてしまう問題が SEPM で確認されています。
（中略）
問題回避のため、シマンテックセキュリティレスポンスは SEP のセキュリティコンテンツの日付を変更せず、コンテンツのリビジョン番号のみ増やしています。シマンテックセキュリティレスポンスは、恒久対策が行われるまで、この方法を回避策として提供します。
とりあえずリビジョン番号はあげてるから問題はないという見解っぽいけど、日付が変わらないって結構問題じゃありません？ 最新版かどうかはサイト上で確認する以外ないだろうし、直感的な確認ができませんよね。
あとエンドユーザーからの問い合わせが増えるのも管理側としては面倒な話。 「定義ファイルの日付が古いままなんですけど...」「あ～それはですね...」てな会話が当面続く訳で。 彼らには日付が古くなっていたら連絡して下さいという話を常日頃しているのでそれが裏目にでちゃいます。
早く直して下さい。
雰囲気的にネットワーク周りの問題だとは思っていたけど、元々カプセル化されたものをそのまま移設しているわけだし、変わっているとしたらNICのMACくらい。 だからOpenVPNってMACに依存するの？とか悩み出してこれが深みへの入り口となりました。(^^;)
結局下のサイトさんを見つけて解決。
きのさいと - VMware/ESXi/TIPS集
http://www.masatom.in/pukiwiki/VMware/ESXi/TIPS%BD%B8/
ここにある通り、ネットワーキングのプロパティのセキュリティタブでプロミスキャスモードを許可することで解決しました。
ちなみに私の場合VMware Serverのゲストで問題なく動いていました。 その時は何もはまらず素直に動いていたのですが、ESXiにはセキュリティ設定があったんですね。 目から鱗でした。
ありがとうございました。 助かりました。m(._.)m
ESXi4だと最低2G積んでないとハイパーバイザのインストールすら拒否される。 仕方ないのでESXi3を入れることにしたんですが、インストール後起動しようとすると特定の場所で固まる問題が発生。 画面には、
Loading module ipmi_si_drv ...
と表示されている。 コンソールでAlt+F12押して起動ログを見ると、なんとなく微妙に動いているような動いていないような感じ。
ぐぐってみたら全く同じ現象に出くわしている人は多いみたい。 上の状態で１時間くらい待てばとりあえず起動はするという事だったので待ってみると、確かに１時間１０分位で起動した。 ログ見るといくつかのIPMIモジュールをロードする際に異常があるのかタイムアウトする（にしちゃ長過ぎるけど）みたいな感じ。
見た通りIPMI関係っぽいので必要ないっちゃ必要ない。 でも起動に毎回こんなに時間かかってるのではたまらない。 なのでこれを無効化してしまおうと。
適当にESXi内のファイルをあさってみたところ、/sbin/configにipmi関係のモジュールをロードする箇所を発見。 ここを編集していけばいいはず。 ちなみにESXi4の場合は/etc/vmware/init/init.d/72.ipmiみたい。
ただ単純に編集しただけだと、ホストを再起動したときに設定が初期化されてしまうので、編集したファイルをoem.tgzに放り込む必要がある。 で、以下が今回行った作業内容。
まず/sbin/configを直接じゃなく、テンポラリにコピーして編集する。 後でtarで固める時に実際の構造と同じに展開されるようにmkdirしてその中にコピーすること。
mkdir -p /tmp/oem/sbin
cd /tmp/oem/sbin
cp /sbin/config .
vi config
このファイルの中に
loadIPMI=`vsish -e get /hardware/ipmiSupport | sed 's/IPMI state: \([^ ]*\).*/\1/'`
というのがあって、これ以降数行がIPMIモジュールのロードをしている。 なので、上の行をコメントアウトして次の行でloadIPMIに0を代入する。
# loadIPMI=`vsish -e get /hardware/ipmiSupport | sed 's/IPMI state: \([^ ]*\).*/\1/'`
loadIPMI=0
これでファイルを保存したらtarして出来たファイルを/bootbankにコピーする。
cd /tmp/oem
tar cvzf oem.tgz sbin
chmod 755 oem.tgz
cp oem.tgz /bootbank/
これで起動時に/sbin/configが上書きされて、IPMIモジュールがロードされないようになる。
ESXi4でも同じ方法でいけるとおもう。 この場合72.ipmiの中をコメントアウトすればいいんではないかと。
で、これを期にという訳でもないのですが、ネットワーク環境を見直すことにしました。 回線及びプロバイダを変更します。
停止は１２月１２日の午後１時あたりから。 回復は未定ですが、恐らく半日～１日位で終わるのではないかと思います。
相変わらずバイク凄いっすね。排気ガスも物凄い。
警察が交通整理してるけど、かえってそれが渋滞の元になってる気がする。(^_^;)
]]>
って、だからなんだよみたいな。（汗）これまた全然ベトナムじゃないし。まぁたまにお買い物する店だと言うことで、思い出の１ページとさせて下さい。(^_^;)
]]>
一昨日現地人である知り合いの皆さんの協力の下、どうにかこのN82、動いてくれました。アドレスブック消失というアクシデントはありましたが…(^_^;)まぁ想定の範囲内。でもおかげで通話もネットも何不自由なくできるようになりました。有り難い事です。
只今食事にきたところです。ホーチミン1区レタントン通り、ランカスターの斜め前に構えるHCM胡蝶です。室内なのでGPSが効かず地図が出ないであろう事が残念。
一人で静かに食事したいようなお疲れモードの時は大抵ここ。店員も静かでゆっくり食事できます。
あー疲れた。さっさと食べてホテルで寝よう。
]]>
前に青歯片耳ヘッドセットは使っていたので、新鮮味は皆無。反対に不満点は幾つかありまして。
その辺の話は後で追記しましょうかね。
]]>
大昔乗った時は確かはくちょう丸っていう名前だと思ったけど、いつの間にか二代目に世代交代したんですね。
見た目的にはあまり変化ないような気がするのは気のせい？
何気なくお土産みたらさすが榛名。頭文字Dのキャラメル売ってました。笑ってしまった。
今日は天気良くて最高ですね。１日ゆっくりしていきます。(^_^)
でもこの店こんな名前じゃなかったような...いつ変わったんでしょ。
空いた時間にやるつもりなので、突然サーバー停止状態になると思います。 また停止期間を気にすることなく作業するつもりです。 DNSの伝播とかネガティブキャッシュ云々はまったく気にしないことにしてるので、どの程度の停止になるかわかりません。 経験ないしね。 まぁ長くても数日でしょう。
また復旧後も設定不備による不具合があるかもしれません。 お気づきの点等ありましたらコメントください。
追記：
とりあえず作業完了しました。
後々同様の事をするかもしれないので覚書として追記。 作業中リアルタイムでTwitterにTweetしていたのでその内容とサーバーの各種ログを織り交ぜてどんな流れだったのか調べてみた。 作業内容としては以下のとおり。
事前準備
bindの各ゾーンファイルのTTLを1時間(3600)に変更し数日放置
当日
22:25 Internic等々にネームサーバーのアドレス変更申請
22:28 DNSのフォワーダー及びゾーン設定変更
22:35 セカンダリDNS設定変更
22:40 ルーターのPPPoE設定変更＆再起動
事後処理
翌日特に問題がなさそうだったのでTTLを１日に戻した
実作業時間は１５分程度。 概ね思ったとおりの時間で作業できたのだが、１点意外だったのが全作業終了後、一番最初にアクセスが来るまでの時間。 ルーターをリセット（このタイミングでIPが変わった）してからわずか数十秒で１番目のhttpdへのアクセスが来たこと。
ルーターリセット前もアクセスが止まることはなかった。 これは作業開始前にキャッシュしていた人という事だろう。 ということは１５分以内で切り替わったことになる。 勿論作業を始める直前に名前解決した人はルーターリセット後しばらくの間は接続できなくなっていただろうけど、それもTTLを１時間にした事で遅くとも５０分後には再アクセスできるようになっていたはず。
つまり作業開始から１時間で完全に切替ができていたことになる。 TTLをもう少し短くしていれば３０分で終わったかも。
結構あっさりいくもんなんだな。 これならプロバイダ引越しもあまり苦じゃないな。 という感想でした。
Status of bl.open-whois.org: DEAD
http://www.dnsbl.com/2009/08/status-of-blopen-whoisorg-dead.html
結局直接的な原因はメールサーバーではなくDNSだったみたいな。
流れとしてはMTAが外部からメール受ける→Spamassassinが各種チェック（その中にopen-whoisチェックが含まれる）→チェックに時間かかる→その間にも同様のケースがどんどん起こる→やがてDNSがオーバーロード→やがてDNSに問合せできなくなったメールサーバーがお亡くなり、といった感じみたい。 一種のDoS的な動き。
メールサーバーの異常はとても目立つ為、当初調査する箇所を見誤った。 元々Spamassassinは入れた覚えはあっても、それが使っているサービスまで目が行き届いてなかったわけで。
改善の方法は上のリンクに書いてある通りなんだけど、私の場合は最新の72_active.cfをSpamassassinのリポジトリから落としてきました。
そのうちバージョンアップ時に対応するみたいだけど、同様の事象に出くわしている方がいたらご確認下さい。
で、折角ESXi4.0に移行したので、新機能であるシンプロビジョニングとやらを試してみたいと。 いや実は大してゲスト作ってない割にはディスクが厳しくなってまして、新規にゲスト作る都度ディスクの割当に悩むみたいな状況でして。 この機能を使えば物理的な拡張（≒出金）を少し先延ばしにできるんじゃないかと。
勿論パフォーマンスが低下するのは見えてますが、ディスクガリガリなサーバーじゃなければさほど問題ではないでしょうし、その辺は使い分ければいい訳で。 そもそもVMware Serverなんかではこっちがデフォだったような...とはいえあれは2gbsparseっぽかったですが。
今回は既にESXi3で構築したゲストをコンバートする方向でやってみました。 以下がやった方法。
]]> 対象ゲストのシャットダウンまず対象となるゲストをシャットダウンします。 これは普通にvSphere ClientからやればOK。
この作業は私はsshで入ってやりました。 別にunsupportedで入ってもいいですし、Remote CLIとかでもできるのかな？（未確認）
でシェルに入ったら、対象となるゲストのイメージが格納されているディレクトリにcdします。 例えばcd /vmfs/volumes/datastore1/target/って感じ。
そしたら次のコマンドでコンバートします。 イタリック部分は適宜置き換え。
vmkfstools -i target.vmdk -d thin target_thin.vmdk
コンバートっていうかクローニングなんですけどね。（汗） ちなみに開始直後、以下のメッセージが出るのでやろうとしていることは間違えないのではないかと。
Destination disk format: VMFS thin-provisioned
仮想ディスクのサイズによって所要時間はまちまちですが、普通結構かかると思います。 進行状況がパーセンテージで出てるのでおとなしく待ちます。
続いてvSphere Client上でインベントリから旧仮想ディスクを削除します。 対象ゲストのサマリタブにある「設定の編集」をクリックして、仮想ディスクを選択、削除ボタンをクリックです。
この時上の表示の右側に下のようなものが見えると思いますが、
「仮想マシンから削除」を選んだ状態であれば、仮想ディスクの実体（.vmdkファイルそのもの）は削除されません。 完全に移行できたことを確認してから削除したほうがいいでしょうね。 古い実体があればいつでも元に戻せますし。
上で削除したらそのまま先ほど作成した仮想ディスクを追加していきます。 追加ボタンをクリックして、「ハードディスク」を選択→次へ、「既存の仮想ディスクを使用」→次へ、と進んだら参照ボタンをクリックしてファイルを選択します。（上の例で作ったファイルだとtarget_thin.vmdk）
あとはそのまま次へで突き進んでいけば追加は終わります。
これで一通りの作業は完了となります。
とりあえずゲストがちゃんと動作することを確認した後で、リソースの状況を確認してみました。
プロビジョニングしたディスクのサイズは30Gですが、実質使っているサイズは6Gちょっとに減っています。 当然データストアの未使用領域もその分増えてます。
ちなみにvmkfstoolsのパラメーター変えれば元に戻すこともいつだってできるので、やってみてパフォーマンス激落ちとか感じたら元に戻す作業をもう一度すれば良いだけです。
よかった。 これでもう少しゲストが作れそうです。
2009-07-09追記：
シンプロビジョニングにした状態で、以前書いたバックアップ処理がうまく動作するか検証してみたら、どうもthinからmonosparseへのクローニングはthickからmonosparseよりパフォーマンスが上みたいです。 というか未使用領域のスキップが速い感じ。
毎週末ゲストOSをcronで自動バックアップしてますが、処理時間短縮してくれそうです。 これも嬉しい結果。
例年（でもないか？）この季節になると送っていただけるのですが、今年のはとても甘くて美味しかったです。(^_^) ここまで甘いのは過去になかったかも。
いつもありがとうございます。ご馳走様でした。