Skip navigation
2012

新年早々、こんな KB 見つけました。

 

Performance history for Past Year may contain only 30 days of information in vSphere 5.1
http://kb.vmware.com/kb/2042164

 


KB を見た限りでは、vCenter 5.1 のパフォーマンス情報が30日分しか残らなそうに見えます。

DB のストアドプロシージャのロジック(の不具合?)で
30日を超えたパフォーマンス情報はパージされてしまうらしく、past year(年単位の) ビューを見ると気づけるようです。

 

vCenter 5.1、5.1a、5.1b いずれでもまだ問題は修正されていないようです。

 

また、

Product Version(s):
VMware vCenter Server 5.1.x

だけなので、vCenter 5.0 以前には関係ないはずです。

 

vCenter Operations のようなvCenter 自身の過去情報に頼らないモニタリング製品を
導入している環境では問題ないと思いますが、

vCenter のモニタリング情報を頼りにしている現場では要注意(定期的にKBを確認するなど)だと思います。

※この記事をポストした時点では、KB の更新日は2012年12月29日でした。

 

以上、今日の気づきでした。


補足

vCenter 5.1 U1a では修正されたようです。

それ以前のリリースの場合も、ストアドプロシージャの再作成で修正できます。

VMware KB: Performance history for Past Year contains only 30 days of information in VMware vCenter Server 5.1

ためしに、ESXiのホスト名をコマンドで変更してみようと思います。

 

下記のように変更してみます。

 

変更前: esxi02 (ドメインなし)

変更後: esxi102.test.local

ホスト名を  ~02 から ~102 に変更し、ドメイン名もつけてみます。

 

ESXiのホスト名は esxcli で変更できます。
せっかくなので、リモートのサーバ(vMA)から esxcli を実行してみようと思います。

ESXiにログインして直接 esxcli を実行するときは、「--server」や

ユーザ/パスワード指定は不要になります。

 

vMA から esxcli でホスト名変更

 

まず、vMA に SSH で接続します。

Last login: Sun Dec 16 12:25:12 2012 from 192.168.0.2
Welcome to vMA

vi-admin@localhost:~> export VI_USERNAME=root
vi-admin@localhost:~> export VI_PASSWORD=*****
  ★esxcliでは、事前にユーザ/パスワードを環境変数で設定しておくことができます。

 

今の設定を確認します。

 

ホスト名を変更する ESXi ホストの IP アドレス(192.168.5.62)を指定しています。

事前にユーザ名とパスワードは環境変数として設定してあるため入力不要になっています。

vi-admin@localhost:~> esxcli --server 192.168.5.62 system hostname get
   Domain Name:
   Fully Qualified Domain Name: esxi02
   Host Name: esxi02

 

esxcli コマンドでホスト名を変更します。

vi-admin@localhost:~> esxcli --server 192.168.5.62 system hostname set --domain="test.local" --host="esxi102"

 

esxcli コマンドでホスト名を確認します。変更は、即座に反映されます。

vi-admin@localhost:~> esxcli --server 192.168.5.62 system hostname get
   Domain Name: test.local
   Fully Qualified Domain Name: esxi102.test.local
   Host Name: esxi102

 

 

ESXi 側で確認

 

ESXiに直接SSHでログインし、設定を確認してみました。

~ # vmware -v
VMware ESXi 5.1.0 build-799733 ★ためしたESXiのバージョンは5.1です。

~ # hostname
esxi102.test.local ★ホスト名がちゃんと反映されてる。

~ # uname -n
esxi102.test.local

~ # cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1             localhost.localdomain localhost
192.168.5.62    esxi102.test.local esxi102 ★hostsファイルも自動更新されていた。

 

以上、ESXiのホスト名変更でした。

vCenter 5.1 のインストール ベストプラクティスの記事を見つけました。

 

Installing vCenter Server 5.1 best practices
http://kb.vmware.com/kb/2021202


が、内容的には、ほぼインストールマニュアルの要約となっています。

KBの中に表示されているSliderocketのスライド(これも英語)の中身は
そのKBに書かれている内容と同じです。
 

インストールマニュアル

 

VMware vSphere のドキュメント(リリース 5.1 を選択すること)
http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs

 

vSphere のインストールとセットアップ ガイド(PDF版)
http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-installation-setup-guide.pdf
日本語マニュアルだと P.195~306 あたりの約110ページに相当します。

 

英語をとるか、

ページ数の多いマニュアルを取るか…

 

ただし、マニュアルには
実際は表が含まれていたり、トラブルシュートだったりするので
すべて読まなくても大丈夫なはず。

 

しかし一度はざっと眺めておきたいものです。

 

 

ということで、
慣れないvCenter 5.1 への取り組み方についてです。

 

  1. まずは一度、vCenter5.1を「Simple Install」でインストールしてみて
    感覚をつかんでからインストールマニュアルを読む。
    とりあえずVMなどにインストールしてみたほうがよいです。
    WebClientも忘れずにインストールします。
    (vCenter5.1~の新機能は、基本的にWebClientからじゃないと使用できないです)


  2. 最初の1読目は、マニュアルのタイトルだけ読んでいく。
    1回読んで完全理解するのは、絶対無理なので
    タイトル以外の部分は一応眺めておき、
    どこに何が(というよりどんなキーワードが)書いてあるのかを、ざっと見ておく。


  3. 小規模のvCenter1台構成(SSOやWebClientを全部1サーバにインストール)であれば
    vCenter関連コンポーネント(特にSSOとか)の仕組みを
    そんなに気にしなくて良いはずなので、ひとまず読み飛ばす。


  4. (Adobe Readerの場合限定ですが)
    マニュアルのPDF検索するときは
    「Ctrl + F」 ではなく 「Ctrl + Shift + F」 で検索して
    関係ありそうなところを並べて見られるようにする。


  5. vCenterをインストールするときは、バグを避けるため
    最新版(この時点だと vCenter Server 5.1.0b のはず)を使用する。
    vCenter5.1 に限っては、5.0以前とくらべて仕組みが大きく変わったので
    少しでもバグ修正されている方が安心だと思います。

 

などでしょうか。

半分はvCenter関係ないところですが・・・

地味にスナップショットのサイズ確認をするKBを見つけました。

スナップショットを削除しているときの様子を確認できます。


Commands to monitor snapshot deletion in ESX 2.5/3.x/4.x and ESXi 3.x.x/4.x.x/5.x
http://kb.vmware.com/kb/1007566

 

 

ためしにスナップショットを削除して見てみました。環境は、ESXi 5.1 です。


lsコマンドで見ているだけだとVMDKの見た目のサイズは変わらず
「-delta.vmdk」がなくなることで、どのファイルまで適用されたかがわかります。
たとえば、「-000002-delta.vmdk」の適用が完了すると「-000002-delta.vmdk」が削除されます。

 


方法1: lsコマンドをwatchコマンドでループ実行する。

 

この方法では、数秒ごとに最新の状態だけが画面に表示されます。

 

lsコマンドでwin2008sv1というVMの構成ファイルを表示し、

「grep -E "delta|flat"」でスナップショットに関係あるファイルだけフィルタ表示しています。

watch -n 10 を付けると指定した秒数ごとに画面が更新されます。デフォルトは2秒ごとです。

 

終了するときは、 Ctrl + C を押します。

~ # watch -n 10 'ls -luth /vmfs/volumes/datastore1/win2008sv1 | grep -E "delta|flat"'


Every 10s: ls -luth /vmfs/volumes/datastore1/win2008sv1 | grep -E "delta|flat"

-rw-------    1 root     root         7.5G Dec 24 09:10 win2008sv1-000001-delta.vmdk
-rw-------    1 root     root        32.1M Dec 24 09:10 win2008sv1-000002-delta.vmdk
-rw-------    1 root     root        40.0G Dec 24 09:09 win2008sv1-flat.vmdk

 

(10秒ごとに画面更新)


Every 10s: ls -luth /vmfs/volumes/datastore1/win2008sv1 | grep -E "delta|flat"
-rw-------    1 root     root         7.5G Dec 24 09:11 win2008sv1-000001-delta.vmdk
-rw-------    1 root     root        32.1M Dec 24 09:10 win2008sv1-000002-delta.vmdk
-rw-------    1 root     root        40.0G Dec 24 09:09 win2008sv1-flat.vmdk

 

(10秒ごとに画面更新)

 

Every 10s: ls -luth /vmfs/volumes/datastore1/win2008sv1 | grep -E "delta|flat"

-rw-------    1 root     root        32.1M Dec 24 09:11 win2008sv1-000002-delta.vmdk
-rw-------    1 root     root         7.5G Dec 24 09:11 win2008sv1-000001-delta.vmdk
-rw-------    1 root     root        40.0G Dec 24 09:09 win2008sv1-flat.vmdk

 

 

方法2: lsコマンドをwhileでループ実行する。

 

「while true」で、lsコマンドを無限ループしています。

この方法だと、これまでの表示結果も画面上に残ります。

head -10 を付けると、最初の10ファイルだけ表示されます。
sleep 3 で、表示間隔(秒)を指定しています。

こちらも終了するときは、 Ctrl + C を押します。

~ # while true;do date;ls -lt /vmfs/volumes/datastore1/win2008sv1/*vmdk |head -10;echo ________;sleep 3;done
Mon Dec 24 08:48:17 UTC 2012
-rw-------    1 root     root           16863232 Dec 24 08:48 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
-rw-------    1 root     root        42949672960 Dec 24 08:46 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk
-rw-------    1 root     root                344 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002.vmdk
-rw-------    1 root     root                530 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1.vmdk
-rw-------    1 root     root         8069926912 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
-rw-------    1 root     root                337 Oct 14 13:21 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001.vmdk
________
Mon Dec 24 08:48:21 UTC 2012
-rw-------    1 root     root           16863232 Dec 24 08:48 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
-rw-------    1 root     root        42949672960 Dec 24 08:46 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk
-rw-------    1 root     root                344 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002.vmdk
-rw-------    1 root     root                530 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1.vmdk
-rw-------    1 root     root         8069926912 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
-rw-------    1 root     root                337 Oct 14 13:21 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001.vmdk
________
Mon Dec 24 08:48:24 UTC 2012
-rw-------    1 root     root           16863232 Dec 24 08:48 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
-rw-------    1 root     root        42949672960 Dec 24 08:46 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk
-rw-------    1 root     root                344 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002.vmdk
-rw-------    1 root     root                530 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1.vmdk
-rw-------    1 root     root         8069926912 Dec 24 08:45 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
-rw-------    1 root     root                337 Oct 14 13:21 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001.vmdk
________

 

 

lsだけだとわかりにくいので、

ついでに duコマンド でも試してみました。
もとのVMDKにどんどん適用されていく様子が見えます。(サイズが増加していく)

※たぶんThin形式だから見えています。Thick形式だと固定サイズになりそうです。

 

方法1-2: duコマンドをwatchで実行

 

~ # watch 'du /vmfs/volumes/datastore1/win2008sv1/*vmdk | grep -E "delta|flat"'


Every 2s: du /vmfs/volumes/datastore1/win2008sv1/*vmdk | grep -E "delta|flat"

7881728 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
17408 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
14405632 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk

 

(画面更新)

 

Every 2s: du /vmfs/volumes/datastore1/win2008sv1/*vmdk | grep -E "delta|flat"

7881728 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
17408 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
14416896 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk

 

(画面更新)

 

Every 2s: du /vmfs/volumes/datastore1/win2008sv1/*vmdk | grep -E "delta|flat"

7881728 /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
17408   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
14426112        /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk

 

方法2-2: duコマンドをwhileで実行

~ # while true;do date;du -h /vmfs/volumes/datastore1/win2008sv1/*vmdk |head -10;echo ________;sleep 30;done
Mon Dec 24 08:56:23 UTC 2012
7.5G    /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
64.0k   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001.vmdk
17.0M   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
0       /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002.vmdk
14.3G   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk
64.0k   /vmfs/volumes/datastore1/win2008sv1/win2008sv1.vmdk
________
Mon Dec 24 08:56:53 UTC 2012
7.5G    /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
64.0k   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001.vmdk
17.0M   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
0       /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002.vmdk
14.5G   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk
64.0k   /vmfs/volumes/datastore1/win2008sv1/win2008sv1.vmdk
________
Mon Dec 24 08:57:24 UTC 2012
7.5G    /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001-delta.vmdk
64.0k   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000001.vmdk
17.0M   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002-delta.vmdk
0       /vmfs/volumes/datastore1/win2008sv1/win2008sv1-000002.vmdk
14.6G   /vmfs/volumes/datastore1/win2008sv1/win2008sv1-flat.vmdk
64.0k   /vmfs/volumes/datastore1/win2008sv1/win2008sv1.vmdk
________

 

すべてのスナップショットを削除すると、

最終的には.vmdkと、-flat.vmdk だけが残ります。

 


以上、スナップショットのモニタリングでした。

サポートされていないLinuxOSをインストールしたVMの

仮想マシン(仮想ハードウェア)のバージョンを 8 から vmx-09 にバージョンアップしたところ、

運悪くOSが起動できなくなってしまいました。(OS起動途中でpanicになったり・・・)

 

そこで、あえて
「仮想マシンバージョンのバージョンダウン」 をやってみました。

例では、「vm1」というVMを使用しています。

 

※VMware的には、おそらくサポートされないはずなので、
 自己責任 & どうしてもというときだけ実行するようにしましょう。

 


1. まず、VM設定ファイル (.vmxファイル)を編集します。

 

vi で設定ファイルを編集しています。

~ # vi /vmfs/volumes/datastore1/vm1/vm1.vmx
virtualHW.version = "9"

virtualHW.version = "8"


2. 既存のVMを登録解除します。

うまくいった場合は、とくに何も表示されません。

~ # vim-cmd vmsvc/unregister /vmfs/volumes/datastore1/vm1/vm1.vmx
~ #

 

3. 設定編集したvmxファイルで、VMを再登録します。


うまくいくと、数字が表示されます。
この数字は内部的に使用されるVMの名前で、毎回変わります。(下の例だと81です)

~ # vim-cmd solo/registervm /vmfs/volumes/datastore1/vm1/vm1.vmx
81

 

ちなみに、すでに登録されているVMを重複登録しようとすると、
下記のようなエラーが出ます。

そのため、vmxを登録するときは、既存のVMを登録解除してから登録する必要があります。

~ # vim-cmd solo/registervm /vmfs/volumes/datastore1/vm1/vm1.vmx
(vim.fault.AlreadyExists) {
dynamicType = <unset>,
faultCause = (vmodl.MethodFault) null,
name = "81",
msg = "The specified key, name, or identifier already exists.",
}

 


登録後のVMをvSphere Client等で確認すると、
バージョンが 8 に戻っているはずです。

 

この後、VMを起動したら問題なく起動できました。

VMの登録解除や再登録は、データストアブラウザ経由でもOKだと思います。

 

 

以上、むりやり仮想マシンバージョンを下げる方法でした。

今回も、前回、前々回の記事の続きで vCenter SSO のKB紹介です。

 

前回、前々回同様、

下記の記事でピックアップされているSSO関連KBを見ています。

 

Where is the Best Practice Guide for SSO?
http://blogs.vmware.com/kb/2012/12/where-is-the-best-practice-guide-for-sso.html

 

 

今回は、最後に

SSOの高可用性機能と、「じつはvCenterSSOではない」ものです。

 

 

SSOの高可用性機能


vCenterSSOがもつ高可用性機能についてのKBを

ピックアップしてみました。

SSO自体が、複数台でアクティブ/アクティブで動作することができるようですが、

難易度高めな気がします。

 

Configuring vCenter Single Sign On for High Availability
http://kb.vmware.com/kb/2033588
※SSOをHAモードでインストールします。

 

Setting up Apache load balancing software with vCenter Single Sign On
http://kb.vmware.com/kb/2034157

※そして、Apacheで処理を分散します。

mod_proxy (mod_proxy_balancer)を使うつもりのようです。

 

Updating SSL certificates for vCenter Single Sign On servers behind a load balancer
http://kb.vmware.com/kb/2034181

※ そしてSSL証明書の入れ替えも必要になります。

 

Cannot install high-availability backup node after you change the SSL certificate for vCenter Single Sign On
http://kb.vmware.com/kb/2034069

 

 

 

「じつはvCenterSSOではない」もの


これ以降は、参考にした記事にはピックアップされていたのですが
別製品(vCenter用ではないSSO)についてのKBのようです。
vCenter SSO をインストールするときは、基本的に読まなくて良いはずです。

 

Socialcast 等もシングルサインオン(SSO)をするのですが、

これはvCenterとは直接関係ない、別のSSO機能です。

 

SSOが一般IT用語(VMware用語ではなく)なのでややこしいと思います。

「SSO」がvCenter Single Sign On を指しているかどうかは、

KBの対象が、(KB画面の右はじあたり)が

  • Product(s):
    VMware vCenter Server
  • Product Version(s):
    VMware vCenter Server 5.1.x

となっているかを確認するとよいです。

 


Configuring an Active Directory Federation Services Relying Party for use with Socialcast Single Sign On
http://kb.vmware.com/kb/2035246

 

Enabling or disabling Single Sign On flow in Socialcast On Premise
http://kb.vmware.com/kb/2035248

 

Single Sign On (SSO) Occasionally Fails When Using Passwords with Fewer than Six Characters
http://kb.vmware.com/kb/1003772

 

Verifying the Single Sign On flow before activation in Socialcast On Premise
http://kb.vmware.com/kb/2035253

 

Signing in via Single Sign On in Socialcast fails with the error: Unable to decrypt the assertion
http://kb.vmware.com/kb/2035832

 

Using existing SSL certificates in PingFederate for Socialcast On Premise Single Sign On
http://kb.vmware.com/kb/2035372

 

Troubleshooting issues with Single Sign On in a VMware View environment
http://kb.vmware.com/kb/1029391

 

Single sign on does not work when connecting from View Portal on Mac OS to a Terminal Server desktop back end
http://kb.vmware.com/kb/1007583

 

Single Sign On does not work over PCoIP when connecting to a Windows Vista Desktop
http://kb.vmware.com/kb/1019466

 

Single Sign On (SSO) does not work with Windows virtual machines over PCoIP when interactive logon messages are enabled in a group policy
http://kb.vmware.com/kb/1018819

 

Single sign on (SSO) does not work correctly when the HP RGS display protocol is used to connect
http://kb.vmware.com/kb/1011492

 

 

以上、SSOのKBピックアップでした。

前回のポストの続きです。

 

前回: vCenterSSOベストプラクティスのかわりに。

こんな記事を見つけました。

 

Where is the Best Practice Guide for SSO?
http://blogs.vmware.com/kb/2012/12/where-is-the-best-practice-guide-for-sso.html

上記の記事から、トラブルシュート系のものをピックアップしてみました。

量が多いので実際にトラブルに当たった時に読むことになりそうです。

 

★は、特に読んでおいたほうがよさそうと思ったものにつけてあります。

 

 

トラブルシュート系

 

Adding a vCenter Single Sign On Active Directory Identity Source fails with the LDAP error: The server requires binds to turn on integrity checking
http://kb.vmware.com/kb/2035934

 

Troubleshooting Single Sign On and Active Directory domain authentication with the vCenter Server Appliance
http://kb.vmware.com/kb/2033742

 

Troubleshooting Single Sign On with the vCenter Server Appliance configuration on an external database
http://kb.vmware.com/kb/2033624

 

Troubleshooting the configuration of vCenter Single Sign On within the vCenter Server 5.1 Appliance
http://kb.vmware.com/kb/2033152

 

Troubleshooting the vCenter Server Appliance with Single Sign On login
http://kb.vmware.com/kb/2033338

 

Troubleshooting vCenter Server Appliance configuration with an external vCenter Single Sign On server
http://kb.vmware.com/kb/2033737

 

Resetting an expired password in VMware Single Sign On (SSO)★
http://kb.vmware.com/kb/2035864

期限切れパスワードのリセットについてです。

 

Unlocking and resetting the vCenter Single Sign On (SSO) administrator password★
http://kb.vmware.com/kb/2034608

SSO自身がもつ管理者ユーザのパスワードリセットについてです。

 

Troubleshooting Single Sign On (SSO) issues in vCenter Server 5.1★
http://kb.vmware.com/kb/2033137

 

Troubleshooting Single Sign On based vSphere Web Client 5.0.x login errors
http://kb.vmware.com/kb/2033253

 

Troubleshooting Single Sign On on a Windows Installation★
http://kb.vmware.com/kb/2033208

 

Troubleshooting SSL certificate updates and Single Sign On★
http://kb.vmware.com/kb/2033240

 

Troubleshooting vCenter Single Sign On installations which fail with: Error 29114. Cannot connect to DB
http://kb.vmware.com/kb/2035831

 

Troubleshooting vCenter Single Sign On when it does not start★
http://kb.vmware.com/kb/2034517

 

Installing Single Sign On fails with the error 20010: Failed to Configure LookupService
http://kb.vmware.com/kb/2038086

 

Installing Single Sign On fails with the error: Error 29115 Cannot authenticate to DB
http://kb.vmware.com/kb/2035449

Installing vCenter Single Sign On fails with error: Unable to create database schema: Invalid filegroup ‘RSA_INDEX’
http://kb.vmware.com/kb/2036318

 

Installing vCenter Single Sign On fails with the error: Error 20010: Failed to configure LookupService
http://kb.vmware.com/kb/2036497

 

Installing vCenter Single Sign On fails with the error: Unable to create database users: Password validation failed
http://kb.vmware.com/kb/2035949

 

Installing vCenter Single Sign On in an IPv6 environment fails with the error: Error 29114.Cannot connect to database
http://kb.vmware.com/kb/2035454

 

Installing vCenter Single Sign On on the Oracle database fails with the error: Failed to access configuration database
http://kb.vmware.com/kb/2036656

 

Adding vCenter Single Sign On Identity Source fails with the error: Unable to detect baseDN
http://kb.vmware.com/kb/2037365

 

After making a change or restarting Single Sign On server system, vCenter Server 5.1.x fails to start★
http://kb.vmware.com/kb/2036170

 

After updating SSL certificate for vCenter Single Sign On,  a newly installed instance of vCenter Server fails to start★
http://kb.vmware.com/kb/2033215

 

Logon in VSM 9.x is not evaluating new login info entered when Single Sign On (SSO) is enabled
http://kb.vmware.com/kb/2019835

 

Navigating to the Log Browser after updating vSphere 5.1 Single Sign On Certificates fails with an Unauthorized Access error
http://kb.vmware.com/kb/2037927

Log Browser というのは、「vSphere Web Client」というvCenterコンポーネントに含まれる機能です。

 

Registering vCenter Orchestrator with a vCenter Single Sign On server which contains a large number of groups might cause issues
http://kb.vmware.com/kb/2039478

 

Logging into vCenter Orchestrator with vCenter Single Sign On fails if the System Domain is not in the list of Default Domains
http://kb.vmware.com/kb/2039317

 

Unable to delete a user or group from a vCenter Single Sign On (SSO) group
http://kb.vmware.com/kb/2037102

 

vCenter Single Sign On (SSO) does not autodiscover trusted domains if domains are manually added
http://kb.vmware.com/kb/2036320

 

vCenter Single Sign On and dependent services fail to start after you reboot the system
http://kb.vmware.com/kb/2032749

 

vCenter Single Sign On fails at start up or during initialization
http://kb.vmware.com/kb/2033164

 

vCenter Single Sign On fails to connect to a Microsoft SQL instance
http://kb.vmware.com/kb/2039092

 

vCenter Single Sign On installer reports the error: Error 29155.Identity source discovery error
http://kb.vmware.com/kb/2034374

 

VMware VirtualCenter Single Sign On and Lookup services fail to start after upgrading to vCenter Server 5.1
http://kb.vmware.com/kb/2041528

 

vSphere 5.1 Single Sign On (SSO) installation fails with error: Error 29133. Administrator login error.
http://kb.vmware.com/kb/2035820

 

 

もとにしたブログの記事には、

View Manager(仮想デスクトップ関連)のものや

Socialcast(ソーシャルコミュニケーション関連)のものも含まれていたので、

それは除外しています。

 

以上、SSOのトラブルシュート系KBでした。(もう少しつづく)

こんな記事を見つけました。

 

Where is the Best Practice Guide for SSO?
http://blogs.vmware.com/kb/2012/12/where-is-the-best-practice-guide-for-sso.html


(上記の記事が書かれた 2012/12/19 時点で)
「vCenter Single Sign On」(SSO) については、
VMware社のベストプラクティスガイドがありません。

この時点でKBが65もあるが、これを一つにまとめるのは微妙、ということのようです。

 

vCenter5.1からは SSOのインストールが必須になっているのですが、
情報を集めるのが大変です。

 

そこで記事から、これはと思うものをピックアップしてみました。

★は、特に読んでおいたほうがよさそうと思ったものにつけてあります。

 

 

インストール前に、必ず読んでおいたほうがよさそうなもの。

 

Comparing the behavior of vCenter Single Sign On with earlier versions of vCenter Server★

http://kb.vmware.com/kb/2032135

vCenter5.0のころとの違いについてです。

 

vCenter Single Sign On FAQ★
http://kb.vmware.com/kb/2034918

 

Single Sign On installation details matrix★
http://kb.vmware.com/kb/2036922

vCenterコンポーネント(SSOふくむ)はバラバラのサーバにインストールすることが可能です。

さまざまな構成ごとに、どうインストールしたらよいかがマトリクスになっています。

 

Location of Single Sign On log files for vCenter Server 5.1★
http://kb.vmware.com/kb/2033430

エラーログファイルの出力先がまとめられています。

 

Backup and restore the vCenter Single Sign On (SSO) configuration★
http://kb.vmware.com/kb/2034928

SSOのバックアップリストアについてです。

「Single Sign On バックアップバンドル」の取り方、戻し方が説明されています。

 

Installing vCenter Single Sign On in a multisite deployment
http://kb.vmware.com/kb/2034074

SSOをどこにインストールするか決めるときの考え方が書かれています。

1台のサーバにvCenterコンポーネント全部インストールする場合は

あまり気にしなくてもよいと思います。

 

Identifying the vCenter Single Sign On server deployment mode
http://kb.vmware.com/kb/2035817

上の「~multisite deployment」と一緒に読んでおくとよいと思います。

たいていの場合、「Basic」でよいと思います。

 

 

インストール前に読んでおいたほうがよさそうなもの(設定の注意点など)

 

Configuring and troubleshooting vCenter Single Sign On password and lockout policies for accounts
http://kb.vmware.com/kb/2033823

 

Enabling Single Sign On with Anonymous Access to the Customer Portal
http://kb.vmware.com/kb/2004545

 

Exporting and importing for manual Single Sign On (SSO) replication in VMware vCenter Server 5.1.x
http://kb.vmware.com/kb/2038677

 

 

追加設定系(必要であれば・・・VSA、LDAP認証など)

Configuring vCenter Single Sign On database connectivity with the vCenter Server Appliance
http://kb.vmware.com/kb/2033829

 

Update vCenter Single Sign On settings after you change the host name or port of the database server
http://kb.vmware.com/kb/2033516

 

Single Sign On installation for non-English upgrade of vCenter Server
http://kb.vmware.com/kb/2037976

 

Configuring a vCenter Single Sign On Identity Source using LDAP with SSL (LDAPS)
http://kb.vmware.com/kb/2041378

 

 

以上、とりあえず大事そうなものをピックアップしてみました。(つづく)

壊れた ESXi を修復してみました。

 

ある日、気が付いたらvSphere Clientにエラーが表示されていました。

ESXiのストレージ障害のようです。


(しっかりしたUSBにインストールしていないESXiは、わりと頻繁に障害が発生します。)

esxi_dev_error1.png

ちなみに、私の環境では

  • ESXiはUSBメモリにインストール
  • データストアはローカルディスクに作成

しています。

 

今回バックアップ・リストアしたのは

ESXi 5.1 ですが、ESX 5.0 でも同じ感じだと思います。

壊れたのは、ESXi の部分なので、そこだけ再インストールします。

 


1.ESXiのバックアップ


まず、必ず再起動する前にESXi構成情報のバックアップを取得しておきます。
※再起動すると現在のramfs上の設定情報が消えてしまいます。

※この時リソースプールの情報も一緒に記録しておいたほうがよさそうです。(メモ帳とかに)

 

今回はvMAからバックアップを取得しています。

vSphereCLI(esxcfg-cfgbackup.pl)が入っていれば、vMAでなくてもOKです。

コマンドラインは、Windows版のesxcfg-cfgbackupでも同じはずです。

vi-admin@localhost:~/work> esxcfg-cfgbackup --save --server=192.168.0.244 --username=root esxi51_backup_20121216.tar.gz
Enter password:  ★パスワードを入力
Saving firmware configuration to esxi51_backup_20121216.tar.gz ...

vi-admin@localhost:~/work> ls -l esxi51_backup_20121216.tar.gz ★作成されたバックアップファイルを確認
-rw------- 1 vi-admin root 24227 2012-12-16 12:27 esxi51_backup_20121216.tar.gz

  • --save は 「設定を保存する」。
  • --server には、ESXiのIPアドレスを指定。
  • 最後の~tar.gz がバックアップファイル名

です。

 


2.一応、ESXiを再起動してみた


(期待通り?)一部の構成情報がおかしくなっています。

とりあえず、気づいた症状は下記です。

  • 削除されたはずのVMが復活している。
    ただしVMDKは存在しないので、「Unknown 2 (アクセス不可)」 などとなっている。
  • 新規作成したVMが見えなくなっている。(当然VMDKは存在する)
  • 作成した仮想スイッチ、ポートグループが消滅している
  • リソースプールが削除されている。

 

問題がある領域は、VMが配置されているVMFS領域ではなく
ESXiがインストールされている領域(下記の青い部分)だけなので
VMFSはそのまま、ESXiだけ再インストールして復旧します。

~ # fdisk -l

***
*** The fdisk command is deprecated: fdisk does not handle GPT partitions. Please use partedUtil
***

Found valid GPT with protective MBR; using GPT

Disk /dev/disks/mpx.vmhba32:C0:T0:L0: 31266816 sectors, 29.8M ★こわれたのは、USB部分(ちなみに32MBです)
Logical sector size: 512
Disk identifier (GUID): 225c42d9-dd3b-4e2d-8060-ec33d1d6114c
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 31266782

Number Start (sector) End (sector) Size Code Name
1 64 8191 8128 0700
5 8224 520191 499K 0700
6 520224 1032191 499K 0700
7 1032224 1257471 219K 0700
8 1257504 1843199 571K 0700
Found valid GPT with protective MBR; using GPT  ★ここから下のデータストア部分は無事そう

Disk /dev/disks/t10.ATA_____WDC_WD5000AAKX2D753CA1________________________WD2DWMAYUU525859: 976773168 sectors, 931M
Logical sector size: 512
Disk identifier (GUID): 8f0a54d6-f554-4353-84f7-8d0f064df6f0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       976768064        931M   0700
~ #

 

3. ESXiの再インストール

 

無償版のESXiハイパーバイザだと

VMが乗っている状態で esxcfg-cfgbackup リストアができないようなので
一度 ESXi を再インストールして、設定をリストアします。

 

もともとESXiがインストールされていた領域に、ESXiを再インストールします。
このとき、VMFSの領域にインストールしないように注意します。

(データストアのVMはそのままにしておきたいため)

 

再インストール後、IPアドレスだけは設定しておきます。

 

 

4. ESXi 設定情報のリストア

 

実行すると、自動的にESXiがメンテナンスモードになり、再起動されます。

再起動を待って、vSphere Clientで接続して環境が復旧したことを確認します。

 

バックアップで使用した esxcfg-cfgbackup コマンドに --load をつけることで、

設定のリストアになります。

ここでもvMAからコマンド実行していますが、vSphereCLIが入っていればどこからでもOKです。

vi-admin@localhost:~/work> esxcfg-cfgbackup --load --force --server=192.168.0.244 --username=root esxi51_backup_20121216.tar.gz
Enter password: ★パスワードを入力
The restore operation will reboot the host.
Type 'yes' to continue:
yes  ★「yes」と入力する。
Uploading config bundle to configBundle.tgz ...
Performing restore ...
vi-admin@localhost:~/work>  →自動的にESXiは再起動される。

 

 

5. リストアの結果

 

リストア後の環境を確認したところ、下記のような感じでした。(気づいたものだけですが)

 

  • ライセンス情報もリストアされた。
  • リソースプールは復旧されなかった。
    →ただのリソース制限情報なので、作成しなおしでも復旧はできる。
    →エラーが発生したら、リソースプールの設定を控えておいたほうがよさそう。
  • 仮想スイッチ設定、ポートグループ設定は復旧した。
  • VMの登録情報は復旧した。
    (バックアップ所得時に削除していたものは消えていて、
    作成されていたものは登録された状態)

 

 

以上、ESXiのバックアップ、リストアについての話でした。

ESXi の esxcli による時刻設定について試してみました。

 

ESXi には、Linux などと同様に

  • ソフトウェアクロック(ESXi の時刻設定)
  • ハードウェアクロック(HW での時刻設定)

があります。


両方の設定を esxcli で変更してみます。
わかりやすくするために、日付だけ別の値を指定して変更します。

 

 

現在時刻の確認。バージョンは ESXi 5.1 です。
(もともと、ちょっと時計がずれてました。)

~ # vmware -v
VMware ESXi 5.1.0 build-799733

~ # date
Sat Dec 15 14:34:32 UTC 2012

~ # esxcli hardware clock get
2012-12-15T14:35:22Z

~ # esxcli system time get
2012-12-15T14:34:44Z


まずは、system time set コマンドでの時間設定変更。
ハードウェア、システム両方の設定が変更されました。

~ # esxcli system time set --year=2012 --month=12 --day=15 --hour=01 --min=30 --sec=01
~ # date
Sat Dec 15 01:30:05 UTC 2012
~ # esxcli hardware clock get
2012-12-15T01:30:13Z
~ # esxcli system time get
2012-12-15T01:30:18Z


次は、hardware clock set での設定変更。
時刻設定を、日付だけ「16日」に変更しています。

 

結果、ハードウェアクロックだけ設定変更されました。

ソフトウェアクロックはそのままで、date の結果もそのまま(ソフトウェアクロックを見るため)です。

~ # esxcli hardware clock set --year=2012 --month=12 --day=16 --hour=01 --min=30 --sec=01
~ # date
Sat Dec 15 01:30:50 UTC 2012
~ # esxcli hardware clock get
2012-12-16T01:30:10Z
~ # esxcli system time get
2012-12-15T01:30:59Z

 

もう一度、system time set コマンドでの時間設定変更(再確認)してみます。

先ほどのコマンドから、日付だけ「14日」に変更しています。

やっぱり、ハードウェア、ソフトウェア両方のクロックが変更されました。

~ # esxcli system time set --year=2012 --month=12 --day=14 --hour=01 --min=30 --sec=01
~ # date
Fri Dec 14 01:30:05 UTC 2012
~ # esxcli hardware clock get
2012-12-14T01:30:10Z
~ # esxcli system time get
2012-12-14T01:30:15Z

 

試した結果

  • system time set は、ソフト/ハード全体の時計設定変更
  • hardware clock set は、ハードウェアだけ設定変更

するようです。

 

ちなみに、時刻設定のオプションは

-y 2012 -M 12 -d 16 -H 01 -m 30 -s 01

といった感じで短縮することもできます。

 

以上、ESXi の時刻設定でした。

esxcli でCPU情報を見てみました。

 

 

物理CPUの情報は、ソケット数やコア数、NUMAノード情報や
ハイパースレッディングの有効/無効まで見ることができます。

 

※ESXi 5.0 / 5.1 どちらも同様に見ることができます。

 

 

まず、AMD Athlon II を見てみました。

1ソケット2コア、AMDなので、当然ハイパースレッディングは無しです。

~ # esxcli hardware cpu list

CPU:0
   Id: 0
   Package Id: 0 ★パッケージ(=ソケット)がわかる。
   Family: 16
   Model: 6
   Type: 0
   Stepping: 3
   Brand: AuthenticAMD ★AMDです。
   Core Speed: 1297838400
   Bus Speed: 199667417
   APIC ID: 0x0
   Node: 0 ★NUMAノードがわかる
   L2 Cache Size: 1048576
   L2 Cache Associativity: 16
   L2 Cache Line Size: 64
   L2 Cache CPU Count: 1
   L3 Cache Size: -1
   L3 Cache Associativity: -1
   L3 Cache Line Size: -1
   L3 Cache CPU Count: 1

CPU:1
   Id: 1
   Package Id: 0
   Family: 16
   Model: 6
   Type: 0
   Stepping: 3
   Brand: AuthenticAMD
   Core Speed: 1297838400
   Bus Speed: 199667417
   APIC ID: 0x1
   Node: 0
   L2 Cache Size: 1048576
   L2 Cache Associativity: 16
   L2 Cache Line Size: 64
   L2 Cache CPU Count: 1
   L3 Cache Size: -1
   L3 Cache Associativity: -1
   L3 Cache Line Size: -1
   L3 Cache CPU Count: 1


~ # esxcli hardware cpu global get
   CPU Packages: 2
   CPU Cores: 2
   CPU Threads: 2
   Hyperthreading Active: false
   Hyperthreading Supported: false ★ハイパースレッディング使えません
   Hyperthreading Enabled: true ★これがTRUEでも、HWが対応していない。
   HV Support: 3
   HV Replay Capable: false
   HV Replay Disabled Reasons: incompatible CPU

 

 

Intel Core i7 を見てみました。

1ソケット4コア、ハイパースレッディングは有効です。

~ # esxcli hardware cpu list
CPU:0
   Id: 0
   Package Id: 0
   Family: 6
   Model: 58
   Type: 0
   Stepping: 9
   Brand: GenuineIntel
   Core Speed: 3392294127
   Bus Speed: 99773329
   APIC ID: 0x0
   Node: 0
   L2 Cache Size: 262144
   L2 Cache Associativity: 8
   L2 Cache Line Size: 64
   L2 Cache CPU Count: 2
   L3 Cache Size: 8388608
L3 Cache Associativity: 16
   L3 Cache Line Size: 64
   L3 Cache CPU Count: 2

(途中省略。)

CPU:7
   Id: 7
   Package Id: 0 ★4コアCPUなので、「CPU:7」でもパッケージIDは0(1つ目)。
   Family: 6
   Model: 58
   Type: 0
   Stepping: 9
   Brand: GenuineIntel
   Core Speed: 3392294127
   Bus Speed: 99773329
   APIC ID: 0x7
   Node: 0
   L2 Cache Size: 262144
   L2 Cache Associativity: 8
   L2 Cache Line Size: 64
   L2 Cache CPU Count: 2
   L3 Cache Size: 8388608
   L3 Cache Associativity: 16
   L3 Cache Line Size: 64
   L3 Cache CPU Count: 2

 

~ # esxcli hardware cpu global get
   CPU Packages: 1
   CPU Cores: 4    ★物理コア数
   CPU Threads: 8 ★ハイパースレッドにより、物理コアの倍にみえる。
   Hyperthreading Active: true ★ハイパースレッディング有効です。
   Hyperthreading Supported: true
   Hyperthreading Enabled: true
   HV Support: 3
   HV Replay Capable: true
   HV Replay Disabled Reasons:

 


esxcli、結構CPU情報がわかります。

 

 

以上、今日の気づきでした。

esxcli は、esxcfg-* などのコマンド群にかわる、

最近のESXiの メイン管理コマンドです。

 

※従来通り、esxcfg-*などの管理コマンドも、まだ ESXi 5.x では利用可能です。

 

 

地味な話ですが、esxcli にもバージョンがあります。

 

 

たとえば、ESXi 5.0 には、esxcli 5.0 が入っています。

~ # vmware -l
VMware ESXi 5.0.0 Update 1

 

~ # esxcli system version get   ★ESXi のバージョンを表示。

   Product: VMware ESXi
   Version: 5.0.0
   Build: Releasebuild-623860
   Update: 1

 

~ # esxcli --version   ★esxcli のバージョン表示。
Script 'esxcli' version: 5.0

 

ESXi 5.1 には、esxcli 5.1 が入っています。

~ # esxcli system version get
   Product: VMware ESXi
   Version: 5.1.0
   Build: Releasebuild-799733
   Update: 0

 

~ # esxcli --version
Script 'esxcli' version: 5.1.0

 

 

esxcli もバージョンアップにともない、できることが増えています。

 

こんな記事を見つけました。

What’s New In ESXCLI 5.1

http://blogs.vmware.com/vsphere/2012/09/whats-new-in-esxcli-5-1-2.html

 

 

たとえば、esxcli 5.1 からは

ESXi のシャットダウン/再起動 や、

SNMP設定もできるようになりました。

 

 

5.0 ではできなかったシャットダウンが

~ # esxcli --version
Script 'esxcli' version: 5.0
~ # esxcli system shutdown poweroff --reason="test"
Error: Unknown command or namespace system shutdown poweroff
                     ★5.0 には shutdown コマンドがない。

 

5.1 ではできるようになりました。

~ # esxcli --version
Script 'esxcli' version: 5.1.0
~ # esxcli system shutdown poweroff --reason="test"
System is not in maintenance mode. Cannot perform requested
                     ★メンテナンスモードにしわすれた。

~ # esxcli system maintenanceMode set --enable=true  ★メンテナンスモードにする。
~ # esxcli system maintenanceMode get
Enabled    ★メンテナンスメードが有効になった。
~ # esxcli system shutdown poweroff --reason="test"
                            ★このあとESXi はシャットダウンされる。

 

以上、esxcli の話でした。

この記事をみて知ったのですが、

 

VMware APIs and SDK support

http://blogs.vmware.com/kb/2012/12/vmware-apis-and-sdk-support.html

 

vSphere Web Services SDK や PowerCLI に対するサポートサービスがあるようです。

 

 

VMware SDK Support Program
for vSphere APIs, SDKs, PowerCLI

https://www.vmware.com/support/services/sdk.html

 

 

ターゲットとしているのは、

大規模な環境をスクリプト自動化で管理している組織だったり(クラウド事業者などのこと?)、

vSphereと連携するソフトウェアを開発する会社などのようです。

 

 

当然、代わりにプログラミングしてくれたりはしないようですが、

「SDKでこんなことできますか?」

「動かしてみたらこんな動きしますがバグですか?」

「スクリプトつくったけど性能でないんですよ」

的なことが聞けたりするみたいです。

 

 

結構需要ありそうなきがするのですが、

やっぱり英語だけですかね・・・

以前にポストした、ESXi Syslog の JST での受信について試してみました。

 

この設定を、実際に試してみようと思います。

図解 ESXi のsyslogを日本標準時(JST)受信する方法

 

ESXi の Syslog を日本時間(JST)で出力してみます。

今回も、rsyslog を使用します。説明中の Syslog サーバ は rsyslog のことです。

ESXi 5.0 を使っていますが、ESXi 5.1 でも変わりません。

 


1.  まず、ESXi の Syslog を、Syslog サーバに転送しておきます。

 

手順については、こちらを参考にしてください

ESXi 5.x で Syslog 転送。rsyslogで受信。

 

ESXi 側で設定したSyslog 設定の戻し方は、こちらです。

ESXi 5.x Syslog 設定のリセットコマンド

 

 

2.Syslog サーバ側のログフォーマットの設定を変更してみます。

 

rsyslog の設定ファイルを編集します。

[root@oel62 ~]# vi /etc/rsyslog.conf

下記3行を、ファイルの末尾に追記します。
※実際に運用する環境では、もっと設定のカスタマイズが必要です。

$template TsTest1, "%timestamp%, %msg%\n"
$template LogFileName1,"/var/log/%hostname%/%programname%_%$year%_%$month%_%$day%.log"
*.* ?LogFileName1;TsTest1


Syslog サーバ再起動時のエラー抑止のため、下記のファイルも編集しておきます。

[root@oel62 ~]# vi /etc/sysconfig/rsyslog

 

変更箇所は下記の1行です。

 

SYSLOGD_OPTIONS="-c 4 -r"
↓(「-r」を削除)
SYSLOGD_OPTIONS="-c 4"

 

3. Syslog サーバ(rsyslog)を再起動します。

 

[root@oel62 ~]# service rsyslog restart
システムロガーを停止中:                                    [  OK  ]
システムロガーを起動中:                                    [  OK  ]

 

rsyslog を再起動して少し待つと、今回のサンプルでは、

/var/log/<ESXiのホスト名>

ディレクトリに

プログラム名_年_月_日.log」 というログファイルができます。

[root@oel62 esxi01.local]# pwd
/var/log/esxi01.local

[root@oel62 esxi01.local]# ls
Hostd_2012_12_03.log    Vpxa_2012_12_03.log    vmkernel_2012_12_03.log

 

 

4.  ESXi 側で、テストメッセージを出力します。

 

★テスト1

ESXi 側での時刻をログに表示するため、`date` を入れています。

赤いタイムスタンプが、ESXi 側でSyslog送付時にコマンドで取得したタイムスタンプです。

一方、

青いタイムスタンプが、Syslogによって出力されたタイムスタンプです。

(ESXi 側でテストメッセージを送信)

~ # esxcli system syslog mark --message="TestMsg01 `date`"


(Syslogサーバ側)
[root@oel62 esxi01.local]# ls
Hostd_2012_12_03.log  Vpxa_2012_12_03.log  mark_2012_12_03.log 

shell_2012_12_03.log  vmkernel_2012_12_03.log

 

[root@oel62 esxi01.local]# cat mark_2012_12_03.log
Dec  2 22:46:22,  TestMsg01 Sun Dec  2 22:46:20 UTC 2012


★テスト2

ログが発生した時刻ではなく、Syslog サーバが受信した時刻を出力します。

テスト1の設定ファイルの、下記(赤字)を変更ます。

 

$template TsTest1, "%timegenerated%, %msg%\n"
$template LogFileName1,"/var/log/%hostname%/%programname%_%$year%_%$month%_%$day%.log"
*.* ?LogFileName1;TsTest1

 

Syslog サーバ側でファイル編集後に rsyslogd を再起動し、
ESXi 側からログ出力のテストをします。

~ # esxcli system syslog mark --message="TestMsg02 `date`"


★テスト3

受信したログを、RFC3339 形式で時刻を出力します。

テスト2 とは、ログファイルの出力フォーマットが変更されます。

テスト1の設定ファイルの、下記(赤字)を変更ます。

$template TsTest1, "%timegenerated:::date-rfc3339%, %msg%\n"
$template LogFileName1,"/var/log/%hostname%/%programname%_%$year%_%$month%_%$day%.log"
*.* ?LogFileName1;TsTest1

 

Syslogサーバ側でファイル編集後にrsyslogdを再起動し、
ESXi側からログ出力のテストをします。

~ # esxcli system syslog mark --message="TestMsg03 `date`"

 

5. 結果確認

 

ログファイルへの出力結果を見てみます。

[root@oel62 esxi01.local]# cat mark_2012_12_03.log
Dec  2 22:46:22,  TestMsg01 Sun Dec  2 22:46:20 UTC 2012  ★テスト1の出力
Dec  3 07:48:05,  TestMsg02 Sun Dec  2 22:48:55 UTC 2012  ★テスト2の出力
2012-12-03T07:50:11.564731+09:00,  TestMsg03 Sun Dec  2 22:51:01 UTC 2012  ★テスト3の出力

 

JST で出力できました。

上記の例では、

 

日本時間だと、12/3 07:48

協定世界時だと、12/2 22:48

ぐらいとなっています。

 

TestMsg02、TestMsg03 として出力したログは、先頭のタイムスタンプが日本時間になっています。

今回は、ESXi と Syslog サーバ(rsyslog)とで

ログ出力時間を JST に合わせる方法を説明します。

 

ESXi で Syslog サーバにログ転送した場合、

ESXi 側が協定世界時(UTC)で、Syslog サーバ側が日本標準時(JST)設定だと、

Syslog サーバ側のログファイルに2種類のタイムスタンプをもつログが出力されてしまいます。

syslog1.png

 

たとえば現在、日本時間で19:00だったとします。

この時、JST 設定のサーバと、ESXi とで、

Syslog サーバのログファイルのタイムスタンプにズレが発生します。

 

  • ESXi から受信したログは、UTC で 10:00 と出力される。
  • ESXi 以外から受信したログファイルは、19:00と出力される。

    (地域設定が日本としてある、Syslog サーバ自身のログや、Linux サーバなど)

syslog2.png

こういった場合、ログ受信する Syslog サーバが rsyslog であれば、

ログのタイムスタンプをすべて日本時間(JST)に合わせることが可能です。

 

rsyslog は、だいぶ前から UNIX / Linux で使われている Syslog の後継とされる

Syslog サーバソフトウェアです。Red Hat 6.x、CentOS 6.x、Oracle Linux 6.x などでは、

デフォルトで rsyslog が使用されています。


具体的には、

rsyslog のログ出力フォーマットの設定を変更して、

Syslog メッセージ自体もつタイムスタンプ(ログの生成時間)ではなく、

Syslog サーバ側での 受信時間 を出力するようにします。

 

rsyslog の設定を、

UTC のまま syslog に時刻出力してしまう設定である %TIMESTAMP% から、

%timeenerated% というパラメータに変更します。

syslog3.png

 

以上、ESXi の Syslog を JST に合わせる方法でした。

具体的な設定方法についても、紹介したいと思います。

つづく・・・

ESXi の Syslog を日本時間(JST)出力してみる。

vCenter 5.1 には、
vCenter Single Sign-On(vCenterSSO)、vCenter Inventory Servicesの事前インストールが必須となります。

新しくSSOのしくみを使うことが必須となるため、

vCenter管理者など、ログインユーザについての注意が必要そうです。

 

 

マニュアルからの抜粋(2か所)です。

vCenter Single Sign-On が vCenter Server アップグレードに与える影響
http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.install.doc/GUID-3BDE41A9-32C2-40D8-A17E-5070E2332D2F.html


vCenter Single Sign-On および vCenter Server を異なるホストまたは仮想マシンにインストールする場合は、
vCenter Server へのログイン アクセスを管理していた以前のローカル オペレーティング システム ユーザーは Single Sign-On では使用できません。

 

 

vCenter Single Sign-On をマルチサイト モードまたはクラスタ化された高可用性モードでインストールすると、
ローカル オペレーティング システム ユーザーのアップグレード前の権限がすべて失われます。
vCenter Server 5.1 では、「ローカル オペレーティング システム ユーザー」という用語は、
vCenter Server ホスト マシンまたは仮想マシンではなく、Single Sign-On ホスト マシンのローカル ユーザーを指します。


上記を見ると下記のようなSSOインストールをした場合、
Windowsのローカルユーザが使えなくなるケースがあるようです。
たとえば、ローカルのAdministratorユーザでログイン不可となったりします。

 

  • vCenterとvCenterSSOを別のWindowsサーバ(仮想マシン)にインストールする場合

          ※SSOからvCenterのローカルユーザを参照できないためだと思われます。

 

  • 「高可用性モード」(vCenterSSO自体が持つ機能)でインストールする場合

     ※この構成の場合、複数のSSOサーバが稼働することになるので

      どこかのローカルユーザを参照することはせずに、AD(Active Directory)、LDAPなどを

      参照する必要があるためと思われます。

 

vCenter Single Sign-On、Inventory Service、vCenter Server のインストールまたはアップグレードに必要な情報
http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.install.doc/GUID-200B9E03-D46B-44A9-9B0E-4863D067CFFF.html

 

Single Sign-On の新規インストールにプライマリ ノードを作成する場合、次のいずれかのオプションを選択します。(Simple Install には該当しません)。

■ 基本: シングル ノードの Single Sign-On インストールの唯一のノードで、ローカル システム ユーザーがアクセスできます。
■ マルチノード高可用性またはマルチサイト Single Sign-On の新規インストールのプライマリ ノード。


「高可用性モード」については、

vCenterSSOをインストールするサーバが1台であれば不要なので、個人的には可能な限り
SSOのインストールでは「基本」モードを選択したほうが無難と考えられます。

 

仮に、SSOサーバを「高可用性モード」にした場合は下記のような技が必要になります。

ちょっと敷居が高い感じです。

vCenterやSSOに可用性が必要な場合は、「基本モード」+ vSphereHAで構成するのが現実的な気がします。

 

Configuring vCenter Single Sign On for High Availability

http://kb.vmware.com/kb/2033588

 

Setting up Apache load balancing software with vCenter Single Sign On

http://kb.vmware.com/kb/2034157

 

SSOサーバをActive/Activeで稼働させ、

Apache + mod_proxy で分散アクセスさせています。

 

いずれにしても、
vCenter5.1の新規インストール、アップグレードをする場合は
「ちゃんと想定しているユーザでログインできるか」 の事前検証が必須になると思います。

 

以上、SSOのログインユーザには要注意という話でした。

今回は、ESXi の Syslog 設定の続きです。

以前に ESXi の Syslog 転送の設定方法についてポストしましたが、

 

(記事はこちら)

ESXi 5.x で Syslog 転送。rsyslog で受信。

 

こういうことを検証すると、
設定の切り戻しが必要なケースが多いと思います。
そのため、Syslog 設定のリセット方法をお伝えします。

 

1. まず、現在の設定状態を確認します。

 

現状では、192.168.0.192 の Syslog サーバが転送先として指定されています。

~ # esxcli system syslog config get
   Default Rotation Size: 1024
   Default Rotations: 8
   Log Output: /scratch/log
   Log To Unique Subdirectory: false
   Remote Host: udp://192.168.0.192

 

2. 設定をデフォルトに戻します。

転送先指定の Remote Host (loghost) 設定をリセットします。

~ # esxcli system syslog config set --reset=loghost

 

この時点で表示上はコマンド反映されますが、
実際の設定は syslog をリロードするまで反映されません。

~ # esxcli system syslog config get
   Default Rotation Size: 1024
   Default Rotations: 8
   Log Output: /scratch/log
   Log To Unique Subdirectory: false
   Remote Host: <none>

 

3. ESXi の Syslog をリロードします。

~ # esxcli system syslog reload

このコマンド実行後に Syslog サーバ側のログファイルを見ると
ESXi からのログ出力が停止していることが確認できるはずです。

 

4. 最後に、ESXi のファイアウォールで Syslog のポートをふさいでおきます。

 

現状は、syslog 転送を許可しています。

~ # esxcli network firewall ruleset list | grep syslog
syslog                 true

 

コマンドで、syslogルールセットを無効にします。

~ # esxcli network firewall ruleset set --ruleset-id=syslog --enabled=false

 

syslog が無効になりました。

ファイアウォール設定は、コマンドを実行すると

特に再起動しなくても即反映されます。

~ # esxcli network firewall ruleset list | grep syslog
syslog                false

 

以上、Syslog 転送先設定のリセット手順でした。