インストール自体は全く問題なく可能。

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

# yum install gcc kernel-devel kernel-headers

が必要。

vCenter Server fails when upgrading from VirtualCenter 2.0.2 to vCenter Server 2.5 on a Japanese locale with SQL Server 2005

という不具合。

解決策は[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にエラーが出ているログがあった。

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

Windows Server 2003なマシンをP2Vしました。

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

新規提供開始は日本時間で8/23（土）

既存SnSユーザのアップグレードは8/27（水）

vCenter連携をすると、管理ツールからエージェントの配置ができる。

が、エージェントがIP Reachableにならないと配置に失敗してしまう。エージェントがDHCPでIPアドレスの取得ができる環境でないとダメな様子。

DHCPで配布されたIPアドレスでエージェントを設定してしまうと、手動で変更するのが面倒（管理ツールでの登録が外れる）になるので、エージェントはOVFファイルからインポートする方法をオススメします。

タイトルの通り、Windows2000ドメインのメンバサーバとなっているWindows Server 2008 R2上にvCenter 4.1 update 1をインストールする時、2008R2にパッチ適用しないと失敗します。

ここに書いてある通りです。

Installing vCenter Server 4.1 on a Windows 2008 R2 system fails

Symptoms

• Cannot install vCenter Server 4.1 on a Windows 2008 R2 system
• Installing vCenter Server 4.1 on a Windows 2008 R2 system fails
• You see on of these errors:
• • The trust relationship between this workstation and the primary domain failed in the jointool-0.log
  • Setup cannot create vCenter Server directory Services Instance

Resolution

This issue may occur if the Active Directory in your environment is hosted by a Windows 2000 domain controller. This issue occurs because vCenter Server 4.1 is unable to retrieve the security identifier (SID) for an account.

To resolve this issue, you must apply the x64-based version of a Microsoft hotfix. For more information and to download the hotfix, see the Microsoft Knowledge Base article 976494.

Note: You must reboot the system before installing vCenter Server again.

上記にあるようにKB976494のパッチ適用が必要です。

パッチはリンク先のフォームからメールアドレスを登録すると、ダウンロードリンクと解凍パスワードが送られてくるので、それで。

適用後、再起動するとインストールが出来ました。

リリースされたので早速インストール。

vCenterは64bitOSが必要になったので、プリインストールの2008R2をそのまま利用することにした。

hpのG7はPOSTの画面がスタイリッシュになってて驚いた。ちょっと見にくいけど、気分が上がった。

SmartStartを使ってインストールしたサーバと比べてプリインストールのOSの方が、きびきび動いているような気がする。

TFT7600に繋いでるけど、ワイド画面に対応していないので綺麗に表示されない。困ったもんだ。

<環境>

• UPS APC Smart-UPS
• ESX vSphere4

<必要な手順>

1. ESX側にPCNSをインストールする
2. UPSにESX(PCNS)を登録する
3. ESXに稼働中のゲストOSをシャットダウンするスクリプトを設置する
4. PCNSのシャットダウン時に実行されるスクリプトに先のスクリプトを指定する

<以下格闘の記録>

非HA環境の場合は、ESXのシャットダウン時にゲストOSは連動してシャットダウンされるが、HA環境の場合、ESXの停止がUPSからのシャットダウンなのかホスト障害による停止なのか判別がつかずもう一方のESXにゲストOSをHAしてしまう。

それを回避するため、UPS交換からのシャットダウン指示の場合は、稼働中のゲストOSをシャットダウンしESXを停止するような設定（スクリプト）が必要となる。

現在のところ、PCNSのv2.2.4（最新版）はvSphereのESX,ESXiの 4.0.0 update 1までの対応。ESX,ESXi 4.0.0 update2及び、最新のESX,ESXi 4.1には未対応。

2010/11/02追記

上記の取り消し部分について追記。

2010/10/29付の対応OS表によると4.1および4.0.0 update2に対応したとのこと。ESX、ESXi双方が対応。しかもESXi向けにVIMA用カスタムインストールスクリプトまで用意された。時間が無いので未検証だが、これで一応ESXiでもPCNSが利用出来ることになった。

ここで、ESXとESXiの場合の設定が異なることについてメモ。

ESXにはServiceConsole(COS)があるので、そこにPCNS(ESX版)をインストールする。ESXiにはCOSがないのでVIMA(vMA)という仮想アプライアンスを稼働させ、そこにPCNS(ESXi版）をインストールする。

つまりUPSからのシャットダウンシグナルを前者は直接ESXが受け取り、後者ではVIMA(vMA)が受け取ることになる。

シグナル受信後の振る舞いはPCNSの設定に依存する。通常はShutdown Configurationでシャットダウン時に実行するスクリプトを指定し、Configuration EventsでOn Battery等のイベント時にシャットダウンするよう設定しておく。

設定するスクリプトについてはAPCがサンプルをWEBに公開しているが、一部修正しないと動かなかった。

情報共有のために書いておく。

stopVMs.pl : ESX Server上で稼動しているゲストOSを確認しShutdownを行う。
——
#
# stop running VMs
#
$vmwarecmd = "/usr/bin/vmware-cmd";
# enumerate all VMs
@configs = `$vmwarecmd -l`;
chomp(@configs);
# stop VM if its running
foreach $config (@configs) {
$isalive = `$vmwarecmd "$config" getstate`;
chomp($isalive);
if ($isalive =~ /=.on/) {
print "Stopping $confign";
$retval = `$vmwarecmd "$config" stop`;

$retval = `$vmwarecmd "$config" stop soft`;

}
}
——
stopHAs.sh : stopVMsの呼び出し用シェルスクリプト。
——
/usr/bin/perl /usr/local/bin/PowerChute/stopVMs.pl

——

vmware-cmdの仮想マシンの停止を行うコマンドで、stop soft(=シャットダウン）するように明示しないといけない模様。

stopHAs.shをPCNSのShutdown Scriptで指定してやれば、UPSからの信号受信時にスクリプトが実行され稼働中のゲストOSが停止する。

動作確認がとれているのはESXのみだが、同様の理屈でESXi（VIMA(vMA)）でも稼働するはず…なのだが、VIMA(vMA)がUPSからのシャットダウン信号を受信してもシャットダウンがかからない、という状況。

結果的にはESXiでの実装を諦め、ESXでの実装に切替えた。

VMware、及びAPCから正式なドキュメントが出ていない状況なので、しばらくESXiの実装は避けようと思う。