ad1

2018年11月7日水曜日

vCenter 6.xの各バージョンの証明書インポート

vCenter Web Clientを利用する際、検証環境での利用がメインだったので
Web Clientを利用する際はいつも証明書の警告を無視して利用していましたがイベントのデモ用でお客様の目に触れる環境を久々に作った際に、6.5以降で証明書がだいぶ親切になっていたので覚え書き。

※証明書インポートしておかないと、データストアブラウザでのファイルアップロードに失敗したりもするので適用しておくことが推奨です。

手順の基本は以下KB参照(KBでは6.0.xの記載ですが6.5以降も基本同じで、一部親切仕様になっています)。
vCenter Server ルート証明書をダウンロードしてインストールして、Web ブラウザ証明書の警告を防ぐ方法 (2148936)

まずはvCenter 6.0.xの画面から。
▲保護されていない通信」が目立ちます。
証明書のダウンロードは右下の「信頼されたルート CA 証明書をダウンロード」をクリック。

vCenter 6.5では「vSphere Client (HTML5) - 一部の機能」のリンクが追加されていますが基本的に同じです。


vCenter 6.7u1ではHTML5 vSphere Clientにフル機能が実装されたのでメインがHTML5、Flash版はFLEXという名称でサブになっています。
証明書のダウンロード手順は同じです。

ダウンロードしたZIPファイルを解凍すると、vCenter 6.0.xの時はKBの記載通り、
certフォルダに、 xxxxxxx.0 と xxxxxxx.r1 というファイルがあります。
 ここでは
xxxxxxx.0  -> xxxxxxx.0.crt
xxxxxxx.r1  -> xxxxxxx.r1.crl
と拡張子をそれぞれ追加します。


変更後は以下のようになります。

この拡張子の変更作業、vCenter 6.5以降ではZIPファイルを解凍するとWindows用にはフォルダ分けされていてすでに拡張子が適用された状態となり、即利用可能です。
だいぶ親切になりました。


 証明書のインポート手順は各バージョン同じで、crtファイル -> crlファイルの順でインポートします。
Windowsの場合はファイルを右クリックから「証明書のインストール」を選択。

保存先は作業端末なので他のユーザーも利用できるようにローカルコンピュータとしました。

「証明書をすべて次のストアに配置する」にチェックを入れ、「参照」から証明書ストアを選択します。

ここでは「信頼されたルート証明書機関」を選択します。

 「次へ」をクリックし、

「完了」をクリックすれば終わりです。


この操作を、crtファイル、crlファイルにそれぞれ行い、
複数のvCenterなどインポート対象がいくつかある場合は、同様の作業を繰り返します。

証明書のインポート後はWebブラウザを再起動すれば以下のようにすっきりとした画面が開きます。
※接続時にはIPアドレスではなく、FQDNでアクセスしてください。




vCenterもバージョンが進むにつれ、ちょっとしたところが改善されていますね。
お客様に見せる環境などでは見栄えも大事なので証明書は作業端末にインポートしておきましょう。

2018年10月24日水曜日

vCenter6.5のrootアカウントパスワードの失効とvCenter Server Applianceのアップグレード失敗

ここ数年のvCenter Server Appliance(vCSA) 5.5 や 6.0をデプロイすると、初期状態ではrootアカウントのパスワード期限が90日に設定されていました。
90日間越えてしまうとrootアカウントがロックされてしまいVAMI UIやSSHでのログインが不可となります。

この際は以下KBを参照し、LinuxOS側にシングルモードでコンソールログインしてrootアカウントのパスワードを初期化する必要がありました。
vCenter Server Appliance の root アカウントにログインできない (2069041)

vCSA 6.5からは初期状態のrootアカウントのパスワード期限が365日に延長されました。
私も油断していたのですが、検証環境のvCSA6.5が初期状態のままで365日経過してしまいましたが、その時に気づいた今までとの違いをご紹介します。
vCenter 6.5 root ユーザーのパスワードおよびパスワード有効期限の設定の変更

まず、vCSA 6.5の場合、パスワードの期限が切れてもアカウントロックされる事はなく、VAMI UI(https://<vCSA_IP-FQDN>:5480/)や、SSHでのrootログインが可能でした。
この辺りは以前のバージョンに比べるとだいぶ緩くなっています。

ただ、ログイン可能なのですが、VAMIのアカウント管理画面では以下のように、パスワードが過去の時間に切れたことが表示されます。

そして、パスワードの期限が切れている場合はVAMIでのパスワード再設定や、有効期限の無効化の設定は弾かれてしまいます。


先日はこの画面を確認せず、rootアカウントのパスワードが有効なものと思いこんで、vCenterのバージョンアップを実行したところ、以下のようなエラーで失敗しました。


最初はDB容量や空き容量のひっ迫などを疑ったのですが、色々調査するとrootアカウントがおかしいのでは?となり、確認したら有効期限が切れていました。
SSHにもVAMIにもrootでログインできたので気付くのに遅れてしまいました。

vCSA 6.5で有効期限の切れた状態のrootアカウントのパスワード変更は、VAMI UIからは実行できず、SSHかローカルコンソールでvCSAのLinux側にログインしてCLIで passwd
コマンドを投入して再設定します。



再設定後は問題なくvCSAのバージョンアップも成功し、VAMI UIでパスワードの再設定、有効期限の設定変更も可能になりました。


vCSAのバージョンアップ前にはrootアカウントの有効性を確認する事をお勧めします。

2018年10月3日水曜日

vSAN 6.6.x、vSAN 6.7.0環境でResync動作時にVMDKを拡張すると不整合が起きる不具合(KB58715)について

9/18にアナウンスされていたvSAN 6.6.x、vSAN 6.7.0における、
「vSAN Resync動作時にVMDKの拡張作業を行うとデータの不整合が起きる」問題に対応したパッチが提供されました。
最新のvSAN環境でVMDKの拡張したかも?という方はご注意ください。

それぞれESXi 6.5u2 EP7 と、ESXi 6.7 EP9で、以下のKBで詳細は記載されています。

Virtual Machines running on VMware vSAN 6.6 and later report guest data consistency concerns following a disk extend operation (58715)
https://kb.vmware.com/kb/58715

vSAN 6.7 - Express Patch 4 Release:
http://kb.vmware.com/kb/58848
ESXi670-201810001 Build 10176752

vSAN 6.6 - Express Patch 9 Release:
http://kb.vmware.com/kb/58852
ESXi650-201810001 Build 10175896


元々、回避策として以下のオプションの無効化が指示されていましたので、
今回のパッチ適用の前に、オプションは無効化しておいた方が良さそうです。
・VMDK のサイズを増やしたことのない場合は
 /VSAN/ClomEnableInplaceExpansion オプションを無効(0)に設定。

・VMDK のサイズを拡張した、または拡張したか分からない場合は
 /VSAN/ClomEnableInplaceExpansion オプションを無効(0)に設定し、
 今回リリースされたESXi 6.5u2EP9、6.7 EP4を適用する。

KBでは丁寧にクラスタに対して全ホスト一括で設定できる様にPowerCLIの1Line scriptも公開されておりました。
Foreach ($VMHost in (Get-Cluster -Name (Read-Host "Cluster Name") |Get-VMHost)) {Get-AdvancedSetting -Entity $VMHost -Name VSAN.ClomEnableInplaceExpansion | Set-AdvancedSetting -Value '0' -Confirm:$false}

とりあえず、VMDKの拡張を実施していない環境であれば急いでパッチを当てる必要は無さそうですが、リスクを排除するために対象バージョンの修正パッチ以降にバージョンアップするまでは、/VSAN/ClomEnableInplaceExpansion は 0 に変更しておくべきです。

また、vSAN 6.6.1、6.7のどちらも修正パッチ適用後は /VSAN/ClomEnableInplaceExpansion は 1 に戻すことが可能です。
全てのホストの修正パッチ適用後は、以下のようなPowerCLIで一括適用が出来ます。

Foreach ($VMHost in (Get-Cluster -Name (Read-Host "Cluster Name") |Get-VMHost)) {Get-AdvancedSetting -Entity $VMHost -Name VSAN.ClomEnableInplaceExpansion | Set-AdvancedSetting -Value '1' -Confirm:$false}

2018年9月7日金曜日

CVE-2018-3646 : ESXi サイドチャネル対応スケジューラの有効化 とその影響

vCenter を 6.0 U3hまたは6.5 U2c、6.7d 以上にアップグレードした環境では、
ESXiホストに対しCVE-2018-3646の対策(ESXi サイドチャネル対応スケジューラ)が有効化されていない場合に、
「このホストにはCVE-2018-3646で記述されている問題に対する脆弱性があります。 詳細およびVMwareの推奨については、https://kb.vmware.com/s/article/55636を参照してください」
といった警告メッセージがvSphere Client、Web Client上に出力されます。

対策方法は以下KBに記載がありますが、関連KBが複数あること、
全ESXiで「ESXi サイドチャネル対応スケジューラの有効化」する必要があり、
されには、Vmwareはこの設定の有効化でパフォーマンスが数%低下するとの指標を示しています。
※現状でCPU利用率がひっ迫している環境ではパフォーマンス低下が20%を超える可能性もあるようです。

■ 投機的実行に関連して発生するセキュリティ問題の概要

Intel プロセッサの「L1 Terminal Fault」(L1TF) 投機的実行の脆弱性に対する VMware の対応の概要 CVE-2018-3646、CVE-2018-3620、CVE-2018-3615 (55636)
https://kb.vmware.com/kb/55636?lang=ja

■vSphere環境への「ESXi サイドチャネル対応スケジューラの有効化」手順の説明

vSphere 用 Intel プロセッサにおける「L1 Terminal Fault」(L1TF - VMM) 投機的実行の脆弱性に対する VMware の対応 CVE-2018-3646 (55806)
https://kb.vmware.com/kb/55806?lang=ja

■「ESXi サイドチャネル対応スケジューラの有効化」手順
▼WebClient、HostClientで各ホストの詳細設定で変更する場合
VMkernel.Boot.hyperthreadingMitigation  => true に変更(デフォルトはfalse)

▼ESXCLIで設定する場合
確認方法
esxcli system settings kernel list -o hyperthreadingMitigation

設定方法
esxcli system settings kernel set -s hyperthreadingMitigation -v TRUE

▼PowerCLIで設定する場合
※PowerCLIでの設定方法は確認方法と合わせて以下KBで説明されています。

HTAware 軽減策ツールの概要および使用法 (56931)
https://kb.vmware.com/kb/56931?lang=ja

■「ESXi サイドチャネル対応スケジューラの有効化」した場合の性能影響について

「L1 Terminal Fault - VMM」(L1TF - VMM) の軽減策によって VMware が受けるパフォーマンス面の影響の説明 CVE-2018-3646 (55767)
https://kb.vmware.com/kb/55767?lang=ja

CPUに余裕がある環境では影響は数%だが、CPU利用率が70%を超える環境では20%近いアプリケーションの性能低下が見られます。

■ アセスメントについて

上記KB55806の文中に、利用中の環境がどの程度の影響を受けるかアセスメントするツールがKB56931で公開されているので、
事前に調査する場合は以下を参照ください。

HTAware 軽減策ツールの概要および使用法 (56931)
https://kb.vmware.com/kb/56931?lang=ja

※調査と合わせて、「ESXi サイドチャネル対応スケジューラの有効化」をPowerCLIで有効化する手順が説明されています。

このKBに添付されているZIPフィアルを解凍し、PowerCLIのモジュールとして追加する事で実行しますが、色々とソースを読むと勉強になるPowerShellスクリプトなのでお勧めです。

2018年8月28日火曜日

vSphere6.7U1と vSAN 6.7U1の発表

ラスベガスで開催中のVMworld 2018でvSphere 6.7u1が正式に発表され、公式ブログなどにも情報が出てきました。個人的に気になったものを拾ってみました。

vSphere 6.7u1関連の公式Blog
vSAN 6.7u1関連の公式Blog
VMworld 2018のセッション動画は以下URLに順次公開が始まっているようです。
それぞれ、個人的に気になる機能が強化されていましたので、実際に触ってみるのが楽しみです。
リリース時期に関しては
In conjunction with the announcement of vSphere Platinum we also have announced vSphere 6.7 Update 1 (note: general availability will be later this year).
とあるので、もう少し後になりそうです。

気になる強化された機能はざっと以下になります。
  • vSphere Client(HTML5)の強化
    以下のように、すべての管理機能がHTML5のvSphere Clientに統合されたようです。 
All administrative functions have now been completed for the vSphere Client
  • クラスタ クイックスタート(Cluster Quickstart)
    今までのようにHA、DRS、vSAN、vDSなど機能ごとに有効にして、設定をしていかなければならなかったvSAN Ready Nodesのセットアップも、6.7u1で実装される Cluster Quickstart で VxRailなどのHCIアプライアンスに近いクイックセットアップが実現できそうです。vDSへの移行もサポートしてくれるのは運用のハードルが大幅に下がりそうです。
    クイックスタート機能はESXiホストの拡張時も活用できるようなので、これもVxRailのようにESXiがインストールされたホストをネットワークに接続すれば数分でvSANクラスタへの組み込みが完了してくれるようです。
    • vSphere HA、vSphere DRS、vSANなどのクラスタサービスの設定
    • ホストの追加 - 複数のホストの同時追加
    • vSAN展開タイプの指定
    • vDSを含むネットワーク構成
    • ディスクグループの設定
    • 重複排除と圧縮/暗号化などのデータサービスの設定
This configuration includes HA & DRS, Enhanced vMotion Compatibility (EVC), a vSAN datastore, and networking including a Virtual Distributed Switch (VDS). With Cluster Quickstart you can go from zero to fully functioning cluster in a matter of minutes. And, when it is time to expand the cluster, there is a simple workflow to add new hosts and configure them using the cluster settings used during initial setup.
This new workflow also includes a cluster validation that can be used to ensure all settings have been properly configured on all hosts and will report any discrepancies.
  • Update Managerの機能拡張
    Update ManagerでもvSANクラスタの更新時にコントローラドライバ、ファームウェアの更新を適切に実施してくれるように機能が改善されました。
  • vSANキャパシティレポートの改善
  • vSANでTRIM / UNMAPサポート
    地味にこのTRIM / UNMAPのサポートが長期的なvSANデータストアの運用では嬉しい機能実装と考えています。
  • サポート診断の機能強化
HTML5のvSphere Clientがメインになる事で、恐らくそれに合わせてくるVxRail 4.7も新しいUIで機能を実装してくると思われますし、
vSAN Ready Nodes自体も、VxRailに負けないくらいの自動化機能が標準で利用できるようになるのはとても面白そうです。

vSphere Platinum、その他のアップデートはもう少し情報を精査してからまとめたいと思います。

2018年8月23日木曜日

Cheero Power Deluxe 20100mAh のレビュー

少し前ですが、5月末にモバイルバッテリーのCheero Power Deluxe 45W 20100mAh(CHE-094)を購入したのでご紹介。

Cheero Power Deluxe 45W 20100mAh(CHE-094)

元々、USB Type-cコネクタで充電するThinkpad X1 Carbon 2017を外出先で充電可能な大容量バッテリーが欲しいと思い探していたので、この製品を購入しました。

ほぼ同時期に発売された「Lenovo USB Type-C ノートブックパワーバンク(14000mAh)」と悩んだのですが、パワーバンクの売りであると思った「パワーバンクを充電しながらPCにも給電可能」というのが、Thinkpadの角コネクタで充電しながら、Type-cでPCへ出力という仕組みだったので、今さら各コネクタのACアダプタ持ち歩かないし、Cheeroに比べて容量少なくて値段は3倍だったので却下となりました。
ちなみに私が購入した時はAmazonで4,480円でした。

以下、使ってみた感想。

パッケージはシンプル。

同梱物は45cmくらいのType-C - Type-C のケーブルのみ。

起動中のX1 Carbonに接続してみると約45Wで給電されます。

終日開催のセミナーなどに参加して、スマフォでテザリングしながらPCでVDIしていると16時くらいにはどちらもバッテリー残容量が0に近くなりますが、このCheeroがあるとぷらす時間くらい分は充電されるので重宝します。

ThinkpadのType-C 65Wのアダプタで充電すると45W前後で充電されます。2時間もあれば満充電できます。
本体横に記載されている定格は以下の通り。
Input :
  [Type-C PD] 5-20V=45W max
  [Micro USB] 5V=2.1A max
Output:
  [Type-C PD] 5-20V=45W max
  [USB-A] 5V=3A max、9V=2A Auto-IC

満充電に近くなると低速充電になりました。

ACアダプタから充電中のX1 CarbonからType-CケーブルでつないでCheeroを充電しようとしても残念ながら充電はできません。
また、Type-Cの口は一つだけなのでCheeroを充電しながらPCへの給電も不可です(Type-Aから携帯電話などの充電は可能)。

コネクタ接続口はこの様な感じ。
In専用のマイクロUSBの口が不要だからType-Cの口を2つ揃えて欲しかった。

充電中、給電中は側面の青色LEDが点灯、点滅。

2018年8月2日木曜日

8/1からvSphere ESXiのバージョンの呼称が変わった? (8/2修正:イメージ名が併記されるように修正されまました)

※日本時間8/2の夜にKBが再修正され、バージョン名(ESXi 6.7 EP 02a)、リリース名(ESXi670-201807001)、Build番号が併記されるようになったようです。

vSphere 6.7.0c、6.0u3gがリリースされたのでパッチなどをDLしつつ、バイナリのBuildバージョンと名称のマッチングを確認しようとしたところ、
どうも昨日のKBの更新で、ESXiのパッチリリースに関してはGAバージョン、Updateバージョン以外のパッチバージョンは、「6.7.0c」や「6.0u3g」などの名称を無くし、My Vmwareからダウンロードした際のイメージ名称である「ESXi670-201807001」「ESXi600-201807001」などに呼称を変更したようです。 ※ 8/2に併記されるように変更されていました。

8/2更新のKB
Build numbers and versions of VMware ESXi/ESX
https://kb.vmware.com/kb/2143832

個人的にはMy VMwareのパッチDLページ(https://my.vmware.com/jp/group/vmware/patch#search) で落としたファイル名がそのまま紐づくので、ファイル名 - Build番号 - バージョン名称 と三つを管理しなくてよくなり、かつ日付ベースのバージョン呼称がKBに掲載され、間違い難くなったかなと思います。


ちなみに、8/1更新のKBは以下のような表組で、バージョン名称が削除されていました。
焦ってBlogに一報を載せた次第です。


vCenterなどは従来通り、「6.7.0c」などの名称なので、8/2の更新でESXiがどのvCenterバージョンと同等か判断しやすくなりました。
Build numbers and versions of VMware vCenter Server
https://kb.vmware.com/kb/2143838



Vmware全製品のBuild番号とバージョンの整合は以下のKB参照
Correlating build numbers and versions of VMware products
https://kb.vmware.com/kb/1014508

ちなみに、ここ一年近く更新されていない、日本語版のKBの方は従来の名称のみが掲載されています。
VMware ESXi/ESX のビルド番号とバージョン




お客様向けの導入成果物やパラメータシートに決め打ちの記載がある場合は修正が面倒ですね..

過去30日でアクセスの多い投稿