vRealize Operations Manager 6.6をデプロイしていく。

 こんにちは。

私は、vRealize Operations Manager 6.2　までしかデプロイしたことがなかったので、vRealize Operations Manager 6.6をvSphere Web Client からデプロイする流れのメモとして、画面ペタペタ貼ろうかと思います。

あらかじめMyVMwareからダウンロードしておいた、ovaファイルをvSphere Web Client を使ってデプロイします。

 デプロイするところを指定。

デプロイされるテンプレートの概要が表示される。

 [Next] ボタンをクリックしていく。

デプロイ自体は完了。

同じネットワーク上にあるPCのブラウザから IP Address を入力してアクセスすると以下の画面が表示される。[EXPRESS INSTALLATION] をクリックした。

ウィザードが表示されるので、[Next]ボタンをクリックして進めていく。

adminユーザーのパスワードを設定する。

 [FINISH]ボタンをクリックする。

構成が始まります。私の環境ではこの画面が20分くらい表示され続けました。パフォーマンス次第かと思います。

自動的に画面が遷移し、VMware vRealize Operations Manager のログイン画面が表示されます。

さっそくadmin ユーザーでログインすると、またまた初期構成を行うための画面が表示されます。[NEXT]ボタンで進めていきます。

ライセンスキーを入力します。

[FINISH]ボタンをクリックします。

ログインすると [Administration]タブ が選択された状態で表示されます。

情報を得るには、まずvCenter Server から情報を取得しなければいけないので、設定します。歯車のアイコンをクリックします。

vR ops 6.2のときと似た画面になりました。vCenter Adapter にvCenter Server との通信必要な情報を入力して、[TEST CONNECTION]ボタンをクリックします。

[TEST CONNECTION]ボタンをクリックし、vCenter Server と接続テストを行います。

接続がうまくいくと、[Test connection Successful] と表示されます。[SAVE SETTINGS]ボタンをクリックします。

 vCenter Adapter の中に自分が作成したものが表示されます。

情報収集がはじまります。 

ここまでの作業に何やら情報を取得してきていました。

（あまりvR Ops 詳しく無いので…）

ただのメモでした。

オワリ

vCenter管理下のESXiに直接接続して仮想マシンの作成/登録はやめておいたほうがいい。

こんにちは。

今回は、運用の中でvCenterがを利用しているけど、何かの理由でESXiに直接vSphere Client を使って接続し、仮想マシンを作成、登録をするとあまりよくない、という内容です。

例えば、vCenter Server を仮想マシンとして稼働させていたけど、うまく動かなくなり、バックアップからリストアしなければいけないとき、vSphere Clientを使ってESXiホストに直接接続して、インベントリから削除しなければいけないということがあったとします。削除後、同じ名前でインベントリに登録したりすることもあると思います。

このような操作は、vCenter Server 側からするとやめてほしい操作のようです。

VMware KB 2078577 に記載があります。

vCenter Server でのインベントリへのVMの登録または追加方法 (2078577) | VMware KB

■抜粋
ESX ホストが vCenter Server によって管理されている場合、仮想マシンの登録は vCenter Server を使用して実行してください。

注：vCenter Server を使用せずに仮想マシンを登録すると、ホストと vCenter Server インベントリの間で不一致が起こり、予期しない結果を招く場合があります。
＝＝＝

vCenter Serverに管理されているESXiホストでインベントリを追加すると予期せぬ挙動が発生することがあるそうです。

もし、どうしてもESXi側で仮想マシンの作成・登録を実施するのであれば、

vCenter Server の管理下から意図的に外すということも１つの手段です。

vCenter Server に管理されているESXiにvSphere Client に直接接続すると、解除のメニューがあります。

■vSphere Client(C#)

■VMware Host Client 

運用時はついついやってしまいそうな操作なので、気をつけたいところです。

また、このような情報は構築するシステム屋さんは意識しないことが多く、構築後の変更作業やトラブル時にも意識がいきづらいものなので、ユーザー側で把握しておきたい内容ではあります。

今回は短いですが、これくらいで。

オワリ

vCSA6.5（vCenter Appliance6.5）をアップデート Build 4602587 -> 5705665

まだあまり、vCSA6.5を利用している環境は多くみませんが、

vCSA(vCenter Appliance)6.5 のバージョンアップ手順をメモ代わりに記載します。

vCSA6.5 からはすごくかっこいい管理画面になっています。

vCSAの管理画面（VMware vSphere® Appliance Management）へのアクセスはブラウザから <FQDN or IPAddress>:5480   でアクセスします。

ログインしたあと [更新] をクリックします。

現在のバージョンなどが表示されます。

バージョンアップには何個か方法があり、[設定]ボタンをクリックすると、

デフォルトのレポジトリからファイルを自動取得する方法か、

自分でレポジトリの指定するか、自分でイメージをダウンロードしてくるかの３つです。

私は面倒だったので、デフォルトのレポジトリから取得する方法で行おうとしました。

しかしエラーになりました。

なぜエラーになるのか、少しだけ調べると、レポジトリの場所のURLをブラウザでアクセスすると、「File not found.」だそうです...。

そのため、アップデートは失敗しました。（これが理由かはよくわからないですが）

自分でレポジトリを作るのも面倒なので、仕方なく手動でダウンロードしてアップデートする方法を実施することにします。

アップデートするための isoファイルはMyVMwareからダウンロードします。

https://my.vmware.com/ja/group/vmware/patch#search

　※ダウンロードには Myvmware アカウントが必要です。

ダウンロードしたisoファイルををデータストアにおきます。

 仮想マシンの編集画面を開きます。

vCSA6.5の仮想マシンにある、CD/DVD drive にisoファイルをマウントします。

データストアにある isoファイルを指定します。

再び vCSAの管理画面にもどり、[更新の確認］ボタンから［CDROMの確認］をクリックします。 すると、利用可能なアップデートが表示されます。

アップデートのインストールボタンをクリック！

ウィザード画面が表示されます。インストールボタンをクリックします。

アップデートが開始されます。ただ待ちます。

100％になりました。[OK]ボタンをクリックして閉じます。

アップデート後は、再起動が必要ですが、自動で再起動されないため、手動で再起動する必要があります。

左のメニューから [サマリ]をクリックします。

[再起動]をクリックします。

しばらく待ってから　<FQDN or IPAddress>:5480   

にブラウザでアクセスします。Build 4602587　から　5705665　にバージョンアップされていることが確認できます。

以上です。

最近あまり、手順系の記事を載せてなかったので、載せてみました。

オワリ

Do you know dcui command? It's useful.

Hello .

Maybe, It is not widely known that ESXi dcui command.

You know?

dcui is Direct Console User Interface.

We can use dcui command in ssh. 

1. ssh Login

2. dcui command execute.

3. Amazing,It is the same as physical Screen. 

4. We can modifing settings for ESXi.

I intorduce VMware KB 2039638.

Accessing Direct Console User Interface (DCUI) from an SSH session (2039638) | VMware KB

■Notice

dcui command is under the sbin directory.

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

[root@localhost:/bin] pwd
/sbin
[root@localhost:/bin] ls | grep -i dcui
dcui
dcuiweasel

[root@localhost:/bin] less dcui
"dcui" may be a binary file. See it anyway?

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

Thanks.

意外に知られていないSSH接続後の dcuiコマンド

こんにちは。

今回は意外に知られていない dcui コマンドについてです。

ESXiの細かな設定変更する際にSSH接続して操作するのはよくあることですが、

SSH接続後には　dcui というコマンドが使えるようになっています。

dcuiは　Direct Console User Interface　の略です。

では、さっそくESXiにTeratermを使って見ていきます。

まずログインです。

SSHログインして早速ですが、dcui コマンドを実行します。（引数無し）

すると、画面を直接見たときの画面と同じ画面が表示されます。

（元々壁紙がミランダ・カーだったのですが、見にくいので一旦　黒の壁紙に変更しました。）

通常通りログインすることができ、操作も可能です。

実は、VMware KB 2096655 でも紹介されていますが、

わざわざ調べる人もいないので、あまり知られていないのではないでしょうか。

SSH セッションからダイレクト コンソール ユーザー インターフェイス （DCUI） へのアクセス (2096655) | VMware KB

一応比較として載せますが、実際のサーバーの画面は、このように見えています。

dcuiコマンド実行後の画面と同じですね。

困った時の１つの手段として、頭の片隅に覚えておくと便利かもしれません。

■補足

dcuiは sbin 配下にあるバイナリファイルで実装されています。

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

[root@localhost:/bin] pwd
/sbin
[root@localhost:/bin] ls | grep -i dcui
dcui
dcuiweasel

[root@localhost:/bin] less dcui
"dcui" may be a binary file. See it anyway?

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

オワリ

例外はありそうだがVMDirectPath I/O はデフォルトで無効になっている（ESXi 5.5 p10, 6.0 p04, 6.0 U3 and 6.5)

こんにちは。

VMDirectPath I/O についてです。

最近VMware KB で、既定値が変わった記述があったり、

状況の変化があったので記事したいと思います。

みなさまご存知の通り、VMDirectPath I/O とは、

サーバーに搭載しているHBA（PCI）などを 仮想マシンに直接割り当てることができる機能です。

細かいアーキテクチャは一切排除したイメージ図です。

VMDirectPath I/Oは、仮想マシンに物理的なハードウェアを連携させる機能なので、

実際に動作保証するのか、それとも保証しないのか、については、

ハードウェアベンダーに依存してしまいます。

要件についてはVMware KB に記載がありますので、ご覧頂ければと思います。

VMware vSphere VMDirectPath I/O：プラットフォームとデバイスの要件 (2144754) | VMware KB

要件に該当しないものをESXiから仮想マシン VMDirectPath I/Oを使ってみせた場合、

案外使えることが多いですが、動作保証しない（いわゆるNot Supported）な構成になります。

動作保証しないものを VMDirectPath I/Oを使って仮想マシンに接続した際に、

何が起こりうるかというと、仮想マシンの停止やESXiのPSOD（Parple Screen of Death）が起こることがあります。

様々なWeb上の情報では、VMDirectPath I/Oは直接仮想マシンに接続されるような言い回しになっていますが、
実際にはESXiが少なからず仲介して、仮想マシンにPCIデバイスを接続させています。

多くのハードウェア割り込み処理を行いながら、仮想マシンに対してデバイスを提供しているので、予期せぬハードウェア割り込みが行われたりするとPSODになってしまったりします。

そこでまずご紹介したいのが、VMware KB 2079988 です。

割り込み再マッピングを使用した場合、ESXi 6.0.x、ESXi 5.x、ESXi/ESX 4.1 で vHBA および他の PCI デバイスが応答を停止する場合がある (2079988) | VMware KB

あまり詳しくないのですが、ESXi/ESX 4.1 以降のバージョンでは、割り込み再マッピング コード（Interrupt Remapping）というものが導入されたらしく、

この機能によって、VMDirectPath I/O が動作するようです。

この割り込み再マッピングの動作がイマイチらしく、VMware KB では以下の症状が出ることを紹介しています。

• ESXi ホストが応答しない
• 仮想マシンが応答しない
• HBA が応答を停止する
• 他の PCI デバイスが応答を停止する
• vCenter Server で「不明デバイスの不正なパス （Degraded path for an Unknown Device）」というアラートが発生する場合がある
• HBA がドライバへの応答を停止する少し前に、VMkernel または messages ログに無効なベクトルのエラーが表示される場合がある。エラーは次のようになります。

対処は、割り込み再マッピングの無効化だそうです。

# esxcli system settings kernel set --setting=iovDisableIR -v TRUE

※ioDisableIR というのをTureにすることで割り込み再マッピングを無効化できます。
 　無効化を有効化するというなんともややこしいパラメータ名......

ここまででお気づきの方もいらっしゃるかもしれませんが、

割り込み再マッピングによって VMDirectPath I/O が実装されているので、

もし、上記の事象が発生したときに、対処である割り込み再マッピングの無効化すると、

VMDirectPath I/O を利用中の環境だと動作しなくなってしまいます。

何ヶ月か前のVMware KB 2079988にはこんな記載があったのですが、現在では削除されていました。

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

注： 割り込み再マッピングを無効にすると、VMDirectPath I/O パススルー機能も無効になります。

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

続いて、VMware KB 2147325 のご紹介です。

ESXi host fails with a diagnostic screen due to an Intel® Virtualization Technology Erratum (2147325) | VMware KB

ざっくりとした内容は、VMDirectPath I/O 機能で利用する割り込み再マッピングが原因でPSODになるというVMware KBです。

対処を一部抜粋します。

Resolution

VMWare recommends contacting the hardware manufacturer for updated BIOS or possible workarounds.

 

Note: A prior version of this KB article recommended that customers experiencing the problem described above work around it by configuring ESXi to disable the Intel® VT-d interrupt remapper (setting boot option iovDisableIR=FALSE and rebooting). VMware ESXi 5.5 p10, 6.0 p04, 6.0 U3 and 6.5 by default disable the Intel® VT-d interrupt remapper for this purpose.

まずはじめに、各サーバーベンダーに確認することやBIOSをアップデートすることが記載されています。 

そして注目すべき点はこの部分です。

「VMware ESXi 5.5 p10, 6.0 p04, 6.0 U3 and 6.5 by default disable the Intel® VT-d interrupt remapper for this purpose.」

非常に重要なことが記載されています…。

以下のESXiからは割り込み再マッピングがデフォルトで無効化されていると記載されています...

 

ESXi5.5 patch10

ESXi6.0 patch4

ESXi6.0 Update3

ESXi6.5 GA 

 

 

OSとしてのデフォルト値について、まさかのVMware KB の一部に記載されています。

もし、今後、VMDirectPath I/Oを利用する環境を構築するときは、割り込み再マッピングを有効化しなければ、仮想マシンにデバイスをうまくパススルーできないと思いますので、注意が必要です。

 

 

私は試してはいませんが、既にVMDirectPath I/Oを利用している環境に対して、

ESXiのバージョンアップを行う際にも注意が必要です。

 

 

理由は、既定値が変更されているので、現在使用中の環境に対してパッチを適用すると、　iovDisableIR　が false から true に変更されてしまう可能性があり、

もし、trueに変更されてしまうと、VMDirectPath I/Oがうまく動作しないと思います。

 

ということで、既定値をコマンドで見てみました。

 

■ESXi5.5

~ # vmware -v
VMware ESXi 5.5.0 build-2068190
~ # esxcli system settings kernel list -o iovDisableIR
Name Type Description Configured Runtime Default
------------ ---- --------------------------------------- ---------- ------- -------
iovDisableIR Bool Disable Interrrupt Routing in the IOMMU FALSE FALSE FALSE

 

なるほど。VMware KB のとおりです。

 

■ESXi6.5d 

[root@xxxxx:~] vmware -v
VMware ESXi 6.5.0 build-5310538
[root@xxxxx:~] esxcli system settings kernel list -o iovDisableIR
Name Type Description Configured Runtime Default
------------ ---- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------- ------- -------
iovDisableIR Bool Disable Interrrupt Remapping in the IOMMU. Not applicable for platforms pre-configured by firmware to use x2APIC (e.g., platforms with > 256 logical processors); for these interrupt remapping is always enabled. FALSE FALSE FALSE

 

 

なにやら、コマンド結果の表示が全く異なっています。

 

しかし、「iovDisableIR Bool Disable Interrrupt Remapping in the IOMMU.」と記載されているので、無効ではあるようです。

 

また「Not applicable for platforms pre-configured by firmware to use」と記載があるため、使用するファームウェアによって事前に構成されている場合は適用されないという記載もあるので、VMware KB の記述は正しいということになるかと思います。

 

 

長々と記載しましたが、私自身、時間が経つと確実に忘れそうな

内容だったので、覚えている間に記事にして備忘録代わりにしました。

 

 

オワリ