VMware製品はこう使うのよ。

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

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

 こんにちは。

 

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

 

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

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

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

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

 

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

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

 

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

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

 

デプロイ自体は完了。

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

(あまりvR Ops 詳しく無いので…)

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

 

ただのメモでした。

 

オワリ

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 の管理下から意図的に外すということも1つの手段です。

 

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

 

■vSphere Client(C#)

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

 

■VMware Host Client 

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

 

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

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

 

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

 

オワリ

 

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   でアクセスします。

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

 

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

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

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

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

 

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

 

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

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

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

 

以上です。

 

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

 

オワリ

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

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

 

2. dcui command execute.

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

 

3. Amazing,It is the same as physical Screen. f:id:japan-vmware:20170611230725p:plain

 

4. We can modifing settings for ESXi.

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

 

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を使って見ていきます。

まずログインです。

 

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

 

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

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

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

 

 

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

 

■補足

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)などを 仮想マシンに直接割り当てることができる機能です。

 

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

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

 

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 の記述は正しいということになるかと思います。
 
 
長々と記載しましたが、私自身、時間が経つと確実に忘れそうな
内容だったので、覚えている間に記事にして備忘録代わりにしました。
 
 
オワリ
 

ESXi6.5 にvSphere Client 6.0(C#)で接続できた(あれ...?)

こんにちは。

 

ESXi6.5 からは主にvSphere Host Client を使ってESXiホスト単体を操作することができ、vCenter で管理されている場合は vSphere Web Client (Flash/HTML5)で操作することが一般的かと思います。

 

ところが、ESXi6.5 にvSphere Client 6.0(C#)がインストールされたPCから接続することができてしまいました。驚いています。(以前からそうだったのか...忘れました)

 

VMware Product Interoperability Matrices

を参照すると、vSphere Client で絞ると6.5の表記は無い。一般にはサポート外というやつかとおもいます。

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

 

■接続するPCの  "プログラムと機能"画面 

vSphere Client 5.5 , vSphere Client 6.0 のみ インストールされています。

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

 

 

■vSphere Client 6.0でESXi6.5に接続する

私の手元の環境はESXi6.5 Build 5310538  でした。

結果ですが、ご覧の通り接続が可能でした。

仮想マシンの作成およびパワーオンもできました。

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

 

海外の人のBlogなどでは仮想マシンのコンソール操作もできない、といったことを言っている人もいるのですが、私の手元の環境ではコンソールからWindowsにログインすることもできました。

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

 

■調べると

Web上の資料を漁っていると、このような情報を見つけました。

VMware vSphere Client 6.5 Feature Support

vSphere Client でサポートしない操作や機能が載っています。

一方でサポートされる操作・機能も記載されています。

 

サポートされない操作や機能が盛りだくさんです。

サポートされない機能が盛りだくさんなので、

VMware Product Interoperability Matrices にはあえて6.5の表記が無いのかもしれません。

 

どちらにせよ、あまりvSphere Client はvSphere 6.5 では使わないようにして、

何かあったときのために、頭の片隅に使用可能なことを覚えておくといいような気がしました。

 

ぜんぜん自信がない記事ですが、書くことで何かいいことがあるといいのですが。

 

オワリ

ESXi6.0/ESXi6.5 - VMware Host Client のセッションタイムアウト値を無くす。

こんにちは。

 

海外で記事にしている人がいたので、忘れないように記事にしようと思いました。

 

VMware Host Client はブラウザベースのアプリケーションであるため、

セッションタイムアウト値が予め設定されています。

デフォルトでは900秒(15分)に設定されています。

 

15分が経過後にセッションタイムアウトされたときの画面がこちら。

 

設定は変更ができるので、メモとして残します。

 

VMware Host Client とはナニ?と思った人は以前の記事を是非見て下さい。

bambi.paddle-point.com

 

 

ブラウザから https://<IP Address>/ui/#/login にアクセスし、rootユーザーでログインします。

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

 

[管理] - [システム]タブ - [詳細設定] - [UserVars.HostClientSessionTimeout] を探す。

デフォルトでは900秒(15分)に設定されています。

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

 

デフォルトの900秒(15分)から 0秒 に設定変更します。

0秒にすることでセッションタイムアウトすることはなくなりますが、

設定を反映するには、VMware Host Client を開き直すか、ログオフが必要です。

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

 

vSphere Client(C#)のときは開きっぱなしでもそのまま使えたので、

セッションのタイムアウトに違和感がある方は設定変更をご検討下さい。

 

ログアウト直前は事前にタブ上にタイムアウトするまでの時間が表示されます。

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

 

タイムアウトしたときはログイン画面に戻ります。

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

 

検証機などには設定しておくと便利かもしれません。

 

オワリ