Skip navigation
1 2 3 Previous Next

naoyuki kaneda's Blog

45 posts

本ブログは3回にわたって執筆している「vCenterとSDDC ManagerのDBをローカルPCにインポートする方法」の第三回目です。

 

前回と前々回の記事はこちらを参照してください。

 

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBダンプ取得方法】

 

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

 

第三回の今回は一回目で取得したDBダンプを、二回目で構築したローカルPCのPostgreSQL DMBSにインポートします。

 

 

DB Dumpファイルの下処理

SDDC ManagerのDBダンプ(postgres-db-dump.gz)は、解凍してテキスト形式(postgres-db-dump)のファイルにさせしてしまえばそれでOKです。

それ自体で完結していますので特に何もする必要はありません。

 

問題はvCenterのDBダンプのほうです。vCenterのVCDBはTablespaceと呼ばれる機能で、DBの一部を別の場所に保存しています。

(この辺りは私の知識ではよくわかってませんが、、)

第一回の記事で、/storage/seat/vpostgres/* の部分をまとめてTarで固めて圧縮しましたが、その部分がTablespaceにあたります。

TableSpaceの場所はDB Dump内にフルパスで記載されてなければならず、VCSAから採取したDB Dumpには当然、/storage/seat/vpostgres/のままになっています。

ローカルのDMBSにインポートする前にこのパスを修正する必要があります。

 

1.vCenter DB Dumpの下準備その①【解凍する】

何はともあれまずは解凍しましょう。話はそれからです。

ローカルPCに転送したtgz形式のファイルを任意の解凍ツールで解凍してください。

以下のファイルが含まれているはずです。

      • vcdb_dump
      • alarmtblspディレクトリ
      • eventtblspディレクトリ
      • hs1tblspディレクトリ
      • hs2tblspディレクトリ
      • hs3tblspディレクトリ
      • hs4tblspディレクトリ
      • tasktblspディレクトリ

 

2.vcdb_dumpファイルをテキストエディタで開いて編集する

次にvcdb_dumpファイルをテキストエディタで開きます。

ファイル自体がとても大きいため、Notepadではスペックが足りません。

※大容量のテキストファイルを開けるエディタを利用してください。もしくは転送前のVCSAにてviなどで編集してから転送してください。(筆者は秀丸を利用してます)

 

 

編集するのは以下のTablespaceについての項目です。

見て分かる通り、TablespaceのロケーションのPathがVCSA内のロケーションにままです。

1.PNG

これを編集して、ローカルPCのロケーション(絶対パス)に書き直します。

 

 

 

以下は書き直した際の例です。書き直す際は実際に実施している環境のPathに置き換えてください。

2.PNG

書き換えが終わったらSaveしてDB ダンプ側の対処は終了です。

 

 

 

PostgreSQL側の下準備

次にPostgreSQL側の事前準備を説明します。

PostgreSQLにpgadminで接続する場合は特に準備は不要なのですが、psqlで接続する場合は事前に対処が必要となります。

psqlはPostgreSQL DBMSを起動した際にすでにpsqlで接続済みの状態となっていますが、このCLIは利用することができません。

まず、psqlのCLIからはDBをインポートできませんし、インポート後にいろいろやっているとすぐにエラーになって使えないことがわかります。

エラーになる理由は私にはわかりませんが、とりあえず、別途psqlを別途起動し、改めて接続すれば問題ありません。

 

しかしながら改めて接続した場合でも、いくつか問題が発生するため事前に下準備をする必要があります。

 

まずはPowershellを起動し、バッファサイズを最大にします。デフォルトのバッファサイズだと少なすぎて表示が切れてしまうからです。

3.PNG

 

 

次に、起動したPowershellで、PostgreSQL DBMSをインストールしたフォルダのどこかにあるpsql.exeを実行すれば、DBMSに接続できるのですが、このままだと文字コードの問題が発生します。

 

 

細かくは説明しませんが、日本語のWindows環境のデフォルトはShift JISなのに対し、DB Dumpの中身はUTF-8なので表示する際に問題が発生するのです。

なので、Powershellの表示文字コードとpsqlのデフォルトの文字コードを両方ともUTF-8にする必要があります。

何はともあれPowershellを起動して以下の2つのコマンドを実行すればOKです。

 

> chcp 65001

> $env:PGCLIENTENCODING = "UTF8"

 

1つ目のコマンドはPowershellの文字コードをUTF8にするためのものです。

2つ目のコマンドはpsqlの文字コードをUTF8にするためのものです。

 

このコマンドを実行したら、一度postgreSQL DBMSに接続してください。以下のコマンドで接続できます。

> psql.exe -U postgres

 

接続したら以下のコマンドをうってエンコードがUTF8になっていることを確認します。

postgres=# SHOW client_encoding;

 

 

一連の流れの例は以下です。

※chcp 65001を実行した直後にPowershellがRefreshされるため、このコマンドの実行行は表示されてません

 

 

Active code page: 65001

PS C:\Users\administrator\Downloads\vcdb_dump> $env:PGCLIENTENCODING = "UTF8"

PS C:\Users\administrator\Downloads\vcdb_dump>

PS C:\Users\administrator\Downloads\vcdb_dump>

PS C:\Users\administrator\Downloads\vcdb_dump>

PS C:\Users\administrator\Downloads\vcdb_dump> C:\Users\administrator\Downloads\PostgreSQLPortable\App\PgSQL\bin\psql.exe -U postgres

psql (10.4)

WARNING: Console code page (65001) differs from Windows code page (932)

         8-bit characters might not work correctly. See psql reference

         page "Notes for Windows users" for details.

Type "help" for help.

 

 

postgres=# SHOW client_encoding;

client_encoding

-----------------

UTF8

(1 row)

 

 

 

 

postgres=#

 

 

DB Dumpのインポートを実行

ここまで確認出来たらいったんpsqlからExitします。Exit方法は\qです。

Exitしたら以下のコマンドで、postgreSQL DBMSにDBをインポートします。

> psql.exe -U postgres -f .\vcdb_dump

 

※-f オプションでdb dumpのファイルを指定しています。インポートするdb dumpは一つだけを想定しています。別のdb dumpをインポートしたい場合は後述の手順でいったんDBをResetし、再度イニシャライズしてからインポートします。

 

インポート中にエラーが出ないことを確認してください。Tablespaceのパスが間違っていた場合は、エラーが表示されます。

※「role "postgres" already exsits 」 というエラーが出るのは問題ありません。それ以外のエラーがでたら内容を確認してください。

 

問題なく完了したら改めて、> psql.exe -U postgres で接続してください。

\l (¥マークと小文字のエル)でDatabaseの一覧を表示すると、インポートされたデータベースが表示されていると思います。

pgadminのGUIからも同様に確認できるはずです。(自動で更新されない場合はrefreshして下さい。)

 

 

 

DMBSの再イニシャライズ方法(ポータブル版のみ)

上記まででDB ダンプのインポートは完了なのですが、別の環境のDBをインポートしようとすると名前がかぶったりしてしまうのでうまくインポートできないはずです。

個別に削除してもいいのですが、ゴミがすべて手動で消すのは面倒なので、再度イニシャライズをしてしまうのが良いです。

ポータブル版の場合、再度イニシャライズするのは非常に簡単です。

ポータブル版のPostgreSQLをインストールしたフォルダにDataというフォルダがあると思います。

Dataフォルダ配下にさらにdata というフォルダがあります。

このdata というフォルダを丸ごと削除して、DMBSを再度起動すればOKです。

    1. まずは既存のPosgreSQL DMBSを終了します。終了方法は起動した際のコマンドプロンプトのpsqlを\qでExitすればOKです。
    2. 次の上記のdataフォルダを丸ごと消してください。
    3. 再度PostgreSQLを起動すれば、DBがイニシャライズされ初期状態になります。(それまでに書き込んだ処理はすべて消えます。)

これでDBMSが初期状態に戻ってますので、きれいな状態で再度あたらしいDB Dumpをインポート可能です。

 

 

 

 

いかがでしたでしょうか。

三回に分けて紹介したDB Dumpのインポートはこれで終了です。

実際には閲覧をするためにはpsqlの使い方やSQL文の知識が必要になりますが、この記事ではカバーしません。

Internet上にわかりやすい記事があると思うので探してみてください。

vCenterとSDDC Managerの内部管理用PostgreSQL DBMSのDB Dumpを、ローカルのPostgreSQL DBMSにインポートする手順の第二回です。

 

本記事は以下の記事の続きに当たります

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBダンプ取得方法】

 

また次回の記事は以下です。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

 

第一回の記事では、インポートするDBのDump取得を説明しました。

今回の記事ではローカルPC(Windows PC)にPostgreSQLをInstallする方法を説明します。

 

PostgreSQLをWindows PCにどのように構築するか

Install自体は難しい作業ではありません。ググればいくらでも手順紹介記事が出てくると思いますし、Installerの入手もたやすいです。

ただし、目的ではDBの一般的な使い方とは異なり、あくまでもDumpされたDBの静止点を閲覧するためだけの用途になります。

そのため、ふつうにInstallするよりも、簡単に削除やResetや再構築が可能な環境となることが望ましいです。

PostgreSQLに限らず、アプリケーションを普通にIntallしてしまうと、レジストリや環境変数などがいじられてしまい、アンインストールしたとしても残滓が完全に消しきれない場合などもあります。なによりInstallすること自体にちょっと懸念がある場合も考えられます。

 

そこで、今回はPostgreSQLのポータブル版を利用することにしました。

ポータブル版であればレジストリや環境変数などに依存せず、インストール場所を指定し、実行ファイルを実行するだけで利用可能になります。

USBメモリなどにインストールして、持ち運び可能なDBにすることもできますし、削除やResetがしたいくなった場合はInstall フォルダを削除するだけでOKです。

 

もちろん、通常インストーラでインストールしても問題ありません。

この記事では通常のインストーラでのインストール方法は説明しませんので、そちらを実施される場合はググっていただければ記事がたくさん出てくると思います。

通常手順でInstallされる場合は、以下の記事の内容は必要ありませんので、第三回にスキップしてください。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

 

ポータブル版のPostgreSQLをダウンロードする

本記事ではあえてダウンロード先のURLを示しません。

https://www.postgresql.org/download/ ではポータブル版が公開されていなかったからです。

ググればPortable 版のPostgreSQLのダウンロードリンクが容易に見つかるとは思いますが、安全性については各自の責任でお願いいたします。

 

またダウンロードするPostgreSQLのVersionについては、目的とする環境と同じか、最も近いものが良いと思います。

 

 

ポータブル版をInstallする

ダウンロードする際にZipやtar.gzなどもあると思いますが、paf.exe 形式のものがあればこれを利用するのが一番容易だと思います。

こちらの実行ファイルをダウンロードして実行すればWizardが現れますので、ダウンロード先のフォルダを選択すれば解凍してすぐに使えるようになります。

 

 

ポータブル版を起動する

ポータブル版のインストールしたフォルダに実行ファイルがありますのでそちらを起動してください。

起動すると自動的にDBのイニシャライズが開始されて、

Initialising database for first use, please wait...

 

といったメッセージがひょうじされます。数分とたたずに利用可能な状態になります。

以下のようなメッセージが出てpostgres=#と出れば完了しています。

'postgres' connected on port 5432. Type \q to quit and shutdown the server.

 

 

psql (10.4)

WARNING: Console code page (1252) differs from Windows code page (932)

         8-bit characters might not work correctly. See psql reference

         page "Notes for Windows users" for details.

Type "help" for help.

 

 

postgres=#

 

試しに \l と入力して、イニシャライズ直後のDBのリストを見てみましょう。

※\l は¥マーク(バックスラッシュ)と、アルファベット小文字のL(エル)です。

postgres=# \l

                             List of databases

   Name    |  Owner   | Encoding | Collate | Ctype |   Access privileges

-----------+----------+----------+---------+-------+-----------------------

postgres  | postgres | UTF8     | C       | C     |

template0 | postgres | UTF8     | C       | C     | =c/postgres          +

           |          |          |         |       | postgres=CTc/postgres

template1 | postgres | UTF8     | C       | C     | =c/postgres          +

           |          |          |         |       | postgres=CTc/postgres

(3 rows)

 

 

 

 

postgres=#

 

こんな感じになっているはずです。

 

 

DB管理ツールをInstallする

通常PostgreSQLをInstallするとpgadminという管理用GUIも一緒にInstallされますがポータブル版にはpsqlのコマンドラインしかInstallされません。

そのため、別途pgadminをInstallすることをお勧めします。

pgadminはGUIでDBを管理したり閲覧したりできるツールなのでSQL文が苦手な人だけでなく、DBの構造を俯瞰したり、ちょろっとDB内の値をいじりたい場合などに便利です。

pgadminは以下からダウンロード可能です。

https://www.pgadmin.org/

 

↑のサイトのダウンロードページからWindows用のInstallerを選んでInstallすればOKです。特に難しい点はないので一直線の作業です。

 

 

pgadminを起動してDBに接続する

インストールしたpgadminを起動すると、ブラウザが起動して自動的にローカルのpgadminのプロセスに接続されます。

1.PNG

 

↑のような画面がでれば成功です。

 

 

 

 

次に、左側の枠内のあるServersのところを右クリックしてCreate > Server...を選びましょう

2.PNG

 

 

 

設定ウィザードが出るので、General タブのNameの項目に任意の名前を入れましょう。

3.PNG

 

 

 

 

 

 

 

 

 

 

 

次にConnectionタブのHostのところにlocalhostと入力して、残りはすべてデフォルトのままSaveボタンを押してください。

4.PNG

 

 

 

 

 

 

 

Saveが完了すると左側の枠に表示が現れます。

5.PNG

 

 

 

展開するとDB内の構造や中身の情報を見ることができます。

6.PNG

 

 

 

 

 

ためしにDatabaseを一つ追加してみましょう。

Databasesのところを右クリックしてCreate->Database....を選んでください。

7.PNG

 

 

 

 

 

 

 

GeneralタブのDatabaseに任意の名前を入れて、Saveして下さい。

8.PNG

 

 

 

 

 

 

Saveが完了すると新しいDatabaseが現れます。

9.PNG

 

 

 

 

 

PSQLのコマンドでも作成したDatabaseを確認してみましょう。

 

 

先ほどの出力と比べるとtestdbがリストに追加されたことがわかります。

10.PNG

 

 

 

pgadminでは、DBに対する様々な操作が可能ですが、その他の操作や閲覧方法については、以下の外部記事がとても分かりやすかったのでこちらをご参考にしていただければと思います。

https://itsakura.com/pgadmin4-db-create

 

 

pgadminの停止方法

pgadminはちょくちょく動作がおかしくなることがあります。

そういう場合はpgadminを再起動すればよいです。

タスクトレイにpgadminの象さんのマークがあるので、それを右クリックしてShutdown Serverを選んで停止し、改めて起動してください。

 

 

今回はPostgreSQL DBMSのInstallとGUI管理ツールであるpgadminを紹介しました。

次回では実際にDumpしたDBをインポートして、内容を確認する作業を説明します。

 

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

VMware製品の調査をしていると、製品が内部に持つ管理DBの中身を見ることがあります。

管理DBの中身を見る方法は、実機で直接DBに接続してSQLコマンドをたたく方法と、Dumpされたテキストファイルを見る方法がありますが、

このブログでは3回に分けてDumpされたDBをローカルのPostgreSQLにインポートして、ローカルで調査する方法を紹介したいと思います。

第一回はSDDC ManagerとvCenterの内部管理DBのDump方法について紹介します。

 

※筆者はPostgreSQLに関する知識は素人に毛が生えたレベルですので不正確な部分についてご容赦ください。また、DB Dumpなどの方法についてはVMwareから提供されている方法を正としていただき、本ブログはあくまでも参考情報としてご利用ください。

 

第2回、第3回の記事は以下です。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

 

 

全体の流れを確認

DB Dumpの取得方法を説明する前に、3回にわたる今回の記事の流れを説明します。

ゴールはVCSAとSDDC ManagerのDBの中身をローカルPCにInstall したPostgreSQL DBMSで閲覧することです。

DBの情報をローカルにコピーする必要があるため、DBの中身をDumpし、それをインポートする流れになります。

そのため、第一回では対象のDBのDumpを取得する方法を説明します。

第二回では実際にDB DumpをインポートするPostgreSQL DBをWindows PCにInstallする手順を示します。

第三回では、DB Dumpを実際にインポートする手順と注意事項などについて説明します。

 

 

SDDC ManagerのDBダンプ取得方法

SDDC Managerの管理DBのDump方法は非常に簡単です。

SDDC Managerのログバンドルを取得するとその中に含まれています。

SDDC Managerはsos utilityで取得できますが、実行の際に--sddc-manager-logs オプションをつけることでSDDC Managerのログバンドルを明示的に指定して取得可能です。

sos utilityを用いたログ採取については下記もご参考ください。

Cloud Foundation システムのログの収集

 

ログバンドルの中にpostgres-db-dumpというファイルがありますので、こちらがDB Dumpに相当します。

 

 

VCDB (vCenter内部管理DB)のダンプ取得方法

こちらについては、VMwareの公式情報が見つからなかったのであくまでもPostgreSQL観点での実施方法になります。

なお、今回の検証で利用しているのは、vCenter Server Applianceの6.7.0-15132721です。

 

0. VCSAのサービスを停止

DB dumpを取得する前に、VCSAのサービスを停止しましょう。

以下のVMware KBを参考にしてください。。

https://kb.vmware.com/s/article/2109887?lang=ja

 

1. postgres ユーザのパスワードを確認する

VCSA内のPostgreSQL DBのpostgres ユーザのパスワードを確認します。

パスワードは.pgpassファイルに書かれており、以下のコマンドで中身を確認できます。

# cat /root/.pgpass

 

2. postgreSQL DBのDumpを取得する

パスワードを確認したらDB Dumpを取得します。

DBのDumpはサイズが大きくなることが想定されるのであらかじめ、容量に余裕のある場所に生成するようにします。

本記事では/storage/core 配下に保存することにします。

/storage/coreはデフォルトで50GBが割り当てられており、障害が発生しない限りほとんど空いてます。

#  cd /storage/core/

 

次にpg_dumpallコマンドでダンプを取得します。以下のコマンドを実行するだけでOKです。

#  pg_dumpall -U postgres > vcdb_dump

 

ファイル名はなんでもいいです。

コマンドを実行するとパスワードが求められますので、1.のステップで確認したパスワードを入力してください。

パスワードを間違えるとエラーメッセージが出ますが、何も出ずにプロンプトが返れば成功です。

 

3. TableSpaceのファイルもまとめて.tgzに固める

VCDBの一部は別の場所に保存されているのでそちらも採取しておく必要があります。

2.のステップで取得したDumpファイルと合わせてtarで固めて圧縮し、転送しやすくしましょう。

以下のコマンドで十分です。

# tar cvzf vcdb_dump.tgz vcdb_dump /storage/seat/vpostgres/*

 

vcdb_dump.tgz がカレントディレクトリ(/storage/core)に生成されているはずなので、これをローカルのPCに転送しましょう。

 

4. VCSAのサービス起動

DB Dump採取前に停止したサービスは忘れずに起動してください。

 

 

今回は、vCenterとSDDC Managerの内部管理用PostgreSQL DBMSのDump方法について紹介しました。

次回はローカルPCにPostgreSQL DBMSをインストールする方法を紹介します。

 

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

本記事ではVxRailのESXi Imageに目的のFixが含まれているかを確認します。

 

 

VxRail の ESXi ImageとVMwareのESXi Imageの差異について

 

VxRailには、ESXiのImageが含まれています。

しかしながら、VxRailのESXi ImageはVMwareから公開されているESXi Imageと必ず同じとは限らず、微妙に差異がある場合があります。

 

では、不具合などのFixを確実に適用したい場合はどうしたらよいでしょうか。

 

 

目的のFixが含まれているかを確認する方法

 

 

目的のFixが含まれていることを確認するもっとも簡単な方法は、VxRailのRelease Noteを見ることです。

重要なSecurity FixなどはReleaseNoteに記載されていることが多いため、容易に確認が可能です。

 

ただしすべてのFixがReleaseNoteに記載されるわけではありませんので、記載のないものについては個別に確認する必要があります。

 

ESXiのImageはZipで固められているので、その中身をみて個別のFixが入っていることを確認するのが一番確実です。

 

 

 

具体的な手順

 

ここでは、以下で報告されているSecurity FixがVxRail 4.7.510に含まれているかどうかを確認する手順を例にとって説明します。

 

 

DSA-2020-118: Dell EMC VxRail Appliance Security Update for Third Party Component Vulnerability in VMware ESXi

https://support.emc.com/kb/543403

 

VMSA-2020-0008

https://www.vmware.com/security/advisories/VMSA-2020-0008.html

 

 

上記のFixはVxRailのReleaseNoteを見るとVxRail 4.7.510に含まれている旨の記載があります。

Release-Notes 4.7

https://support.emc.com/docu91467_VxRail-Appliance-Software-4.7.x-Release-Notes.pdf

 

 

 

本当に含まれているかを、VxRailのUpgradeファイル内のESXi Imageを展開して確認してみましょう。

VMSA-2020-0008 によると、ESXi 6.7でのFixed Versionは、ESXi670-202004103-SG

だとあります。

My VMwareのProduct Patchから、このFixはESXi670-202004002 に含まれていることがわかります。

 

 

 

 

ESXi670-202004002のリリースノートを見てみると以下の記載があります。

 

 

 

 

 

つまり、VMware_bootbank_esx-ui_1.33.7-15803439のVIBがVxRail 4.7.510のESXi Imageに含まれていればよい、ということになります。

 

 

では、実際にVxRail 4.7.510のUpgradeファイルをダウンロードして中身を確認しましょう。

https://dl.dell.com/downloads/DL98593_VxRail-4.7.510-Composite-Upgrade-Package-for-4.7.x.zip

 

 

こちらのZIPを確認すると、以下のようなディレクトリ構造が見えますので、bundles → ESXi-xxx.zip と辿ってESXi Imageを入手します。

 

 

 

このESXi-xxx.zipを解凍するとさらにディレクトリ構造がありますので、metadata.zipをさらに解凍します。

 

 

metadata.zipに含まれる、vmware.xmlファイルを開きます。

 

 

このファイルの中で先ほど調べたVIB(VMware_bootbank_esx-ui_1.33.7-15803439)を検索します。

 

 

対象のVIBが確認できましたのでこのVersionには問題なくFixが含まれていることを確認できました。

VMware ブログ(Jiveのプラットフォーム)で、前からちょっと困っていたことがありました。

それは引用やテーブル機能を利用した際にインデントが反映されないということです。

 

記事を書いていると、項目ごとにインデントを加えたりして見やすくすると思いますが、テーブルや引用を利用するとその部分だけインデントされずに、ちょっとイマイチな感じになります。

例えば以下です。

 

 

インデント済み

 

インデントされない

 

インデントされない

 

インデントされた

 

 

上記のようにテーブルや引用に対して、インデントを実行しても枠自体はインデントされず、中身のコンテンツがむなしくインデントされるのみです。

これに対する解決策として、記事のHTMLを直に編集する、という手段があります。

HTMLエディターは以下の場所をクリックすることで開けます。

0.PNG

 

 

HTMLエディターを開いたら、対象のテーブルや引用を<div style="position: relative;left: 80px;">と</div>で囲みます。

具体的には以下のようにします。

 

1.PNG

 

すると以下のようにインデントされたかのようにすることができます。

要素内で80pxとしているところの数字を変えれば、左側からのずらし幅を調整できます。

 

 

インデントされた

 

インデントされた

 

 

この方法を見つけたので今後は記事作成のストレスが軽減されそうです。

もっと早く調べておけばよかったなと思いました。

この記事では、VxRail のGUIからSRS設定と正常稼働モニタリング設定の確認方法を説明します。

 

 

 

【VxRail 4.0.x/4.5.x/4.7.0x】VxRail Manager GUIからの確認

SRSステータスの確認

無効の場合

日本語表示

1.png

英語表示

2.png

有効の場合

日本語表示

3.png

英語表示

4.png

正常動作モニタリングの設定確認

※正常性モニタリングの項目が「Suppress Mode」や「抑制モード」という項目で表示される場合があります。その場合は下記のDell EMC コミュニティをご参照ください。

https://dell.to/2zq9qQI

 

無効の場合

日本語表示

7.png

英語表示

8.png

有効の場合

日本語表示

5.png

英語表示

6.png

 

 

【VxRail 4.7.x/7.x】vCenter Plugin からの確認

SRSステータスの確認

無効の場合

日本語表示

9.png

英語表示

10.png

有効の場合

日本語表示

11.png

英語表示

12.png

 

正常動作モニタリングの設定確認

無効の場合

日本語表示

13.png

英語表示

14.png

有効の場合

日本語表示

15.png

英語表示

16.png

vSphere Update Manager(VUM)からvSphere Lifecycle manager (vLCM)への変更

vSphereの標準のUpgrade機能であったVUMからvLCMに変更された。Upgrade前のPrecheck機能が追加されたことにより、より安全にUpgradeを遂行できるようになった。

また、DellとHPEが提供するPluginを利用することによってFirmwareやDriverのUpgradeも可能になった。

ただし、VxRail環境ではこの機能は使うことができず、以下のようにエラーになる

 

1.png

 

参照URL

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere-lifecycle-manager.doc/GUID-74295A37-E8BB-4EB9-BFBA-47B78F0C570D.html

https://tinkertry.com/how-to-upgrade-from-vsphere-6-7-to-7

 

 

vSAN7 がNative File Serviceを提供

vSANはこれまで仮想マシンを格納するためのデータストアとしての機能や、vSAN外部に対してiSCSIストレージとして動作することが可能だったが、今回あらたにNAS Storage機能が追加された。

NASサービスを有効化すると、NASを提供するための仮想マシンがOVAからデプロイされ各ホスト(最大8ホストまで)に配置されるため、リソースを消費する。

またvSAN Skyline healtcheckにFileService用の項目が増える

これまでは、NASが必要な際はvSANの外部に別途構築したり、vSANデータストア上の仮想マシンにNASのサービスをインストールする必要があったがその必要がなくなった。

プロトコルとしてNFS v4.1 とv3が提供されるがCIFS/SMBの機能はない。

vSANが提供するNFSをESXiにマウントして仮想マシンのVMDKを保存するためのデータストアとして利用することはできないが、vSAN Cluster上の仮想マシンに対して直接マウントさせることは可能。

ファイルサービス用にデプロイされたVMではコンテナが動作している。そのため、障害時やメンテナンス時はvMotionやHAは使われずにコンテナのサービスが自動で移動する

 

 

https://blogs.vmware.com/virtualblocks/2020/03/10/announcing-vsan-7/

https://storagehub.vmware.com/t/vsan-frequently-asked-questions-faq/file-service-7/

https://www.youtube.com/watch?v=Zzp1E4d4eIw

 

 

2.png

3.png

 

4.png

PSCがEmbeddedのみになる。

vSphere 6.xで推奨されていた外部PSC構成は非サポートとなり、内蔵型のPSCのみがサポートとなる。

VxRailで内部VCSAを利用していた場合は、Upgrade時に自動でEmbedded PSC構成に代わる。

外部VC構成だった場合は、VC側のUpgradeを行った後に、VxRail Managerにて、構成を一致させる処理が必要になる

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vcenter-server-7-migration-upgrades.html

 

 

Windows Server 版のvCenterが使えなくなる。

7.0 からはVCSAのみが利用可能なため、現在Windows 版のVCを使っている場合はマイグレーションが必要になる。

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vcenter-server-7-migration-upgrades.html

 

vSphere6.0.x (VxRail 4.0.x) からはUpgradeできない

vSphere 7.0  へアップグレード可能なのはvSphere 6.5/6.7のみであり、6.0からの直接のUpgradeはできない。

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vcenter-server-7-migration-upgrades.html

 

 

DRSのエンハンスメント

DRSはこれまでESXiレベルでのパラメータに基づき負荷分散をしてきたが、vSphere 7.0では仮想マシンレベルのパフォーマンスに基づき移動させるように変わった。

また、モニタリング頻度も5分から1分に短縮された

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-improved-drs.html

 

vMotionのエンハンスメント

vMotionのパフォーマンスが改善され業務影響が減った

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vmotion-enhancements.html

 

ライセンスのUpgradeが必要

vSphere6.xでは6.0/6.5/6.7で共通のライセンスが利用可能だったが、vSphere7ではUpgradeする必要がある。

https://kb.vmware.com/s/article/2006974

 

VCF4 & Kubernetes関連

vSphere 7.0はVCF4と対応する。Kubernetesとの連携も強化されている

https://vmusketeers.com/2020/03/10/vcf4-vsphere-7-vsan7-vrops-8-1-and-everything-else/

https://blocksandfiles.com/2020/03/10/vmware-vsphere-7-kubernetes/

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-tanzu-kubernetes-clusters.html

https://blogs.vmware.com/vsphere/2020/04/how-to-get-vsphere-with-kubernetes.html

 

VCSAの複数vNIC設定が可能になった

vCenterのマルチホームが可能になった。

ただしVxRailのInternal VCSAで使えるかどうかは要確認

https://www.vladan.fr/what-is-vcenter-server-7-multi-homing/

https://www.youtube.com/watch?v=2kFZXa9lloM

 

 

参考ブログ・ドキュメント

https://www.vmware.com/products/vsan/whats-new.html

https://lab8010.com/announcing-vsan-7-summary/

https://lab8010.com/introduction-vsphere-7-summary/

https://vmusketeers.com/2020/03/10/vcf4-vsphere-7-vsan7-vrops-8-1-and-everything-else/

本記事では、VMware Flingsで提供される無償のCross vCenter vMotionツールについて紹介します。

前回までの記事は以下です。

 

        既存環境からvSAN 環境へのMigration:その① 【イントロダクション】

既存環境からvSAN 環境へのMigration:その②  【PowerCLIのInstall】

既存環境からvSAN 環境へのMigration:その③ 【既存環境からのvMotion】

【VxRail】 続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】

 

 

本シリーズの久々の投稿となります。

本シリーズは、Non-Shared SSO環境(≒ ELMなし)のvCenter間でのvMotionについて、PowerCLIを利用した方法を解説してきました。

今回はPowerCLIから離れて、より簡単に同じことが実施できるツールについて紹介させていただきます。

 

VMware Flingsとは?

今回紹介するツールはVMware Flingsで公開されてます。

     Flings | VMware Flings

VMware Flingsとは何なのか?という疑問に思う方もいらっしゃると思います。

VMware Flingsのサイトにアクセスするとトップに以下の説明(?)がありました。

     Flings are apps and tools built by our engineers and community that are intended to be explored.

 

つまり、vmwareの有志のエンジニアが作成している各種便利ツールをやアプリを公開している場です。(だと理解してます)

ここで公開されているツールは、基本的にvmware製品サポートには含まれませんが、便利だと思います。(需要があれば)

 

Cross vCenter Workload Migration Utility

今回ご紹介するツールは、以下のURLからダウンロードできます。

Cross vCenter Workload Migration Utility | VMware Flings

 

使い方は非常に簡単で、JRE(Java Runtime Environmen)がInstallされているWindows PCで実行するだけです。

ダウンロードページのInstructionと、Look & Feelで使えるとは思いますが、改めて本ブログでも紹介させていただきます。

 

メリットとデメリット

メリット

非常に簡単

コマンドを打たなくていい

環境要件が緩い(PowerCLIも不要)

PowerCLIでネックとなった、vNICの接続ポートグループも個別に指定可能

 

デメリット

ツール自体はサポート対象ではない(PowerCLIも通常のサポートには含まれないので差はないかも?)

失敗した場合のトラブルシューティングには、通常のCross vCenter vmotionと同等の知識が必要となる

 

環境要件

Requirementは以下のようになっています。

 

  • vCenter Server 6.0 Update 3 or above (ESXi hosts must also be 6.0u3+
  • Java Runtime Environment 1.8-10
  • Web Browser
  • Please review https://kb.vmware.com/kb/2106952 for Cross vCenter vMotion requirements

 

注意点は特にないです。vSphere 6.x以降であれば6.0~6.5~6.7で相互にvMotionすることも可能です。(執筆時点では7.x以降との互換性については不明)

Javaは1.8.-10となってますが、筆者の環境はJava Build 1.8.0_231で動いてますので厳しい制限ではないと思います。

Javaが入っていればWindowsに限らないはずですが、筆者は試してません。

ブラウザはChromeでOKです。

Cross vCenter vMotionの制限はKBを参照いただく通りですが、EnterprisePlusライセンスが必要、という点は重要です。それ以外は工夫で何とかなると思います。

 

 

使い方

Note: Windows環境での利用を想定しておりますが、Linux環境でも同様だと思われます。

 

まずはファイルをダウンロードしましょう。

1.PNG

 

 

 

 

 

 

 

使い方は非常に簡単で、PowerShellかコマンドプロンプトを開いて、ダウンロードしたjarファイルを以下のような形で実行してあげるだけです。

PS C:\Users\Administrator\Downloads> java -jar .\xvm-3.1.jar

 

 

ファイル名は実際にダウンロードしたファイル名を指定してください。Versionにより異なります。

 

 

公式のInstructionでは起動時にvCenterの情報を指定する方法が示されていますが、指定せず後で入力する形のほうがシンプルですので、こちらの方法を採用しています。

 

 

 

 

実行が完了すると以下のような出力が出ます。

 

PS C:\Users\Administrator\Downloads> java -jar .\xvm-3.1.jar

14:48:00 INFO  *** Cross vCenter vMotion Utility ***

14:48:02 INFO  Starting ApiController v3.1 on SAMPLEPCNAME with PID 8016 (C:\Users\Administrator\Downloads\xvm-3.1.jar started by kanedn in C:\Users\Administrator\Downloads)

14:48:04 DEBUG Running with Spring Boot v2.0.3.RELEASE, Spring v5.0.7.RELEASE

14:48:04 INFO  No active profile set, falling back to default profiles: default

14:48:09 INFO  Using app port 8443. The default port is 8443 and can be changed by using the -Dserver.port flag

14:48:09 DEBUG Initialized controller with empty state

14:48:13 INFO  Started ApiController in 12.276 seconds (JVM running for 15.589)

14:48:13 INFO  XVMotion app initialized successfully!

 

 

 

 

 

ここまで出力されていれば、実行は完了です。

 

 

 

 

JavaのプログラムがWindows PC上で実行されてますので、ブラウザでアクセスしましょう。

 

2.PNG

https://localhost:8443

デフォルトでは8443ポートが利用されます。変更することも可能ですが、多くの場合は変更不要と思います。

 

 

 

 

 

 

ページが開いたらまずMigrateボタンを押します。

3.PNG

 

 

 

 

 

次にRegisterボタンを押します。押した先でソースとターゲットになるvCneterを登録します。

4.PNG

 

 

 

 

 

 

この段階ではまだ何も登録されていないはずですが、登録されているvCenterがある場合は以下のように表示されます。

5.PNG

 

 

 

 

 

 

新規で登録する場合はフォームに従って必要な情報をいれてSubmitを押します。

6.PNG

 

 

 

 

 

ソースとターゲットの両方を登録しましょう。

2つ登録されていると以下のようになります。

7.PNG

 

 

 

 

 

登録が終わったらMigrateボタンをして、vMotionの設定に移ります。

※vMotion Utilityという名前ですが、Cold Migrationも可能です。

 

必要事項を入力してSubmitを押すだけです。

8.PNG

 

実行開始るとTask Informationのページに移ります。

 

9.PNG

 

おっと、今回はすぐにErrotとなってしまいました。

errorのところをクリックするとInfoのところに原因などを教えてくれます。

が、個々の情報だけではわからないことが多いです。

 

10.PNG

 

 

 

問題が発生した場合は、vCenter側のログを見る必要があります。

vMotionが開始されるとソースのvCenter側でもタスクができます。Taskの実行状況はvSphere ClientのGUIから確認できます。

失敗した場合は、Taskのエラーメッセージから何か判断できることもあります。

Taskのメッセージからも判断できない場合は、vCenterやESXiのログを見る必要があるでしょう。

 

原因を排除してvMotionがうまいく言った場合、Task InformationのStatusがRunningになり、Progressバーが進行してやがて100%になります。

100%になってもすぐに終了ではなく、StatusがRunningからSuccessになるのを待ちましょう。Successになるまで終了ではありません。

なお、RunningになればGUIを閉じてもTaskは中断されず最後まで実行されます。

 

 

 

 

 

トラブルシューティング

今回はラボ環境でしたが数多くの失敗に遭遇しました。

失敗した場合は以下の流れで見ていくのが良いと思います。

 

1.Cross vCenter Workload Migration Utility のWebUIのErrorメッセージ

2.Utility 起動時に利用した、PowerShell実行画面のメッセージ

3.各vCenter GUIの最近のタスクと詳細情報

4.vCenterのログ(vpxd.log)

5.ESXiのログ(vpxa.log およびhostd.log)

 

代表的な失敗例を挙げてみましたので、トラブルの際にはご参考にしていただければ幸いです。

    1. 仮想ハードウェアVersionに互換性がある

    2. DVSのversionがおなじ(踏み台VDSが必要)

    3. TargetはClusterではなく単体ホストを指定。(Not RespondingがあるためCluster指定だとうまくいかない場合がある。)

    4. vCSAがお互いに名前解決可能

    5. vMotionネットワーク間で疎通がある。

 

1は移行先のClusterで仮想ハードウェアのバージョン相互運用性がある必要があります。Versionの新しいほうから古いほうに移行する場合に注意が必要です。

 

2はDVS Versionの制限です。移行先と元でVDS Versionが同じである必要があります。VDSは複数持てるので、同じVersionのVDSを踏み台VDSとして作成すれば問題ありません。

ただし、踏み台VDSには最低でも1つ以上のUplinkが必要です。Uplinkがない場合はVDSの候補として出てきません。

 

3は、移行先のターゲットリソースとして、Clusterではなく、ホスト単体を指定したほうが良い、という経験上のBest Practiceです。Cluster配下のHostに障害(Not Respondingなど)がある場合、移行が失敗することがあります。そういう場合は単体ホストを明示的に指定して移行を開始すれば回避できます。ただし、この方法では自動で負荷分散がされないので注意が必要です。移行した先にDRSによる負荷分散が実行される場合もあると思いますが、すべてのvMotionを単体ホストで実行した場合、vMotionの同時実行数の制限に抵触する可能性がありますので、やはり移行の段階から分散したほうが無難です。参考:Limits on Simultaneous Migrations

 

4は、名前解決の問題です。vCenterが対向サイトのリソース(vCenterやHostなど)を見つけるときに名前解決が必要となります。DNSの設定に留意ましょう。

 

5は、vMotionネットワーク間での疎通についてです。当然ながらソースホストとターゲットホストでvmotionネットワークに疎通がなければvmotionできません。

vmotionネットワークの疎通が難しい場合、Cold Migration (仮想マシンがPowerOff状態)にすれば、Management ネットワークが利用されますのでワークアラウンド可能です。

 

1以外は基本的にどうにかなりますが、1の仮想ハードウェアは一度上げたものは下げれません。Versionの古いClusterに移行する可能性がある場合は、仮想マシンを作る段階で6.0~6.7で互換性のあるVersionを選んで置き、迂闊にUpdateしないことが重要です。

 

 

 

いかがでしたでしょうか?正直なところ、苦労してPowerCLIでやるよりもこっちのほうがいいと思います。

サポート対象でない、という点ではPowerCLIとほぼ同等ですし、こちらのツールであればPowerCLIのように作りこむ必要性がありません。

ぜひお試しいただければと思います。

VxRailなど、PowerEdge上にESXiをInstallしている場合、トラブルシューティングや初期構築などでiDRACの仮想コンソールに接続することはしばしばあると思います。

先日、ESXiのInstall用途で、iDRACの仮想コンソールにJavaで接続しようとしたら、エラーになって接続できないことがありました。

 

結論からいうと、iDRACのFWをUpdateするか、Javaのセキュリティファイルの設定を書き換えることで解決できました。

その時のトラブルシューティングを記します。

 

 

事象

キャプチャをとればよかったのですが、残念ながら取り損ねてしまいました。

英語でのキャプチャが欲しかったので後で事象を再現させて取ればよい、と楽観していたところ再現しなくなってしまったので取れずじまいです。

 

事象としては、idracの仮想コンソールにJavaで接続しようとした際に、Javaのアプレット(?)が起動した直後に「ビューワが切断された~」みたいなメッセージがでて接続できないという事象でした。

 

トラブルシューティング

Javaのコンソールやトレースを有効化する

Javaのエラーを見れば何かわかる、と思ったのでJavaのコンソールやロギングを有効化しました。

有効化は、コンパネからJavaのコントロールパネルを開き、AdvancedタブからConsoleやLoggingやTracingのチェックを入れればいいだけです。

1.PNG

 

事象を再現してログをみる

コンソールとロギング・トレーシングの設定をしたら、もう一度事象を再現させて、ログを見ればよいです。

実際に記録されていたログは以下です。

2020年2月19日

4:07

 

 

Java Web Start 11.241.2.07

Using JRE version 1.8.0_241-b07 Java HotSpot(TM) Client VM

JRE expiration date: 20/05/17 0:00

console.user.home = C:\Users\Administrator

----------------------------------------------------

c:   clear console window

f:   finalize objects on finalization queue

g:   garbage collect

h:   display this help message

m:   print memory usage

o:   trigger logging

p:   reload proxy configuration

q:   hide console

r:   reload policy configuration

s:   dump system and deployment properties

t:   dump thread list

v:   dump thread stack

0-5: set trace level to <n>

----------------------------------------------------

Missing Application-Name manifest attribute for: https://ip.ex.am.ple:443/software/avctKVM.jar

replace numpad

** Max Size: W = 1920 H = 1040

** Window Pref Size: W = 1040 H = 823

** Max Size: W = 1920 H = 1040

** Window Pref Size: W = 1040 H = 823

JNLPClassLoader: Finding library VMAPI_DLL.dll

JNLPClassLoader: Finding library jawt.dll

JNLPClassLoader: Finding library avctKVMIO.dll

ProtocolAPCP.receieveSessionSetup : v1.2 APCP = true

APCP Version = 259

 

 

 

 

Supported protocols: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

 

 

 

 

Enabled protocols: [TLSv1, TLSv1.1, TLSv1.2]

 

 

 

 

Supported ciphers: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

 

 

 

 

Enabled ciphers: [SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5]

 

 

 

 

Exception in server handshake

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

at sun.security.ssl.Handshaker.activate(Unknown Source)

at sun.security.ssl.SSLSocketImpl.kickstartHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.b(Unknown Source)

at com.avocent.d.d.b.a(Unknown Source)

at com.avocent.a.b.w.g(Unknown Source)

at com.avocent.a.b.w.a(Unknown Source)

at com.avocent.app.c.l.m(Unknown Source)

at com.avocent.app.c.l.e(Unknown Source)

at com.avocent.idrac.kvm.a.e(Unknown Source)

at com.avocent.idrac.kvm.Main.a(Unknown Source)

at com.avocent.idrac.kvm.Main.main(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.sun.javaws.Launcher.executeApplication(Unknown Source)

at com.sun.javaws.Launcher.executeMainClass(Unknown Source)

at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)

at com.sun.javaws.Launcher.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

at sun.security.ssl.Handshaker.activate(Unknown Source)

at sun.security.ssl.SSLSocketImpl.kickstartHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.b(Unknown Source)

at com.avocent.d.d.b.a(Unknown Source)

at com.avocent.a.b.w.g(Unknown Source)

at com.avocent.a.b.w.a(Unknown Source)

at com.avocent.app.c.l.m(Unknown Source)

at com.avocent.app.c.l.e(Unknown Source)

at com.avocent.idrac.kvm.a.e(Unknown Source)

at com.avocent.idrac.kvm.Main.a(Unknown Source)

at com.avocent.idrac.kvm.Main.main(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.sun.javaws.Launcher.executeApplication(Unknown Source)

at com.sun.javaws.Launcher.executeMainClass(Unknown Source)

at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)

at com.sun.javaws.Launcher.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

CoreSessionListener : connection failed

in CoreSessionListner : fireOnSessionStateChanged

KVM session state SESSION_FAILED

Javaのログを見慣れない人でも何となく赤くした部分を最初に見るのではないかと思います。

その部分を見ると何やらProtocalだか、Cipher Suiteだかが適切でないように思えてきますね。

 

Javaのセキュリティ設定を緩めにしてみる

Googleで、「Java Cipher Legacy」とかでググってみたところ、どうやら設定ファイルをいじると古いプロトコルも使えるようです。

以下の場所ファイルを編集して、ProtocolとかCipherをDisableにしている行を片っ端からコメントアウトしてみました。

もちろん編集前にバックアップを取っておくべきことは言うまでもありません

 

C:\Program Files (x86)\Java\<java version>\lib\security\java.security

 

実際には以下の項目をコメントアウトしました。

※コメントアウトした行のみを抜粋

##jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \

##    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224

 

##jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024

 

##jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \

##    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

 

 

コメントアウトしたのちに、再度接続を試みました。

 

接続成功!!

今度はエラーで切断されることなく接続することができました。

その際のJavaコンソールの出力は以下(ProtocalとCipherの部分のみ抜粋)でした

 

Supported protocols: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

 

Enabled protocols: [SSLv3, TLSv1, TLSv1.1, TLSv1.2]

 

Supported ciphers: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, TLS_DH_anon_WITH_AES_256_GCM_SHA384, TLS_DH_anon_WITH_AES_128_GCM_SHA256, TLS_DH_anon_WITH_AES_256_CBC_SHA256, TLS_ECDH_anon_WITH_AES_256_CBC_SHA, TLS_DH_anon_WITH_AES_256_CBC_SHA, TLS_DH_anon_WITH_AES_128_CBC_SHA256, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_DH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_ECDH_anon_WITH_RC4_128_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, TLS_RSA_WITH_NULL_SHA256, TLS_ECDHE_ECDSA_WITH_NULL_SHA, TLS_ECDHE_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_SHA, TLS_ECDH_ECDSA_WITH_NULL_SHA, TLS_ECDH_RSA_WITH_NULL_SHA, TLS_ECDH_anon_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5]

 

Enabled ciphers: [SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5]

失敗していた時とのログを見比べると、Enabled ProtocalでSSLv3が増え、Supported Cipherの項目も内容が大きく増えていることがわかります。

その結果、Enabled cipherとSupported Cipherで共通するCipherが現れました。

 

想像ですが、JavaのCipherに関する設定を緩くしたことでEnabled とSupportedの内容で一致するものが出てきたことで接続できるようになったものと思われます。

 

iDRACをFWのUpdateをしたら再現しなくなった

ESXiのInstallとFWのUpgrade作業を終えた後に再度事象を再現させようとしたところ、設定ファイルを戻しても再現しませんでした。

おそらく、FWのUpgradeにiDRACのUpdateが含まれており、それによりJavaのアプレットも更新されたことでCipherの問題が出なくなったと想像してます。

 

JavaのVersionにも依存?

きちんと切り分けをしたわけじゃないですが、いくつかの端末では設定ファイルをいじらなくても接続できるものがありました。(iDRAC Update前)

おそらくは、端末にインストールされているJavaのVersionによってはセキュリティ設定のデフォルト値などの関係で影響を受けずに接続できるものと思われます。

(そうじゃないといろいろおかしい)

 

まとめ

新しいJavaと古いiDRAC FWの組み合わせで、仮想コンソールにJavaアプレットで接続できない場合があることがわかりました。

解決方法としては、iDRAC FWをUpdateするか、Javaのセキュリティファイルをいじって古いプロトコルや暗号方式を有効化することで回避できます。

JavaのVersionを古いもの(理想はiDRAC FWのリリース当時のJava)にすることでも解消できそうですが、未検証です。

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

この記事では、vCenterからvSANクラスターを管理、トラブルシュートする際に用いられるCLIユーティリティ、

RVC(Ruby vSphere Console)の超基本的な使い方について紹介します。

RVCでは、vSANクラスターの状態確認・リソースの使用量や各Object・Componentの参照等、一般的な情報の参照からハイレベルな調査まで様々な作業が可能です。

vSANクラスターに障害が発生した場合の解析や、GUIからは実施できないような細かい設定を伴う作業をvSANクラスターに行う場合にも用いられます。

詳細な利用方法については文末のリファレンスをご参照ください。

 

 

1. ログイン

vCSAにSSHでログイン後、下記のコマンドでログインします。

認証には、vCenter SSOアカウントを使用してください。

    ※vCSAのSSHを無効化している場合は、下記手順にて有効化が必要です。

    VxRail: ESXi、vCenter、PSCのSSH有効化

# rvc

Install the "ffi" gem for better tab completion.

Host to connect to (user@host): administrator@vsphere.local@localhost  < vCenter SSO ユーザー名@localhostを入力

password:                                                                                          < vCenter SSO パスワードを入力

0 /

1 localhost/

>

 

rvcコマンドと同時にユーザー名を指定でもログイン可能です。

# rvc administrator@vsphere.local@localhost          < vCenter SSO ユーザー名@localhostを入力

Install the "ffi" gem for better tab completion.

password:                                                                                   < vCenter SSO パスワードを入力

0 /

1 localhost/

>

 

2. パスの移動、参照

RVCでは、vSANを構成するリソースがファイルシステムのようなツリー構造で表現されています。

RVCコマンドでは各リソースのパス(RVCの公式ドキュメント等ではObjectと呼ばれています)を指定して実行する必要がありますので、どこにどのリソースが配置されているかを漠然と把握しておくとスムーズに作業が行えます。

とはいえ、難しく考える必要はなく一般的なUnixベースOSと同じ要領でls・cd コマンドで参照・移動を行うだけです。

お馴染みの矢印キー↑↓でのコマンド履歴参照や、Tabキーによるオートコンプリートも可能です。

 

各パスは、一般的なUnixベースOSと同じくフルパス指定、相対パス指定の他、./(カレントディレクトリ)、 ..(1つ上位のディレクトリ)などで参照可能です。

 

vSANのトラブルシュートでは、vSANのコンピュートリソースのパスを指定してコマンドを実施する場合が多いです。

一般的には、vSANコンピュートリソースのパスは下記に配置されています。

 

/localhost/データセンター名/computers/vSANコンピュートリソース(vSANクラスター名)

  

 

例として、"vsan.check_limits"コマンドを使用してみます。

vsan.check_limitsは、vSANクラスター内の各ホストのディスク使用率や、ネットワークの制限項目を参照するコマンドで、vSANコンピュートリソースを引数に指定して実行します。

 

※画像は適宜クリックで拡大してください

※↓はgif動画です

1.gif

 

例のようにフルパス指定や相対パス指定でコマンドを実行できます。

 

また、特殊なパス指定の方法として、インデックス指定があります。

RVCでは各ディレクトリにインデックスが付いており、パス名を入力しなくてもインデックスをコマンドの引数にすることが可能です。

 

2.png

 

インデックス指定でコマンドを実行する際には一点クセがあり、一旦lsコマンドでパスに対するインデックスを参照してから引数に指定する必要があります。

 

3.png

 

3. Tips

vSANのコンピュートリソース等、長いパスをいちいち指定、コピペするのが面倒な場合は、markコマンドでパス名に略称を付与することができます。

尚、markコマンドで付与した略称はセッション限定ですので、RVCからログアウトすると設定が消えます。

mark <任意の略称> 対象のパス

  

 

markコマンドで付与した略称をコマンドの引数に指定するには、略称の前に"~"を付けます。

 

4.png

 

以上

 

 

関連記事:

CLIによるvSANリバランス

Deployment - which DLLs do you need?

RVCを活用した情報収集

RVCを活用してアラーム情報を取得する

 

参考文献:

VMware Virtual SAN Diagnostics and Troubleshooting Reference Manual

VMware® Ruby vSphere Console Command Reference for Virtual SAN

Ruby vSphere Consoleの使い方(起動/ログイン/基本操作編) - VMwareな日々

いったいどれくらいの人がこのナレッジの恩恵を受けるのかは不明ですが、一応共有しておきます。

※VMTNはJiveと呼ばれるプラットフォームを使っているはずですので、同じプラットフォームを使っている場合は流用可能と思います。

 

問題定義

日々日本語でVMware関連のナレッジを発信している筆者ですが、ちょっと前までURLがごちゃごちゃするのが悩みでした。

具体的には以下のような感じになってしまいます。

ブログ名:【VxRail】既存環境からvSAN 環境へのMigration:その① 【イントロダクション】

URL:https://communities.vmware.com/people/nkaneda/blog/2019/09/24/vxrail-%E6%97%A2%E5%AD%98%E7%92%B0%E5%A2%83%E3%81%8B%E3%82%89vsan-%E7%92%B0%E5%A2%83%E3%81%B8%E3%81%AEmigration-%E3%81%9D%E3%81%AE-%E3%82%A4%E3%83%B3%E3%83%88%E3%83%AD%E3%83%80%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

 

上記を見ればわかるように日本語のタイトルでブログを執筆するとタイトル=URLになる関係上、マルチバイト文字がURLエンコードされて、かなりごちゃごちゃします。

筆者はブログを仕事でも活用(ナレッジの紹介など)しているため、URLがごちゃごちゃするのが何となく嫌でした。URLだけみてどの記事なのかの判別も不可能ですし。。。

 

ちなみに上記の仕組みにはもう一つ難点があって、上の例ですとブログタイトルの「その①」の①の部分がどうやら環境依存文字として正しく認識されないらしく、②も③も同じタイトルして扱われてしまうようです。そのため、②や③を執筆すると同じURLになってしまう、という不具合があります。

 

解決方法

この問題の解決方法はいたってシンプルです。

最初にブログを作成するときにASCII文字だけでタイトルを設定し、Save Draftで保存します。

すると、この段階でのブログタイトルでブログのURLが作成されます。

そのあと、ブログタイトルを変えたとしてもURLは維持される仕様のため、URLがエンコードによってごちゃごちゃするのを防げます。

下記の図は、本ブログを作成したときの様子ですが、いったんASCII文字のみでブログタイトルを記述しているのがわかると思います。

そしてこの時のタイトルが、いまあなたがアクセスしているURLに反映されます。

1.PNG

 

大したことのないナレッジですが、これによってURLをコピペするときもすっきりしますし、うっかり間違った記事を案内してしまうミスも減らせます。

最近vSphere関連の以下の記事をフォローするようになりました。

VMware Support Insider

 

定期的に各製品に関する流行り(?)のKBが紹介されているのでサポートの人間としてはぜひとも押さえておきたいところです。

 

先日のUpdateにて、以下のKBを見つけました。

Transferring files through vSphere Client might fail (2147256)

 

vSphere Client経由でのデータストアへのファイルのUploadやOVA/OVFのデプロイが失敗する、という内容のKBで、サポート観点でいえば、問い合わせが来るたびに「あー、あれね。」となるような事象です。

 

今回このKBに注目した理由として、私自身がこのKBをしらなかったためです。

この事象自体はよく知っていて、何度も解決策を案内していたのですが、一度もこのKBにたどり着くことはできませんでした。

 

しかし、よくよく調べてみるとこの事象でエラーになった際のエラー画面にバッチリこのKBの番号が書かれてるんですね。。。

 

ovf error.PNG

 

エラー画面を送ってくれない人も多いので全く気付いてませんでした。完全に灯台下暗しでした

(というか、問い合わせる前にきづいて~)

 

 

自分のサポートエンジニアとしての未熟さを痛感したとともに、VMware Support Insider  をフォローしてよかった、と思った次第です。

 

 

### (オマケ) vmware KB 豆知識

vmwareのKBにはCreate DateとLast Update Dateが確認できますが、Create Date = Publish Date(External)ではないので注意が必要です。

Create Dateはあくまでも、KB自体が最初に作成されたタイミングのようで、外部向けに公開された日付とは限りません。

たとえば、 https://kb.vmware.com/s/article/70650 はCreate Dateが2019/6/10になってますが、このKBはvSphere 6.7U3での改善を紹介しているものですので、vSphere 6.7U3の公開(2019/8/20)よりも前に公開されてはいませんでした。

ふつうはCreate DateやLast Modified Dateを気にする場面は少ないと思いますが、もし確認される際は↑の事実をご留意ください。

Unmapの必要性

vSANのサポートをしていると時々「容量が足りない!容量を空ける方法を教えてほしい」といった問い合わせを受けることがあります。

Storageのサポートをしていた時からたびたびこういう問い合わせを受けますが、ベンダーだけが知る秘密の方法、みたいなものはないので基本的にはお客様のデータを削除していただくか、Diskを追加して容量を拡張していただく、という形になります。

※お客様の使い方を効率化することで空き容量を捻出できる場合もあると思いますが、基本的にはサポートでなく有償のコンサルタントサービスになるのが一般的と思います。コンサルに金を出すくらいならその金でDiskを買うか、自分で勉強したほうがいい、というのは私の個人的な意見です。

 

もちろん多くのお客様は上記のようなことはご承知なので、データの削除をしてくれます。ただしVMwareやStorageをよくご存じでないお客様の場合、

「GuestOSでデータを削除したのにvSANの空き容量が増えない」

というお問い合わせを受けることがあります。

vSANの場合は基本的にはThin Provisioningとなりますので、vSAN上の仮想マシンが仮想ディスクを消費するたびに領域が少しずつ割り当てられていく、という仕組みになっています。

一度割り当てられた領域は割り当て済みとなるため、たとえその領域が使用されていなかったとしてもあとから回収することはできません。(※vSAN 6.7U1以前)

vSANにはThinではなくLazy zero-ed Thickのようにすることはできますが、デフォルトはThinなので特に指定しない限り上記のような動作になります。

具体的には以下のような感じになります。

 

最初に100GBの仮想ディスクを持つ仮想マシンをvSANデータストア上にThinで作成し、その上にOSをInstallしたとします。

Install直後は10GBほどしか使われてないとすると、対象の仮想ディスクのvSANデータストア上での容量も10GBほどになります。

その後、GuestOSにて50GBの書き込みを実施したとします。そうするとvSANデータストアで対象の仮想ディスクに追加で50GB分の容量が割り当てられるので、合計で60GBとなります。

その後、あとから書き込んだ50GBのデータを、GuestOS上で削除した場合、GuestOS上でのDisk使用率は低下しますが、vSANデータストアにおいてはすでに60GB分が割り当て済みなので、対象の仮想ディスクのvSANデータストア上のサイズは60GBのままです。(GuestOS上では10GB分のサイズしか使用してない)

この場合、対象の仮想ディスクに割り当て済みだが、実際には使用されていない容量が50GBあることになります。

この50GBはvSANデータストア上のほかの仮想ディスクですることもできず、かといって対象の仮想ディスクを使用するGuestOSからも使用されてないので完全に無駄な領域となってしまいます。

 

つまり、vSANデータストア上に作成した仮想マシンにて、上記のような作業を繰り返してしまった場合、実際に使っている量よりも明らかにvSANの使用容量が多いぞ?ということになってしまうわけです。

 

この問題を解決するためには、GuestOSで使用されなくなった領域をvSANデータストアに返却する仕組みが必要です。

その機能のことをUnmapといいます。

この機能はvSAN 6.7U1からサポートされました。(デフォルトでは無効)

この機能を利用することで、上記のような容量管理上無駄となってしまう領域を再利用することが可能になります。

 

Unmapの利用方法

Unmapは前述のとおりvSAN 6.7U1からの機能となりますので前提条件として、ESXi/vCenterがともにvSphere 6.7U1以降であり、vsan disk formatも7以上である必要があります。

https://kb.vmware.com/s/article/2145267

https://kb.vmware.com/s/article/2150753

 

またUnmap機能はデフォルトで無効になっていますが、使用方法はVMware Docから確認できます。

Reclaiming Space with SCSI Unmap

UNMAP/TRIM Space Reclamation on vSAN | vSAN Space Efficiency Technologies | VMware

 

細かい使用方法や前提条件(仮想ハードウェアのVersionなど)は上記の公式ドキュメントに譲りますが、大体の流れとしては以下のようになります。

    • 前提条件を満たしていることを確認
    • RVCにて機能を有効化する。
    • 各GuestOSごとの設定

 

GuestOS側での対応について

UnmapのオペレーションはvSAN側から開始するものではなく、GuestOS側から開始するものです。

というとも、vSANデータストア側からは、GuestOS内でどの領域を使用しているのかが不明なため、GuestOSがストレージ側(vSAN)にどの領域を解放してよいのかを教えてあげる必要があるためです。

Widowsサーバの場合、2012以降であればこのUnmapを開始する作業(Trim)がデフォルトで有効になっているため、特に問題はないと思いますが、Linux環境ではちょっとOSや環境に応じて個別の対応が必要になるかもしれません。

※あくまでも私の認識ではありますが、TrimとUnmapは同じ意味であり、OSの文脈ではTrimが使われ、Storageの文脈ではUnmapが使われることが多い印象です。

厳密には異なるかもしれませんが、少なくともこの記事ではTrim=Unmapとして記載してます。

※※WindowsサーバにおけるTrim設定の確認や動作検証などは以下のブログが参考になると思います。

https://www.idaten.ne.jp/portal/page/out/secolumn/vmware/column52.html

 

CentOS7 + LVM 利用の場合

私の環境ではLVMを利用したCentOS7でした。

その場合は以下の対応が必要となりました。

lvm.confの編集

LVMの場合は実際にDiskを管理しているのLVMサービスになりますので、LVMにてTrim/Unmapを有効化する必要があります。

具体的には、/etc/lvm/lvm.conf ファイルの

issue_discards = 0

の部分を

issue_discards = 1

にしてあげる必要があります。

 

fstabの編集

ファイルシステムでもTrim/Unmapを有効化してあげる必要があります。

具体的には、/etc/fstab を編集して対象のファイルシステムにdiscardオプションをつけてあげる必要があります。

私の環境の場合はLVMで作成した/dev/mapper/centos-home をXFSファイルシステムでフォーマットして、/homeとしてマウントしていましたので、fstabには以下のように設定されてました。

/dev/mapper/centos-home /home                   xfs     defaults

この部分に手を加え、

/dev/mapper/centos-home /home                   xfs     defaults,discard

として、discardオプションを足しました。

 

trimの実行

設定が終わったらTrimを実行してあげる必要があります。

VMware Docによるとfstrimコマンドで実施することが推奨とありました。

/homeのファイルシステムに対して実行したい場合は、以下のような形式で実行します。

※不要なファイルはあらかじめGuestOSレベルで削除しておいてください。

※※設定直後はコマンドが成功しないことがありました。その場合はいったんRebootしてあげてください。

 

(コマンド)# fstrim -v /home

(出力)/home: 1.7 TiB (1838816620544 bytes) trimmed

※ -v オプションはつけなくてもいいのですが、つけないと何も出力が返ってこないので、私はつけるようにしてます。(なんとなくの安心感があるので。)

 

 

Unmapの結果や進捗を確認する

fstrimコマンドを実行した場合、出力は比較的すぐに返ってきます。

もちろん、そんな短時間にUnmap処理自体が完了したわけではありません。

私の理解ではOSはUnmapの処理をStorageに指示するのみで実際の処理はStorage側で実施されているはずです。

vSANの場合もOS側から進捗や結果を確認することはできず、vSANの統計情報や、vSphereの消費容量から確認することになります。

 

Unmap IOを確認する

vSANのパフォーマンス情報にはUnmap IO情報が個別の項目として存在するのでそこから確認可能です。

Unmap IOは対象の仮想マシンが稼働するホスト上で記録されます。

つまり、Unmapを実行した仮想マシンAが、ESXi Bで稼働していた場合は、ESXi BのvSAN統計情報を確認する必要があります。

vSphere Client(HTML5)にログインし、ホストとクラスタのViewから、ESXi Bを選択し、監視→vSAN → パフォーマンスから確認できます。

 

Unmap前の情報

以下がUnmap前の統計情報です。UnmapのIOPSがずっとゼロであることがわかります。

1.PNG

 

Unmap後の情報

以下がUnmap後の情報です。Unmap IOPSが増えており、同じタイミングでTrim/Unmap スループットが記録されています。

Unmap IOがあるうちはUnmap進行中、Unmap IOがなくなったら完了、と言えそうです。

2.PNG

 

Unmap結果について

Unmapの結果については、vSphere Client(HTML5)から、vSANの空き容量が増えていることを確認したり、対象の仮想マシンがデータストア上で消費する容量が減っていることで確認できます。

今回はキャプチャをとり忘れてしまったのですが、実際にやってみる際は事前と事後の容量を比較してみるといいと思います。

 

 

Unmapされない?

きちんと設定したはずなのに、想定通りにUnmapが走ってくれない場合もあると思います。

対象の仮想マシンでSnapshotがある場合は、Unmapしたい領域をSnapshotが使っていて解放されないことがあるようです。

Snapshotがない場合でも、Replicationなどのソリューションが介在している場合、うまく動作しないことが考えられます。

私のラボ環境ではDell EMCのRP4VMでReplicationを行っている仮想マシンに関してはUnmapが動作しませんでした。

詳細なロジックや追加検証にて確認すべき余地はあるため、確定情報ではないですが、Unmapがうまくいかない場合は、SnapshotやReplicationなどの機能をOffにしたり削除したりといった切り分けが有効化と思います。

 

いかがでしたでしょうか。vSANは70%程度の容量使用率が推奨されている関係もあって、いきなり容量が足りなくなる、ということはほとんどないとは思いますが、空き容量が少なくなってくると、vSANの動作に影響が出たり、パフォーマンスが出なかったり、障害時に可用性が維持できないなどの問題が生じます。

現在空き容量でお困りではないユーザであっても、使用していない領域を再利用できるに越したことはないと思います。

Unmapは地味に大事な機能だと思いますので、vSAN 6.7U1以前のVersionをお使いの場合は、ぜひともUpgradeをご検討ください。

このブログの内容が運用や管理の助けになれば幸いです。

先日(といっても数か月前。。。)に頭を悩ませた事象です。

たぶんvSAN(Storage vMotion?)のバグだと思います。

 

 

概要

Storage vMotionをする際に、容量が足りているはずなのに、容量不足としてエラーになってしまう事象です。

vSAN データストアから非vSAN データストアへのStorage vMotionで発生しました。

 

発生条件

実際に私が経験した状況をそのまま記します。

 

移行対象の仮想マシン

    • vSAN データストア上で稼働するごく普通のVM
    • 約4TBの仮想ディスクが接続されている
    • FTT1 Mirrorなので、vSANデータストア上は約8TBの容量消費となる

 

移行先データストア

    • iSCSI 接続のLUN。VMFS6でフォーマットされている
    • 空き容量は5TB

 

↑の状況でStorage vMotionを試みたところ容量不足としてエラーになりました。

8TBのサイズの仮想マシンを5TBしかないデータストアに移行しようとしているためです。

しかし、この計算は明らかに間違っており、移行できるべきです。

ためしに、Storage vMotionではなく、仮想マシンのReplicationにて移行を実施すると、問題なく成功します。

 

原因

容量不足としてエラーになった原因は、4TBしかない仮想マシンが8TBととして計算されているためです。

たしかに、vSAN データストアでは、FTT1 Mirrorで仮想ディスクを構成した場合、データストア上の消費容量は8TBになります。

しかしながら、実際の仮想マシンサイズは4TBなのだから、5TBの移行先データストアに移行できないのはおかしいです。

 

解決策

残念ながら当時は未解決でした。

LUNを拡張するか、仮想マシンのサイズを小さくするか、Replicationにて移行するかしか手がありませんでした。

最新のVersionでは試してませんが、おそらく未解決だと思われます。

日本の vExpert 有志による Advent CalendarのイベントにvExpert一年生として今年から参加させていただきました。

この投稿は、vExperts Advent Calendar 2019 - Adventar の 2日目です。

2日目のブログでは、vSphereの管理をより便利にするためのAPI関連Tipを紹介します。

 

vSphereの管理インタフェースについて

まず最初にvSphereを管理するためにどんな管理インターフェースを使っているかのおさらいです。

とりあえず思い浮かんだものを列挙してみました

    • vSphere Client (HTML5)
    • vSphere WebClient (Flash)
    • vSphere Client (C#)
    • Host Client
    • PowerCLI
    • DCUI
    • VAMI GUI (PSC/VCSA)
    • Shell/SSH
    • ESXi CGI (??? 正式名称をしらないです。。)
    • MOB
    • RVC
    • vSphere API (Python/Java/RESTAPI 他)

まず最も基本であり、親しみがあるインターフェースはvSphere GUI (HTML5/Flash/C#) でしょう。

私自身はvmware サポート関係の仕事なので、実際のユーザがどのように管理しているのかはよく知らないのですが、おそらくDCUI/VAMI/SSHなどは、トラブルシューティング以外の場面では、ほとんど使われないのではないか、と想像してます。

 

vExpertになるような方々が多く愛用されているのは、おそらくPowerCLIなのではないか、と思います。vSphereのGUIにログインすることなく、vSphereへの命令や参照をスクリプト化することができ、GUIでの作業と比較して、正確さ、迅速さ、自動化、などの多大なメリットがあります。

 

一方で、それ以外のAPI (pythonやRESTAPI)などは、vSphereと連携する製品での実装は多くみられますが、実際に運用管理の場面で一から作成することは非常に少ないのではないか、と思います。今回はこれらのマイナーなAPIのなかでも、curlとwgetだけを使って利用できるもの(RESTAPI、MOB、ESXi CGI)に焦点を当ててご紹介したいと思います。

 

PowerCLIを使わない理由

私自身はPowerCLIをほぼ使いません。

PowerCLIを使うのはPowerCLIでしかできない作業をする場合のみです。(独立SSO vCenter間のvMotionなど)

PowerCLIを使わない理由は、一言でいえば私がvSphereサポートを生業にしているためです。

私の職場では、トラブルシューティングの際に、ログ解析だけでなく、実際にお客様環境にログインして事象を調査したり、ログを採取したり、といった作業があります。

そういった作業の際に、PowerCLIを使うことができたら非常に便利だなぁと思うのですが、いかんせんお客様環境のため、PowerCLIがインストールされているとは限りません。

PowerCLIどころか、FlashやJava(JRE)といった、GUI作業に必要なツールすらInstallされていないことが多々あります。

また、場合によってはWindows PCのようなDesktop端末が存在せず、LinuxベースのCUIのみの管理端末しかないことも多く存在します。

つまり先に列挙した例でいうと、

    • vSphere Client (HTML5) >>> ブラウザがないので使えない
    • vSphere WebClient (Flash)   >>> ブラウザがあってもFlashがなくて使えない
    • vSphere Client (C#)  >>>> Install されてない
    • Host Client >>>> ブラウザがないので使えない
    • PowerCLI   >>>> Install されてない
    • DCUI   >>>> アクセス手段がない
    • VAMI GUI (PSC/VCSA)  >>>> ブラウザが使えない
    • Shell/SSH
    • ESXi CGI (??? 正式名称をしらないです。。)
    • MOB
    • RVC
    • vSphere API (Python/Java/RESTAPI 他)

 

つまり、メジャーどころの管理インターフェースのほとんどが利用できない環境で、障害対応をしなくてはなりません。

そのような非常に制限の厳しい状況下で調査やログ採取をするために利用要件の少ないAPIの活用が必要でした

 

なぜCurlとWget?

理由はシンプルです。この二つのコマンドはVCSAを含む多くのLinux端末にデフォルトで搭載されているからです。

そういった端末にSSHで接続さえできてしまえば、API経由で必要な情報を抽出できます。

利用要件はSSHに必要なネットワークアクセスと、認証情報と、Puttyの実行ファイルだけで済みます。

 

 

vSphere RESTAPIをつかってみよう

さて、前置きが長かったですがようやく本題です。まずはcurlコマンドで簡単に利用できるRESTAPIの使い方から紹介します。

私がRESTAPIを学び始めた当初は、比較的難しい開発向けの情報しか見つからず、RESTAPIでできる参照&命令の把握や、リクエスト方法のフォーマットや認証IDの取得方法がわからずとても苦労しました。

しかしながら現在は非常に便利なapi explorerというものがデフォルトで提供されています。

api explorerは一言で言ってしまえば、

「あなたの代わりにRESTAPIのcurlコマンドを作成してれるツール」

です。

どういうことなのか、さっそく見てみましょう。

 

 

API ExplorerにCurlコマンドを生成してもらう

 

api explorerにはvCSAにHTTPSでアクセスした際のランディングページの以下の場所から移動できます。

1.PNG

アクセスすると、操作対象によっていくつかAPIの選択肢が出ますが、vSphere関連の参照&命令がしたい場合はvcenterを選んでください。

2.PNG

 

vcenter API配下には、RESTAPIのパス毎に使用方法の説明などが記載されていますが、とりあえず例としてVMの一覧を取得してみましょう。

まずはpath名がVMのところを展開してください。そうするとメソッドがいくつか表示され、それぞれのメソッドの説明が見えるはずです。

その中で一番上のGET メソッド(仮想マシンの情報を表示する命令)をさらに展開すると具体的なRequest方法の説明が読めますが、

ここではとりあえず、一番下にある「TRY IT OUT!」のボタンを押してみましょう。(下図参照)

3.PNG

 

そうすると、実際にこのRESTAPIを実行するためのCurlコマンドとその実行結果を表示してくれます。

※API Explorerが生成するCurlコマンドにはデフォルトで-kが入ってませんので、証明書関連のエラーが想定される場合は-kを足してください。

 

4.PNG

 

ここで表示されるCurlコマンドをコピペして実行すれば、実際の環境でもそのまま使えるというわけです。めちゃめちゃ便利ですね。

しかし、ちょっと待ってください。実行結果をよく見ると、エラーになっています。

エラーの原因は"This method requires authentication." です。

当然ながら、vCenterから情報を抽出するためには認証が必要なので、認証情報を提供する必要がありました。

 

RESTAPIに必要な認証情報を取得する

結論から言うと、RESTAPIのリクエストヘッダに、session idを入れて送信する必要がありました。

セッションIDは以下のCurlコマンドで取得可能です。

 

curl -k -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'vmware-use-header-authn: test' --header 'vmware-api-session-id: null' -u 'administrator@vsphere.local' 'https://<vcenter ip>/rest/com/vmware/cis/session'

 

↑のコマンドを実行すると、administrator@vsphere.localのパスワードが求められますので、入力してあげると、以下のような感じでSession IDが返されます。

 

5.PNG

 

ここで得たSession IDを、最初に実行したCurlコマンドの vmware-api-session-id に入力してあげればOKです。具体的には以下のようになります。

 

6.PNG

 

↑のコマンドを実行すると対象vCenterで管理される仮想マシンの情報がJsonのフォーマットで入手できます。

 

 

以上が、vSphere REST APIの簡単なご紹介でした。

REST APIは比較的若い機能なのでまだまだできることが限られますが、使いやすいさやスクリプト化のしやすさもあるので今後も拡張されると思います。

なれない方には難しい点がまだあると思いますが、この記事とAPI Explorerを使えばだいぶ簡単にCurlコマンドまでは落とし込めるようになったのではないかと思います。

 

 

ESXi CGI ??? の使い方

ESXi CGIってなんやねん!?と思う方も多いと思いますが、私も正式な呼び名を知らないのでご容赦ください。

ようするに、https://<esxi ip>/host やhttps://<esxi ip>/folderでアクセスできる機能のことを勝手にそう呼んでいるだけです。

ESXiに対する直接の操作になりますので、vCenterが機能していない環境でも利用可能です。

この機能を利用すると以下のことが可能です。

    • /folder にアクセスすることでデータストア上のファイルの閲覧とダウンロード
    • /host にアクセスすることで、ESXiの主要なログファイルや構成ファイルを取得可能
    • vm-supportを取得可能

 

/folderの使い方

特に説明の必要はないと思います。

https://<esxi ip>/folder にアクセスして、ログインも済ませればあとなLook & Feelで使えると思います。

ブラウザの右クリックから対象ファイルのURLも取得可能です。

 

/hostの使い方

/folderと同様に、/hostにアクセスすれば使えます。

限られたファイルしか閲覧できませんが、ESXiへのSSHが不要な点がメリットです。

Curlコマンドを使って簡単に対象のファイルを入手できます。

 

vm-supportの取得方法

以下のコマンドで入手可能です。

wget https://ip/cgi-bin/vm-support.cgi --user <> --password <> --no-check-certificate -O <output file name>

 

この方法は、https://kb.vmware.com/s/article/1967 でも紹介されています。

vm-supportの取得方法はいくつかやり方がありますが、個人的にはこの方法が一番楽だと思います。

 

MOBの使い方

MOBはvCenterとESXiの両方に対して使える機能です。

vCenterはデフォルトで有効ですが、ESXi6.0以降のESXiではデフォルトで無効になっているので利用前に有効化する必要があります。

有効化の方法はこちらをご参考にしてください。(https://www.virtuallyghetto.com/2015/02/quick-tip-vsphere-mob-is-disabled-by-default-in-esxi-6-0.html

 

こちらの使用方法もとても簡単です。URLに情報を取得したいmoidを指定してあげればOKです。

例えば以下のような形になります。

https://<esxi/vcenter ip>/mob/?moid=ha-host     

 

自分がアクセスしたいオブジェクトのURLを知るためにはブラウザでアクセスするのが一番簡単です。

いちどvcenter/esxiのmobブラウザのホーム(/https://ip/mob)にアクセスしてブラウザからたどっていって、対象のオブジェクトを見つけたらその時のURLを記録するだけです。

7.PNG

 

このURLに対してcurlやwgetをしてあげればこのページの情報が入手できます。※ただしHTMLフォーマットになります。

 

今回紹介した方法の中では、mobから得られる情報が一番多いです。しかしながら出力がHTMLになってしまうという使いにくさと、メソッドを実行する際のちょっと特殊な方法をとる必要があるため、使用には難易度が高いです。

メソッドの実行に関して今回はご紹介はしませんが、もしご興味がある場合は私の過去のブログをご参考にしていただければと思います。

     CurlコマンドでESXiのSSHを有効化する方法

     ※ポイントとしては、MOBのURLにたいして 直接Curlを実行するだけではメソッドを実行することはできず、Mobブラウザに隠されているHidden 要素のSessionIDをPOSTしてあげる必要があります。

 

 

 

おわりに

今回の記事ではマイナーなAPIや管理インターフェースから情報やログファイルを入手する方法を紹介しました。

どれもこれもPowerCLIと比べると便利さや機能性に欠けますので、ユーザ目線ではあまり役に立たないかと思います。

しかしながら、Curlならではの良さもありますので、もしお役に立てそうな場面がありましたら是非とも活用してみてください。

あと、サポートの人たちはこんな感じで苦労しながら調査していることを少しでも思い出していただけたら、調査用の端末には十分な性能とアプリケーションをご準備いただけますと幸いです。

 

以上、vSphere APIのTipでした。

明日の vExperts Advent Calendar 2019 - Adventar は、interto さんです。よろしくお願いします。