Skip navigation
1 2 3 Previous Next

naoyuki kaneda's Blog

37 posts

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 さんです。よろしくお願いします。

nkaneda Enthusiast
vExpert

vSAN Specialist 2019 取得

Posted by nkaneda Nov 10, 2019

vSAN Specialist 2019 取得しました。

vSAN Specialist 2019 を取得しました。

すでにvSAN Specialist 2017を取得していたので、特に勉強はしませんでしたが問題なく合格できました。

一応、メモも兼ねて合格のアドバイスなどを残せればと思います。

 

 

試験概要

試験コード:5V0-21.19 (https://www.vmware.com/education-services/certification/vsan-2019-exam.html)

合格点 300/500満点中  (筆者は440点で合格)

試験時間 120分 (英語のみ ※ 2019/11/1現在)

 

試験範囲:vsan 6.7U1以降を想定した内容になっています。vSANの設計・構築・管理を問う問題がでますが、管理(運用とトラブルシューティング)がメインという印象です。

 

勉強資料

以下の資料は上記試験範囲のすべてではありませんが、この辺りを押さえておけば合格点は取れます。

そもそも、vSANに限らず、特定のIT技術の設計・構築・管理を全部カバーするエンジニアってかなり限られると思いますし。。。

 

試験を受けた感想

普段からvSAN触っている人ならNo勉強で行けると思います。出題のメインは管理とトラブルシューティングだった印象です。

以下のブログで紹介されている練習問題をマスターしていけばほぼほぼ大丈夫だと思います。

https://lab8010.com/vsan-specialist-practice/

※上記はvsan specialist 2017 (vSAN 6.6) までの範囲から作成された問題ですが今回の試験でも有効です

※本件と関係ないですが、とてもいいブログなのでぜひフォローすることをお勧めします

stretched cluster関連の問題は割と多めにでますので、不慣れな人はそこは勉強したほうがいいですね。

2-nodeも少なからず出ました。Stretched Clusterの要件の差異なども知っておいたほうがいいですね(Witnessへのネットワーク要件が、それぞれ200msと500msという違いがありますね)

iscsi TargetやEncryptionやUnmapといった内容もちょいちょい選択肢で出てきますが、わざわざ勉強しなくても合格点に足りると思いますので、用語として知っておけば大丈夫です

vSAN BootstarpとかConsigAssistといった、私自身のなじみの薄い分野の問題が出ることを警戒していましたが、わずかにしかでませんでした。答えはわかりませんでしたが、特に気にしてないです。合格しましたし。

 

総括

    • 上記のブログの練習問題で8割越え目指す
    • ストレッチクラスタの資料は熟読する
    • 余裕があれば2Nodeも。

この記事ではCurlコマンドのみを利用した、ESXiのSSHサービスの有効化方法を示します。

 

SSHの有効化がコマンド実行毎に必要となる環境の例

VMware環境を監視するために、Zabbixなどのアプリケーションを用いて、SSHコマンドを定期的にESXi上で実行したりしている環境はそれなりにあると思います。

SSHコマンドをRemoteから実行するためには、当然ながらESXiでSSHサービスが有効になっている必要があります。

多くの場合はSSHサービスを事前に有効化しておけば問題ないのですが、HCI製品などでSSHサービスの管理が明示的に行えない場合も時折あるかと思います。

たとえば、HCI製品固有の管理用VMがESXi Cluster全体のSSHサービスのOff/Onを動的に実施している場合などです。

 

そういった環境でZabbixなどの外部サーバから、SSHコマンドによる出力の監視を行いたい、と考えた場合、事前にSSHを有効化しておいたとしても、Systemが自動的にESXiのSSHサービスを無効化してしまい、監視用のコマンドが失敗する、といったことがあり得ます。

 

もちろんコマンドを実行する前にSSHサービスを都度有効化しさえすれば問題ないのです。

そういったことはPowerCLIやpyvmomiなどを使えば比較的簡単に実施できると思います。

しかしながら場合によってはLinuxで実行する必要があったり(PowerCLI使用不可)、Pythonなどのモジュールを自由に導入できない場合などもあるかと思います。

 

そういう要件の環境においてCurlコマンドでESXiのSSHを有効化できたら非常に便利かな?と思いましたのでCurlコマンドで実現する方法を紹介いたします。

この記事では結論部分のみを紹介しますが、答えにたどり着くまで(約1時間半)にもいろいろと勉強になることがありましたので、機会があれば紹介したいと思います。

 

 

実施手法

今回はMOB経由で実施する方法を選びました。

ちゃんと調べてませんが、もしかしたらVersionによってはRESTAPIで実施可能だったり、別のInterfaceからCurlコマンドのみ実施可能かもしれませんが、今回は筆者都合かつ広いVersionをカバーする意図でMOBを利用しました。もっと便利なやり方を知っている方がいたら教えていただきたいです。

 

 

試験環境

以下の環境で試しました。

・実行OS:SUSE Linux Enterprise Server 12 SP2

・curl  version :curl-7.37.0-37.34.1.x86_64

・ESXi Version :VMware ESXi 6.7.0 build-13644319

 

事前準備

対象となるESXi上でMOBが有効になっている必要があります。

ESXi上のMOBサービスはデフォルト無効になっているようです。(vSphere 6.0以降)

その場合は以下のサイトを参考にMOBを有効化しておいてください。

https://www.virtuallyghetto.com/2015/02/quick-tip-vsphere-mob-is-disabled-by-default-in-esxi-6-0.html

また対象となるESXiのIP、ユーザ名、パスワードが必要です。

 

有効化のコマンド

細かいことは抜きにして、以下で有効化可能でした。

 

# hostuser=<username>

# hostpass=<password>

# hostip=<ip address>

 

# SessionID=$(curl -s -k --user "$hostuser:$hostpass" --cookie-jar vc_cookie.txt  "https://$hostip/mob/?moid=serviceSystem&method=start"|awk -v FS="(vmware-session-nonce|value=\"|)" '/vmware-session-nonce/{print $3}' | cut -d"\"" -f1)

# curl -s -k  --cookie vc_cookie.txt  -X POST -d "vmware-session-nonce=$SessionID&id=TSM-SSH"  "https://$hostip/mob/?moid=serviceSystem&method=start" > /dev/null

 

直接サービス起動のMethodを実行することはできないため、一度対象のページにアクセスして、SessionID(vmware-session-nonce)を取得したうえで、そのSessionIDと起動したいサービス名をPOSTしてあげることで可能になりました。

"vmware-session-nonce

Embedded VCSAの構成変更とUpgrade

 

VxRail 環境では、構成変更や設定変更が一部制限されています。

VxRailのデザインになっている構成や設定を変更してしまうと、VxRailが想定通りに動作しない可能性があります。

また、Upgradeや交換作業などによって、変更した設定がデフォルトに戻ってしまうかもしれません。

 

VxRailに同梱されるVCSA/PSCの構成情報を変更した場合はどうなるのでしょうか。

VxRailのEmbedded VCSAは、デフォルトでSmallサイズとして構成されます。

VxRailでは最大でも64ホストなので、このサイズで足りる想定なのでしょうが、仮想マシンがとても多い環境など、場合によってはメモリを増やしたり、Diskを拡張したりしたい場合もあるかもしれません。

 

試しにEmbedded VCSA/PSCのCPU/Memory/Diskを変更して、Major Upgrade後に変更が維持されるかどうかを確認してみました。

今回のテストでは4.5.314 から 4.7.212への Upgradeで試しました。

 

 

事前の予想

VxRail 4.5.314 はvSphere 6.5系、VxRail 4.7.212はvSphere 6.7系なので、Upgradeに際して新しいVCSA/PSC VMが作成され、既存のVCSA/PSCからデータがMigrationされます。

なので、Upgrade前に変更した仮想ハードウェア情報は維持されないと予想しました。

 

構成変更なしでUpgradeをしてみた

まずは構成変更をせずに、vCenter 6.5 → 6.7へのUpgradeをしてみて、ログや証明書などが維持されるかどうか確認してみました。

結果は以下です。※PSCも同様なので割愛

 

維持されるもの

    • SSL証明書
    • タスク履歴
    • イベント履歴

 

維持されないもの

    • Host key fingerprint (SSH接続時に更新が必要)
    • ログ(/var/log/配下など)

 

構成変更してUpgradeをしてみた

次に仮想ハードウェアを構成変更して、変更が維持されるか確認しました。

※PSCも同様なので割愛

 

初期状態

Upgrade前の状態は以下です

 

1.PNG

 

デフォルトのままなので、vCPUは4、メモリは16GB、Diskサイズもすべてデフォルトです。

 

 

変更内容

以下の構成変更をしました。

      • vCPUを4 → 8
      • メモリを16GB → 32 GB
      • /storage/log (ハードディスク5) を 10GB → 20 GB

 

変更後の構成は以下です。

 

2.PNG

 

 

Upgrade後

Upgrade(Migration)後の構成は以下でした

 

3.PNG

 

結果は私の事前の予想と反し、CPUとメモリの変更は維持され、Diskサイズの変更はデフォルトに戻りました。

 

まとめ

今回のテストでは事前の予想とは異なる結果となりましたが、CPUとメモリの変更が維持されるのは安心できますね。

Diskについてはデフォルトに戻ってしまうので、/storage/logではなくDBのボリュームが拡張されていた場合にどうなるのかは気になります。

その他、パスワードの有効期限設定なども確認し忘れてしまったので、今後判明したらUpdateしようと思います。

ちょっと前の話なので今更感がありますが、Version 76以降のGoogle ChromeからFlashの実行がデフォルトでBlockされるようになりました。

以前であれば、Flashの実行が必要な際にポップアップが出てAllow or Blockを選択できましたが、Version 76にUpdateしたとたんに出なくなりました。

 

Flashが実行できないとWebClientが使えないことになってしまいますが、ブラウザの設定を変えれば以前のようにポップアップを出すことができます。

詳細は以下のURLをご確認ください。

 

https://gigazine.net/news/20190731-google-chrome-76/

VxRailの環境では、未構成NodeのDiscoveryのためにIPv6のマルチキャストが必要です。

マルチキャスト通信は定期的に行われており、ある程度の帯域を消費するわけですが、実際にどれくらいの通信量なのかと質問を受けたので実際にラボ環境で測定してみました。

 

ラボ環境では、VxRailが3クラスタあり合計12Nodeです。

そのうち一つのVxRail Manager VM上でTCPDUMPを実行し、結果をWireSharkで解析しました。

Loudmouthで利用するマルチキャスト IPv6 アドレスである ff02::fb 宛のパケットでフィルターをかけて収集したところ、

24917秒の観測時間中に、9740個のLoudmouthマルチキャストパケットが観測されました。

 

内訳は以下です。

 

1.jpg

 

12個以上のソースがあるのはVxRail ManagerやSmart Fabricなどがあるためです。

また、パケットの平均サイズは約220バイトでした。

 

2.jpg

 

これが多いのか、少ないのか、影響があるのかないのかの環境次第だと思いますが、とりあえず参考情報として公開してみました。

この記事では、vCenterで発生するアラートをSNMPを使用して通知する設定方法を紹介します。

 


1. vCenterへSNMPサーバ(Receiver)やCommunity stringなどの設定

 

a. vCenter Server SettingsのMenuへ移動

     ・vCenter 6.0の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Manage > Settings > General でvCenter Server Settingsを表示、SNMP receiversの項目を押して展開し設定状態の確認

右側にあるEditを押す

vCenter_Setting_4.0.JPG.jpg

 

 

   ・vCenter 6.5の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Configure > General でvCenter Server Settingsを表示、SNMP receiversの項目を押して展開し設定状態の確認

右側にあるEditを押す

vCenter_Setting_4.5.JPG.jpg

 

   ・vCenter 6.7の場合

vCenter Client(HTML5) にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Configure > General でvCenter Server Settingsを表示、SNMP receiversの項目を押して展開し設定状態の確認

右側にあるEditを押す

vCenter_Setting_4.7.JPG.jpg

 

 

b. Edit vCenter Server SettingsにてSNMP receiversの欄に設定する情報(Port / Community)を入力

※複数のReceiverを設定する場合は、Enabledにチェックを入れることを忘れないでください

Edit_SNMP.JPG.jpg

 

vCenter 6.7の場合は"Enable receiver"をクリックし緑にすることで有効化できます

Edit_SNMP_4.7.JPG.jpg

 

 

c. 設定した値がGUIに反映されていることを確認

Edit_SNMP_check.JPG.jpg

 

 

2. vCenterに定義されているアラート設定に、SNMP通知を送信する設定を追加

※下記例はESXiがvCenterへの応答がなくなった場合等に発生するアラートの"Host connection and power state"を例にしています

※アラートを見つける際には、虫眼鏡マークの"Filter"に文字列を入力すると見つけやすいです(vCenter 6.0, 6.5)

※アラートを見つける際には、Alarm Name横にあるマークを押して文字列を入力すると見つけやすいです(vCenter 6.7)

 

a. vCenterに定義されているアラート(Alarm Definitions)一覧へ移動し設定を追加するアラートを選択

     ・vCenter 6.0の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Manage > Alarm Definitions を選びアラート一覧を表示、"Host connection and power state"の項目を選択

右側にあるEditを押す

アラート設定.jpg

 

     ・vCenter 6.5の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Monitor > Issues > Alarm Definitions を選びアラート一覧を表示、"Host connection and power state"の項目を選択

右側にあるEditを押す

アラーム設定_4.5.jpg

 

     ・vCenter 6.7の場合

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvCenterを選択し

Configure > Alarm Definitions を選びアラート一覧を表示、"Host connection and power state"の項目を選択

上部のEDITを押す

アラート設定_4.7.jpg

 

 

b. アラートが発生した際にSNMP trapを送信する設定を実施

・vCenter 6.0、6.5の場合

左側の"3 Actions"タブを選択

緑の"+"を押して、Action列にて"Send a notification trap" を選択

アラームのステータス移行に関して"Once"か"Repeat"を選択しSNMP trapの送信するタイミングと頻度を選びます

アラート設定_snmp.jpg

 

・vCenter 6.7の場合

     "Alarm Rule 1"までNextで進む

     "Send SNMP traps"をチェックして緑に変更(必要に応じて"Repeat"にチェック)

     そのままNEXTで進み、SAVE

 

アラート設定_snmp_4.7.jpg

 

 

アラーム毎のステータス移行はアラートのTriggers欄を参照すると良いです

triggers.jpg

 

Triggers_4.7.JPG.jpg

 

 

c. 設定したActionがGUIに反映されていることを確認

・vCenter 6.0、6.5の場合

"Host connection and power state"の詳細欄のActionsを押して展開

Send a notification trapと反映されていることを確認

 

アラート設定_設定後_snmp.jpg

・vCenter 6.7の場合

     "Host connection and power state"の左側にある↓をクリックし展開

     Alarm Rulesにsend SNMP trapsと反映されていることを確認

 

アラート設定_設定後_snmp_4.7.jpg

 

 

■補足:MIBファイルに関して

MIBファイルを使用したい場合は下記のVMware KB(1013445)にあるものをご使用ください

(画面、右側の"Attachments" にファイルがございます)

 

SNMP MIB module file download (1013445)

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

 

Attachments_MIB.JPG.jpg

 

### 参考文献

SNMP MIB module file download (1013445)

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

アラーム アクションの指定

アラームとしての SNMP トラップの送信

vCenter Server の SNMP 設定の構成

この記事では、vSphere Web Client/Host Client/ Dell EMC FTPサイトなどのGUIを英語にする方法を紹介します。

 

###ブラウザのの英語表示設定 ###

 

 

 

Google Chromeの場合

 

 

1.Google Chromeの右上のアイコンから設定を選びます。

1.PNG.png

 

 

2.開かれた画面で一番下まで行き、詳細設定をクリックして展開します。

2.PNG.png

 

 

3.”言語”の設定項目を探して、”言語を追加”から英語を追加します。

 

3.PNG.png

 

4.英語が追加できたら右側のアイコンから序列を変更し、英語が一番上に来るようにします。

4.PNG.png

 

 

5.英語が一番上にきたら再起動ををクリックします。(Chromeが再起動します。)

5.PNG.png

 

 

6.(vSphere WebClientの場合のみ)再度Google Chromeが起動されたら、以下のようにLocaleを指定する形でWebClientにアクセスします。

https://<Web Client Server>:9443/vsphere-client/?locale=en_US

 

※上記後もWebClientの表示が英語にならない場合は、一度WebClientをログアウトしてログインしてみてください。

その他ブラウザの再起動やキャッシュのクリアなどを試してください。

 

 

 

 

Internet Explorer(IE)の場合

 

1.IEからインターネットオプションを開き、全般>言語をクリックしてください。

 

6.PNG.png

 

 

2.言語の優先順位の設定をクリックしてください。

7.PNG.png

 

 

3.コントロールパネルの言語設定が開きますので、”言語の追加”からEnglishを追加してくださいl

8.PNG.png

 

 

4.Englishが追加できたら、序列を変更し、Englishが一番上に来るように変更してください。

9.PNG.png

 

 

5.設定が完了したら右上のXからコントロールパネルを閉じ、IEを再起動してください。

 

6.(vSphere WebClientの場合のみ)再度IEが起動されたら、以下のようにLocaleを指定する形でWebClientにアクセスします。

https://<Web Client Server>:9443/vsphere-client/?locale=en_US

 

※上記後もWebClientの表示が英語にならない場合は、一度WebClientをログアウトしてログインしてみてください。

その他ブラウザの再起動やキャッシュのクリアなどを試してください。

!!!!!!  留意事項 !!!!!!

本記事はEMC Community Networkの記事のコピーです

同Communityが将来的にDell Communityに統廃合される可能性があるため、退避用に作成しています。

オリジナルのEMC Community文書については以下をご参照ください。

EMC Community Network - DECN: VxRail: WebEx調査時に端末にご用意いただくもの

 

 

この文書は、Dell EMCのサポートエンジニア(VxRail)がWebEXによる調査や作業を実施する際に必要となるスペックやアプリケーションを記述したものです。

 

※WebEX端末 = お客様がWebEx用にご用意いただいた物理PCもしくは仮想マシンのこと

 

#### VxRail: WebEx調査時に端末にご用意いただくもの ####

 

 

WebEx端末の推奨スペック

  • CPU: 2GHz以上が2コア以上
  • メモリ:4GB以上
  • Disk:空き容量が10GB以上
  • リソース優先度:標準以上

 

 

必須でご用意いただきたいアプリケーション

  • SSHクライアント(TeratermやPuttyなど)
  • SCP、SFTPクライアント(WinSCPなど)
  • vSphere Web Clientへのアクセスに必要なFlashおよびHTML5対応のブラウザ

※事前のご準備がされていない場合はInstallや実行ファイルのダウンロードをお願いさせていただきます

 

 

状況により必要となるアプリケーション

  • Java(JRE Version 8)  ※BMCの仮想コンソールへのアクセスに必要となります。NodeのNot Responding発生の際は必須です。
  • vSphere 統合プラグインが使用可能なブラウザ
  • vSphere Client

 

 

ご準備いただきたいIP情報

  • VxRail Manager IP
  • vCenter server IP
  • iDRAC/BMC IP

 

 

 

ご準備いただきたい認証情報

※お客様のセキュリティポリシーなどにより開示できない場合は都度ご入力いただく必要がございます。

  • VxRail Manager root ユーザパスワード
  • vSphere web client 管理ユーザ名およびパスワード
  • vCenter root ユーザパスワード
  • PSC root ユーザパスワード
  • ESXi root ユーザパスワード
  • iDRAC/BMC  パスワード