読者です 読者をやめる 読者になる 読者になる

自由人なエンジニアの備忘録

好きなことを好きに描く、ん~のびしろですね!

ESXi のインストールメディアからVMware Toolsの ISO ファイルを抜き取る。

既に知られている内容かもしれないことを堂々と書こうかと思う。

 

ESXi上に仮想マシンを作成し、OSをインストールしたあと、
ほとんどの場合、ゲストOSにVMware Tools をインストールすると思います。

 

vSphere Client での操作だと、この部分の操作である。

f:id:japan-vmware:20170121005433p:plain

 

[VMware Toolsのインストール/アップグレード] をクリックすると、
ゲストOSにインストールメディアがマウントされます。

f:id:japan-vmware:20170121010048p:plain

 


Windows Server 2012 R2のゲストではこのようなアイコンになります。

f:id:japan-vmware:20170121010255p:plain

 

ここまではごく当たり前の操作であるが、このVMware Tools メディアは、
ESXiのインストールメディアにも含まれていることはご存知でしょうか。

 

今回は、VMware Tools のISO ファイルをESXiのインストールメディアのどこにあるかをメモするための記事です。

 

私はHewlett-Packard Enterpriseのサーバーをよく使うため、HPEのESXi6.5のインストールメディアをもっているので、それで試します。

f:id:japan-vmware:20170121011004p:plain

 

ISOファイルをWindowsでマウントして中身を見る。
最近のWindowsであればISOファイルをダブルクリックで中身が見れます。
メディアの中に「TOOLS.T00」というファイルがあります。

f:id:japan-vmware:20170121011238p:plain

 

「TOOLS.T00」を別の場所にコピーします。

f:id:japan-vmware:20170121012020p:plain

 

このファイルを「TOOLS.T00」から「TOOLS.tgz」に名前を変えます。

 

f:id:japan-vmware:20170121012201p:plain

 

「TOOLS.tgz」になったので、解凍します。

f:id:japan-vmware:20170121012556p:plain

 

フォルダが1つ出現します。開きます。

f:id:japan-vmware:20170121012645p:plain

 

フォルダが2つ出現します。「vmtools」フォルダを開きます。

f:id:japan-vmware:20170121012710p:plain


ここまでのディレクトリの場所はここです。
「\TOOLS\6.5.0\vmtools」
1つ挙げると、windows.iso」ファイルこれはWindows用のVMwareToolsのISOメディアです。

f:id:japan-vmware:20170121012811p:plain

 

windows.iso」をマウントして、開いてみます。
中身はこのようになっています。

f:id:japan-vmware:20170121013142p:plain

 

Setup64.exe が64bitのOS用です。
ダブルクリックするとインストーラーのウィザードが開きます。

 

インストール当時のVMwareTools を保存しておきたい場合などは、
インストールメディアから抜き取っておくといいかもしれません。

 

【補足】

ここまで、長々と書きましたが、VMware社はVMwareToolsの各種バージョンをWeb上に公開しています。こちらを見るとよいかと思います。

https://packages.vmware.com/tools/esx/index.html


一番最新のバージョンからESX3.5まで取り揃えてあります。

入手先に困ったときは見てみるとよいかもしれません。

 

オワリ

「親なし」になったマシンをvSphere Web Clientの画面上から削除しようとしたら、削除するメニューを見つけれなかった。

おひさしぶりです。

 

今日たまたま、ESXiホストやvCenter Serverを再起動したとき、vCenter から見みると、
「親なし」の不要仮想マシンができてしまったので、対処をしていこうと思った次第です。

 

【環境】
vCenter Server 6.5
ESXi6.0 Update 2

 

vSphere Web Client のインベントリではこのようになっています。
英語環境なので、 (orphaned)  となっています。

f:id:japan-vmware:20170116224327p:plain

 

 

従来からある vSphere Client (C#版)であれば サクっと削除できるのですが、
vSphere Web Client で対象の仮想マシンを右クリックすると、このような表示です。

f:id:japan-vmware:20170116230447p:plain
昔からある 「インベントリから削除」 のメニューは見受けられません…

画面からは消せない!?

 

とおもったら、すごい場所にインベントリから削除する項目がありました。
ツイッターでご指摘頂き、すごく助かりました。

f:id:japan-vmware:20170117155452p:plain

 

私は、上記メニューを見つけられず、vSphere PowerCLI を使って、
インベントリ一覧からVMを削除していました。情けない。。

こんなことをしていたので、ただのご紹介です。

vSphere PowerCLIはvmwareが出している管理ツールの1つです。

MicrosoftPowerShellをベースに作られているCLIツールです。

f:id:japan-vmware:20170117005114p:plain

 

起動直後はこのようなモジュールの読み込みが始まります。

f:id:japan-vmware:20170117005340p:plain

 

使えるようになると、このような画面になります。

f:id:japan-vmware:20170117005735p:plain

 

では、まず、vCenter Server に接続します。
以下のコマンドを実行します。
> Connect-VIServer –Server XXXXX –User XXX –Password XXX

f:id:japan-vmware:20170117010602p:plain

※警告は無視して大丈夫です。

本当にvCenter に接続されているかどうか確認するため、特に害がないGet-VMコマンドでVMの一覧を取得します。
すると、きちんとvCenterの情報をとれました。

f:id:japan-vmware:20170117011310p:plain

上記が、親なし のVMですが、そのような雰囲気は出ていませんね。

 

では、この "RHEL7.2"  というVMを削除しようと思います。

Remove-VM -VM "<仮想マシン名>"   
つまり、

Remove-VM -VM "RHEL7.2"

を実行します。

 

削除していいか聞かれます。 y を入力してEnterを押します。

f:id:japan-vmware:20170117013254p:plain

 

すると、vSphere Web Client のインベントリから対象のVMを削除してくれます。

 

画面をすぐに見てもらえるとわかりますが、即時反映です。

画面をリフレッシュしなくてもよいです。

 

結構、私は検証とかをしていると知らぬ間に親なしの不要仮想マシンが存在したりします。

 

vSphere Web Client からできることがわかったので安心しました。

せっかくなので、PowerCLIの方法も書いたままにするとします…笑

 

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


f:id:japan-vmware:20170109234513p:plain

 

+ 環境で 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接続します。

f:id:japan-vmware:20170106003401p:plainf:id:japan-vmware:20170106004402p:plain

 

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

# 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回取得してみます。

f:id:japan-vmware:20170106010536p:plain

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

 

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

f:id:japan-vmware:20170106010912p:plain

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

 

ダウンロードします。

f:id:japan-vmware:20170106011103p:plain

 

f:id:japan-vmware:20170106011146p:plain

 

CSVファイルを開きます。

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

f:id:japan-vmware:20170106011324p:plain

 

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


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)使用していることになっています。

f:id:japan-vmware:20161221043225p:plain

 

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

f:id:japan-vmware:20161221043654p:plain

 

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

 

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

 

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

f:id:japan-vmware:20161221044324p:plain

 

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

 

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

f:id:japan-vmware:20161221044824p:plain

 

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

f:id:japan-vmware:20161221045018p:plain

 

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

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

f:id:japan-vmware:20161222001434p:plain

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

 

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

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

コマンドを実行します。

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

f:id:japan-vmware:20161222002516p:plain

100%になりました。

f:id:japan-vmware:20161222002858p:plain

 

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

f:id:japan-vmware:20161222003146p:plain

 

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

【縮小後】
f:id:japan-vmware:20161222003627p:plain

【縮小前】

f:id:japan-vmware:20161221045018p:plain

 

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

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

 

以上になります。

 

【補足】

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 でログインしてみます。

f:id:japan-vmware:20161218182634p:plain

 

ログイン後の画面です。

f:id:japan-vmware:20161218183738p:plain

 

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

[Firmware] をクリックしてみます。
f:id:japan-vmware:20161218184007p:plain

 

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

f:id:japan-vmware:20161218184322p:plain

 

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

f:id:japan-vmware:20161218184647p:plain

 

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

f:id:japan-vmware:20161218185100p:plain

 

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

f:id:japan-vmware:20161218185228p:plain


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

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

f:id:japan-vmware:20161218190625p:plain

 

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

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

 

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

 

オワリ。

 

 

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

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

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

 

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

 

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

 

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

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

f:id:japan-vmware:20161215014637p:plain

 

図の説明をします。

■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リクエストをストレージに向けて行っている可能性があります。サイジングのミスである可能性もあります。
たとえば、1つのVM上でデータベース, Webサーバー,リアルタイム処理, 分析処理などが一気に動作していたりすると、サーバーとストレージ間の処理の限界近くに達していることもあるとおもいます。

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

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

 

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

 

(Sample)

f:id:japan-vmware:20161216001243p:plain

 

 この値の指標ですが、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.

f:id:japan-vmware:20161211235012p:plain

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

f:id:japan-vmware:20161212000048p:plain

 

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)

f:id:japan-vmware:20161212000551p:plain

 

 6. Upgrade was Complete!!!!

f:id:japan-vmware:20161212001157p:plain

 

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.(^ω^)