個人的な話で恐縮ですが、vExpert 2017 受賞しました。
＋vExpert 2017 Award Announcement
vExpert 2017 Award Announcement - VMTN Blog - VMware Blogs
本Blogをみてくださっている方のおかげです。本当に感謝感謝です。
私は製品を売る側の人間ではないので、技術情報が多めですが、
役立つ情報をいろいろ書いていくので、どうぞよろしくお願いいたします。
VMware Tools に含まれるDriver（vsepflt.sysとvnetflt.sys）でWindowsがBSODになることがあります。
こんにちは。
今回は地味に困ったときのネタです。
VMware Tools に含まれるDriver（vsepflt.sysとvnetflt.sys）でWindowsがBSODになることがあるので、その考察や見解についてです。
ESXi上で動作する仮想マシンには、ほとんどの場合、
VMware Tools をインストールしているとおもいますが、仮想マシンで動作するOSがWindows の場合、VMware Tools に含まれるvSheild関連（現在だとNSX関連）のDriverの動作が起因し、Windows がBSODになってしまったり、クラスターリソース（主にクラスタディスク）が見えなくなってしまうなどの事象が起こることがあります。
そのため、既知事例ということで、VMware 社はVMware KB 2082204 を公開しています。
+ vShield Endpoint Thin Agent (vsepflt.sys) および vShield Endpoint TDI Manager (vnetflt.sys) ドライバを使用してインストールされた Windows 仮想マシンが応答しなくなるか、障害が発生して青色の診断画面が表示される (2082204)
https://kb.vmware.com/kb/2082204
上記のVMware KB の説明では、VMware Tools 5.1 に影響する既知の問題で、ESXi 5.1 および 5.5 に影響する場合があり、ESXi 5.5 Update 2 で修正されていると記述されています。
しかしながら、ESXi 5.5 Update 2 以降の環境でも事象が発生する模様です。
実際に、vsepflt.sysとvnetflt.sysが起因と考えられるBSODを複数回確認しています。
調べたところ、VMware Tools に含まれるvsepflt.sysとvnetflt.sysの相互の連携における問題があり、BSODなどの事象が発生することがあるようです。（細かいことは謎）
・vShield Endpoint シン エージェント ドライバ (vsepflt.sys)
・vShield Endpoint TDI Manager ドライバ (vnetflt.sys)
BSODなどの事象が発生しないようにする回避策としては、
上記Driverのアンインストールもしくは、アンロードを実施します。
以下のVMware KBに方法は記載されています。
https://kb.vmware.com/kb/2082588 （英語）
https://kb.vmware.com/kb/2083369 （日本語）
vSheild やNSXを利用していない環境であれば、アンインストールしても支障はありません。
また、現在はデフォルトではインストールされないようになっています。
■参考画像
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
【その他の問題点１】
vShieldやNSXを使っていない環境であれば、上記Driverをアンインストールやアンロードを行えばいい話なのですが、もしvShield やNSXをばりばり使っている場合はそうもいきません。（NSX,vShieldは専門外ですが...）
vShield Endpoint シン エージェント ドライバ (vsepflt.sys)は、Windows ファイル システム フィルタ ドライバ で、その名のとおり、
ファイルシステムへのリクエストをフィルタリングするモジュールになっています。
フィルタドライバの説明はMicrosoft のBlogをご覧ください。
https://blogs.msdn.microsoft.com/jpwdkblog/2009/05/13/filesystem-filesystem-filter/
このフィルタドライバがその他のファイルシステムへのI/Oを阻害することが結構あり、BSODになることもあります。Windows は標準でディスクI/Oを６０秒行えない状態が発生するとファイルシステムを守るために、BSODになるようレジストリで設定されています。
レジストリとしてはここです。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue
内容は異なりますが、似たVMWare KB もありました。
https://kb.vmware.com/kb/2080692
こういった事情もあり、アンインストールおよびアンロードできない場合はなかなか厄介です。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
【その他の問題点２】
上記で、vShield Endpoint シン エージェント ドライバ (vsepflt.sys)のことを記載しましたが、vSphere 環境で動作するセキュリティ製品で vsepflt.sys が動作要件になっているものがあります。
例えば、トレンドマイクロのDeepSecurity は vsepflt.sysが動作要件になっているようで、明確な要件が書かれた文献はすぐみつけれませんでしたが、以下のサポートページには、「 vsepflt が正常に動作していること を確認してください。」と記載されています。
http://esupport.trendmicro.com/solution/ja-JP/1313647.aspx
セキュリティ対策製品でvsepflt.sysが要件になっている場合は簡単にアンインストールできないでしょうし、困りものです。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
問題点１，２にぶち当たったときは結局のところ、最新のVMware Toolsにして様子をみるしかないという感じかと思います。
VMware Product Interoperability Matrixes から現在使用しているESXiで利用可能なVMware Tools をみて、https://packages.vmware.com/tools からVMwareToolsのインストーラーを入手して、バージョンアップすることがお勧めです。
文脈がぐちゃぐちゃですが、今回はこのへんで。
ESXi上にESXiをインストールして仮想ディスクをSSDとして認識させる。（Nested ESXi）
こんにちは。
今回はESXiがインストールされたサーバ上に仮想マシンとしてESXiをインストールします。
そしてその後、仮想マシンとして動作するESXiからみると、SSDが搭載されたホストにみえるよう設定してみようと思います。
短い言い方をすると、Nested ESXiに接続された仮想ディスクをSSDとして無理やり認識させる方法を紹介します。
情報元はこちらのBlogです。いわゆるパクリです。
Emulating an SSD Virtual Disk in a VMware Environment | virtuallyGhetto
細かいことはすっ飛ばして、イメージ図はこのような感じです。
======================
◆使う環境
vCenter Server 6.5
物理ホスト：VMware ESXi 6.0 Update 2
Nested ESXiのOS：ESXi 6.0 Update 2
======================
では、Nested の ESXi6.0 Update 2 を作っていきます。
vSphere Web Client から普通に仮想マシンを新規作成していきます。
わかりやすい名前をつけました。
使用するデータストアも特にどれでもかまいません。
ここの選択は重要です。以下を選択します。
[Guest OS Family:] → Other
[Guest OS Version] → VMware ESXi 6.0
ESXiの最小インストール要件を満たすためにメモリを8GBに増やし、vCPU 2にしました。
私はVMware Remote Console が好きなのでよく使っています。
仮想マシンをパワーオンし、画面を表示したあと、
ESXi6.0 Update 2 のISO イメージをマウントします。
手元にあった インストールメディアが以下のものでしたので、これを使います。
[VMware-VMvisor-Installer-6.0.0.update2-3620759.x86_64.iso]
iso イメージからブートさせました。
Enterキーを押してインストールを進めます。
警告がでますが、あとから修正するのでそのまま進み、インストールを完了させます。
インストール後はこの仮想マシンをパワーオフします。
パワーオフ後に仮想マシンの編集画面を開きます。
x64の仮想マシンをNested ESXi上で稼働させるために
[Expose hardware assisted virtualization to the guest] にチェックをいれます。
※必須ではないです。
Nested ESXiからSSDに見えるようにしたい仮想ディスクを追加します。
このとき、どのSCSIコントローラーのバスに接続したのかをメモするか
覚えておくようにしてください。
今回の環境は SCSI 0：1 につないでいます。
まだ仮想マシンはパワーオンせず、仮想マシンの構成ファイル（.vmx）を編集するためにvSphere Web Client から 構成ファイルをダウンロードします。
ダウンロードした . vmxファイルをテキストファイルで開き、
scsi0:1.virtualSSD = 1 を追記して保存します。
"scsi0:1" の部分はSSDに見せたい仮想ディスクの場所を指します。
上記で記録した部分です。
編集したファイルを同じ場所にアップロードします。
仮想マシンをパワーオンして、IP Address を設定してください。
（私の環境はDHCPなので自動でIP Addressを取得しています）
ESXi6.0 Update 2 はvSphere Host Client がデフォルトでインストールされているため、
vSphere Host Client を開いてログインします。
では、指定した仮想ディスクがSSDに見えているか確認します。
[新しいデータストア] をクリックしてみます。
仮想ハードディスクのはずが、SSDに見えていますね！！
このまま進めてデータストアを作成してみます。
データストアとして作成してもきちんとSSDとして認識しています。
（当然性能はお察し...）
■考察
検証目的としてどうしてもESXiホストにSSDとして見せる必要があったり、
とりあえず、勉強や一時的な検証のためにVMware vSANを構築 しなければいけないときは、使うとよいと思います。
特にVMware vSAN は最低でもESXiホストが3台必要で、SSDがそれぞれのホストに1つは必須なので、お財布事情を考えると使うこともあると思います。
既に私はお世話になってしまいました...
今回はこのへんで。
ESXiのマルチパスのポリシーとIOPS値はストレージベンダーの推奨になっていますか？
こんにちは。
今回はESXiを外部ストレージに接続するときのパスの設定についての備忘録です。
私は仕事柄、いろいろな環境におかれたESXiを見ます。
その中で気になったのが、ESXiを外部ストレージと接続する際、
パスの設定を考慮していない環境をちらほら見かけます。
パスの設定はある程度ストレージベンダー毎に推奨値を公開しており、
意外にも推奨値に設定していないケースがあります。
そのため、今回はパスの設定について少し記載してみようと思います。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
今回着目する設定値は、パス選択プラグイン (PSP) ポリシーと、IOPS値の設定です。
VMware KB でいうと以下の 2098075 が該当します。
【ラウンド ロビンの IOPS 制限をデフォルトの 1000 から 1 に調整する (2098075)】
https://kb.vmware.com/kb/2098075
ここでいうポリシーというのは、ストレージと接続されたESXiの複数のパスをどのように扱うのかという設定で、IOPS値というのは、どれだけのIOを行ったら次のパスからI/Oするのか、を定義する設定になります。
この部分の設定は各ストレージベンダーで推奨値がドキュメントで公開されています。
公開ドキュメントによると、DELL EMCのVMAX, Hewlett Packard Enterpriseの3PARでは、
パス選択プラグイン (PSP) ポリシーは、”ラウンドロビン”
IPOS値 は １
が推奨となっていました。
”ラウンドロビンとはなにか？” ですが、ラウンド ロビン (RR) は
使用可能なすべてのパスを順次回転させ、構成された複数のパスにまたがる負荷分散を可能にするポリシーです。例えば３パス使用できる接続になっているようであれば、
３つのパスをすべて活用して分散しながらアクセスするということになります。
ポリシーについてもう少し理解を深めたい場合はVMware KB を見るのもいいかと思います。
【ESXi 5.x および ESXi/ESX 4.x のマルチパス ポリシー (2019882)】
https://kb.vmware.com/kb/2019882
”IPOS値 とはなにか？” ですが、例えばポリシーをラウンドロビンで "IOPS=１" に設定している場合は、I/O操作を1回行ったら、次のパスを使うという動作をするようになります。
IOPS=1にすることで、1回のI/O毎に別のパスに切り替わるような動作になります。
複数のパスからI/O処理が流れるため、負荷分散されるということになります。
■流れ（２パスのとき）
I/Oを1回実施→次のパスを使う→I/Oを1回実施→元のパスに戻ってIOする→繰り返し
このような動作で、負荷分散が動作しています。
VMware KB にも記載があります。
https://kb.vmware.com/kb/2098075
抜粋
==========================================================
1回の I/O の後にパスを切り替えることで、パス全体の I/O のバランス、ひいてはストレージ プロセッサのバランスが改善されます。パス全体で均等な I/O バランスが得られます。
==========================================================
これらの設定について、推奨していることをDELL EMC のVMAXのドキュメントにかかれていました。
【Using EMC VMAX Storage in VMware vSphere Environments】
→Page 86
また、Hewlett Packard Enterpriseの3PARでは以下のドキュメントに記載があります。
【HPE 3PAR StoreServ Storage and VMware vSphere 6 best practices】
http://h20195.www2.hpe.com/V2/getpdf.aspx/4AA4-3286ENW.pdf
→Page10
パスのポリシー設定ですが、デフォルトでは、PSP = MRU、IOPS ＝ 1000 になっています。
MRUというのは Most Recently Used の略です。
最近一番使われたパスです。
IOPS=1000 という設定は1000回 I/O を行ったら次のパスへ移動するということです。
デフォルトの設定だと、片方のパスに1000回 I/O が一気に流れてくるため、
Storege側としては、１つのパスから多くのI/Oを受け取ることになります。
これらの推奨設定値から推測できることは、DELL EMCのストレージもHPEのストレージも、１つのパスから多くのI/Oを受け取ることは好まず、なるべく複数のパスから分散してI/Oを受け取りたいのであろう、という推測がたちます。
試しにHPEのStorageのアーキテクチャの資料を軽く検索してみるとこのような図がありました。
Storage が専門ではないので正直この部分で見解が合っているかは怪しいですが、Storage側としてはどのパスからI/Oを受け取ってもStorageのコントローラーが
フルメッシュでつながっているので大丈夫であるため、ラウンドロビンにしてほしい？のではないかなと思いました。
https://www.hpe.com/h20195/v2/GetPDF.aspx%2F4AA3-2542ENW.pdf
今回は忘れそうだったので、覚えている内容を書きました。
間違っていなければいいのですが…
おわり
ESXi のインストールメディアからVMware Toolsの ISO ファイルを抜き取る。
既に知られている内容かもしれないことを堂々と書こうかと思う。
ESXi上に仮想マシンを作成し、OSをインストールしたあと、
ほとんどの場合、ゲストOSにVMware Tools をインストールすると思います。
vSphere Client での操作だと、この部分の操作である。
[VMware Toolsのインストール/アップグレード] をクリックすると、
ゲストOSにインストールメディアがマウントされます。
Windows Server 2012 R2のゲストではこのようなアイコンになります。
ここまではごく当たり前の操作であるが、このVMware Tools メディアは、
ESXiのインストールメディアにも含まれていることはご存知でしょうか。
今回は、VMware Tools のISO ファイルをESXiのインストールメディアのどこにあるかをメモするための記事です。
私はHewlett-Packard Enterpriseのサーバーをよく使うため、HPEのESXi6.5のインストールメディアをもっているので、それで試します。
ISOファイルをWindowsでマウントして中身を見る。
最近のWindowsであればISOファイルをダブルクリックで中身が見れます。
メディアの中に「TOOLS.T00」というファイルがあります。
「TOOLS.T00」を別の場所にコピーします。
このファイルを「TOOLS.T00」から「TOOLS.tgz」に名前を変えます。
「TOOLS.tgz」になったので、解凍します。
フォルダが１つ出現します。開きます。
フォルダが２つ出現します。「vmtools」フォルダを開きます。
ここまでのディレクトリの場所はここです。
「\TOOLS\6.5.0\vmtools」
１つ挙げると、「windows.iso」ファイルこれはWindows用のVMwareToolsのISOメディアです。
「windows.iso」をマウントして、開いてみます。
中身はこのようになっています。
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) となっています。
従来からある vSphere Client （C#版）であれば サクっと削除できるのですが、
vSphere Web Client で対象の仮想マシンを右クリックすると、このような表示です。
昔からある 「インベントリから削除」 のメニューは見受けられません…
画面からは消せない！？
とおもったら、すごい場所にインベントリから削除する項目がありました。
ツイッターでご指摘頂き、すごく助かりました。
私は、上記メニューを見つけられず、vSphere PowerCLI を使って、
インベントリ一覧からVMを削除していました。情けない。。
こんなことをしていたので、ただのご紹介です。
vSphere PowerCLIはvmwareが出している管理ツールの１つです。
Microsoft のPowerShellをベースに作られているCLIツールです。
起動直後はこのようなモジュールの読み込みが始まります。
使えるようになると、このような画面になります。
では、まず、vCenter Server に接続します。
以下のコマンドを実行します。
> Connect-VIServer –Server XXXXX –User XXX –Password XXX
※警告は無視して大丈夫です。
本当にvCenter に接続されているかどうか確認するため、特に害がないGet-VMコマンドでVMの一覧を取得します。
すると、きちんとvCenterの情報をとれました。
上記が、親なし のVMですが、そのような雰囲気は出ていませんね。
では、この "RHEL7.2" というVMを削除しようと思います。
を実行します。
削除していいか聞かれます。 ｙ を入力してEnterを押します。
すると、vSphere Web Client のインベントリから対象のVMを削除してくれます。
画面をすぐに見てもらえるとわかりますが、即時反映です。
画面をリフレッシュしなくてもよいです。
結構、私は検証とかをしていると知らぬ間に親なしの不要な仮想マシンが存在したりします。
vSphere Web Client からできることがわかったので安心しました。
せっかくなので、PowerCLIの方法も書いたままにするとします…笑
