VMware-Toolsをインストールするときの諸注意を自分用にまとめ。

# yum install gcc kernel-devel kernel-headers

が必要。

そのCIFSサーバとは別ドメインに所属しているPCだったので、DNSサフィックスが異なる状況。

アクセスの簡素化を図るため、サーバ名だけでアクセス出来るように、PCが所属するドメインのDNSサーバにCIFSサーバのAレコードを書いてある。

まとめると次の通り。

・CIFSサーバ cifs.example1.com

・Windows7 PC7.example2.com

PC7は[\\cifs]でアクセスするが、実際には[\\cifs.example2.com]でアクセスすることになる。

この状態ではアクセス不可。

PC7から、[\\cifs.example1.com]だとアクセスすることが可能。

直感的にWindows7のNTLM認証レベルが高すぎる？ことが原因のように推測していますが、果たしてそれがどういう理屈で影響しているのか、ちょっと分かりません…。

ブログに書いても忘れてしまいがちなのですが、何となく書いておこうと思います。

1. 痩身
2. コミュ力
3. 計画的に、自発的に

1. 痩身

   物理的な身体の痩身、ダイエットを気を入れてやらないと成人病になってやばいので。暮らしの仕方や精神的なものも痩身していきたいと思います。

2. コミュ力

   去年から新入社員の教育担当になっていますが、これまで以上にコミュ力を成長させないとマズいと思ってます。チーム力を高めて今まで一人では出来なかったことを実現していきたいです。

3. 計画的に、自発的に

   色んなことに行き当たりばったりというか、イベントドリブンというか、自発的に動けない性質ですが、それを少しでも改めたいです。

という不具合。

解決策は[Do not upgrade.]。酷い…。

旧バージョンをアンインストールし、新バージョンを[Clean Database]でインストールすること。

パフォーマンスデータなどなど、一切消えてしまいます。これまた酷い…。

ESX410-201104001、ESX410-201107001の適用が必要とのことですが、Update 2パッチを適用すればOK。

■リリース情報
http://www.vmware.com/jp/support/support-resources/pubs/vs_pubs/vsp_esx41_u2_rel_notes.html

SFCB での整数のオーバーフローに関する問題の解決
今回のリリースで、SFCB での整数のオーバーフローに関する問題は修正されました。この問題は、 /etc/sfcb/sfcb.cfg内の httpMaxContentLength がデフォルト値から 0 に変更されると発生していました。この整数のオーバーフローにより、リモートの攻撃者が Content-Length HTTP ヘッダに大きい整数を挿入して、サービス拒否 （ヒープ メモリの破損） を発生させたり、恣意的なコードを実行したりする危険性がありました。
CVE （Common Vulnerabilities and Exposures） プロジェクト （cve.mitre.org） は、この問題を CVE-2010-2054 として公表しています。

■適用手順

1. 対象のESXホストをメンテナンスモードにする（稼動している仮想マシンはオフにするか、vMotionする必要がある）
2. ダウンロードしたupdate-from-esx4.1-4.1_update02.zipを対象のESXにSCP等でアップロードする
3. ESXのコンソールにログインする（SSH、コンソール）
4. suでroot権限を取得する
5. 2.でZIPを保存したディレクトリにcdする
6. # esxupdate –bundle update-from-esx4.1-4.1_update02.zip update を実行する
7. ずらずらーっと表示されたあと、[Succesfully]と表示されたことを確認して、ESXを再起動する
8. 再起動完了後、コンソールにログインしてsuし、# esxupdate queryを実行し、Update2が適用されているか確認する

http://www.nec.co.jp/pfsoft/vmware/vs41/ver.html#sfcb

NECのサイトだけど、分かりやすいので。

ESX4.0、ESX4.1(Update 1含む)でsfcbプロセスの動作不良により高負荷になるらしい。

先週末からあるESX上の仮想マシンのバックアップ完了時刻がいつもより大きくズレていたので注意はしていたんだけど、今日ESXがスローダウンしてしまった。

コマンドを受け付けなくなったので、強制的にリブートをかけた後でmessagesを見ているとちょうどバックアップが遅くなった日の日中にsfbcdにエラーが出ているログがあった。

パッチ適用までの間デーモンを止めておくのが無難かな。

ドメインはvalue-domainのままで、blog.gmry.netだけをさくらに転送させています。

value-domainのDNS設定で[blog]のAレコードをさくらのIPに指定して、さくらのコントロールパネルのドメイン設定で、「他社管理のドメインを移管せずに使う」で、[blog.gmry.net]を追加して完了。

移行直後はなぜか重かったですが、今は快適に動いてます。非常に軽くて、放置気味だったテーマやプラグインをいじる気になりました。

容量が半分以下になるので、ファイルを整理してパーティションサイズを縮めてコピーしました。

ThinkpadはWindows 7 Lenovo Enhanced ExperienceでWindows7の起動が元々早いので、起動時間に驚くほどの変化はありませんでした。が、VirtualBoxのマシンを起動、復元、スタンバイさせるのがかなり早くなりました。

Adobe系アプリケーションだともっと効果を感じるんだろうなあ。

思い切ってHDDの整理が出来たので良しとしよう。

XeonなのでP2V後は2CPUに設定されています。

2個も必要無いだろう、ということで何も考えずにCPUを1個に減らしました。

直後からアラートメールが飛びまくり。ホストのCPU、1コア分を食いつぶしてる様子。

以前にP2Vしたマシンで同様のことをしてもそんなことにはならなかったので、どうしたものか…とツイートしたら、ヒントをいただけました。

High CPU utilization of inactive Windows virtual machines

きちんとHAL設定しないとダメ、ってことでした。

確かにHAL見てなかったです。

Windows XP または Windows Server 2003 セットアップ後の HAL オプション

ここにあるように、WindowsXP以降では、UniプロセッサからMultiプロセッサは自動認識されHALも自動で変更されるようですが、MultiからUniへはMSもVMwareもNGのようです。

HAL、というあたりが付けられなかったあたり、コンピュータの基本的なことを分かってないな、と自覚しました…。恥ずかしい…。

で、下記の[reorder alphabetically.]にチェックを入れて[Save Changes]でOK。