OS再起動時に Windows に設定しているIP アドレスが 169.254.x.x になる

ついこの間、Windows Server 2012 R2 で OS 再起動を実行後、
IP Address を固定に設定している環境でも、
169.254.x.x のアドレスに変わる事象に遭遇しました。

正直焦りました。

最初は同じネットワーク上に同じIP Address のマシンが存在するのか？
とか、いろいろ四苦八苦しましたが、そういうわけでもなく、違う要因でした。

[Environment］

OS: ESXi5.5
Guest OS : Windows Server 2012 R2

+ 環境で Cisco デバイスを使用していると、ESX/ESXi 上の Microsoft Windows Vista 以降の仮想マシンで重複した IP アドレスが誤って検出される
https://kb.vmware.com/kb/2092679

+ False duplicate IP address detected on Microsoft Windows Vista and later virtual machines on ESX/ESXi when using Cisco devices on the environment (1028373)

https://kb.vmware.com/kb/1028373

VMware KB に記載の内容になりますが、事象は以下の内容です。

• Windows Vista 以降のバージョンで IP アドレスを割り当てるとき、重複した IP アドレスの競合が表示されます。
• Windows Vista 以降のバージョンを再起動すると、169.254.x.x の IP アドレスが割り当てられます。
• vSwitch 上のアップリンク ポートのない vSwitch 上に同じ仮想マシンをセットアップすると、IP アドレスは正常に割り当てられます。
• 同じ vSwitch 上の Windows 2003 仮想マシンに同じ IP アドレスを割り当てると、IP アドレスは正常に割り当てられます。

私が遭遇したとき、Windowsのイベントログに以下のような記録がありました。

◆システムログ
Tcpip 4199 なし IP アドレス xxx.xxx.xxx.xxx とシステムのネットワーク
ハードウェア アドレス XX-XX-XX-XX-XX-XX が 重複しているのを、検出しました。
このシステムのネットワーク操作は 無効になる可能性があります。

この記録で私はなんとかVMware KB 2092679 にたどり着けました。

Ciscoのスイッチに影響を受けるみたいなので、
単純にESXiのログだけみたり、事象だけを見ていると解決には時間がかかります。

少し視野を広げる必要があります。

Ciscoのスイッチに影響するようなので、ESXi上のゲスト以外にもHyper-V上のゲストでも、物理ホストでも発生すると思うので、なかなか注意したい内容でした。

[補足]
関連情報としては以下のようなものがありました。

False duplicate IP address detected on Microsoft Windows Vista and later virtual machines on ESX/ESXi when using Cisco devices on the environment (1028373)
https://kb.vmware.com/kb/1028373

Duplicate IP Address 0.0.0.0 Error Message Troubleshoot
http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

日本語で情報を解説してくれている方もおられました。すごく有り難い。
http://rtaki.sakura.ne.jp/infra/?p=664

オワリ。

ESXi にSSH接続してパフォーマンスの情報を定期的に取得してcsv ファイルに出力。

ESXiのパフォーマンスを取得するとき、どうやったらいいの？

という内容です。

実際に取得したデータを見たいと思っても、見るデータがなければ始まりません。

きちんとしたデータを取って、現状を把握していきましょう。

本稿では主にコマンドの理解と流れを書きます。


ESXiにTeratermなどでSSH接続します。

以下のコマンドを実行します。

＃　esxtop -a -b -d 60 -n 60 > ログ出力先

 ※SSH接続した画面は閉じてはいけない。

■コマンドの意味

ESXi のパフォーマンス情報を60秒毎に取得し、60回取得するという意味です。
全てのパフォーマンスカウンタを取得しています。
つまり1分に1度取得して60回取得するので、1時間分のパフォーマンスデータです。
ログ出力先のところはデータストア名を指定するとよいです。

例1）esxtop -a -b -d 60 -n 60 > /vmfs/volumes/Datastore1/perf.csv

仮に2秒おきに120回情報を取得する場合はこのようなコマンド引数です。

例1）esxtop -a -b -d 2 -n 120 > /vmfs/volumes/Datastore1/perf.csv

テスト的に10秒間隔で6回取得してみます。

終わるまでコマンド結果が返ってこないような状態になります。

CSVファイルが出力されているかをvSphere Web Client から確認してみます。

きちんとファイルが存在しています。

ダウンロードします。

CSVファイルを開きます。

テスト的に10秒間隔で6回取得するコマンドを実行したので、6回分だけ表示されています。

ファイル出力させる方法は以上になります。

VMware社の日本語KBだと以下が該当します。’

https://kb.vmware.com/kb/2097572

ですが、不親切ですので本稿を書きました。

本稿の取得方法であれば、すべてのパフォーマンスカウンタを取得し、
ファイル出力するので、情報の漏れがないため、後から追加で収集したりする手間を
省けると思います。

ガッツリパフォーマンスを見たい人はこのあたりを見ることが多いかと思います。

https://kb.vmware.com/kb/2001003

https://kb.vmware.com/kb/1008205

Using VisualEsxtop to troubleshoot performance issues in vSphere - Support Insider - VMware Blogs

以上になります。

Thin で作成された仮想ディスクの縮小方法（Guest : Linux） - 今更感ありますが。

こんにちは。

すごく今更感がありますが、ESXi上で動作する仮想マシンの仮想ディスクが
Thin（シンプロビジョニング）で作成されているとき、

使用していない仮想ディスクの領域を縮小させる方法について書きます。

Thin（シンプロビジョニング）の仮想ディスクでは、一度利用した（書き込んだ）領域は、ファイルを削除したあとも、そのまま回収されず、明示的にに回収させることで、
仮想ディスクを縮小させることができます。

ゲストOS上ではファイルを削除したあとも、書き込んだ領域とのひも付け（mappingとか言うみたいですが）を削除しているだけで、実態が残っていることがほとんどです。

残されたデータは他のデータで上書きされるまで、残ってしまうことがほとんどです。
そのため、ゲストOSとして未使用領域となっている部分に ゼロを書き込むことで、
ESXiは、対象の仮想ディスクに使われていない領域があることを認識し、
仮想ディスクサイズを縮小させることができます。

（説明下手ですみません）

順に進めていきます。

まずは現状確認です。
ゲストOSとしてRHELを利用しています。
現在は、root 領域 14％ （約3GB）使用していることになっています。

しかし、vSphere Client からESXiホストに接続して、
データストアブラウザを開いて仮想ディスクのサイズを確認すると、13GBくらいあります。

実際の使用量は、ゲストOS上では約3GBで、ESXiからは約13GBくらいですので、
10GBくらいの容量差があります。これは非常にモッタイナイ。
ゲストOSであるRHELからは、ESXiが使っていると思っている領域は、
空き状態になっているように見えているということになります。

そのため、このゲストOSが空いていると思っている領域に　ゼロ書き込みを行います。

今回はRHELのゲストOSですので、ddコマンドを使い、
ゼロ書き込みしたファイルがデスクトップに出ています。（オプションで指定したので）

ddコマンド完了後は、ゲストOS側では使用領域が＋10GBされています。
ゼロ書きしたファイルが残っているためです。

今回デスクトップにファイルを作成するように指定したので、削除します。
ファイル自体は不要なので削除しています。

データストアブラウザ上でも少し容量は増えていました。

次にESXi 側での操作を実施します。

ESXiにSSH接続して、
/vmfs/volumes/データストア/仮想マシンフォルダ
まで移動します。

-flat.vmdk ファイルが仮想ディスクファイルの実態です。

では、仮想ディスクを縮小させてみましょう。

（あらかじめ仮想マシンは停止しておきましょう）

コマンドを実行します。

> vmkfstools -K ./<仮想マシン名>.vmdk

100%になりました。

ls の結果を見てみましょう。作業前と容量に変化はありません。

仮想ディスクが縮小されました。
縮小後と縮小前を比較します。

【縮小後】

【縮小前】

このように定期的にメンテナンスできる環境であれば、

知らぬ間にデータストアを圧迫していることもあるので、実施頂ければと思います。

以上になります。

【補足】

vmkfstools にはいろいろオプションがあります。
便利なものもあるので、見てみるのもいいかもしれません。

vmkfstools - 仮想ディスクのオプション

https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.storage.doc/GUID-0AC9C948-4D0A-4634-99B8-E10CC09EFE47.html

vmkfstools は現在ではesxcli コマンドに置き換えられている機能もあります。

たとえば、ESXi 5.1 では　vmkfstools -y　でUNMAP操作をしますが、

ESXi5.5以降は　esxcli storage vmfs unmap を使います。

今回はこのへんで！

HPE ServerのiLO4 Web 管理画面からESXiにインストールしてあるDriverバージョンが見れる。

こんにちは、この間、HPE の 中古のProLiant DL320e Gen8 を買って、
いろいろいじってみました。

いろいろ画面を見ていると、ILO4 のWeb 管理画面からESXi上に
インストールされている Driver や Vib を見ることができる画面があったのでご紹介です。

HPE の ProLiant には iLO4 というマザーボードから独立した
ProLiant を管理する機能が備わっているとのことだったので、
どんなもんなのかと弄ってみた感想を綴ってみようと思います。

運用者の視点で記載していきます。

iLO4 はIP Address を設定して、ブラウザからアクセスして利用することになります。

iLO4  に IP Address を設定する方法については、公開ドキュメントを見ました。

https://h20628.www2.hp.com/km-ext/content-webapp/document?docId=emr_na-c03352387

iLO4 にはFirmware というものがあるようで、今回は Firmware 2.50 というバージョンのようでした。（結構新しいみたいです）
こちらがログイン画面です。

Administrator でログインしてみます。

ログイン後の画面です。

[Firmware]　と　[Software]　というタブがあります。

[Firmware] をクリックしてみます。

各NIC やRAID コントローラーやHBAのFirmware などを一覧表示してくれます。
ここまでは、iLO4 はHPE のサーバーだし、Hardware 情報くらい取ってきてくれて当たり前な感じもします。

次に、[Software] タブをクリックします。
すると、ESXiにインストールされているDriverなどを見ることができます。
以下の画像では、［HPE Software］にチェックが入っているので、
HPEに関するツールやDriver 類が表示されています。なかなかいいんじゃない？

[Running Software ]　のラジオボタンをクリックすると、
ESXi 上のプロセスが表示されます。

[Installed Software] のラジオボタンをクリックすると、
既にインストール済みのツール類が表示されます。
（ここではなぜか、バージョンは表示されないんですね…...）

表示されている内容を見るとほとんど、
esxcli software vib list  の結果を表示しているように見えました。

ILO4 Web 管理画面に表示されている情報はどこから取っているのかな？
と思って、ESXiにSSH接続してハードウェア監視のプロセスを止めてみました。

すると、やはり情報取れなくなりました。

ESXiから情報をもらっているみたいです。（あたりまえか）

運用監視の人であったり、ただのユーザーの人がESXiにSSH接続して、
Driver バージョンとか見るのは、少しハードルが高いようなときは、
結構使えるものではないかな、と思いました。

オワリ。

ディスクI/Oが遅い、不安定、esxtopを見てみるのもいいかもしれません。

今回はストレージに関するパフォーマンスのヒントになりそうな

内容を書こうかと思います。ほぼほぼ未来への自分へのメモです。

ESXi ではほとんどの場合、共有ディスクを複数のESXiホストと共有しているため、
共有ディスクへのアクセスに問題が発生したり、ストレージ障害が発生すると
大きいトラブルに発展することがほとんどかと思います。

しかし、一方で、ストレージ障害は発生していないが、
ディスクI/O遅延が発生するなどは、原因が顕著化しないため、
ずるずると問題が長期化したり、気づいたときには大きな問題になっていることも
多くあります。

そこで、１つのアプローチとしてですが、ディスクI/O遅延を調査するとき、
ESXi観点から問題を切り分けたいときは、esxtop を用いて、
大まかに切り分けを行うことがあります。

ディスクのI/O遅延では、どの段階でコマンドの待ち時間が多く発生しているかを
見ていくことが正攻法になります。

図の説明をします。

■Kernel command wait time
日本語だと カーネルコマンド待ち時間 です。
仮想マシン上のDriverからESXiが管理しているファイルシステムまでの待ち時間です。
一般にKAVGと言われます。

 + esxtop(ex.)
　\Physical Disk(vmhba1:vmhba1:C0:T1:L0)\Average Kernel MilliSec/Command

■Physical Device command Wait time
ESXi自身のDriverからStorageアクセスまでの待ち時間です。
一般にDAVGと言われます。

+ esxtop(ex.)
　\Physical Disk(vmhba1:vmhba1:C0:T1:L0)\Average Driver MilliSec/Command

■Total command wait time(guest wait time)

Kernel command wait time　と　Physical Device command Wait time の合計です。
一般にGAVGと言われます。

+ esxtop(ex.)
　\Physical Disk(vmhba1:vmhba1:C0:T1:L0)\Average Guest MilliSec/Command

DAVG ＋ KAVG = GAVG です。


【どこで待ち時間の値が高くなっているか？】

コマンド待ち時間（GAVG）の値が高くなっている場合、
次にDAVGの値が高くなっているのか、もしくはKAVGの値が高くなっているのかを確認します。
ハイパーバイザーで遅延が発生しているのか、それともESXiのDriverからストレージまでの間で遅延が発生しているのかを切り分けます。

・Kernel command wait timeの値が高い場合（KAVG）
　→ESXiホスト側でリソース不足が発生していないか確認する。
　（CPU負荷などが多い）
　　しかし経験上、vSphere Client から見たら多くがわかるため、
　　この値が高いことは少ない傾向にある。

・ Physical Device command Wait timeの値が高い場合（DAVG）
　→ストレージ自体になんらかの問題が発生している。
　　例えばコントローラのFirmware動きがよくないであったり、
　　ストレージ側のディスクのパフォーマンスがよくないこともあります。

　→SCSI コマンドのリトライやSCSIコマンドのAbort が多く発生している場合
　　経路やストレージ側を怪しむべき（だいたいログからわかります）

　→Reservation Conflict （SCSI 予約競合）などが多く発生しているようであれば、
　　VMFS上のVMの数を減らしてみるなど。

　→HBA, NIC, などのFirmware やDriverがボトルネックになっている可能性。

このあたりを怪しむべきです。

【KAVGもDAVGも高い！】
ゲストOSが想定よりも膨大なディスクI/Oリクエストをストレージに向けて行っている可能性があります。サイジングのミスである可能性もあります。
たとえば、１つのVM上でデータベース, Webサーバー,リアルタイム処理, 分析処理などが一気に動作していたりすると、サーバーとストレージ間の処理の限界近くに達していることもあるとおもいます。

このような場合は、esxtopだけでは判別つきませんが、少なくとも
ゲストOSもESXiもいっぱいいっぱいの処理をしている可能性が高いことはわかります。

処理の分散化を検討するのも１つの手かもしれません。実際にいろいろ試して切り分けしていくしかないでしょう。

私の手元でストレージに定期的に高負荷を書けたときのサンプル資料を載せます。
定期的にゲストOS上で高負荷をかけているので、均等に値が高いわけではなく
負荷が上がったときに値が高くなっています。

（Sample）

 この値の指標ですが、VMwareの書籍には参考基準値の記載がありました。
====================================================

■Kernel command wait time（KAVG）

　参考基準値：5ms 

■Physical Device command Wait time（DAVG）
参考基準値：20～50ms

■Total command wait time(guest wait time)

参考基準値：20～50ms

しかし、あくまで目安なので一概に言えないところが難しいです。

====================================================

私がサンプルしたデータはFC接続のストレージでの結果となりますが、

25.0を超えたあたりから体感で遅くなっていることを感じました。

ネットサーフィンしていると、あまり存じ上げない会社から、
私が個人的に好きなまとまった資料が公開されています。

＋ esxtop 6.0
http://www.running-system.com/wp-content/uploads/2015/04/ESXTOP_vSphere6.pdf

＋ esxtop 5.5

http://www.running-system.com/wp-content/uploads/2012/08/esxtop_english_v11.pdf

【補足】

忘れそうなので、ほぼほぼ自分へのメモのために書きましたが、
見てくれる方がいると嬉しいなと思ったり。

今回はこのへんで。

ESXi upgrade From ESXi5.5 build 2403361 to ESXi6.5 build 4564106 Conflicting vibs Error (net-mst)

ESXi upgrade From ESXi5.5 build 2403361 to ESXi6.5 build 4564106 Conflicting vibs Error(net-mst) (hpe customized Image)

【Envrionment】
Server: BL460cGen9
OS: ESXi5.5 Update2 (build 2403361) --> ESXi6.5 (build 4564106)

I had an issue now.
when trying to upgrade BL460c Gen9 from 5.5u2 to 6.5
where I showed an error message.

The upgrade on Scanning system lator show this screenshot.

message:
<CONFLICTING_VIBS ERROR: Vibs on the host are conflicting with vibs in metadata.
Remove the conflicting vibs or use Image Builer to create a custom ISO providing newer
versions of the conflicting vibs.
['Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560',
'Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560']>

■Resolution
1. Check VIBs with net-mst in name
~# esxcli software vib list | grep net-mst

2. Remove net-mst VIB/offline bundle driver
~# esxcli software vib remove -n net-mst

----- I'm sorry, lost picture......

3. Restart host.

4. Boot to HPE Custom ESXi6.5 Image.

5. select to Upgrade(F11)

 6. Upgrade was Complete!!!!

Memo:

I used Custom Image file name bellow.
VMware-ESXi-6.5.0-OS-Release-4564106-HPE-650.9.6.0.28-Nov2016.iso

Thanks.（＾ω＾）